EP4736546A1

EP4736546A1 - Procédé d'adaptation d'une puissance d'émission d'un dispositif émetteur et dispositif électronique associé

Info

Publication number: EP4736546A1
Application number: EP24735644.7A
Authority: EP
Inventors: Kamil KOCISZEWSKI; Mohamad YASSIN; Salvatore Costanzo; Marion DUPREZ; Adrian OZI B O
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2023-06-28
Filing date: 2024-06-26
Publication date: 2026-05-06
Also published as: FR3150680A1; WO2025003249A1

Abstract

L'invention concerne un procédé d'adaptation d'une puissance d'émission d'un dispositif émetteur (gNB) d'un réseau d'accès radio (RAN), le réseau d'accès radio (RAN) étant connecté à un réseau cœur (CN). Le procédé comprend : une obtention d'une valeur représentative d'un paramètre de qualité de service d'au moins une portion de connexion entre un terminal utilisateur (UE) et une application (cApp) accédée par ledit terminal utilisateur (UE) et connectée au réseau cœur via un réseau de données (DN); et une adaptation de la puissance d'émission du dispositif émetteur en fonction de la valeur obtenue.

Description

Titre de l'invention : Procédé d’adaptation d’une puissance d’émission d’un dispositif émetteur 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é d’adaptation d’une puissance d’émission d’un dispositif émetteur. 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 [« 3 G »), 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] Le découpage des fonctions réseaux en services et la virtualisation de ces fonctions réseaux visent notamment à améliorer l’efficacité énergétique d’un réseau cellulaire 5G. Ce critère d’efficacité s’avère capital dans le cadre de la 5G où une augmentation significative du trafic de données est envisagée. De récentes études relatives à la consommation d’énergie dans de tels réseaux montrent cependant qu’environ 80% de l’énergie est consommée par les stations de base de ces réseaux. Aussi, différentes stratégies ont été définies qui visent à adapter la puissance d’émission d’une station de base, voire à la mettre en veille en cas de non-utilisation.

[0008] Ainsi, une station de base est par exemple mise en veille ou réveillée en fonction d’une distance entre des terminaux utilisateurs et la station de base auxquels ils sont attachés. D’autres stratégies visent à mettent en veille une station de base lorsque le volume de données échangées est inférieur à une valeur prédéterminée. Une station de base peut également être mise en veille pendant une période de temps déterminée lorsqu’il a été préalablement établi - par exemple à l’aide de statistiques - que le volume de données échangées est relativement faible pendant cette période [par exemple, pendant la nuit). Enfin, d’autres stratégies sont dites multicritères puisqu’elles visent par exemple à minimiser une certaine consommation d’énergie, tout en maximisant le profit des opérateurs en charge de ces réseaux.

[0009] Cependant, ces décisions de mise en veille et de réveil sont mises en œuvre à un haut niveau, i.e., pour un grand nombre de terminaux utilisateurs, et ne sont donc pas propres à un terminal utilisateur donné. A fortiori, les différentes stratégies d’adaptation de la puissance d’émission des stations de base jusqu’à présent envisagées ne permettent pas d’améliorer l’efficacité énergétique d’un réseau d’accès radio, tout en veillant également à assurer une certaine qualité de service à un terminal utilisateur donné.

Exposé de l’invention

[0010] 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 à la fois d’améliorer l’efficacité énergétique d’un réseau d’accès radio, tout en veillant également à assurer une certaine qualité de service à un terminal utilisateur donné.

[0011] À cet effet, et selon un premier aspect, l’invention concerne un procédé d’adaptation d’une puissance d’émission d’un dispositif émetteur d’un réseau d’accès radio, le réseau d’accès radio étant connecté à un réseau cœur. Le procédé est mis en œuvre par une application informatique d’un contrôleur du réseau d’accès radio et comprend :

- une obtention d’une valeur représentative d’un paramètre de qualité de service d’au moins une portion de connexion entre un terminal utilisateur attaché au dispositif émetteur et une application accédée par ledit terminal utilisateur et connectée au réseau cœur via un réseau de données; et,

