OCUDU 26.10 apporte la 5G par satellite et un test d’interopérabilité plus exigeant à l’Open RAN

OCUDU 26.10 est le type de version open source qu’il est facile de mal interpréter. Les fonctions mises en avant semblent répondre en même temps à plusieurs problèmes difficiles des télécoms : connectivité par satellite, MIMO de niveau supérieur, gestion des faisceaux, positionnement, fronthaul ouvert et sécurité renforcée. Le projet passe aussi d’une première publication publique à un calendrier prévisible, en avril et en octobre, sous gouvernance de la Linux Foundation.

Cela rend cette version importante. Cela n’en fait pas pour autant un remplacement prêt à l’emploi d’un réseau d’accès radio commercial. OCUDU 26.10 doit plutôt être compris comme une implémentation publique sérieuse d’une pile 5G CU/DU, avec suffisamment de nouvelles capacités pour justifier des expérimentations chez les chercheurs en télécoms, les concepteurs de réseaux privés et les développeurs d’équipements. Rien ne permet de conclure que les difficultés centrales de l’interopérabilité Open RAN ont disparu.

La question utile est donc plus précise que celle de savoir si OCUDU est prêt pour la production. Quelles parties de la version une équipe techniquement équipée peut-elle tester dès maintenant, quelles hypothèses de matériel et de synchronisation les sous-tendent, et quelles fonctions nécessitent encore une validation indépendante de bout en bout ?

Ce qui change dans OCUDU 26.10

Les notes de version officielles recensent un ensemble étendu d’ajouts. Le plus important est la prise en charge du Release 17 pour les réseaux non terrestres, ou NTN. Cette version ajoute également une prise en charge de base du Split 7.2b O-RAN dans l’implémentation Open Fronthaul, la gestion d’antennes 8T8R, la gestion des faisceaux des Releases 15 et 16 pour FR1 et FR2, le positionnement fondé sur l’angle, les signaux de référence de positionnement en liaison descendante, l’accès aléatoire en deux étapes, la présélection de l’ordonnancement montant, les allocations configurées, le regroupement de TTI, la répétition de PUCCH et la prise en charge de DTLS.

L’annonce de la Linux Foundation regroupe ces changements autour de trois thèmes pratiques : davantage de choix de déploiement, de meilleures performances radio et une latence réduite, ainsi que des fonctions supplémentaires de positionnement et de sécurité. La description est juste, mais les notes détaillées comptent davantage que ce résumé, car elles exposent le niveau de maturité de chaque fonction.

Plusieurs entrées sont explicitement présentées comme une prise en charge de base ou comme n’ayant pas encore été testées avec un O-RU. Cette formulation n’est pas une note secondaire. Dans un RAN distribué, une fonction peut compiler, réussir ses tests unitaires et échouer lorsqu’elle rencontre une unité radio donnée, une source d’horloge, un profil de compression, un réseau de transport ou une implémentation de gestion particuliers. Une note de version précisant qu’une fonction n’a pas été testée de bout en bout indique à l’évaluateur par où commencer ; elle ne promet pas que le travail est terminé.

OCUDU se présente comme un projet gNB 5G open source complet, couvrant le plan de contrôle de l’unité centrale, le plan utilisateur de l’unité centrale et l’unité distribuée. La documentation officielle indique qu’il vise les déploiements commerciaux et la recherche, fonctionne sur du matériel x86 et ARM généraliste, suit les spécifications 3GPP et O-RAN, et est distribué sous licence BSD 3-Clause. Le dépôt est hébergé sur GitHub comme miroir, tandis que les contributions se déroulent dans le dépôt GitLab du projet.

Cette structure compte parce qu’OCUDU n’est pas seulement un démonstrateur de protocoles. Sa valeur se situe à la frontière entre les normes, les systèmes temps réel, le matériel RF et les outils de déploiement. Plus le projet expose publiquement cette frontière dans son code, plus il devient utile aux équipes qui doivent inspecter, modifier ou valider un RAN au lieu de le consommer comme une appliance fermée.

