Description Titre de l'invention : Procédé de gestion d’un réseau d’accès radio et dispositif électronique associé Domaine Technique [0001] La présente invention appartient au domaine général des télécommunications, et notamment des communications sans fil mises en œuvre sur des réseaux de type radio tels que des réseaux mobiles (ex. 4G, 5G, B5G etc.), etc. Elle concerne plus particulièrement un procédé de gestion d’un réseau d’accès radio. Elle concerne également un dispositif électronique comprenant un contrôleur de réseau d’accès radio configuré pour mettre en œuvre un tel procédé. Technique antérieure [0002] Afin de s'adapter à la croissance continue et toujours plus rapide du trafic de données émises par les systèmes de télécommunications sans fil, différentes technologies sont aujourd'hui mises en œuvre, et font encore l'objet de perfectionnements en vue d'une exploitation optimale dans les années à venir. [0003] L’architecture des réseaux de télécommunications sans fil actuellement déployés ou en cours de déploiement est définie par le consortium de standardisation connu sous le nom de 3GPP (Third Generation Partnership Project). C’est le cas notamment des réseaux sans fil dits de deuxième génération (« 2G ou GSM»), de troisième génération (« 3G »), et de quatrième génération (« 4G »). [0004] Jusqu’à la quatrième génération, les architectures de réseau définies par le consortium 3GPP reposent le plus souvent sur des équipements spécifiques, dédiés à des fonctionnalités précises, que ce soit au niveau du réseau d’accès ou du cœur de réseau, notamment en ce qui concerne la transmission de paquets depuis ou à destination d’un terminal mobile. [0005] Le manque de flexibilité et d’évolutivité inhérent à ce type d’architecture a conduit le consortium 3GPP à envisager l’adoption d’architectures plus flexibles pour la génération de réseaux sans fil dite « 5G », afin de pouvoir répondre
rapidement à des demandes extrêmement diverses en termes de trafic et/ou de qualité de service. [0006] Pour répondre à ces contraintes extrêmement diverses, la 5G s’appuie notamment sur le découpage des fonctions réseaux en services, et sur la virtualisation de ces fonctions réseaux. La virtualisation des fonctions réseaux consiste à déployer des fonctions habituellement remplies par des équipements dédiés et spécifiques sur des serveurs génériques situés dans des centres de données (« data center » selon la terminologie anglo-saxonne). Ces fonctions sont alors mises en œuvre sous la forme de programmes informatiques pouvant être facilement activés, désactivés et paramétrés en fonction des besoins. Les ressources en mémoire ou capacité de calcul peuvent alors être allouées de manière dynamique. [0007] Les exigences en termes de performances cibles d’un réseau cellulaire 5G ont été définies par la recommandation IMT-2020 de l’Union Internationale des Télécommunications (UIT). De manière plus spécifique, des valeurs théoriques maximales en termes de latence et de débit ont été définies. Cependant, l’architecture actuellement définie par le consortium 3GPP ne permet pas d’obtenir de valeurs de latence et/ou de débit de bout-en-bout (« end-to-end » en anglais), et à fortiori d’adapter la configuration du réseau de télécommunications en fonction de ces valeurs. Exposé de l’invention [0008] La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permet à une application informatique d’un contrôleur du réseau d’accès radio, d’obtenir une valeur représentative d’un paramètre de qualité de service de bout-en-bout déterminée par un module du réseau cœur, de sorte à optimiser la configuration de ce réseau d’accès radio. [0009] À cet effet, et selon un premier aspect, l’invention concerne un procédé de gestion d’un réseau d’accès radio connecté à un réseau cœur, le procédé étant mis en
œuvre par une application informatique d’un contrôleur du réseau d’accès radio et comprenant : − une réception, en provenance d’un module du réseau cœur, dit « module d’évaluation d’un indicateur de performance de bout-en-bout », d’une valeur représentative d’un paramètre de qualité de service de bout-en- bout d’une connexion entre un terminal utilisateur et un module d’entrée du réseau cœur, ou d’une connexion entre le terminal utilisateur et une application accédée par ledit terminal utilisateur et connectée au module d’entrée du réseau cœur au travers d’un réseau de données, ; et, − une gestion du réseau d’accès radio en fonction de la valeur obtenue. [0010] Un critère de performance de bout-en-bout offre comme avantage de refléter de manière fiable les performances d’un réseau. Par ailleurs, les valeurs d’un paramètre de qualité de service de bout-en-bout permettent de quantifier la qualité des données effectivement reçues par le terminal utilisateur. [0011] Comme évoqué ci-après, le module dit « module d’entrée » est notamment configuré pour acheminer des données en provenance du terminal utilisateur à travers le réseau cœur, et est dans ce cas considéré comme un module d’entrée du réseau cœur, du point de vue du terminal. [0012] De manière générale, on considère que les étapes d’un procédé ne doivent pas être interprétées comme étant liées à une notion de succession temporelle. [0013] Dans des modes particuliers de mise en œuvre, le procédé de gestion peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. [0014] Dans des modes particuliers de mise en œuvre, la valeur considérée peut être représentative d’un état courant du paramètre de qualité de service ou d’une prédiction. [0015] Ainsi, par exemple, dans des modes particuliers de mise en œuvre, ledit paramètre correspond à une latence ou à un débit, et la valeur est représentative d’un état courant de la latence ou du débit de la connexion.
[0016] Cette caractéristique offre l’avantage de permettre à l’application informatique de contrôler le réseau d’accès radio en temps réel. [0017] Dans des modes particuliers de mise en œuvre, ledit paramètre correspond à une latence ou à un débit, et la valeur est représentative d’une prédiction de la latence ou du débit de la connexion, et le procédé selon l’invention comprend en outre une étape de prédiction, par le réseau cœur, de la latence ou du débit de la connexion. [0018] Cette caractéristique offre l’avantage de permettre à l’application informatique d’anticiper une évolution de la latence ou du débit, et à fortiori d’adapter en conséquence la configuration du réseau d’accès radio. [0019] Dans des modes particuliers de mise en œuvre, l’application du contrôleur du réseau d’accès radio comprend un client HTTP, le module du réseau cœur comprend un serveur HTTP, et au moins une fonction d’obtention d’une valeur représentative d’un paramètre de qualité de service mise en œuvre par ledit module est exposée à l’application du contrôleur du réseau d’accès radio au travers d’une interface de programmation d’application (ou API pour « Application Programming Interface » en anglais), et le procédé comprend en outre les étapes suivantes, préalablement à la réception de la valeur : − un accès, par l’application informatique du contrôleur du réseau d’accès radio, à ladite interface de programmation d’application, et, − une transmission, par l’application informatique du contrôleur du réseau d’accès radio et à destination du module du réseau cœur, d’une requête d’obtention d’un résultat d’une application de ladite au moins une fonction d’obtention. [0020] Ces caractéristiques sont avantageuses en ce qu’elles permettent à l’application informatique de communiquer avec le module du réseau cœur, sans avoir à connaître les détails de mise en œuvre des fonctions de ce module. En outre, ces caractéristiques permettent de présenter les fonctions mises en œuvre par le module d’évaluation d’un indicateur de performance comme des services accessibles au travers du protocole HTTP/1 ou HTTP/2. [0021] Dans des modes particuliers de mise en œuvre, le contrôleur du réseau d’accès radio comprend un client HTTP accessible par l’application du contrôleur du réseau
d’accès radio ; le module du réseau cœur comprend un serveur HTTP ; au moins une fonction d’obtention d’une valeur représentative d’un paramètre de qualité de service mise en œuvre par ledit module est exposée au contrôleur au travers d’une interface de programmation d’application, et le procédé selon l’invention comprend en outre les étapes suivantes, préalablement à la réception de la valeur: − un accès, par le contrôleur du réseau d’accès radio, à ladite interface de programmation d’application, − une transmission, par le contrôleur du réseau d’accès radio et à destination du module du réseau cœur, d’une requête d’obtention d’un résultat d’une application de ladite au moins une fonction d’obtention. [0022] Outre les avantages précédemment évoqués, ces caractéristiques sont avantageuses lorsque le contrôleur comprend une pluralité d’applications configurées pour pouvoir accéder au module du réseau cœur (ou à d’autres modules) puisqu’un seul client HTTP embarqué par le contrôleur – et non pas par chaque application de la pluralité – doit alors être implémenté. [0023] Dans des modes particuliers de mise en œuvre, ledit paramètre correspond à une latence ou à un débit, et la au moins une fonction est une parmi : − l’obtention d’une valeur représentative d’un état courant de la latence ou du débit de la connexion entre le terminal utilisateur et le module d’entrée du réseau cœur, − l’obtention d’une valeur représentative d’un état courant de la latence ou du débit de la connexion entre le terminal utilisateur et l’application accédée par ledit terminal utilisateur, − l’obtention d’une valeur représentative d’une prédiction de la latence ou du débit de la connexion entre le terminal utilisateur et le module d’entrée du réseau cœur, et − l’obtention d’une valeur représentative d’une prédiction de la latence ou du débit de la connexion entre le terminal utilisateur et l’application accédée par ledit terminal utilisateur. [0024] Dans des modes particuliers de mise en œuvre, l’interface de programmation d’application (ou API) est de type REST.
[0025] L’utilisation d’une API de type REST (l’acronyme de « REpresentational State Transfer », ou transfert d’état de représentation en français) est avantageuse en ce qu’elle constitue un moyen de communication standardisé utilisant le protocole HTTP entre le client HTTP et le serveur HTTP. [0026] Dans des modes particuliers de mise en œuvre, le procédé de gestion selon l’invention comprend en outre une étape d’obtention, par le client HTTP, d’une adresse IP du serveur HTTP. [0027] Cette étape intervient par exemple dans le cadre d’un mécanisme de découverte au cours duquel l’application informatique du contrôleur consulte un registre de services dans lequel sont enregistrées toutes les instances des services accessibles par cette application (tel qu’un service d’évaluation d’un indicateur de performance de bout-en-bout), ainsi que les moyens d’accéder à ces services. Ces moyens d’accès correspondent par exemple à une adresse web (URL) du serveur HTTP associé audit service, ou à une adresse web de l’API associée audit service. [0028] L’application informatique accède alors à un système de nom de domaine (ou Domain Name System, DNS, selon la terminologie anglo-saxonne) de sorte à obtenir l’adresse IP du serveur HTTP. [0029] Dans des modes particuliers de mise en œuvre, le réseau d’accès radio comprend un premier dispositif émetteur et un deuxième dispositif émetteur distinct du premier dispositif émetteur, et la gestion du réseau d’accès radio comprend : − une adaptation de ressources temporelles et fréquentielles attribuées au terminal utilisateur ; ou − un basculement de connexion du terminal utilisateur du premier dispositif émetteur vers le deuxième dispositif émetteur. [0030] Dans des modes particuliers de mise en œuvre, le réseau d’accès radio comprend au moins un dispositif émetteur, telle qu’une station de base, et la gestion du réseau d’accès radio comprend une détermination de la puissance d’émission du dispositif émetteur en fonction de la valeur obtenue, lorsque des données sont échangées avec ledit terminal utilisateur.
[0031] De cette manière, la puissance d’émission du dispositif émetteur est adaptée en fonction d’une qualité de service attendue par le terminal utilisateur. [0032] Dans des modes particuliers de mise en œuvre, l’étape de gestion comprend une augmentation de la puissance d’émission du dispositif émetteur si la latence a une valeur supérieure à une première valeur seuil, et une diminution de la puissance d’émission du dispositif émetteur si la latence a une valeur inférieure à une deuxième valeur seuil, la deuxième valeur seuil étant inférieure à la première valeur seuil. [0033] Dans des modes particuliers de mise en œuvre, l’étape de gestion comprend une augmentation de la puissance d’émission du dispositif émetteur si le débit a une valeur inférieure à une première valeur seuil, et une diminution de la puissance d’émission du dispositif émetteur si le débit a une valeur supérieure à une deuxième valeur seuil, la deuxième valeur seuil étant supérieure à la première valeur seuil. [0034] Autrement dit, si une qualité de service effectivement fournie au terminal utilisateur est atteinte (e.g., si la valeur de latence de bout-en-bout est inférieure à la deuxième valeur seuil), la puissance d’émission du dispositif émetteur est réduite, et à contrario, si la qualité de service effectivement fournie au terminal utilisateur est inférieure à une qualité de service requise (ou attendue), alors la puissance d’émission du dispositif émetteur est augmentée. [0035] Ainsi, ces caractéristiques permettent de rendre la station de base moins consommatrice en énergie lorsque la qualité de service requise par un terminal utilisateur donné est atteinte (i.e., en étant supérieure à une valeur seuil donnée). Par ailleurs, ces caractéristiques visent à améliorer la qualité de service offerte au terminal utilisateur lorsque cette dernière est inférieure à une certaine valeur seuil. [0036] Dans des modes particuliers de mise en œuvre, la puissance d’émission est adaptée lorsque des unités de ressources temporelles et fréquentielles allouées audit terminal utilisateur sont utilisées. [0037] Cette caractéristique offre l’avantage d’adapter la puissance d’émission d’un dispositif émetteur tel qu’une station de base, pour un terminal utilisateur donné, uniquement lorsque cette station de base et ce terminal utilisateur sont aptes à échanger des données entre eux.
[0038] Dans des modes particuliers de mise en œuvre, le module d’entrée du réseau cœur est configuré comme une passerelle entre le réseau d’accès radio et un réseau de données du réseau cœur. [0039] Dans des modes particuliers de mise en œuvre, le module d’entrée du réseau cœur est un module « fonction de plan utilisateur » (« User Plan Function » selon la terminologie anglo-saxonne). Ce module d’entrée est par exemple conforme au standard 3GPP TS 33.513, version 17.1.0, publiée le 6 janvier 2023. [0040] Dans des modes particuliers de mise en œuvre, le contrôleur du réseau d’accès radio est de type « Near Real Time RIC ». Le contrôleur est alors par exemple conforme à la spécification O-RAN Near-RT RIC Architecture 4.0, “O- RAN.WG3.RICARCH-R003-v04.00”, release 3, publiée en mars 2023. [0041] Dans des modes particuliers de mise en œuvre, l’application du contrôleur est de type « xApp ». Une application de type « xApp » est configurée pour contrôler des fonctionnalités réseau d’accès radio dans un délai court (e.g., inférieur à 1 seconde). Elle est classiquement administrée soit par l’opérateur de télécommunication en charge du réseau de télécommunications, soit par un fournisseur de services. L’application xApp est par exemple conforme à la spécification O-RAN O-RAN Study on Security for Near Real Time RIC and xApps 2.0, “O-RAN.WG11.Security-Near-RT- RIC-xApps-TR.0-R003-v02.00”, version 3, publiée en mars 2023. [0042] Selon un deuxième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de gestion, lorsque ledit programme est exécuté par un processeur. [0043] Selon un troisième aspect, l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré le programme d’ordinateur selon l’invention. [0044] Selon un quatrième aspect, l’invention concerne un dispositif électronique comprenant un contrôleur de réseau d’accès radio configuré pour gérer un réseau d’accès radio connecté à un réseau cœur, le contrôleur incluant une application informatique comprenant : − un module de réception d’une valeur représentative d’un paramètre de qualité de service de bout-en-bout d’une connexion entre un terminal
utilisateur et un module d’entrée du réseau cœur, ou d’une connexion entre le terminal utilisateur et une application accédée par ledit terminal utilisateur et connectée au module d’entrée du réseau cœur au travers d’un réseau de données ; et − un module de gestion du réseau d’accès radio en fonction de la valeur. Brève description des dessins [0045] D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : [0046] [Fig.1] la figure 1 est un exemple de système de communication sans fil dans lequel un procédé de gestion selon l’invention est mis en œuvre ; [0047] [Fig.2] la figure 2 représente schématiquement des sous-modules embarqués dans un module d’évaluation d’un indicateur de performance, selon un exemple de mise en œuvre de l’invention ; [0048] [Fig.3] la figure 3 représente schématiquement une configuration client-serveur du contrôleur et du module d’évaluation d’un indicateur de performance, selon un premier exemple de mise en œuvre de l’invention ; [0049] [Fig.4] la figure 4 représente schématiquement une configuration client-serveur du contrôleur et du module d’évaluation d’un indicateur de performance, selon un deuxième exemple de mise en œuvre de l’invention ; [0050] [Fig.5] la figure 5 représente schématiquement des modules embarqués dans une application d’un contrôleur d’un réseau d’accès radio, selon un exemple de mise en œuvre de l’invention ; [0051] [Fig.6] la figure 6 représente un exemple d’architecture matérielle d’un dispositif électronique comprenant un contrôleur d’un réseau d’accès radio ; [0052] [Fig.7] la figure 7 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé de gestion, selon un exemple de mise en œuvre de l’invention ;
[0053] [Fig.8] la figure 8 représente schématiquement un exemple de requête émise par le contrôleur à destination du module d’évaluation d’un indicateur de performance ; et, [0054] [Fig.9] la figure 9 illustre, sous forme d’ordinogramme, un exemple de gestion d’un réseau d’accès radio comprenant la détermination de la puissance d’émission du dispositif émetteur. Description des modes de réalisation [0055] La figure 1 est un exemple de système de communication sans fil dans lequel un procédé de gestion selon l’invention est mis en œuvre. [0056] Ce système comprend un réseau d’accès radio (RAN) comprenant au moins un dispositif émetteur (gNB), un réseau cœur (CN) connecté au réseau d’accès radio (RAN), et au moins un terminal utilisateur (UE) connecté au réseau d’accès radio (RAN). Le terminal utilisateur (UE) correspond par exemple à un ordinateur portable, un assistant personnel, un objet connecté, ou un téléphone mobile de type « smartphone ». [0057] Dans le présent mode de réalisation, et à des fins de simplification de la description, il est considéré que le système de communication sans fil comporte un unique terminal utilisateur (UE), ainsi qu’un réseau d’accès radio (RAN) comprenant un unique dispositif émetteur (gNB). Il convient cependant de noter qu'aucune limitation n'est attachée au nombre de dispositifs émetteurs (gNB) ou au nombre de terminaux utilisateurs (UE). Les développements qui suivent sont en effet généralisables sans difficulté par l'homme du métier au cas où plus d’un dispositif émetteur (gNB) et un terminal utilisateur (UE) sont considérés. [0058] Le réseau d’accès radio (RAN) et le réseau cœur (CN) appartiennent à un réseau de télécommunications sans fil (non représenté en figure 1) auquel est connecté le terminal utilisateur (UE), et sont aptes à communiquer entre eux dans une bande fréquentielle associée à ce réseau de télécommunications sans fil. Pour la suite de la description, on considère de manière non limitative que ledit réseau de télécommunications est un réseau mobile de type 5G (la cinquième génération de normes de réseau de téléphonie mobile) conforme à la spécification « O-RAN
Architecture Description 8.0 », O-RAN.WG1.OAD-R003-v08.00, version 3, publiée en mars 2023 de l’alliance O-RAN (acronyme de « Open Radio Access Network »). [0059] L’alliance O-RAN est composée d'opérateurs de réseaux mobiles, de fabricants, de fournisseurs et d'organisations de recherche et universitaires travaillant dans le domaine des télécommunications. Elle a défini l’architecture O-RAN qui, tout en s’appuyant sur l’architecture proposée par le consortium 3GPP, vise à faciliter le déploiement de la virtualisation du réseau d’accès radio (RAN). Plus généralement, l’alliance O-RAN vise à définir une architecture de réseau d’accès radio (RAN) qui permet aux équipements et/ou modules logiciels de différents fournisseurs de communiquer. [0060] Il convient toutefois de préciser que l'invention reste applicable à d'autres types de réseau de télécommunications, comme par exemple un réseau mobile 4G (la quatrième génération de normes de réseau de téléphonie mobile), et/ou B5G (acronyme de "Beyond 5G"). [0061] Par ailleurs, l'invention reste également applicable à d'autres types de réseau d’accès radio (RAN) qui s’appuient également sur un découpage des fonctions en services simples indépendants – ou du moins faiblement couplés –, qui communiquent via des interfaces de programmation d’application (API). [0062] De façon générale, une interface de programmation d’application (API) est un ensemble d’outils, de définitions et de protocoles qui facilitent la création de fonctions d’applications configurées pour gérer, ici, le réseau d’accès radio. Une API connecte en quelque sorte un fournisseur de services à des consommateurs de services (e.g., les applications informatiques xApp) sans que ces derniers n’aient à connaître les détails de mise en œuvre des services. [0063] Ainsi, le réseau d’accès radio (RAN) est par exemple conforme au paradigme C- RAN (« Cloud-RAN »). Cette architecture combine la virtualisation et la centralisation des fonctionnalités d’une station de base au moyen de l’informatique en nuage (« cloud computing » selon la terminologie anglo-saxonne). Dans une architecture C-RAN, les unités de traitement (« baseband units » selon la terminologie anglo-saxonne) ne sont plus situées à proximité immédiate de la station
de base, mais sont délocalisées et centralisées au sein d’un ensemble centralisé (« BBU pool » selon la terminologie anglo-saxonne). [0064] En variante, le réseau d’accès radio (RAN) est par exemple conforme au paradigme V-RAN (« Virtual-RAN »). Un réseau d'accès radio virtuel (vRAN) est un réseau d’accès radio (RAN) dont les fonctions réseau sont déployées comme des instances virtualisées situées à différents endroits sur le réseau, par exemple en fonction d’une stratégie de déploiement de l’opérateur de télécommunications. Cette approche offre l’avantage de limiter l’utilisation d’équipements coûteux, et permet de créer des sous-réseaux isolés (tranches de réseau ou « slices » selon la terminologie anglo-saxonne), qui coexistent simultanément sur les mêmes équipements matériels. [0065] Tel qu'illustré par la figure 1, le réseau d’accès radio (RAN) comprend une unité radio (O-RU), une unité distribuée (O-DU) et une unité centrale (O-CU). [0066] L’unité radio (O-RU) est par exemple déployée sur un dispositif émetteur (gNB), et les unités distribuée (O-DU) et centrale (O-CU) sont déployées sur des serveurs distants. En variante, les unités radio (O-RU), distribuée (O-DU) et centrale (O-CU) sont toutes les trois mises en œuvre par le dispositif émetteur (gNB). [0067] L’unité radio (O-RU) est connectée à l’unité distribuée (O-DU) au travers d’une liaison (OFH) dite de « fronthaul », et l’unité distribuée (O-DU) est connectée à l’unité centralisé (O-CU) au travers d’une liaison (OMH) dite de « midhaul ». [0068] Les fonctions réseaux d’une station de base traditionnelle (e.g., d’une station de base conforme à la 4G) sont réparties au sein de ces trois unités en fonction d’une division fonctionnelle des couches OSI qui convient le mieux aux exigences du contexte d’utilisation du réseau de télécommunications. [0069] Cette répartition est par exemple conforme à l’une des options décrites dans la spécification 3GPP « Study on new radio access technology: Radio access architecture and interfaces », TR38.801, release 14, v14.0.0, publiée en avril 2017, chacune ayant ses propres avantages et inconvénients en matière de latence, de débit et de complexité d’implémentation. Ces options sont référencées 1 à 6, 7.1, 7.2, 7.3 et 8.
[0070] Selon un autre exemple, cette répartition est conforme à l’option 7.2 telle que définie par l’alliance O-RAN. L’alliance O-RAN s’est en effet appuyée sur l’option 7.2 définie par le consortium 3GPP pour proposer un découpage de la couche physique basse au niveau de l’unité radio (O-RU), et un découpage de la couche physique haute au niveau de l’unité distribuée (O-DU). Ces découpages sont notamment définis dans la spécification « O-RAN Hardware Reference Design Specification for Outdoor Macrocell with Split Architecture Option 7.2 2.0 », O-RAN.WG7.OMAC- HRD.0-R003-v02.00, release R003 publiée en mars 2023. [0071] L’unité radio (O-RU) est alors configurée pour convertir un signal numérique en un signal radio dans le cas d’une liaison descendante, et inversement dans le cas d’une liaison montante. De manière plus précise, l’unité radio (O-RU) est configurée pour gérer la couche physique basse (e.g., la ou les chaînes RF), le précodage analogique/numérique, le transport des données conformément au protocole eCPRI (acronyme de « evolved Common Public Radio Interface ») et la synchronisation, par exemple conformément au protocole PTP (acronyme de « Precision Time Protocol »),aussi connu sous le nom de IEEE-1588 et IEC 61588. Ce protocole PTP est par exemple défini dans le document "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems," in IEEE Std 1588-2019 (Revision of IEEE Std 1588-2008), pp.1-499, publié le 16 juin 2020. [0072] Toujours conformément à l’option 7.2, l’unité distribuée (O-DU) est configurée pour gérer les sous-couches physiques hautes, MAC (acronyme de l’anglais « Media Access Control ») et RLC (acronyme de l’anglais « Radio Link Protocol »). L’unité centralisé (O-CU) est, quant à elle, configurée pour gérer les sous-couches PDCP (acronyme de l’anglais « Packet Data Convergence Protocol »), SDAP (acronyme de l’anglais «Service Data Adaptation Protocol ») et RRC (acronyme de l’anglais «Radio Resource Control»). La sous-couche MAC est notamment configurée pour établir une correspondance entre les canaux logiques et les canaux de transport. La sous-couche RLC est notamment configurée pour gérer le transfert de paquets PDU (acronyme de l’anglais « Packet Data Unit ») issu de la couche supérieure. La sous-couche PDCP est configurée pour traiter la numérotation de séquences de paquets, la mise en ordre des paquets, et la compression et décompression d’entêtes. Le rôle de la couche
SDAP est notamment de gérer une correspondance entre la qualité de service d’un flux IP et le support radioélectrique. [0073] Tel qu’illustré par la figure 1, le réseau d’accès radio comprend en outre un contrôleur (CTRL) de réseau d’accès radio (RAN) dans lequel sont embarquées une pluralité de fonctions d’application (xApp). Ce contrôleur est par exemple conforme à la spécification O-RAN Near-RT RIC Architecture 4.0, “O-RAN.WG3.RICARCH-R003- v04.00”, release 3, publiée en mars 2023. Il fonctionne alors comme un service par exemple déployé sur un réseau en nuage, et est parfois nommé « near-real time RIC» pour sa capacité à prendre en charge des évènements nécessitant une action dans un délai relativement court (e.g., de 10 millisecondes à 1 une seconde). [0074] Le contrôleur (CTRL) de réseau d’accès radio (RAN) est configuré pour contrôler et optimiser l’efficacité spectrale du réseau d’accès radio, en contrôlant les unités distribuée (O-DU) et centralisée (O-CU) au travers d’interfaces E2. Il intègre pour cela des applications informatiques tierces (xApp) qui automatisent et optimisent ces opérations de contrôle et d’optimisation. Ces applications informatiques (xApp) fonctionnent comme des services, et sont également déployées sur un réseau en nuage. [0075] Le réseau de télécommunications comprend en outre un réseau cœur (CN). Ce réseau cœur (CN) inclut un module d’entrée (UPF) agissant comme une passerelle entre le réseau d’accès radio (RAN) et un réseau de données (DN), tel que l’Internet ou un réseau local/privé. Le réseau cœur (CN) comprend en outre un module (MOD_KPI) d’évaluation d’un indicateur de performance de bout-en-bout décrit en référence à la figure 2. Le module d’entrée (UPF) est connecté à l’unité centralisée (O-CU) au travers d’une interface N3. [0076] Le module d’entrée correspond par exemple au module UPF (pour « User Plane Function ») défini par la spécification 3GPP 23.501 « System architecture for the 5G System (5GS) », version 18.1.0, publiée en avril 2023. [0077] Le module d’entrée (UPF) et le réseau de données (DN) sont connectés au travers d’une interface N6. En outre, au moins une application (cApp) est connectée à ce réseau de données (DN). Il importe ici de noter que bien que la figure 1 illustre le cas où l’application (cApp) n’appartient pas au réseau cœur (CN), il pourrait
également être considéré le cas où ladite application (cApp) est une application dudit réseau cœur (CN). [0078] Tel qu’illustré par la figure 1, le dispositif émetteur (gNB) est une station de base du réseau d’accès radio (RAN). Il peut s’agir indifféremment d’une station de base de type "IAB-donor" connectée au cœur de réseau, ou d’une station de base intermédiaire entre les terminaux utilisateur et une telle station de base de type « IAB-donor ». Une station de base est parfois nommée "nodeB" dans les réseaux 3G, "eNodeB" selon la norme LTE (acronyme de "Long Term Evolution") et "gNodeB" dans les réseaux 5G. [0079] La figure 2 représente schématiquement des sous-modules embarqués dans un module (MOD_KPI) d’évaluation d’un indicateur de performance de bout-en-bout, selon un exemple de mise en œuvre de l’invention. [0080] Tel qu’illustré en figure 2, le module (MOD_KPI) d’évaluation d’un indicateur de performance comprend un sous-module MOD_PROBE configuré pour obtenir une valeur (E2E_KPI#1) représentative d’un état courant de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et le module d’entrée (UPF) du réseau cœur. Pour ce faire, le module d’évaluation (MOD_KPI) est connecté à la sortie du module d’entrée (UPF) et par exemple configuré pour lancer la commande ping() entre le module d’entrée (UPF) et le terminal utilisateur (UE) pour obtenir une valeur de latence, ou la commande iperf() entre le module d’entrée (UPF) et le terminal utilisateur (UE) pour obtenir une valeur de débit. Les commandes ping() et iperf() sont connues de l’homme du métier et ne sont pas décrites en détail ici. [0081] En variante ou en combinaison, le sous-module MOD_PROBE est configuré pour obtenir une valeur (E2E_KPI#2) représentative d’un état courant de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et une application (cApp) connectée au réseau de données (DN) et accédée par ledit terminal utilisateur (UE). Pour ce faire, le module d’évaluation (MOD_KPI) est connecté au serveur sur lequel est déployé l’application (cApp) accédée par le terminal utilisateur (UE), et configuré pour lancer la commande ping() (resp. iperf()) entre ce serveur et le terminal utilisateur (UE) pour obtenir une valeur de latence (resp. de débit).
[0082] Tel qu’illustré en figure 2, le module (MOD_KPI) d’évaluation d’un indicateur de performance comprend en outre un sous-module MOD_PRED configuré pour déterminer une valeur représentative d’une prédiction de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et le module d’entrée (UPF) du réseau cœur et/ou pour déterminer une valeur représentative d’une prédiction de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et l’application (cApp) accédée par ledit terminal. Pour cela, le module MOD_PRED s’appuie sur un historique des valeurs de latence et/ou de débit obtenues par le module MOD_PROBE, et utilise un mécanisme d’apprentissage automatique, tel qu’un réseau de neurones entraîné pour prédire des valeurs futures de latence et/ou de débit, en fonction de valeurs passées et/ou en fonction du type de données qu’il est prévu d’échanger. [0083] La figure 3 représente schématiquement une configuration client-serveur du contrôleur et du module d’évaluation d’un indicateur de performance, selon un premier exemple de mise en œuvre de l’invention. [0084] Tel qu’illustré par la figure 3, le contrôleur (CTRL) de réseau d’accès radio comprend une application informatique (xApp) incluant un client HTTP. Le module MOD_KPI d’évaluation d’un indicateur de performance comprend les deux sous- modules MOD_PROBE et MOD_PRED préalablement décrits, ainsi qu’un serveur HTTP connecté aux modules MOD_PROBE et MOD_PRED et couplé à une interface de programmation d’application (API). [0085] L’utilisation d’une architecture client-serveur entre l’application informatique (xApp) et le module (MOD_KPI) d’évaluation d’un indicateur de performance permet de présenter les fonctions mises en œuvre par ce module MOD_KPI comme des services accessibles au travers du protocole HTTP/1 ou HTTP/2. En outre, l’API permet d’exposer au client HTTP les fonctionnalités offertes par le serveur HTTP (et plus généralement mises en œuvre par le module (MOD_KPI) d’évaluation d’un indicateur de performance), sans que le client HTTP n’ait à connaître les détails d’implémentation de ces fonctionnalités. L’API expose également la manière dont ces fonctionnalités peuvent être accédées (par exemple le nom d’une fonction spécifique à appeler, ainsi que les paramètres d’entrée de cette fonction).
[0086] Ces fonctionnalités correspondent à celles offertes par les modules MOD_PROBE et MOD_PRED : − l’obtention d’une valeur représentative d’un état courant de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et le module d’entrée (UPF) du réseau cœur, − l’obtention d’une valeur représentative d’un état courant de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et l’application (cApp) accédée par ledit terminal utilisateur (UE), − l’obtention d’une valeur représentative d’une prédiction de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et le module d’entrée (UPF) du réseau cœur, et − l’obtention d’une valeur représentative d’une prédiction de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et l’application (cApp) accédée par ledit terminal utilisateur (UE). [0087] La figure 4 représente schématiquement une configuration client-serveur du contrôleur et du module d’évaluation d’un indicateur de performance, selon un deuxième exemple de mise en œuvre de l’invention. [0088] Le module (MOD_KPI) d’évaluation d’un indicateur de performance est identique à celui décrit en référence à la figure 3, et n’est donc pas re-décrit, par souci de concision. [0089] Tel qu’illustré par la figure 4, le contrôleur (CTRL) comprend un client HTTP ainsi qu’une application informatique (xApp) connectée au client HTTP. [0090] Cette configuration s’avère particulièrement avantageuse lorsque le contrôleur (CTRL) comprend une pluralité d’applications (xApp) configurées pour accéder au module du réseau cœur (ou à d’autres modules). En effet, l’implémentation des applications (xApp) est alors simplifiée puisqu’un seul client HTTP est embarqué par le contrôleur (CTRL) − et non pas un client HTTP par application de la pluralité –. [0091] Les API présentées en référence aux figures 3 et 4 sont par exemple de type REST. Comme évoqué précédemment, l’utilisation d’une API de type REST (l’acronyme de « REpresentational State Transfer », ou transfert d’état de représentation en français) est avantageuse en ce qu’elle constitue un moyen de
communication standardisé utilisant le protocole HTTP entre le client HTTP et le serveur HTTP. [0092] La figure 5 représente schématiquement des modules embarqués dans une application d’un contrôleur d’un réseau d’accès radio, selon un exemple de mise en œuvre de l’invention. [0093] Le contrôleur (CTRL) est un composant logiciel. Tel qu’illustré par la figure 5, ce contrôleur (CTRL) de réseau d’accès radio (RAN) comprend une application (xApp) incluant les modules MOD_RX et MOD_PROC dont les fonctionnalités sont décrites en référence à la figure 6. [0094] La figure 6 représente un exemple d’architecture matérielle d’un dispositif électronique (D_CTRL) comprenant un contrôleur d’un réseau d’accès radio. [0095] Tel qu’illustré par la figure 6, le dispositif électronique (D_CTRL) dispose de l’architecture matérielle d’un ordinateur. Ainsi, le dispositif électronique (D_CTRL) comporte, notamment, un processeur 1, une mémoire vive 2, une mémoire morte 3 et une mémoire non volatile 4. Il comporte en outre un module de communication 5. [0096] La mémoire morte 3 du dispositif électronique (D_CTRL) constitue un support d’enregistrement tel que proposé, lisible par le processeur 1 et sur lequel est enregistré un programme d’ordinateur PROG conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de gestion tel que proposé ci- après. Le programme PROG définit un ou plusieurs modules fonctionnels du dispositif, qui s’appuient ou commandent les éléments matériels 1 à 5 cités précédemment, et qui comprennent notamment : − un module MOD_RX de réception d’une valeur représentative d’un paramètre de qualité de service de bout-en-bout d’une connexion entre un terminal utilisateur (UE) et un module d’entrée (UPF) du réseau cœur (CN), ou d’une connexion entre le terminal utilisateur (UE) et une application (cApp) accédée par ledit terminal utilisateur et connectée au module d’entrée du réseau cœur au travers d’un réseau de données (DN). Dans la suite de la description, on considère comme paramètres de qualité de service de bout-en-bout, une latence ou un débit. Toutefois,
l’invention peut s’appliquer à d’autres paramètres de qualité de service ; et − un module MOD_PROC de gestion du réseau d’accès radio (RAN) en fonction de la valeur. [0097] Par ailleurs, le dispositif électronique (D_CTRL) peut encore comporter d’autres modules, notamment pour mettre en œuvre des modes particuliers du procédé de gestion, comme cela est décrit plus en détail ultérieurement. [0098] La figure 7 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé de gestion, selon un exemple de mise en œuvre de l’invention. [0099] Tel qu’illustré par la figure 7, le procédé de gestion comprend une première étape S100 d’obtention, par l’application informatique (xApp) du contrôleur (CTRL) d’un moyen d’accès au module MOD_KPI d’évaluation d’un indicateur de performances. [0100] Cette étape intervient par exemple dans le cadre d’un mécanisme de découverte au cours duquel l’application informatique (xApp) consulte un registre de services dans lequel sont enregistrées toutes les instances des services accessibles par cette application informatique (xApp), tel qu’un service d’évaluation d’un indicateur de performance de bout-en-bout mis en œuvre par le module MOD_KPI, ainsi que les moyens d’accéder à ces services. Ces moyens d’accès correspondent par exemple à une adresse web (URL) du serveur HTTP associé audit service, ou à une adresse web de l’API associée audit service. [0101] L’application informatique (xApp) accède alors à un système de nom de domaine (ou Domain Name System, DNS selon la terminologie anglo-saxonne) de sorte à obtenir l’adresse IP du serveur HTTP. [0102] Le procédé de gestion comprend en outre une étape S110 au cours de laquelle, l’application informatique (xApp) transmet, à destination du module MOD_KPI d’évaluation, une requête REQ_API visant à obtenir la liste des fonctions mises en œuvre par ce module MOD_KPI d’évaluation d’un indicateur de performance. [0103] Cette requête est reçue lors d’une étape S200 par le serveur HTTP du module MOD_KPI d’évaluation, qui, en retour, transmet lors d’une étape S210 une réponse RESP_API à destination de l’application informatique (xApp). Cette réponse
RESP_API comprend par exemple la liste des fonctions exposées à cette application informatique (xApp), et la manière dont ces fonctions peuvent être accédées (par exemple le nom d’une fonction spécifique à appeler, ainsi que les paramètres d’entrées de cette fonction). Cette réponse RESP_API est reçue par l’application informatique (xApp) lors d’une étape S120. [0104] Le procédé de gestion comprend en outre une étape S130 au cours de laquelle l’application informatique (xApp) transmet, à destination du module MOD_KPI d’évaluation, une requête REQ_F visant à obtenir le résultat de l’application d’une des fonctions exposées par l’API et listées dans la réponse RESP_API. La figure 8, décrite ci-après, illustre un exemple de requête REQ_F. Cette requête REQ_F est reçue par le module MOD_KPI lors d’une étape S220, puis analysée lors d’une étape S230 afin de vérifier si la syntaxe employée est conforme à celle attendue. [0105] Si la syntaxe employée n’est pas conforme, un message FAIL indiquant qu’une erreur de syntaxe a été commise est transmis par le module MOD_KPI d’évaluation à destination de l’application lors d’une étape S240, et reçu par cette application lors d’une étape S140. [0106] Si la requête est correctement formée, une étape S250 est mise en œuvre par le module MOD_KPI au cours de laquelle il est déterminé si c’est une prédiction ou un état courant d’un indicateur de performance qui est requis par l’application informatique (xApp). [0107] S’il s’agit d’un état courant, l’étape S260 est mise en œuvre par le module MOD_PROBE du contrôleur CTRL. Lors de cette étape S260, une valeur représentative d’un état courant de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et le module d’entrée (UPF) du réseau cœur ou de la connexion entre le terminal utilisateur (UE) et l’application (cApp) accédée par le terminal utilisateur est déterminée. [0108] De manière plus particulière, si la requête REQ_F vise à obtenir une valeur représentative d’un état courant de la latence (resp. du débit) de la connexion entre le terminal utilisateur (UE) et le module d’entrée (UPF) du réseau cœur, une commande de mesure de latence (resp. de débit) telle que la commande ping() (resp. iperf()) est appliquée entre le terminal utilisateur (UE) et le module d’entrée (UPF)
du réseau cœur. Les commandes ping() et iperf() sont des commandes connues de l’homme du métier et ne sont pas décrites davantage ici. [0109] En variante, si la requête REQ_F vise à obtenir une valeur représentative d’un état courant de la latence (resp. du débit) de la connexion entre le terminal utilisateur (UE) et l’application (cApp) accédée par ce terminal utilisateur, une commande de mesure de latence (resp. de débit) telle que la commande ping() (resp. iperf()) est appliquée entre le terminal utilisateur (UE) et le serveur sur lequel est déployé l’application (cApp). [0110] Ainsi, en référence à la figure 1, la valeur ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ représentative de la latence de bout-en-bout entre le terminal utilisateur (UE) et le module d’entrée (UPF) du cœur de réseau s’exprime sous la forme : ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ + ^^^^ ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ + ^^^^ ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ + ^^^^ ^^^^ ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^ avec ^^^^ ^^^^− ^^^^ la valeur de latence entre le composant A et le composant B. [0111] La valeur ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ ^^^^ représentative de la latence de bout-en-bout entre le terminal utilisateur (UE) et l’application accédée par ledit terminal utilisateur (UE) s’exprime sous la forme : ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ + ^^^^ ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ ^^^^ [0112] S’il s’agit d’une prédiction, l’étape S270 est mise en œuvre au cours de laquelle une valeur représentative d’une prédiction de la latence ou du débit de la connexion entre le terminal utilisateur (UE) et le module d’entrée (UPF) du réseau cœur ou de la connexion entre le terminal utilisateur (UE) et l’application (cApp) accédée par le terminal utilisateur est déterminée. Cette étape est mise en œuvre par le module MOD_PRED du contrôleur CTRL. [0113] Ce module MOD_PRED s’appuie sur un historique des valeurs de latence et/ou de débit obtenues par le module MOD_PROBE, et utilise un mécanisme d’apprentissage automatique, tel qu’un réseau de neurones entraîné pour prédire des valeurs futures de latence et/ou de débit, en fonction de valeurs passées et/ou en fonction du type de données ou de la qualité de service requise par le terminal utilisateur (UE). [0114] Selon un exemple particulier de mise en œuvre, le module MOD_PROBE prend en entrée un historique de données concernant la latence, le débit, la puissance
d'émission, les positions géographiques des terminaux utilisateurs, et d'autres données telles que la charge du réseau. Une fonction objective du module MOD_PROB est alors configurée de sorte prédire une qualité de service (e.g., latence et/ou débit) en utilisant les données d’entrée, et ainsi permettre au contrôleur CTRL de prendre de meilleures décisions en matière de contrôle de la puissance d'émission. La fonction objective vise soit à minimiser la latence, soit à maximiser le débit, soit à parvenir à un compromis entre ces deux mesures. Enfin, il importe de noter que la phase d'apprentissage est par exemple mise en œuvre en utilisant la pratique de l’informatique en nuage (« cloud computing »). Le procédé de gestion comprend en outre une étape S280 au cours de laquelle le module MOD_KPI d’évaluation transmet, à destination de l’application informatique (xApp), une réponse RESP_F incluant la valeur représentative requise. Le format de cette réponse RESP_F est similaire à celui de la requête REQ_F. Cette valeur est reçue par le module MOD_RX de l’application informatique lors d’une étape S150, puis utilisée lors d’une étape S160 pour gérer le réseau d’accès radio (RAN). Cette étape S160 de gestion du réseau d’accès radio (RAN) est mise en œuvre par le module MOD_PROC du contrôleur (CTRL). [0115] Dans des modes particuliers de mise en œuvre, l’étape S160 comprend une adaptation de ressources temporelles et fréquentielles attribuées au terminal utilisateur (UE). [0116] Selon un exemple particulier de mise en œuvre, au cours de l'étape S160, une politique spécifique d'ordonnancement MAC est déterminée par un ordonnanceur MAC, et activée au sein de l’unité distribuée (O-DU). En fonction du type de service, l'ordonnanceur MAC peut associer une plus grande priorité aux flux de données qui ne correspondent pas à une performance cible. [0117] Ainsi, pour un service à large bande passante pour une connectivité sans fil (Enhanced Mobile Broadband, eMBB, selon la terminologie anglo-saxonne) ayant des exigences de débit spécifiques, s’il est déterminé à l’étape S160 qu’une valeur représentative est inférieure à un objectif souhaité, une priorité plus importante est attribuée à ce service et ce, jusqu’à ce que la valeur représentative reçue à l’étape S150 soit optimale, voire maximale.
[0118] Les développements qui précèdent sont adaptables sans difficulté par l’homme du métier dans le cas d’un service soumis à des exigences strictes en matière de latence. [0119] En variante, l’étape S160 comprend un basculement de connexion du terminal utilisateur (UE) d’un premier dispositif émetteur vers un deuxième dispositif émetteur distinct du premier dispositif émetteur. [0120] En variante, l’étape S160 comprend une détermination d’une puissance d’émission du dispositif émetteur (gNB) en fonction de la valeur obtenue, lorsque des données sont échangées avec ledit terminal utilisateur (UE). Cette variante est décrite plus en détail en référence à la figure 9. [0121] Dans des modes particuliers de mise en œuvre, la puissance d’émission n’est adaptée que lorsque des unités de ressources temporelles et fréquentielles (PRB) allouées audit terminal utilisateur (UE) sont utilisées. [0122] L’utilisation de l’OFDMA (Orthogonal Frequency Division Multiple Access) offre désormais la possibilité d’allouer des ressources à la fois dans les dimensions temporelles et fréquentielles. De façon connue en soi, la plus petite unité de ressource fréquentielle pouvant être allouée à un terminal utilisateur (UE) par un orchestrateur (non représenté en figure 1) est nommé PRB (l’acronyme de « Physical Resource Block »). Ainsi, pour la 4G, un PRB dure par exemple 0.5 ms et est constitué de plusieurs (e.g., 7) symboles OFDM, et la largeur de bande d’un PRB est de 12 sous-porteuses. [0123] Ainsi, la puissance d’émission du dispositif émetteur (gNB) n’est contrôlée (et le cas échant adaptée) que lorsque des PRB alloués au terminal utilisateur (UE) sont utilisés, c’est-à-dire uniquement lorsque le terminal utilisateur (UE) et le dispositif émetteur (gNB) sont en mesure de communiquer. [0124] La figure 8 représente schématiquement un exemple de requête REQ_F émise par le contrôleur à destination du module d’évaluation d’un indicateur de performance. [0125] Telle qu’illustrée par la Figure 8, la requête comprend :
− un champ 810 comprenant le nom de la fonction appelée (par exemple GET E2E_KPI_latency ou GET E2E_KPI_throughput) ; − un champ 820 comprenant un identifiant de l’application xApp ayant émis cette requête ; − un champ 830 comprenant un drapeau (« flag » selon la terminologie anglo- saxonne) dont la valeur caractérise si c’est un état courant ou une prédiction d’un critère de performance qui est requis ; − un champ 840 comprenant un identifiant du terminal utilisateur (UE) pour lequel la mesure est requise ; − un champ 850 comprenant un temps correspondant au temps courant ; − un champ 860 comprenant un identifiant de l’application cApp accédée par le terminal. Cette valeur n’est nécessaire que dans le cas où une valeur représentative d’un débit ou d’une latence d’une connexion entre le terminal utilisateur (UE) et cette application cApp est requise par l’application informatique xApp ; et, − un champ 870 comprenant un temps correspondant à un instant futur. Cette valeur n’est nécessaire que dans le cas où une valeur représentative d’une prédiction d’un débit ou d’une latence d’une connexion entre le terminal utilisateur (UE) et le module d’entrée UPF ou l’application cApp est requise par l’application informatique xApp. [0126] La figure 9 illustre, sous forme d’ordinogramme, un exemple de gestion d’un réseau d’accès radio comprenant la détermination de la puissance d’émission du dispositif émetteur. Dans cet exemple, un critère de latence est considéré. Ce procédé est mis en œuvre par l’application informatique xApp précédemment évoquée, ou par une application informatique xApp distincte. Dans ce dernier cas, les deux applications xApp interagissent entre elles par exemple au travers d’une interface dite « EastBound » «ou « WestBound » compatible avec le standard O-RAN. [0127] Lors d’une étape d’initialisation (non représentée), la valeur drapeau start_flag est initialisée à 0, la valeur start_lat est également initialisée à 0, et le paramètre
SLA_LIMIT est initialisé comme une variable globale ayant une valeur donnée (e.g., SLA_LIMIT=15ms). [0128] Le procédé de détermination de la puissance d’émission d’un dispositif émetteur est un algorithme itératif. Tel qu’illustré par la figure 9, le procédé de détermination de la puissance d’émission d’un dispositif émetteur comprend une première étape S1050 au cours de laquelle il est déterminé s’il s’agit d’une première itération de l’algorithme ou pas. [0129] S’il s’agit d’une première itération (e.g., start_flag=0), alors l’étape S1060 est mise en œuvre. Au cours de cette étape, la puissance d’émission actuelle (curr_power) du dispositif émetteur (gNB) auquel est attaché le terminal utilisateur (UE) est obtenue. Puis, lors d’une étape S1070, la valeur drapeau start_flag est paramétrée à 1, et la valeur du paramètre start_lat est paramétrée comme étant égale à la valeur obtenue lors de l’étape S150. Une fois ces valeurs paramétrées, le contrôleur met en œuvre l’étape S1080. [0130] S’il ne s’agit pas d’une première itération (e.g., si start_flag≠0), alors l’étape S1090 est mise en œuvre. Au cours de cette étape, il est testé si la valeur obtenue lors de l’étape S150 est inférieure à la valeur du paramètre start_lat. Si tel est le cas, alors l’étape S1100 est mise en œuvre au cours de laquelle la valeur du paramètre start_lat est paramétrée comme étant égale à la valeur obtenue lors de l’étape S150. Une fois cette valeur paramétrée, le contrôleur met en œuvre l’étape S1080. [0131] Si par contre la valeur obtenue lors de l’étape S150 est supérieure ou égale à la valeur du paramètre start_lat, le contrôleur met en œuvre l’étape S1080. [0132] L’étape S1080 consiste à déterminer des valeurs seuil lat_limit et lat_alert en fonction de la valeur du paramètre start_lat. Dans un mode de réalisation particulier, ^^^^ ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^ ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^ × ^^^^1 et ^^^^ ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^ ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^ × ^^^^2 , avec ^^^^2 > ^^^^1 . Ainsi, M1 est par exemple égal à 1.3, et M2 à 1.6. [0133] Une fois ces deux valeurs seuil déterminées, le contrôleur met en œuvre une étape S1110 au cours de laquelle il est déterminé si la valeur seuil lat_limit est inférieure à la valeur obtenue lors de l’étape S150. Si ce n’est pas le cas (i.e., si la valeur seuil lat_limit est supérieure ou égale à la valeur obtenue lors de l’étape S150), alors l’étape S1120 est mise en œuvre au cours de laquelle il est déterminé
que la puissance d’émission du dispositif émetteur doit être réduite selon un certain pas. Cette étape vise à rendre le dispositif émetteur moins consommateur en énergie lorsque la qualité de service requise par un terminal utilisateur donné est largement atteinte. Une fois déterminé que la puissance d’émission doit être réduite, le contrôleur met en œuvre l’étape S1170. [0134] De retour à l’étape S1110, si par contre la valeur seuil lat_limit est inférieure à la valeur obtenue lors de l’étape S150, le contrôleur met en œuvre l’étape S1130 au cours de laquelle il est déterminé si la valeur obtenue lors de l’étape S150 est inférieure ou égale à la valeur de SLA_LIMIT ou (ou logique) si la valeur obtenue lors de l’étape S150 est inférieure ou égale à la valeur seuil lat_alert. Si ce n’est pas le cas, alors l’étape S1160 est mise en œuvre au cours de laquelle la puissance d’émission du dispositif émetteur n’évolue pas. De cette manière, – e.g., si ce n’est pas le cas –, le fait de conserver la valeur courante de puissance permet d’éviter une oscillation continue (effet «ping pong » ) autour d’une certaine valeur. [0135] Si par contre la valeur obtenue lors de l’étape S150 est supérieure à la valeur de SLA_LIMIT ou si la valeur obtenue lors de l’étape S150 est supérieure à la valeur seuil lat_alert, alors le contrôleur met en œuvre l’étape S1140. L’étape S1140 consiste en un test pour déterminer si le dispositif émetteur (gNB) émet ou pas une certaine puissance d’émission (e.g., si curr_power = 0 ou pas). Si le dispositif émetteur (gNB) a une puissance d’émission nulle, alors l’étape S1160 est mise en œuvre (la puissance d’émission du dispositif émetteur n’évolue pas). Si le dispositif émetteur (gNB) a par contre une puissance d’émission positive, alors la puissance d’émission curr_power est augmentée d’un certain pas, par exemple prédéterminé,lors d’une étape S1150. Cette étape vise à améliorer la qualité de service offerte au terminal utilisateur lorsque cette dernière est inférieure à une certaine valeur seuil. [0136] Autrement dit, les étapes S1110 à S1160 peuvent se résumer comme suit dans le cas où une valeur de latence est obtenue : la puissance d’émission du dispositif émetteur est augmentée si la latence a une valeur supérieure à une première valeur seuil (SLA_limit ou lat_alert), et à contrario, la puissance d’émission du dispositif émetteur est réduite si la latence a une valeur inférieure à une deuxième valeur seuil (latency_limit), la deuxième valeur seuil étant inférieure à la première valeur seuil.
Ainsi, si une qualité de service effectivement fournie au terminal utilisateur est atteinte (e.g., si la valeur de latence de bout-en-bout est inférieure à la deuxième valeur seuil), la puissance d’émission du dispositif émetteur est réduite, et à contrario, si la qualité de service effectivement fournie au terminal utilisateur est inférieure à une qualité de service requise (ou attendue) (e.g., si la valeur de latence de bout-en-bout est supérieure à la première valeur seuil), alors la puissance d’émission du dispositif émetteur est augmentée. [0137] Les développements qui précèdent sont adaptables sans difficulté par l’homme du métier dans le cas où une valeur représentative d’un autre paramètre de qualité de service est obtenue, par exemple une valeur représentative d’un débit. Dans ce cas, la puissance d’émission du dispositif émetteur est augmentée si le débit a une valeur inférieure à une première valeur seuil, et à contrario, la puissance d’émission du dispositif émetteur est réduite si le débit a une valeur supérieure à une deuxième valeur seuil, la deuxième valeur seuil étant supérieure à la première valeur seuil. [0138] Le procédé de détermination comprend en outre une étape S1170 au cours de laquelle le contrôleur détermine si un changement de la puissance d’émission est requis (e.g., si l’une des étapes S1120 ou S1150 a été mise en œuvre). Si tel est le cas, alors le contrôleur CTRL transmet une instruction à l’unité distribuée (O-DU) visant à adapter la puissance d’émission du dispositif émetteur (gNB) lors d’une étape S1180. Puis, lors d’une étape S1190, la variable curr_power est paramétrée comme étant désormais égale à la nouvelle valeur de puissance d’émission. Une fois la variable curr_power paramétrée à la nouvelle valeur de puissance, l’étape S1200 est mise en œuvre. [0139] De retour à l’étape S1170, s’il a préalablement été déterminé qu’aucune modification de puissance d’émission n’était nécessaire, alors l’étape S1200 est directement mise en œuvre. [0140] Lors de l’étape S1200 les valeurs de latence et/ou débit courant ainsi que la valeur de la puissance d’émission du dispositif émetteur sont affichées au travers d’une interface utilisateur dédiée. [0141] Dans des modes de mise en œuvre, l’interface est adaptée pour permettre à un utilisateur (e.g., un utilisateur en charge de la gestion dudit réseau d’accès radio)
d’un équipement affichant ladite interface d’adapter le pas d’augmentation ou de réduction de la puissance d’émission, et/ou pour modifier les valeurs des multiplicateurs M1 et M2 utilisés pour déterminer les valeurs lat_limit et lat_alert lors de l’étape S1080.