- une adaptation de la puissance d’émission du dispositif émetteur en fonction de la valeur obtenue.

[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é d’adaptation 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, le paramètre de qualité de service est une latence, et l’adaptation comprend une augmentation de la puissance d’émission du dispositif émetteur si la valeur représentative de 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 valeur représentative de 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.

[0015] Dans des modes particuliers de mise en œuvre, le paramètre de qualité de service est un débit, et l’adaptation comprend une augmentation de la puissance d’émission du dispositif émetteur si la valeur représentative du débit a une valeur inférieure à une première valeur seuil, et une diminution de la puissance d'émission du dispositif émetteur si la valeur représentative du 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.

[0016] Autrement dit, si une qualité de service effectivement fournie au terminal utilisateur est atteinte, 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.

[0017] 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 (Le., 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.

[0018] Dans des modes particuliers de mise en œuvre, la première valeur seuil correspond à une qualité de service requise par ledit terminal utilisateur.

[0019] Dans des modes particuliers de mise en œuvre, le procédé d’adaptation comprend en outre une étape de transmission, par l’application informatique du contrôleur et à destination d’une unité distribuée associée au dispositif émetteur, d’une instruction visant à adapter la puissance d’émission dudit dispositif émetteur.

[0020] Dans des modes particuliers de mise en œuvre, le procédé d’adaptation comprend en outre, préalablement à l’étape d’obtention d’une valeur, une étape d’identification d’un terminal utilisateur pour lequel la puissance d’émission du dispositif émetteur doit être adaptée, le terminal utilisateur identifié correspondant au terminal utilisateur précédemment évoqué.

[0021] Cette caractéristique permet de déterminer le ou les terminaux utilisateurs pour lesquels des valeurs représentatives d’un paramètre de qualité de service doivent être obtenues, et ainsi d’adapter la puissance d’émission du dispositif émetteur en fonction de valeurs propres à ces mêmes terminaux utilisateurs.

[0022] Dans des modes particuliers de mise en œuvre, le ou les terminaux utilisateurs pour lesquels la puissance d’émission du dispositif émetteur doit être adaptée sont dans un état RCC [acronyme de Radio Resource Control) connecté (i.e., en 3G, 4G, 5G) ou dans un état RCC inactif avec une transmission courante de données [i.e., en 5G).

[0023] Dans des modes particuliers de mise en œuvre, le procédé d’adaptation comprend en outre une étape de transmission, par l’application informatique du contrôleur et à destination d’une interface graphique, d’une instruction visant à afficher la puissance d’émission adaptée et/ou la valeur représentative du paramètre de qualité de service.

[0024] Dans des modes particuliers de mise en œuvre, ladite au moins une portion de connexion correspond à la connexion entre le terminal utilisateur et un module d’entrée du réseau cœur, ou à la connexion entre le terminal utilisateur et l’application accédée par ledit terminal utilisateur.

[0025] L’obtention de la valeur comprend alors la 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 » de ladite valeur, et la puissance d’émission est adaptée lorsque des unités de ressources fréquentielles et/ou temporelles allouées audit terminal utilisateur sont utilisées.

[0026] L’utilisation d’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 de latence et/ou de débit de bout-en-bout permettent de quantifier la qualité des données effectivement reçues par le terminal utilisateur. En outre, ces caractéristiques permettent d’adapter la puissance d’émission d’un dispositif émetteur - telle 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.

[0027] 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.

[0028] 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 d’évaluation 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 le 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, 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 d'évaluation, d'une requête d’obtention d’un résultat d’une application de la au moins une fonction.

[0029] De façon générale, une interface de programmation d’application (ou 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 de ces services.

[0030] 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. [0031] 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 d’évaluation 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 ce module d’évaluation est exposée au contrôleur au travers d’ une interface de programmation d’application, et le procédé 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 d’évaluation, d’une requête d’obtention d’un résultat d’une application de la au moins une fonction.

[0032] 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é.

[0033] Dans des modes particuliers de mise en œuvre, la valeur obtenue est représentative d’un état courant de la latence ou du débit de la connexion.

[0034] 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.

[0035] Dans des modes particuliers de mise en œuvre, la valeur obtenue est représentative d’une prédiction de la latence ou du débit de la connexion.

[0036] 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 puissance d’émission du dispositif émetteur.

[0037] 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. [0038] Dans des modes particuliers de mise en œuvre, le contrôleur du réseau d’accès radio est de type « Near Real Time R1C ». Le contrôleur est alors par exemple conforme à la spécification O-RAN Near-RT R1C Architecture 4.0, “0- RAN.WG3.RlCARCH-R003-v04.00", release 3, publiée en mars 2023.

[0039] 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.WGll.Security-Near-RT- RlC-xApps-TR.0-R003-v02.00”, version 3, publiée en mars 2023.

[0040] 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.

[0041] Selon un deuxième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé d’adaptation, lorsque ledit programme est exécuté par un processeur.

[0042] 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.

[0043] Selon un quatrième aspect, l’invention concerne un dispositif électronique comprenant un contrôleur de réseau d’accès radio configuré pour adapter une puissance d’émission d’un dispositif émetteur d’un réseau d’accès radio, le réseau d’accès radio étant connecté à un réseau cœur, le contrôleur comprenant une application informatique comprenant :

- un module d’obtention d’une valeur représentative d’une latence ou d’un débit d’au moins une portion de connexion entre un terminal utilisateur et une application accédée par ledit terminal utilisateur et connectée au réseau cœur via un réseau de données ; et, - un module d’adaptation de la puissance d’émission du dispositif émetteur en fonction de la valeur obtenue.

Brève description des dessins

[0044] 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 :

[0045] [Fig.l] la figure 1 est un exemple de système de communication sans fil dans lequel un procédé d’adaptation selon l’invention est mis en œuvre ;

[0046] [Fig.2] la figure 2 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 ;

[0047] [Fig.3] la figure 3 représente un exemple d’architecture matérielle d’un dispositif électronique comprenant un contrôleur d’un réseau d’accès radio ;

[0048] [Fig.4] la figure 4 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé d’adaptation, selon un exemple de mise en œuvre de l’invention ;

[0049] [Fig.5] la figure 5 illustre, sous forme d’ordinogramme, un exemple d’obtention d’une valeur représentative d’une latence ou d’un débit de bout-en-bout ;

[0050] [Fig.6] la figure 6 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 ;

[0051] [Fig.7] la figure 7 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 ; et,

[0052] [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.

Description des modes de réalisation [0053] La figure 1 est un exemple de système de communication sans fil dans lequel un procédé d’adaptation selon l’invention est mis en œuvre.

[0054] 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 ».

[0055] 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). 11 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.

[0056] 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 « 0-RAN Architecture Description 8.0 », 0-RAN.WG1.0AD-R003-v08.00, version 3, publiée en mars 2023 de l’alliance O-RAN (acronyme de « Open Radio Access Network »). 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 permettent aux équipements et/ou modules logiciels de différents fournisseurs de communiquer.

[0057] 11 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").

[0058] 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 faiblement couplés.

[0059] 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).

[0060] 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.

[0061] 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).

[0062] 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).