Pourquoi le NTN du Release 17 attire l’attention

Les réseaux non terrestres étendent les procédures 5G à des liaisons impliquant des satellites ou d’autres plateformes aéroportées. La liaison radio n’est plus un trajet court et relativement stable entre un terminal et une station de base proche. Le délai de propagation, la synchronisation, les effets Doppler, le déplacement du satellite, la géométrie de couverture et l’emplacement de la passerelle deviennent des éléments du système. Le logiciel doit tenir compte de ces conditions sans faire comme si une cellule satellite se comportait comme une cellule macro urbaine ordinaire.

OCUDU avait déjà documenté la prise en charge du NTN GEO dans des contenus antérieurs. L’étape 26.10 élargit le périmètre annoncé du projet au NTN du Release 17, et les tutoriels décrivent un mode NTN utilisant les éphémérides SIB19 ainsi que la prise en charge de la synchronisation pour des scénarios GEO et LEO. Le tutoriel NTN est donc plus utile à un futur testeur que le seul titre de l’annonce : il indique qu’un environnement d’essai devra probablement inclure des équipements UE adaptés et un environnement radio soigneusement contrôlé.

C’est ce qui donne à cette version une portée qui dépasse les seuls spécialistes du satellite. Une implémentation ouverte permet aux chercheurs d’examiner la manière dont les hypothèses NTN traversent la configuration, les informations diffusées, la synchronisation et la logique de mobilité. Elle peut servir à des expériences difficiles à mener avec un système fournisseur dont les détails d’implémentation ne sont pas accessibles. Une équipe travaillant sur la connectivité résiliente, des sites industriels isolés, des liaisons maritimes ou des réseaux hybrides terrestres et satellitaires peut aussi utiliser un CU/DU ouvert comme point de comparaison entre architectures.

Le code ouvert ne supprime toutefois pas les contraintes physiques. Un développeur peut exercer une partie du logiciel avec une simulation ou un chemin radio virtuel, mais une évaluation réaliste nécessite un UE, une interface radio ou un émulateur, une synchronisation adaptée, un cœur 5G et un chemin de transport reproduisant les conditions visées. La documentation du projet cite du matériel Amarisoft pour certains tutoriels NTN. Cela rappelle que la démonstration la plus intéressante peut encore dépendre de composants spécialisés ou propriétaires autour du logiciel ouvert.

Il existe une autre limite. La prise en charge d’une fonction standard ne signifie pas la prise en charge de toutes les orbites satellites, configurations de spectre, catégories de terminaux ou séquences de mobilité couvertes par cette norme. Le NTN du Release 17 est un domaine technique vaste. L’interprétation responsable d’OCUDU 26.10 est qu’il fournit une surface d’implémentation publique pour travailler sur le NTN, et non qu’il a résolu la 5G par satellite en tant que catégorie de produit.

Ce que changent le 8T8R et la gestion des faisceaux

Le travail sur le 8T8R est moins visible pour le grand public, mais peut être plus directement pertinent pour les expériences radio terrestres. Une configuration 8T8R utilise huit voies d’émission et huit voies de réception. Un plus grand nombre de ports d’antenne peut offrir un contrôle supplémentaire sur le précodage et les diagrammes de faisceaux, mais le résultat dépend de l’unité radio, de l’étalonnage, des conditions du canal, des codebooks, de la capacité de traitement et du nombre de couches spatiales effectivement utilisées. Huit ports ne signifient pas automatiquement huit flux de données indépendants.

La demande de fusion publique consacrée à cette fonction explique que l’implémentation autorise huit ports tout en plafonnant encore à quatre le nombre maximal de couches par mot de code au stade décrit. Elle mentionne également la configuration CSI, le précodage descendant, la configuration PDSCH, le dimensionnement des tampons HARQ et la gestion de la charge utile PUCCH. Ces détails sont utiles, car ils montrent qu’une fonction liée au nombre d’antennes n’est pas un simple interrupteur. Elle touche aux hypothèses de l’ordonnanceur, aux retours, aux tampons, à la signalisation de contrôle et à l’interface radio.