[0063] 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 ».

[0064] 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.

[0065] 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 », TR 38.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.

[0066] Selon un autre exemple, cette répartition est conforme à l’option 7.2 telle que définie par l’alliance 0-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 », 0-RAN.WG7.0MAC- HRD.0-R003-v02.00, release R003 publiée en mars 2023.

[0067] 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 ») et 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.

[0068] Toujours conformément à l’option 7.2, l’unité distribuée [0-DU] est configurée pour gérer les sous-couches physique haute, MAC (acronyme de l’anglais « Media Access Control »] et RLC [acronyme de l’anglais « Radio LinkControl»]. 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.

[0069] 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 désignées ci-après « applications informatiques tierces ». Ce contrôleur est par exemple conforme à la spécification O-RAN Near-RT R1C Architecture 4.0, ”0-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].

[0070] 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 micro-services, et sont également déployées sur un réseau en nuage.

[0071] 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_KP1) 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.

[0072] Le module d’entrée correspond par exemple au module UPF (acronyme de l’anglais « 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.

[0073] 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]. 11 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).

[0074] Tel qu’illustré par la figure 1, le dispositif émetteur (gNB) est une station de base du réseau d’accès radio (RAN). 11 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.

[0075] La figure 2 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.

[0076] Le contrôleur (CTRL) est un composant logiciel. Tel qu’illustré par la figure 2, ce contrôleur (CTRL) de réseau d’accès radio (RAN) comprend une application (xApp) incluant les modules MOD_OBT et MOD_AD dont les fonctionnalités sont décrites en référence à la figure 3.