OCUDU 26.10 inclut aussi la prise en charge de base des rapports et retours CSI avec codebook de type II, ainsi que la gestion des faisceaux des Releases 15 et 16 pour FR1 et FR2. La gestion des faisceaux regroupe les procédures servant à découvrir, mesurer, sélectionner et conserver des faisceaux adaptés. Dans un système réel, cela implique la signalisation de contrôle, les signaux de référence, les mesures, la mobilité et la coordination entre l’unité distribuée et l’unité radio. Un chemin de code capable d’exécuter la procédure est nécessaire, mais son utilité dépend du comportement de toute la chaîne lorsque les conditions du canal évoluent.

C’est l’une des raisons pour lesquelles il faut lire le jalon du projet en parallèle des notes de version. Le jalon v26.10 présente le travail dans un langage plus orienté ingénierie : Open Fronthaul 7.2 de catégorie B, CSI de type II, 8T8R, gestion des faisceaux, positionnement fondé sur l’angle, signaux de référence de positionnement descendants, accès aléatoire en deux étapes, ordonnancement montant, allocations configurées, regroupement de TTI, répétition de PUCCH, DTLS et NTN du Release 17. Il fournit aussi une trace visible des problèmes et des demandes de fusion, au lieu de présenter la liste de fonctions comme une surface produit achevée.

Pour un laboratoire, c’est une bonne raison d’essayer la version. Le code et l’historique des problèmes peuvent aider à identifier le sous-système responsable d’un échec. Pour un opérateur, c’est aussi un rappel de garder le plan d’intégration explicite. Le bon test ne consiste pas seulement à vérifier qu’une cellule démarre. Il faut déterminer si l’O-RU choisi, le dispositif d’horloge, la largeur de bande, la numérologie, les capacités de l’UE et le profil de trafic produisent un comportement stable sous charge.

Le Split 7.2b est utile précisément parce qu’il n’est pas encore banal

Dans les discussions sur l’Open RAN, l’interopérabilité sert souvent de raccourci pour désigner la promesse qu’une unité distribuée d’un fournisseur puisse fonctionner avec une unité radio d’un autre. L’interface de fronthaul ouvert est au cœur de cette promesse. Dans un découpage fonctionnel 7.2x, une partie du traitement de la couche physique est séparée entre l’O-DU et l’O-RU, tandis que des échantillons radio et des informations de contrôle traversent un réseau de fronthaul. Cela peut élargir l’écosystème des fournisseurs, mais rend aussi opérationnelles les questions de synchronisation, de transport de paquets, de compression et de compatibilité des profils.

L’O-RAN Alliance publie des spécifications pour des interfaces et des fonctions destinées à favoriser des réseaux d’accès radio ouverts, intelligents et interopérables. La distinction entre une spécification et une intégration multi-fournisseur fonctionnelle est essentielle. La spécification définit le contrat. Les implémentations doivent encore s’accorder sur les profils, les fonctions optionnelles, le comportement de gestion, la synchronisation, les limites de performance et la couverture des tests.

OCUDU 26.10 ajoute une prise en charge de base du Split 7.2b. Les notes de version officielles précisent qu’il n’a pas encore été testé avec un O-RU. Cette phrase doit guider l’évaluation de la fonction. Elle est utile aux développeurs qui doivent examiner ou étendre l’interface. Elle ne permet pas de supposer qu’une unité radio 7.2b quelconque se connectera avec succès.