[0077] La figure 3 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.

[0078] Tel qu’illustré par la figure 3, 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.

[0079] 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é d’adaptation 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 d’obtention (MOD_OBT) d’une valeur représentative d’un paramètre de qualité de service d’au moins une portion de connexion entre un terminal utilisateur [UE] attaché au dispositif émetteur et une application [cApp] accédée par ledit terminal utilisateur et connectée au réseau cœur via 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 d’adaptation [MOD_AD] de la puissance d’émission du dispositif émetteur (gNB) en fonction de la valeur obtenue.

[0080] Par ailleurs, le dispositif électronique [D_CTRL] peut encore comporter d’autres modules, notamment pour mettre en œuvre des modes particuliers du procédé d’adaptation, comme cela est décrit plus en détail ultérieurement.

[0081] La figure 4 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé d’adaptation, selon un exemple de mise en œuvre de l’invention. Dans cet exemple, un critère de latence est considéré. Le procédé d’adaptation de la puissance d’émission d’un dispositif émetteur est un algorithme itératif mis en œuvre par une application informatique xApp du contrôleur [CTRL].

[0082] Tel qu’illustré par la figure 4, le procédé d’adaptation comprend une première étape d’initialisation S1000 au cours de laquelle la valeur drapeau start_flag est initialisée à 0. Cette valeur à 0 permet de déterminer s’il s’agit d’une première itération - et dans ce cas start_flag=0 - ou pas.

[0083] Puis, lors d’une étape S1010, un message de type RMR [acronyme de « R1C Message Router »] est reçu par l’application xApp mettant en œuvre le procédé selon l’invention. Ce message est typiquement émis par une application dénommée « kpimon xApp » configurée pour collecter des informations des unités O-DU et O-CU en utilisant une interface E2. Ce message est par exemple reçu après chaque connexion de la station de base [gNB] à l’application « kpimon xApp ».

[0084] Ce message est par exemple conforme au format défini à la page https://wiki.o- ran-sc.org/display/RICP/RMR+Message+Conventions ou à la page https://docs.o- ran-sc.org/proi ects/o-ran-sc-ric-plt-lib-rmr/en/latest/user-guide.html. 11 est typiquement composé d’un entête incluant un identifiant de station de base [nommé "Global gNB ID" par le consortium 3GPP, par exemple "NYN0001246"), et de données utiles. Ces données utiles incluent notamment des données relatives à la latence d’un flux de donnée spécifique pour un terminal utilisateur donné, ou des instructions pour que le dispositif émetteur adapte sa puissance d’émission.

[0085] Ce message est décodé, puis lors d’une étape S1020, son contenu est analysé afin d’identifier, lors d’une étape S1020, un terminal utilisateur [UE] pour lequel la puissance d’émission du dispositif émetteur doit être adaptée.

[0086] Si le terminal utilisateur [UE] identifié n’est pas connecté au réseau de télécommunications, alors l’étape S1030 est mise en œuvre au cours de laquelle la valeur drapeau start_flag est initialisée à 0, la valeur start at 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). Puis le procédé se remet en attente de la réception d’un nouveau message de type RMR.

[0087] Si par contre le terminal utilisateur [UE] identifié est connecté au réseau de télécommunications au travers d’une station de base contrôlée par ledit contrôleur (CTRL) - e.g., si le terminal utilisateur (UE) identifié est dans un état RCC (acronyme de Radio Resource Control) connecté (Le., en 3G, 4G, 5G) ou dans un état RCC inactif avec une transmission courante de données (Le., en 5G), par exemple dans le cadre d’une application de messagerie instantanée ou pour des transmissions à faible volumétrie de données (« Small Data Transmission », SDT) -, une étape S1040 est mise en œuvre au cours de laquelle une valeur représentative d’une latence d’au moins une portion de 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) est obtenue.

[0088] Selon un mode de réalisation particulier, ladite au moins une portion de connexion entre le terminal utilisateur (UE) et l’application (cApp) correspond à la connexion entre l’unité radio (O-RU) et l’unité centralisée (O-CU) du réseau d’accès radio (RAN) du réseau de télécommunications.

[0089] En variante, ladite au moins une portion de connexion entre le terminal utilisateur (UE) et l’application (cApp) correspond à la connexion de bout-en-bout entre le terminal utilisateur (UE) et l’application (cApp) ou à la connexion de bout- en-bout entre le terminal utilisateur (UE) et un module d’entrée (UPF) du réseau cœur (CN). Cette variante est décrite plus en détail en référence à la figure 5.

[0090] Le procédé d’adaptation de la puissance d’émission d’un dispositif émetteur comprend en outre une é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.

[0091] S’il s’agit d’une première itération (e.g., stc!rt_flag=O), alors l’étape S1060 est mise en œuvre. Au cours de cette étape, la puissance d’émission actuelle (curr_poiver) 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 S1040. Une fois ces valeurs paramétrées, le contrôleur met en œuvre l’étape S1080.

[0092] S’il ne s’agit pas d’une première itération (e.g., si start lag O), alors l’étape S 1090 est mise en œuvre. Au cours de cette étape, il est testé si la valeur de latence obtenue lors de l’étape S1040 est inférieure à la valeur du paramètre startjat. Si tel est le cas, alors l’étape SI 100 est mise en oeuvre au cours de laquelle la valeur du paramètre startjat est paramétrée comme étant égale à la valeur obtenue lors de l’étape S1040. Une fois cette valeur paramétrée, le contrôleur met en œuvre l’étape S1080.

[0093] Si par contre la valeur obtenue lors de l’étape S1040 est supérieure ou égale à la valeur du paramètre startjat, le contrôleur met en œuvre l’étape S1080.

[0094] L’étape S1080 consiste à déterminer des valeurs seuil lat imit et lat_alert en fonction de la valeur du paramètre start at. Dans un mode de réalisation particulier, latjimit = startjat x Ml et lat_alert = startjat x M2 , avec M2 > Ml . Ainsi, Ml est par exemple égal à 1.3, et M2 à 1.6.

[0095] 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 latjimit est inférieure à la valeur obtenue lors de l’étape S1040. Si ce n’est pas le cas (i.e., si la valeur seuil latjimit est supérieure ou égale à la valeur de latence obtenue lors de l’étape S1040), 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 pas par exemple prédéterminé. 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.

[0096] De retour à l’étape S1110, si par contre la valeur seuil latjimit est inférieure à la valeur obtenue lors de l’étape S1040, 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 S1040 est inférieure ou égale à la valeur de SLAJAMIT ou (ou logique] si la valeur obtenue lors de l’étape S1040 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.

[0097] Si par contre la valeur de latence obtenue lors de l’étape S1040 est supérieure à la valeur de SLAJAMIT ou si la valeur obtenue lors de l’étape S1040 est supérieure à la valeur seuil lat_alert, alors le contrôleur met en œuvre l’étape SI 140. 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.

[0098] 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_Iimit ou Iat_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 (latencyjimit), 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), alors la puissance d’émission du dispositif émetteur est augmentée.