La différence entre 7.2a et 7.2b a également des conséquences pratiques. La localisation de fonctions telles que le précodage détermine ce que l’O-DU et l’O-RU doivent connaître, la quantité d’informations traversant le fronthaul et la manière dont l’unité radio participe à la formation des faisceaux. Les contenus techniques publics sur 7.2x distinguent généralement les catégories A et B autour de cette localisation du précodage. Une équipe qui passe d’une configuration 7.2a à 7.2b doit s’attendre à davantage qu’une modification de fichier de configuration. Elle doit vérifier les profils pris en charge, la compression, les messages du plan de contrôle, la synchronisation et le comportement de l’unité radio.

La documentation publique existante du projet va dans le même sens. Les contenus de fonctions actuellement publiés par OCUDU listent le Split 7.2a via sa bibliothèque Open Fronthaul interne, tandis que les notes de version 26.10 décrivent le 7.2b comme un ajout de base. Cette transition fait de la version 26.10 un test de compatibilité utile pour l’écosystème, mais signifie aussi qu’elle doit être évaluée avec du matériel précisément identifié et un plan de test reproductible.

Une première expérience raisonnable utiliserait un O-RU connu, une bande et une largeur de bande fixes, une configuration documentée d’horloge et de synchronisation, ainsi qu’un test de trafic reproductible entre les différentes compilations. Il faut capturer les paquets de fronthaul et les messages de contrôle, puis enregistrer la charge CPU, les pertes de paquets, les erreurs de synchronisation, la stabilité de l’attachement et le débit. En cas d’échec, l’objectif est d’identifier le contrat qui échoue, non de déclarer toute l’architecture viable ou défaillante.

Le positionnement est une deuxième histoire cachée dans cette version

OCUDU 26.10 ajoute le positionnement fondé sur l’angle et la génération de signaux de référence de positionnement en liaison descendante. Ces capacités annoncent un RAN capable de fournir autre chose que de la connectivité. Les mesures radio peuvent contribuer à des estimations de localisation, au suivi industriel, à la surveillance d’actifs, aux services d’urgence et à des applications conscientes du réseau. Dans un réseau privé, le positionnement peut rester utile lorsque la navigation par satellite est indisponible ou peu fiable.

Les notes de version du projet emploient encore une formulation prudente : les fonctions de positionnement sont décrites comme une prise en charge de base et n’ont pas encore été testées de bout en bout avec un O-RU. Cette réserve est particulièrement importante pour le positionnement, car le résultat dépend de la géométrie des antennes, de l’étalonnage, de la synchronisation, des trajets multiples, de la qualité des mesures et des algorithmes transformant les observations radio en estimation de position.

Un signal de référence de positionnement peut exister dans la pile sans produire une localisation utile dans un entrepôt, un canyon urbain ou un hall industriel. Il faut donc séparer trois questions. Le réseau peut-il configurer et transmettre les signaux concernés ? L’UE et l’unité radio peuvent-ils les mesurer de manière cohérente ? Le système complet atteint-il un niveau de précision et de disponibilité correspondant à l’application visée ? OCUDU 26.10 semble répondre à la première question et ouvre le travail sur les deux suivantes.

Cela reste significatif. Les implémentations ouvertes permettent aux chercheurs d’inspecter les chemins de synchronisation et de mesure, de comparer des algorithmes et de construire des bancs de test reproductibles. Elles peuvent aussi faciliter l’identification de la frontière entre un problème de protocole, un défaut d’étalonnage radio et une hypothèse de positionnement au niveau applicatif. Les systèmes fermés peuvent fournir un résultat plus abouti, mais rendent ce diagnostic plus difficile.

Le travail sur la sécurité dépasse la case à cocher

La version inclut la prise en charge de DTLS pour les communications sécurisées, des travaux d’amélioration de la sécurité et de la résilience, ainsi que des affirmations documentaires concernant les tests de sécurité O-RAN. L’annonce de la Linux Foundation mentionne également le fuzzing continu, la participation à OSS-Fuzz et une validation indépendante. Ce sont des signaux positifs, car une pile réseau qui traite le trafic de contrôle, le trafic utilisateur et les interfaces de gestion possède une surface d’attaque étendue.