[0099] Les développements qui précèdent sont adaptables sans difficulté par l'homme du métier à d’autres paramètres de qualité de service, par exemple dans le cas où une valeur représentative d’un débit est obtenue. 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.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] Dans des modes de mise en œuvre, l’interface utilisateur 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 dispositif sur lequel est affichée 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 Ml et M2 utilisés pour déterminer les valeurs et lat_alert lors de l’étape S1080. Puis le procédé se remet en attente de la réception d’un nouveau message de type RMR.

[0104] La figure 5 illustre, sous forme d’ordinogramme, un exemple de procédé d’obtention d’une valeur représentative d’une latence ou d’un débit de bout-en-bout. Ce procédé est mis en œuvre entre un module d’évaluation d’un critère de performance (MOD_KPI) du réseau cœur (CN) et l’application informatique xApp précédemment évoquée, ou entre le module d’évaluation et une autre application informatique xApp, distincte de l’application xApp et appartenant également au contrôleur CTRL, et mettant en œuvre le procédé d’adaptation. Dans ce dernier cas, les deux applications xApp interagissent entre elles au travers d’une interface E2.

[0105] Tel qu’illustré par la figure 5, le procédé d’obtention comprend une première étape S100 d’obtention, par l’application informatique (xApp) du contrôleur [CTRL] mettant en œuvre ledit procédé d’obtention, d’un moyen d’accès au module MOD_KPI d’évaluation d’un indicateur de performances. [0106] 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’APl associée audit service.

[0107] L’application informatique (xApp) accède alors à un système de nom de domaine (ou Domaine Name System, DNS selon la terminologie anglo-saxonne) de sorte à obtenir l’adresse IP du serveur HTTP.

[0108] 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_AP1 visant à obtenir la liste des fonctions mises en œuvre par ce module MOD_KP1 d’évaluation d’un indicateur de performance.

[0109] 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_AP1 à 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.

[0110] Le procédé de gestion comprend en outre une étape S130 au cours de laquelle l’application informatique (xApp) transmet, à destination du module MOD_KP1 d’évaluation, une requête REQ_F visant à obtenir le résultat de l’application d’une des fonctions exposées par l’APl et listées dans la réponse RESP_APL 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. [0111] 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 MODJCPI d’évaluation à destination de l’application lors d’une étape S240, et reçu par cette application lors d’une étape S140.

[0112] Si la requête est correctement formée, une étape S250 est mise en œuvre par le module MODJCPI 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).

[0113] 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.

[0114] 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 pingf) (resp. iperfff est appliquée entre le terminal utilisateur (UE) et le module d’entrée (UPF) du réseau cœur. Les commandes pingf) et iperff) sont des commandes connues de l’homme du métier et ne sont pas décrites davantage ici.

[0115] 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(J) est appliquée entre le terminal utilisateur (UE) et le serveur sur lequel est déployé l'application (cApp).

[0116] Ainsi, en référence à la figure 1, la valeur T_UE-UPF 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 :

TUE -u PP — T'UE-ORU + T_ORU-ODU + T_ODU-OCU + T_{ocu UPP} avec T_{A -B} la valeur de latence entre le composant A et le composant B.

[0117] La valeur T_UE-cApp 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 :

T ¹ UE-cApp — TUE-UPF + TUPF-CAPP

[0118] 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.

[0119] 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).

[0120] 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, 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 »).

[0121] Le procédé de gestion comprend en outre une étape S280 au cours de laquelle le module M0D_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 relativement 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] La figure 6 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.

[0126] Tel qu’illustré par la figure 6, 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 deux sous- modules MOD_PROBE et MOD_PRED ainsi qu’un serveur HTTP connecté aux modules MOD_PROBE et MOD_PRED et couplé à une interface de programmation d’application (API).