La prise en charge de la sécurité doit néanmoins être lue comme une question de processus et d’architecture, pas comme un label. DTLS peut protéger un canal de communication, mais ne décide pas qui peut l’établir, comment les clés sont provisionnées et renouvelées, quels terminaux sont approuvés, ce qui se passe à l’expiration des certificats, ni comment un déploiement isole les trafics de gestion, de contrôle et du plan utilisateur. Le fuzzing peut révéler des catégories de défauts dans les parseurs et les machines à états, mais ne prouve pas qu’un déploiement est correctement configuré.

La documentation de sécurité et de déploiement doit être lue avec le code source et les rapports de test du projet avant toute installation sur un réseau exposé. Une évaluation sérieuse doit inventorier chaque interface : connexions au cœur de réseau, chemins F1 ou CU/DU internes, connexions E1 entre composants CU, fronthaul O-RAN, API de gestion, métriques, interfaces de conteneurs et éventuels chemins de commande à distance. Il faut ensuite tester l’authentification, les défaillances de certificats, les messages malformés, l’épuisement des ressources, la séparation des privilèges et la journalisation.

La licence permissive BSD-3-Clause est intéressante pour les usages commerciaux et de recherche, mais une licence ne constitue pas une garantie opérationnelle. Le dépôt précise que certaines parties peuvent implémenter des spécifications 3GPP et être soumises à des exigences de licence supplémentaires. Une entreprise qui prévoit de livrer un produit doit effectuer sa propre revue juridique, suivre les composants tiers et conserver les mentions du projet. Elle doit aussi examiner précisément le code et l’état des tests pour les fonctions qu’elle compte distribuer, plutôt que de traiter la licence principale du projet comme une réponse complète en matière de conformité.

Qui devrait essayer OCUDU 26.10

Le public le plus adapté est une équipe qui sait déjà construire et exploiter un environnement de test 5G sous Linux. Le guide d’installation d’OCUDU demande un système d’exploitation basé sur Linux avec prise en charge d’un noyau temps réel. La compilation utilise CMake et C++17, avec notamment SCTP, yaml-cpp, mbedTLS et une bibliothèque FFT parmi les dépendances. Le guide indique Ubuntu 22.04 ou ultérieur, Fedora et Arch comme chemins d’installation pris en charge, tandis que les performances temps réel réelles dépendent de l’hôte, du processeur, de la carte réseau, de la configuration du noyau et de l’installation radio.

Les chercheurs qui travaillent sur le NTN, la gestion des faisceaux, le positionnement ou le fronthaul ouvert peuvent utiliser cette version comme base publique pour leurs expériences. Les équipes de réseaux privés peuvent examiner l’intégration d’une pile CU/DU avec un cœur 5G, un O-RU et un système de gestion. Les fabricants de matériel peuvent exploiter le code et l’historique des problèmes pour valider leurs hypothèses sur les interfaces. Les étudiants et ingénieurs qui apprennent l’architecture 5G peuvent également en tirer profit, à condition de considérer le projet comme un système à comprendre, et non comme un binaire à installer puis à oublier.

Les tutoriels du projet couvrent davantage qu’une simple compilation. Ils incluent un réseau complet en split 8 avec srsUE et Open5GS, des tests de handover avec des UE commerciaux, la configuration NTN, l’intégration avec un Near-RT RIC, DPDK, l’accélération matérielle, des images de conteneurs, un déploiement Kubernetes et l’optimisation des performances. Cette étendue est utile parce qu’elle relie le logiciel à l’écosystème environnant. Elle révèle aussi le coût d’une évaluation réaliste : certains tutoriels nécessitent un USRP, une carte réseau compatible DPDK, un accélérateur, du matériel de synchronisation, un O-RU compatible ou un UE commercial.

OCUDU est un choix moins évident pour une équipe qui recherche un produit 5G privé prêt à l’emploi, avec support fournisseur, combinaisons matérielles certifiées, plan de gestion clé en main et objectif de performance contractuel. Le logiciel peut entrer dans un tel produit, mais la charge d’intégration et de vérification ne disparaît pas parce que le code est ouvert. La possibilité de modifier le code crée même une responsabilité supplémentaire : maintenir un ensemble de correctifs, suivre les changements en amont, reproduire les compilations et décider quels résultats de test suffisent au regard du profil de risque du déploiement.

Un plan d’évaluation pratique

Il faut commencer par choisir une question. Tester en même temps toutes les fonctions de la version 26.10 produirait surtout une grande quantité de bruit. Un laboratoire intéressé par les liaisons satellites devrait commencer par le tutoriel NTN et un scénario défini de synchronisation et d’éphémérides. Une équipe qui évalue l’interopérabilité avec une unité radio devrait commencer par un seul O-RU et le Split 7.2b, plutôt que par un ensemble d’équipements non vérifiés. Un chercheur en positionnement devrait d’abord vérifier la génération et la mesure des signaux avant de promettre un objectif de précision au niveau applicatif.

Il faut figer la révision exacte du code et consigner le compilateur, le noyau, le processeur, la carte réseau, le FPGA ou l’accélérateur, l’interface RF, l’UE, le cœur de réseau et la configuration. Les journaux de compilation et les fichiers de configuration doivent être conservés avec le résultat du test. Les systèmes télécoms open source sont particulièrement sensibles aux détails de l’environnement ; un résultat impossible à reproduire est difficile à interpréter, même lorsque le code est disponible.

L’évaluation doit ensuite être divisée en couches. Premièrement, exécuter les tests logiciels et les contrôles statiques. Deuxièmement, établir une session stable d’attachement et de plan utilisateur avec la configuration prise en charge la plus simple. Troisièmement, ajouter la fonction étudiée. Quatrièmement, introduire la charge, la mobilité, une variation de synchronisation ou un second composant fournisseur. Cet ordre aide à distinguer un problème du système de base, un problème de fonction et un problème multi-fournisseur.

Pour le Split 7.2b, il faut capturer des mesures fonctionnelles et opérationnelles. Vérifier que l’O-DU et l’O-RU sont d’accord sur les profils et la compression. Contrôler la synchronisation avant d’interpréter le débit. Mesurer les débits de paquets, la latence, la gigue, les pertes et la marge CPU. Répéter le test après un redémarrage et dans des conditions d’altération contrôlées. Une interface qui fonctionne une fois sur une paillasse propre ne constitue pas encore un déploiement interopérable.

Pour le NTN, tester les hypothèses de synchronisation et de mobilité séparément du trafic applicatif. Comparer le comportement attendu et observé lorsque le délai et la géométrie changent. Documenter ce qui est simulé, ce qui est émulé et ce qui passe par un équipement RF ou satellite réel. Cette distinction comptera lorsque quelqu’un citera plus tard le résultat comme preuve d’une préparation au terrain.

Pour la sécurité, construire un modèle de menace avant d’activer l’accès distant. Utiliser la segmentation réseau, le moindre privilège, des identifiants protégés et, lorsqu’ils existent, des artefacts signés ou vérifiés. Traiter les images de conteneurs, les outils auxiliaires, les points d’accès de gestion et les systèmes de supervision comme des éléments de la base informatique de confiance. Examiner les rapports de sécurité du projet et son suivi des problèmes, sans déléguer pour autant l’évaluation finale des risques aux mainteneurs amont.

Alternatives et points de comparaison

OCUDU n’est pas la seule voie open source vers une expérimentation RAN 5G. OpenAirInterface reste un projet de référence important pour les chercheurs et opérateurs qui étudient l’Open RAN et les systèmes 5G. Le projet srsRAN fournit une autre pile CU/DU et d’accès radio open source, accompagnée d’une documentation étendue et de contenus d’intégration matérielle. Le choix entre ces solutions doit dépendre de la combinaison de fonctions et de matériel à tester, non d’un classement général.