[0127] Le sous-module MOD_PROBE est configuré pour obtenir une valeur (E2E_KP1#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_KP1) est connecté à la sortie du module d’entrée (UPF) et par exemple configuré pour lancer la commande pingQ entre le module d’entrée (UPF) et le terminal utilisateur (UE) pour obtenir une valeur de latence, ou la commande iperf(J entre le module d’entrée (UPF) et le terminal utilisateur (UE) pour obtenir une valeur de débit.

[0128] 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 l’application (cApp) 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 pingQ (resp. iperfQ) entre ce serveur et le terminal utilisateur (UE) pour obtenir une valeur de latence (resp. de débit).

[0129] Le sous-module MOD_PRED est 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 un 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 le terminal utilisateur (UE). 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.

[0130] 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_KP1) 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ées de cette fonction). [0131] 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 le terminal utilisateur [UE].

[0132] La figure 7 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.

[0133] Le module (MOD_KPI) d’évaluation d’un indicateur de performance est identique à celui décrit en référence à la figure 6, et n’est donc pas re-décrit, par soucis de concision.

[0134] Tel qu’illustré par la figure 7, le contrôleur (CTRL) comprend un client HTTP ainsi qu’une application informatique (xApp) connectée au client HTTP.

[0135] 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é -.

[0136] Les API présentées en référence aux figures 6 et 7 sont par exemple de type REST. 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.

[0137] 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.

[0138] 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_KPIJatency 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.

Claims

Revendications

[Revendication 1] Procédé d’adaptation d’une puissance d’émission d’un dispositif émetteur (gNB) d’un réseau d’accès radio (RAN), le réseau d’accès radio (RAN) étant connecté à un réseau cœur (CN), le procédé étant mis en œuvre par une application informatique (xApp) d’un contrôleur (CTRL) du réseau d’accès radio (RAN) et comprenant :

- une obtention (S1040) d’une valeur représentative d’un paramètre de qualité de service d’au moins une portion de connexion entre un terminal utilisateur (UE) et une application (cApp) accédée par ledit terminal utilisateur (UE) et connectée au réseau cœur via un réseau de données (DN) ; et,

- une adaptation (S1120, S1150, S1160) de la puissance d’émission du dispositif émetteur (gNB) en fonction de la valeur obtenue.

[Revendication 2] Procédé d’adaptation selon la revendication 1, dans lequel le paramètre de qualité de service est une latence, et l’adaptation (S1120, S1150, S1160) comprend une augmentation (S1150) de la puissance d’émission du dispositif émetteur (gNb) si la valeur représentative de la latence a une valeur supérieure à une première valeur seuil, et une diminution (S1120) de la puissance d’émission du dispositif émetteur (gNb) si la valeur représentative de 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.

[Revendication 3] Procédé d’adaptation selon la revendication 1, dans lequel le paramètre de qualité de service est un débit, et l’adaptation (S1120, S1150, S1160) comprend une augmentation (S1150) de la puissance d’émission du dispositif émetteur (gNb) si la valeur représentative du débit a une valeur inférieure à une première valeur seuil, et une diminution (S1120) de la puissance d’émission du dispositif émetteur (gNb) si la valeur représentative du 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.

[Revendication 4] Procédé d’adaptation selon la revendication 2 ou 3, dans lequel la première valeur seuil correspond à une qualité de service requise par ledit terminal utilisateur (UE).

[Revendication 5] Procédé d’adaptation selon l’une des revendications 1 à 4, comprenant en outre une étape de transmission (S1160), par l’application informatique (xApp) du contrôleur (CTRL) et à destination d’une unité distribuée (O-DU) associée au dispositif émetteur (gNB), d’une instruction visant à adapter la puissance d’émission dudit dispositif émetteur (gNB).

[Revendication 6] Procédé d’adaptation selon l’une des revendications 1 à 5, comprenant en outre, préalablement à l’étape (S1040) d’obtention d’une valeur, une étape (S1020) d’identification d’un terminal utilisateur pour lequel la puissance d’émission du dispositif émetteur doit être adaptée, le terminal utilisateur identifié correspondant audit terminal utilisateur (UE) .