La comparaison utile est souvent très ciblée. Quel projet prend en charge la bande et le split visés ? Lequel dispose d’une configuration testée pour l’O-RU choisi ? L’ordonnanceur, l’implémentation PHY ou l’intégration E2 de quel projet correspond à l’expérience ? Quelle est l’activité de la file de problèmes pertinente ? L’équipe peut-elle reproduire une compilation et obtenir de l’aide lorsqu’un problème matériel apparaît ? Une matrice de fonctions vaut moins qu’un chemin testé avec exactement les équipements présents au laboratoire.

La particularité d’OCUDU est de chercher à réunir dans un même projet public une implémentation CU/DU étendue, une gouvernance ouverte, une version d’octobre et des fonctions récentes comme le NTN et le 8T8R. Cela le rend digne d’attention même pour les équipes qui ne l’adopteront pas. Ses choix d’implémentation peuvent servir de point de comparaison avec d’autres piles, et son travail d’intégration public peut montrer les endroits où les normes laissent une marge d’interprétation.

L’alternative à l’évaluation d’une pile ouverte n’est pas toujours un produit commercial. Cela peut être un test de composant plus réduit et contrôlé. Une équipe peut valider un profil Open Fronthaul, un chemin de signaux de positionnement ou une modification de l’ordonnanceur sans construire un réseau à l’échelle d’un opérateur. OCUDU est utile dans ce rôle parce que le code, la documentation et l’historique des problèmes permettent de garder l’expérience proche de l’implémentation.

La véritable portée de cette version

OCUDU 26.10 compte parce qu’il fait entrer le code Open RAN dans une phase plus exigeante. La première publication publique avait établi que le projet pouvait fournir une base CU/DU ouverte et étendue. La version d’octobre pose une question différente : cette base peut-elle absorber la synchronisation satellite, des configurations d’antennes de niveau supérieur, les procédures de faisceaux, le positionnement, les tests de sécurité et des profils de fronthaul supplémentaires sans perdre un processus de développement transparent ?

C’est une histoire plus intéressante que l’affirmation selon laquelle l’open source aurait remplacé l’infrastructure télécom établie. L’Open RAN doit encore gagner la confiance par des tests d’interopérabilité, des mesures de performance, des revues de sécurité, des outils d’exploitation et une maintenance durable. Une licence permissive permet à davantage de personnes d’inspecter le logiciel et de construire dessus, mais elle ne fournit ni étalonnage radio, ni autorisation de spectre, ni synchronisation, ni contrat de support, ni validation de production.

Pour les développeurs, le conseil immédiat est de choisir une fonction de la version 26.10 et de reproduire le chemin documenté par le projet avant de modifier quoi que ce soit. Pour les chercheurs, cette version offre une base plus riche pour des expériences sur le NTN, le positionnement et le traitement radio désagrégé. Pour les opérateurs et les fabricants d’équipements, l’étape suivante devrait être un test d’interopérabilité avec du matériel précisément nommé et des preuves capturées, pas une conclusion générale d’achat.

OCUDU 26.10 est donc prêt à être testé et, dans plusieurs domaines, prêt à servir de support d’apprentissage. Ses propres notes de version indiquent clairement les endroits où il n’est pas encore possible de lui faire confiance sans travail supplémentaire. Cette combinaison — une capacité publique substantielle et des limites visibles — correspond exactement à ce qu’il faut attendre d’un nouveau projet d’infrastructure open source.

Sources

Les faits et le contexte mentionnés ici sont attribués aux notes de version OCUDU 26.10, à la documentation et aux tutoriels OCUDU, au jalon v26.10, à la demande de fusion consacrée aux antennes 8T8R, à l’annonce de la Linux Foundation, aux spécifications de l’O-RAN Alliance, au miroir du dépôt source OCUDU et à la documentation du projet srsRAN. Les liens correspondants sont conservés dans le texte afin de permettre la vérification de chaque point technique.