[Revendication 7] Procédé d’adaptation selon l’une des revendications 1 à 6, comprenant en outre une étape de transmission (S1200), par l’application informatique (xApp) du contrôleur (CTRL) et à destination d’une interface graphique, d’une instruction visant à afficher la puissance d’émission adaptée et/ou la valeur représentative du paramètre de qualité de service.

[Revendication 8] Procédé d’adaptation selon l’une des revendications 1 à 7, dans lequel la moins une portion de connexion correspond à la connexion entre le terminal utilisateur (UE) et un module d’entrée (UPF) du réseau cœur (CN), ou à la connexion entre le terminal utilisateur (UE) et l’application (cApp) accédée par ledit terminal utilisateur (UE), l’obtention (S1040) de la valeur comprenant la réception (S150), en provenance d’un module (MOD_KP1) du réseau cœur (CN), de ladite valeur, et la puissance d’émission étant adaptée lorsque des unités de ressources fréquentielles et/ou temporelles (PRB) allouées audit terminal utilisateur (UE) sont utilisées.

[Revendication 9] Procédé d’adaptation selon la revendication 8, dans lequel l’application (xApp) du contrôleur du réseau d’accès radio comprend un client HTTP, le module (MOD_KPI) 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 le module (MODJCPI) est exposée à l’application (xApp) du contrôleur du réseau d’accès radio au travers d’une interface de programmation d’application (API), le procédé comprenant en outre les étapes suivantes, préalablement à la réception (S150) de la valeur:

- un accès (S120), par l’application informatique (xApp) du contrôleur (CTRL) du réseau d’accès radio (RAN), à ladite interface de programmation d’application (API), et,

- une transmission (S130), par l’application informatique (xApp) du contrôleur (CTRL) du réseau d’accès radio (RAN) et à destination du module (MOD_KPI) du réseau cœur, d’une requête (REQ_F) d’obtention d’un résultat d’une application de la au moins une fonction.

[Revendication 10] Procédé d’adaptation selon la revendication 8, dans lequel le contrôleur (CTRL) du réseau d’accès radio comprend un client HTTP accessible par l’application (xApp) du contrôleur du réseau d’accès radio ; le module (MOD_KP1) du réseau cœur (CN) 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 le module (M0D_KPI) est exposée au contrôleur (CTRL) au travers d’ une interface de programmation d’application (API), le procédé comprenant en outre les étapes suivantes, préalablement à la réception (S150) de la valeur:

- un accès (S120), par le contrôleur (CTRL) du réseau d’accès radio (RAN), à ladite interface de programmation d’application (API),

- une transmission (S130), par le contrôleur (CTRL) du réseau d’accès radio (RAN) et à destination du module (MOD_KP1) du réseau cœur, d’une requête [REQ_F d’obtention d’un résultat d’une application de la au moins une fonction.

[Revendication 11] Procédé d’adaptation selon l’une des revendications 1 à 10, dans lequel la valeur obtenue est représentative d’une prédiction de la latence ou du débit de la connexion.

[Revendication 12] Programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé d’adaptation selon l’une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté par un ordinateur.

[Revendication 13] Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 12.

[Revendication 14] Dispositif électronique (D_CTRL) comprenant un contrôleur [CTRL] de réseau d’accès radio [RAN] configuré pour adapter une puissance d’émission d’un dispositif émetteur [gNB] d’un réseau d’accès radio [RAN], le réseau d’accès radio [RAN] étant connecté à un réseau cœur [CN], le contrôleur comprenant une application informatique [xApp] comprenant :

- un module d’obtention [MOD_OBT] d’une valeur représentative d’un paramètre de qualité de service d’au moins une portion de connexion entre un terminal utilisateur [UE] et une application [cApp] accédée par ledit terminal utilisateur [UE] et connectée au réseau cœur via un réseau de données [DN] ; et,

- un module d’adaptation [MOD_AD] de la puissance d’émission du dispositif émetteur [gNB] en fonction de la valeur obtenue.