FR 3157775 A1 20250627 FR 2314984 A 20231222 Procédés visant à optimiser l’efficacité énergétique d’un équipement utilisateur, entité d’un réseau de télécommunications et équipement utilisateur L’invention concerne un procédé de communication mis en œuvre par un équipement utilisateur d’un réseau de télécommunications via lequel ledit équipement utilisateur transmet des données, le procédé de communication comprenant l’envoi à une entité du réseau de télécommunications, d’au moins une information relative à un statut énergétique de l’équipement utilisateur pour : une pluralité de paramètres de transmission des données, et/ou une pluralité d’applications impliquées dans la transmission des données. Figure pour l’abrégé : Fig. 1. Procédés visant à optimiser l’efficacité énergétique d’un équipement utilisateur, entité d’un réseau de télécommunications et équipement utilisateur L’invention appartient au domaine général des télécommunications. Elle a une application privilégiée mais non limitative dans le contexte d’un réseau de télécommunications 5G (i.e. de 5 ème Génération) et plus particulièrement, de la nouvelle interface radio 5G NR (pour « New Radio » en anglais) définie par le standard 3GPP à compter de la Release 15. L’invention peut également trouver une application dans des réseaux propriétaires, OpenRAN ou encore dans des réseaux de future génération telle que la 6G (i.e. 6 ème génération). L'optimisation de l’efficacité énergétique fait référence à la maximisation de l'utilisation de l'énergie pour obtenir des résultats optimaux, tout en minimisant le gaspillage et les pertes énergétiques. Dans un contexte global, où les préoccupations environnementales et les impératifs économiques convergent, cette optimisation est devenue un pilier central des politiques et des initiatives visant à promouvoir un développement durable et équilibré. Les industriels, notamment, sont de plus en plus conscients de l'importance d’optimiser l'efficacité énergétique comme moyen de préserver l'environnement et de promouvoir une croissance économique durable et vertueuse. A ce titre, l’optimisation de l’efficacité énergétique est au cœur du déploiement de la technologie d’accès radio 5G NR et plus généralement de l’ensemble des réseaux de télécommunications. Dans le contexte particulier des réseaux de télécommunications, on définit souvent l’efficacité énergétique comme étant l’inverse de l’énergie consommée par bit transmis, ou en d’autres termes comme étant le nombre de bits transmis par unité d’énergie consommée. Plus particulièrement, de nombreuses solutions visant à améliorer l’efficacité énergétique des réseaux 5G ont été développées ou sont en cours de développement. Une solution consiste à offrir la possibilité à un équipement utilisateur (ou UE pour « User Equipment » en anglais) de ce réseau de recevoir ou d’émettre des données sur une partie seulement de la bande passante allouée par le réseau à la cellule à laquelle est rattaché cet équipement utilisateur. Une telle fonctionnalité, également connue sous le nom de BWP pour « BandWidth Part » en anglais permet d’adapter dynamiquement la bande passante sur laquelle des données associées à un UE sont transmises (i.e. envoyées ou reçues par l’UE) via le réseau, et incidemment la numérologie utilisée par l’UE sur cette bande. Par numérologie, on entend dans le contexte d’un schéma de transmission de type OFDM (pour « Orthogonal Frequency Division Multiplexing » en anglais) tel que celui adopté par la technologie d’accès radio 5G NR, l’espacement entre les sous-porteuses et la longueur du préfixe cyclique, ou de façon équivalente, la durée d’un symbole OFDM. L’utilisation de ces multiples numérologies permet avantageusement de répondre aux contraintes diverses et variées (aussi désignées par SLA pour « Service Level Agreement » en anglais) en termes de latence, de débit (ou « throughput » en anglais) et de fiabilité, imposées par les différentes catégories de services que les réseaux 5G permettent d’offrir. Ces différentes catégories de services comprennent notamment : des services de type eMBB (pour « enhanced Mobile Broadband » en anglais) s’appuyant sur des débits de données très élevés pour proposer de nouvelles expériences aux utilisateurs (ex. réalité virtuelle, réalité augmentée, diffusion vidéo HD, etc.) ; des services de type uRLLC (pour « ultra Reliable Low Latency Communication » en anglais), qui ont des exigences strictes en matière de latence et de fiabilité des communications (ex. services de gestion à distance, robots industriels, télé-chirurgie) ; et des services de type mMTC (pour « massive Machine Type Communication » en anglais), qui incluent notamment l’Internet des Objets (ou « IoT » pour « Internet of Things » en anglais), et qui ont des exigences élevées en termes de densité de déploiement notamment (ex. ville connectée, agriculture connectée, etc.). des services de type V2X (pour « Vehicle to Everything » en anglais), permettant à un véhicule d’échanger des informations avec un autre véhicule, une infrastructure, au réseau et/ou un piéton. Les services V2X incluent des services de sécurité (ou « safety services » en anglais), qui ont pour but par exemple de minimiser les accidents, les risques des passagers ou des utilisateurs des routes (ex. service d’aide à la conduite ou de conduite autonome), et qui requièrent une latence très faible (inférieure à quelques millisecondes) et une fiabilité de transmission proche de 100%, et des services autres (ou « non-safety services » en anglais) visant davantage à améliorer les conditions de trafic, à minimiser l’influence de la congestion des routes, à améliorer le confort des passagers du véhicule, etc., et qui ont certes besoin de débits de transmission élevés mais peuvent tolérer une certaine latence et une fiabilité moins importante ; et des services de type HMTC (pour « High performance Machine Type Communications » en anglais), qui comme pour les services de type mMTC, ont des exigences élevées en termes de densité de déploiement (et donc de disponibilité des ressources pour communiquer), mais également de faible latence et de débits de transmission élevés. Comme évoqué précédemment, la technologie d’accès radio 5G NR permet à un UE, via la fonctionnalité BWP, d’utiliser une bande passante plus étroite que la bande passante totale allouée par un réseau 5G à la cellule dans laquelle se trouve l’UE. Cette bande passante plus étroite correspond à une partie (désignée par BWP dans la suite) de la bande passante totale allouée par le réseau à la cellule. Compte-tenu des largeurs de bande envisagées en 5G (jusqu’à 400 MHz pour une seule porteuse), le recours à cette fonctionnalité permet avantageusement d’une part, de s’adapter à des UE disposant de capacités réduites en termes de largeur de bande supportée et/ou qu’ils peuvent surveiller, et d’autre part, de réduire la complexité des traitements réalisés par les UE (ex. surveillance et décodage des canaux de contrôle) et ainsi l’énergie qu’ils consomment. Conformément au standard 3GPP, bien que plusieurs BWP puissent être configurées au niveau de l’UE, une seule BWP peut être active (autrement dit, utilisée pour la transmission de données associées à l’UE) à un instant donné en UL ou en DL. Un UE peut toutefois basculer d’une BWP à une autre, autrement dit activer une nouvelle BWP en remplacement de la BWP active courante. Un tel basculement peut être décidé par le réseau (station de base à laquelle est rattaché l’UE), par exemple en vue de satisfaire les exigences de qualité de service (QoS pour « Quality of Service » en anglais) d’un nouveau service requis par l’UE, la nouvelle BWP étant considérée comme mieux adaptée en raison de sa numérologie que la BWP active courante pour transmettre les flux de données relatifs à ce service. Il est déclenché par l’envoi par la station de base, sur un canal de contrôle PDCCH (pour « Physical Downlink Control CHannel » en anglais), d’informations de contrôle DCI (pour « Downlink Control Information » en anglais) destinées à l’UE, au format 0_1 (pour l’UL) ou 1_1 (pour le DL), et comprenant un indicateur de BWP (ou « Bandwidth Part indicator » en anglais) désignant la nouvelle BWP à activer par l’UE. Si un tel mécanisme de basculement d’une BWP à une autre permet de satisfaire les exigences de QoS des différents services requis par l’UE, la fréquente réception d’informations de contrôle DCI, leur traitement et l’activation des différentes BWP en fonction des informations de contrôle DCI représente toutefois un coût énergétique pour l’UE. Ce coût énergétique pour l’UE peut être réduit en considérant un mécanisme de basculement modifié selon lequel, lorsque l’UE ne détecte plus d’inactivité dans sa BWP active courante, l’UE bascule de façon automatique vers une BWP définie par défaut avec laquelle il a été précédemment configuré, à l’expiration d’un délai dit d’inactivité (« inactivity timer » en anglais). La valeur du délai d’inactivité est comprise entre 2 ms et 2560 ms. Cette bascule automatique vers une BWP définie par défaut permet à l’UE de réduire sa consommation énergétique de manière significative. Un autre exemple de mécanisme permettant d’améliorer l’efficacité énergétique d’un UE consiste en un mécanisme de réception discontinue DRX (pour « Discontinuous Reception » en anglais). Un tel mécanisme DRX alterne des périodes de veille au cours desquelles l’UE ne surveille pas le canal de contrôle PDCCH, avec des périodes de réveil au cours desquelles l’UE surveille le canal de contrôle PDCCH afin d’accéder aux informations de contrôle DCI utiles à son fonctionnement. Afin d’améliorer davantage l’efficacité énergétique d’un UE, le mécanisme DRX peut être implémenté en combinaison avec le mécanisme de basculement d’une BWP à une autre. Il existe, bien entendu d’autres mécanismes permettant d’améliorer l’efficacité énergétique au sein d’un réseau de télécommunications qui peuvent être implémentés en combinaison de l’un ou de l’ensembles des trois mécanismes précédemment décrits, le but n’étant pas, ici, d’en faire une liste exhaustive. Avec le développement massif de l’IoT et des services de type V2X, le nombre d’UE destinés à transmettre des données via un réseau 5G est amené à croître de manière significative. Cette forte croissance va augmenter la demande en énergie nécessaire à la fourniture de ces nouveaux services. Il existe par conséquent un besoin de nouvelles solutions permettant d’améliorer davantage l’efficacité énergétique d’un UE. A cet effet, et selon un premier aspect, l’invention concerne un procédé de communication mis en œuvre par un équipement utilisateur d’un réseau de télécommunications via lequel ledit équipement utilisateur transmet des données, le procédé de communication comprenant l’envoi à une entité du réseau de télécommunications, d’au moins une information relative à un statut énergétique de l’équipement utilisateur pour : une pluralité de paramètres de transmission des données, et/ou une pluralité d’applications impliquées dans la transmission des données. Corrélativement, l’invention vise aussi un équipement utilisateur d’un réseau de télécommunications via lequel il transmet des données comprenant un module d’envoi configuré pour envoyer à une entité du réseau de télécommunications, au moins une information relative à un statut énergétique de l’équipement utilisateur pour : une pluralité de paramètres de transmission des données, et/ou une pluralité d’applications impliquées dans la transmission des données. Il convient de noter que l’invention s’applique de manière particulièrement avantageuse en voie montante (UL). L’idée sous-jacente sur laquelle s’appuie l’invention est que la connaissance, par une entité du réseau, d’une information relative au statut énergétique de l’équipement utilisateur fournie par ce dernier peut influencer le choix de traitements à appliquer en vue améliorer l’efficacité énergétique de l’équipement utilisateur. Une telle solution peut avantageusement être implémentée seule ou encore en combinaison avec des solutions déjà existantes permettant, entre autre, une réduction encore plus significative de la consommation énergétique de l’équipement utilisateur. Plus particulièrement, l’équipement utilisateur collecte cette information relative à son statut énergétique pour plusieurs paramètres de transmission des données et/ou pour plusieurs applications, par exemple au moyen d’applications natives exécutées au sein de son système d’exploitation. Une telle information relative à un statut énergétique de l’équipement utilisateur appartient, par exemple, à un groupe comprenant : un taux de consommation d’énergie, une durée de consommation, une valeur d’énergie consommée. De manière connue, une application est un programme informatique utilisé pour fournir un service ou une pluralité de services. Les applications sont déployées sur un dispositif électronique, ici l’équipement utilisateur et s'exécutent en utilisant les services du système d'exploitation du dispositif sur lequel elles sont déployées, pour utiliser les ressources logicielles et/ou matérielles de ce dernier. Aucune hypothèse n’est faite quant à la nature de l’application. L’équipement utilisateur envoie donc cette information relative à son statut énergétique à destination de l’entité du réseau, par exemple dans un message particulier conforme au protocole RRC (appelé ici message RRC), appelé « UEAssistanceInformation », défini notamment dans le standard 3GPP TS 38.331 version 16.1.0 Release 16, et qui est modifié pour les besoins de l’invention afin de pourvoir transporter cette information relative à un statut énergétique de l’équipement utilisateur. De manière connue, un message « UEAssistanceInformation » comprend diverses informations relatives au statut interne de l’équipement utilisateur telles que par exemple les paramètres d’exécution du mécanisme DRX, le statut activé/désactivé de l’indicateur de surchauffe, ou encore le statut RRC « IDLE », « CONNECTED » ou « INACTIVE » de l’équipement utilisateur. Cependant, un tel message n’est pas configuré pour transporter des informations relatives à une consommation énergétique de l’équipement utilisateur pour plusieurs paramètres de transmission des données ou pour plusieurs applications. De nouveaux champs peuvent donc être introduits dans ce message « UEAssistanceInformation » afin de permettre l’envoi des différentes informations relatives à un statut énergétique l’équipement utilisateur pour plusieurs paramètres de transmission des données ou pour plusieurs applications. De manière avantageuse, une telle modification des messages « UEAssistanceInformation » standardisés permet leur réutilisation dans le contexte de la présente invention, évitant l’envoi de messages supplémentaires à destination de l’entité du réseau. Cette modification des messages « UEAssistanceInformation » ne requiert également pas de modification de l’entité du réseau qui sait déjà les traiter. Bien entendu, dans un autre mode de réalisation, un nouveau message peut être créé pour les besoins de l’invention pour véhiculer la ou les informations relatives à la consommation énergétique de l’équipement utilisateur. Dans des modes particuliers de mise en œuvre du procédé de communication, un paramètre de transmission comprend au moins l’un parmi : un identifiant d’une tranche réseau supportée par le réseau, un indicateur d’une partie de bande passante. De manière connue, un équipement utilisateur d’un réseau de télécommunications, tel qu’un réseau 5G par exemple, peut être connecté ou autorisé à se connecter simultanément à des services différents. Le standard 3GPP a par exemple introduit la notion de « network slicing » en anglais (ou découpage d’un réseau en tranches) selon laquelle un réseau physique 5G peut être découpé en plusieurs tranches logiques (ou « slices » en anglais), chaque tranche logique étant associée à un service distinct, caractérisé par un SLA qui lui est propre, et disposant de ressources radio dédiées. Un même UE peut être connecté à 8 tranches réseau simultanément et donc accéder simultanément à des services distincts. Il convient de noter qu’un UE d’un réseau 5G peut être connecté à plusieurs services distincts y compris en l’absence de network slicing. Grâce à l’invention, l’entité du réseau dispose d’informations relatives à une consommation énergétique de l’équipement utilisateur par tranche réseau supportée par le réseau ce qui lui permet d’obtenir des traitements à appliquer, non plus globaux, mais ciblés par types de services. Ainsi, quand dans l’art antérieur un traitement unique est appliqué à l’ensemble des tranches réseau, l’invention permet l’application de traitements différenciés. Il peut également être intéressant de fournir à l’entité du réseau des informations relatives à une consommation énergétique de l’équipement utilisateur présentant une granularité plus fine qu’une information par tranche réseau. En effet, bien que deux services requis par un équipement utilisateur puissent être associés à une même tranche réseau, l’activation d’une BWP peut s’avérer plus pertinente pour l’un de ces services que pour l’autre, notamment en raison de la numérologie associée à cette BWP, sachant qu’il n’est pas optimal d’utiliser une même numérologie pour deux services présentant des contraintes (ou SLA) différentes. Forte de la connaissance d’informations relatives à une consommation énergétique de l’équipement utilisateur par BWP, l’entité réseau peut obtenir des traitements à appliquer avec une granularité encore plus fine et ainsi contribuer à améliorer davantage l’efficacité énergétique de l’équipement utilisateur. Une information relative au statut énergétique de l’équipement utilisateur relative à une tranche réseau ou à une BWP est obtenue au moyen de l’information relative au statut énergétique de l’équipement utilisateur pour au moins une application transmettant des données conformément à ce paramètre de transmission. En effet, une application étant un programme informatique utilisé pour fournir un service ou une pluralité de services à l’équipement utilisateur, elle est nécessairement associée à une BWP et/ou à une tranche réseau. Ainsi, l’équipement utilisateur ayant collecté les informations relatives à son statut énergétique pour plusieurs applications, il lui suffit alors de les regrouper par identifiant de tranche réseau ou par indicateur de BWP. L’entité réseau connaissant l’ensemble des tranches réseau et des BWP attribuées à l’équipement utilisateur peut procéder à ce regroupement à la place de l’équipement utilisateur lorsque ce dernier lui envoie des informations relatives à son statut énergétique pour plusieurs applications. Cela contribue à également à réduire la consommation énergétique de l’équipement utilisateur. Dans des modes particuliers de mise en œuvre du procédé de communication, l’information relative à un statut énergétique de l’équipement utilisateur comprend en outre au moins une information relative à un statut d’une batterie de l’équipement utilisateur. L’information relative à un statut de la batterie de l’équipement utilisateur appartient, quant à elle, à un groupe comprenant : un taux d’autonomie, une durée d’autonomie, un taux de charge, une durée de charge. Grâce ce mode de réalisation de à l’invention, il est possible d’obtenir des traitements appropriés pour réduire la consommation de la batterie de l’équipement utilisateur et contribuer à augmenter sa durée d’utilisation. Dans des modes particuliers de mise en œuvre du procédé de communication, celui-ci comprend en outre une étape de réception en provenance de l’entité réseau de données relatives à un traitement visant à optimiser la consommation énergétique de l’équipement utilisateur. De telles données sont, par exemple, des paramètres de mise en veille de l’équipement utilisateur, un identifiant d’une tranche réseau à utiliser ou à ne plus utiliser pour un service donné, un indicateur de BWP définie par défaut pour l’ensemble des services requis par l’équipement utilisateur, etc. L’invention s’appuie également sur une entité du réseau capable d’obtenir un traitement visant à optimiser une consommation énergétique de l’équipement utilisateur. Ainsi, selon un deuxième aspect, l’invention concerne un procédé mis en œuvre par une entité d’un réseau de télécommunications, comprenant : la réception, depuis un équipement utilisateur du réseau, d’au moins une information relative à la consommation énergétique de l’équipement utilisateur ; l’obtention d’un traitement visant à optimiser une consommation énergétique de l’équipement utilisateur en fonction de ladite au moins une information relative à la consommation énergétique de l’équipement utilisateur pour : une pluralité de paramètres de transmission des données, et/ou une pluralité d’applications impliquées dans la transmission des données. Corrélativement, l’invention vise aussi une entité d’un réseau de télécommunication comprenant : un module de réception, configuré pour recevoir depuis un équipement utilisateur du réseau, au moins une information relative à la consommation énergétique de l’équipement utilisateur ; un module d’obtention configuré pour obtenir un traitement visant à optimiser une consommation énergétique de l’équipement utilisateur en fonction de ladite moins une information relative au statut énergétique de l’équipement utilisateur pour : une pluralité de paramètres de transmission des données, et/ou une pluralité d’applications impliquées dans la transmission des données. L’entité du réseau de télécommunications est par exemple une station de base du réseau (aussi appelée gNB dans le contexte d’un réseau 5G). Il peut s’agir d’une entité matérielle ou d’une entité logicielle, qui peut être répartie sur une ou plusieurs fonctions réseaux ou être hébergée par un ou plusieurs équipements matériels. Selon un troisième aspect, l’invention concerne un système de communication comprenant : au moins une entité d’un réseau de télécommunications selon l’invention ; et au moins un équipement utilisateur selon l’invention, rattaché à ladite au moins une entité du réseau. Le procédé, l’entité du réseau, et le système de communication selon l’invention présentent les mêmes avantages cités précédemment que le procédé de configuration et l’équipement utilisateur selon l’invention. Dans des modes particuliers de mise en œuvre, l’obtention du traitement est également fonction d’au moins une information relative à un statut d’une batterie de l’équipement utilisateur. Il devient alors possible d’obtenir des traitements appropriés pour réduire la consommation de la batterie de l’équipement utilisateur et contribuer à augmenter sa durée d’utilisation. Dans des modes particuliers de mise en œuvre du procédé, celui-ci comprend l’envoi à une autre entité du réseau d’une demande d’obtention du traitement générée au moyen de l’information relative au statut énergétique. D’autres entités du réseau disposant de plus de puissance de calcul ou ayant accès à des informations supplémentaires peuvent ainsi déterminer le traitement visant à optimiser une consommation énergétique d’un équipement utilisateur. Dans un mode particulier de mise en œuvre du procédé, l’obtention du traitement visant à optimiser la consommation énergétique comprend : la détermination, en fonction de l’information relative à un statut énergétique de l’équipement utilisateur, d’une partie de bande passante destinée à être activée par l’équipement utilisateur pour transmettre un trafic relatif au service. Grâce à l’invention, l’entité du réseau peut déterminer la BWP à activer de manière plus judicieuse conduisant à l’adoption de compromis entre la satisfaction des exigences de QoS des services requis par l’équipement utilisateur et l’efficacité énergétique de ce dernier plus équitables. Il convient de noter que ce mode de mise en œuvre de l’invention peut être avantageusement mise en œuvre de sorte à adapter dynamiquement la ou les BWP à activer par l’équipement utilisateur. Ce mode de mise en œuvre de l’invention est très simple à mettre en œuvre. En effet, il s’appuie sur des mécanismes déjà implémentés par l’équipement utilisateur et par le réseau (basculement d’une BWP vers une autre, basculement vers une BWP par défaut à l’expiration d’un délai d’inactivité, utilisation du mécanisme DRX, etc.), qui sont adaptés pour les besoins de l’invention moyennant une faible complexité et qu’elle vient compléter. Ainsi, lorsqu’il est mis en œuvre permet d’améliorer l’efficacité énergétique notamment en contribuant à la réalisation d’économies d’énergie supplémentaires sans pour autant sacrifier les exigences de QoS des services requis par l’équipement utilisateur. Ce mode de mise en œuvre est de plus compatible avec la contrainte imposée par le standard 3GPP selon laquelle un équipement utilisateur ne peut avoir qu’une unique BWP active à un instant donné (il convient toutefois de noter que l’invention s’applique également en l’absence de cette contrainte). Dans des modes particuliers de mise en œuvre du procédé, celui-ci comprend l’envoi, à l’équipement utilisateur, de données relatives au traitement visant à optimiser la consommation énergétique de l’équipement utilisateur. Avantageusement, l’invention propose de transmettre ces données dans un message de configuration tel qu’un message RRC. Bien entendu, d’autres types de messages de configuration peuvent être utilisés en variante pour communiquer à l’équipement utilisateur les informations relatives au traitement àa appliquer déterminé au moyen de l’invention. Dans un mode particulier de réalisation, les procédés objet de l’invention sont mis en œuvre par un ordinateur. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité d’un réseau de télécommunications conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un équipement utilisateur conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de communication tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash. D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés selon l’invention. On peut également envisager, dans d'autres modes de réalisation, que les procédés selon l’invention, l’entité du réseau, l’équipement utilisateur et le système de communication selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées. 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 : FIG. 1 la FIG. 1 , représente un système de communication dans un réseau de télécommunications, conforme à l’invention, dans un mode particulier de réalisation ; FIG. 2 la FIG. 2 représente schématiquement l’architecture matérielle d’un ordinateur sur laquelle s’appuient une entité du réseau et un équipement utilisateur conformes à l’invention, appartenant au système de communication de la FIG. 2 ; FIG. 3 la FIG. 3 représente, sous forme d’ordinogramme, les principales étapes d’un procédé de communication selon l’invention, telles qu’elles sont mises en œuvre par un équipement utilisateur conforme à l’invention appartenant au système de communication de la FIG. 1 ; FIG. 4 la FIG. 4 représente sous forme d’ordinogramme, les principales étapes d’un procédé selon l’invention, telles qu’elles sont mises en œuvre par une entité du réseau conforme à l’invention appartenant au système de communication de la FIG. 1 , FIG. 5 la FIG. 5 représente sous forme d’ordinogramme, les principales étapes décrit les principales étapes d’un premier exemple d’obtention d’un traitement visant à optimiser l’efficacité énergétique de l’équipement utilisateur conforme à l’invention appartenant au système de communication de la FIG. 1 . Description de l’invention La FIG. 1 représente, dans son environnement, un système 1 de communication, conforme à l’invention dans un mode particulier de réalisation. Dans ce mode de réalisation, le système 1 comprend : au moins une entité 2 d’un réseau de télécommunications NW, conforme à l’invention ; et au moins un équipement utilisateur ou UE 3 du réseau de télécommunications NW, rattaché à ladite au moins une entité 2, et conforme à l’invention. Dans la suite de la description et sur la FIG. 2 , par souci de simplification, on considère une seule entité 2 et un seul équipement utilisateur 3 rattaché à cette entité 2. Dans l’exemple de la FIG. 2 , le réseau de télécommunications NW est un réseau 5G NR tel que défini par le standard 3GPP (aux adaptations près nécessaires à la mise en œuvre de l’invention, décrites ci-après). Il met en œuvre notamment la fonctionnalité BWP. Chaque BWP est caractérisée par une numérologie (espacement de sous-porteuse et longueur de préfixe cyclique) et par un nombre de blocs physiques de ressources ou PRB (pour « Physical Resource Block » en anglais) consécutifs respectant cette numérologie. Elle commence à un certain bloc de ressource commun (ou CRB pour « Common Ressource Block » en anglais) dont l’emplacement est identifié par rapport à un CRB servant de référence à toutes les numérologies, aussi appelé point de référence A (ou « Reference point A » en anglais). Des BWP différentes peuvent utiliser la même numérologie mais avoir des largeurs de bande différentes. En fonction du ou des services utilisés par un UE, l’activation d’une BWP peut s’avérer plus pertinente qu’une autre, notamment en raison de la numérologie associée à cette BWP. En effet, comme souligné précédemment, les numérologies plus élevées sont particulièrement bien adaptées aux services requérant des latences faibles, comme par exemple les services uRLLC, tandis que les numérologies moins élevées sont plus adaptées aux services eMBB requérant de très hauts débits. Il n’est donc pas optimal d’utiliser une même numérologie pour deux services présentant des contraintes (ou SLA) différentes. Les différents services utilisés par l’UE 3 peuvent être fournis au moyen de plusieurs applications déployées sur l’UE et s'exécutant en utilisant les services du système d'exploitation de l’UE pour utiliser les ressources logicielles et/ou matérielles de ce dernier. Dans ce contexte et dans le mode de réalisation décrit ici, l’entité 2 conforme à l’invention est une station de base (aussi appelée gNode B ou gNB) du réseau NW, couvrant au moins une cellule CELL du réseau NW à laquelle l’UE 3 est rattaché et via laquelle l’UE 3 peut accéder aux services offerts par le réseau NW. On suppose ici que la cellule CELL est configurée avec au moins une fréquence porteuse CF à laquelle l’opérateur du réseau NW a alloué une bande passante BW(CF). Ainsi, la fonctionnalité BWP permet à l’UE 3 d’utiliser en transmission (en DL et/ou en UL) une partie seulement (BWP) de la bande passante BW(CF) associée à une certaine numérologie µ (désignée dans la suite par « partie de bande passante BWP/µ »), lorsqu’il est rattaché à la cellule CELL. Il convient de noter que l’invention peut s’appliquer dans d’autres contextes ou à d’autres architectures que celle décrite ici, comme par exemple dans un contexte Open-RAN ou dans un réseau de future génération, ou encore dans un réseau propriétaire.. De façon connue en soi, le réseau de télécommunications NW permet d’offrir une pluralité de services à ses abonnés, chaque service étant associé à des contraintes spécifiques, notamment en termes de latence, de fiabilité de transmission, etc., définies par un SLA (pour « Service Level Agreement » en anglais). A titre illustratif, on considère ici pour le réseau NW, les services suivants : un service S1 de type eMBB (ex. réalité virtuelle, réalité augmentée, diffusion vidéo HD, etc.), exigeant des débits de transmission de données élevés ; un service S2 de type uRLLC (ex. service de conduite autonome ou de gestion à distance) exigeant une faible latence (inférieure à une milliseconde) et une fiabilité élevée de transmission des données ; et un service S3 de type mMTC (ex. IoT) ayant une exigence élevée en termes de densité de déploiement. En outre, dans le mode de réalisation décrit ici, le réseau NW met en œuvre un découpage en tranches réseau ou « network slicing ». Chaque tranche réseau SL ou « network slice » est un sous-réseau logique s’appuyant sur l’infrastructure physique du réseau NW et auquel sont allouées des ressources spécifiques (ex. ressources matérielles, logicielle, etc.). Les différentes slices SL du réseau sont donc avantageusement isolées les unes des autres et disposent de ressources qui leur sont propres. Chaque slice offre ici un service distinct et est identifiée par un identifiant de slice unique, tel que par exemple un identifiant S-NSSAI (pour « Single – Network Slice Selection Assistance Information » en anglais) défini dans le standard 3GPP. Ainsi, dans l’exemple de la FIG. 2 , la slice SL(S1) est configurée pour offrir le service S1 et identifiée par l’identifiant S-NSSAI1, la slice SL(S2) est configurée pour offrir le service S2 et identifiée par l’identifiant S-NSSAI2, et la slice SL(S3) est configurée pour offrir le service S3 et identifiée par l’identifiant S-NSSAI3. Il en résulte que selon cette configuration, non seulement le S-NSSAIn associée à une slice SL(Sn), n désignant un entier égal à 1, 2 ou 3 dans l’exemple envisagé, identifie de façon unique cette slice mais également le service Sn qu’elle offre. On suppose ici, à titre illustratif, que l’UE 3 est connecté simultanément à plusieurs slices du réseau NW, et plus particulièrement aux slices SL(S1) et SL(S2) via lesquelles il peut accéder respectivement aux services S1 et S2. Bien entendu, ces hypothèses ne sont pas limitatives en soi et cet exemple n’est donné qu’à titre illustratif. Ainsi, d’autres services peuvent être offerts par le réseau NW en complément ou en variante des services précités, comme par exemple un service de type V2x (qui peut, selon le scénario envisagé, requérir une latence inférieure à quelques millisecondes et une fiabilité proche de 100% (scénarios dits « Safety-related V2x » incluant la conduite autonome par exemple), ou en variante, un débit élevé, une latence plus élevée et une fiabilité faible (scénarios dits « Non-Safety-related V2x » incluent par exemple les divertissements mobiles à hauts débits), un service de type HMTC (requérant une faible latence, une haute disponibilité et des débits élevés), etc. Le réseau NW peut en outre offrir plusieurs services distincts de chaque catégorie. Par ailleurs, l’UE 3 peut être connecté à un nombre différent de slices et/ou à des services différents. En effet, comme mentionné précédemment, conformément au standard 3GPP, un UE peut être connecté à une ou plusieurs slices (jusqu’à 8 simultanément). Enfin, on peut également envisager que le réseau NW offre une pluralité de services présentant des contraintes différentes sans mettre en œuvre de network slicing. Chaque service offert par le réseau NW est alors identifié de manière unique, par exemple à l’aide d’un identifiant de service. Dans le mode de réalisation décrit ici, la gNB 2 et l’UE 3 ont l’architecture matérielle d’un ordinateur 4 telle qu’illustrée à la FIG. 2 . Cette architecture matérielle comprend notamment un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communication permettant à la gNB 2 et à l’UE 3 notamment de communiquer entre eux. La mémoire non volatile NVM constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC et sur lequel est enregistré un programme conforme à l’invention. Ce programme, noté PROG2 lorsque l’architecture matérielle de l’ordinateur 4 est celle de la gNB 2, est enregistré dans la mémoire non volatile NVM et comporte des instructions définissant les principales étapes d’un procédé selon l’invention tel qu’il est mis en œuvre par la gNB 2 (entité du réseau au sens de l’invention). Il définit plus spécifiquement les modules fonctionnels de la gNB 2, qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 4 cités précédemment. Dans le mode de réalisation décrit ici, le programme PROG2 définit notamment les modules fonctionnels suivants de la gNB 2 (représentés sur la FIG. 2 ), qui sont activés pour chaque UE de la cellule CELL pour laquelle la gNB 2 est sollicitée pour transmettre en UL ou en DL des données associées à cet UE (plus particulièrement pour l’UE 3 dans l’exemple envisagé ici) : un module 2A de réception configuré pour recevoir, depuis l’UE 3, au moins une information relative à la consommation énergétique de l’UE 3, un module 2B d’obtention configuré pour obtenir un traitement visant à optimiser une consommation énergétique d’un équipement utilisateur transmettant des données via le réseau en fonction d’au moins une information relative au statut énergétique de l’équipement utilisateur pour au moins deux slices et/ou deux BWP et/ou deux applications, c’est-à-dire au moins deux programmes informatiques utilisés pour fournir une pluralité de services (aucune hypothèse n’est faite quant à la nature de ces applications) ; et un module 2C d’envoi, configuré pour envoyer à l’UE 3, des données relatives au traitement visant à optimiser la consommation énergétique de l’équipement utilisateur. Le fonctionnement des modules 2A, 2B et 2C de la gNB 2 est détaillé davantage ultérieurement en référence aux étapes du procédé mis en œuvre par une entité du réseau selon l’invention. Le programme d’ordinateur enregistré dans la mémoire non volatile NVM, lorsque l’architecture matérielle de l’ordinateur 4 est celle de l’UE 3, est noté PROG3 et comporte des instructions définissant les principales étapes d’un procédé de communication selon l’invention tel qu’il est mis en œuvre par l’UE 3. Il définit plus spécifiquement les modules fonctionnels de l’UE 3, qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 4, cités précédemment. Le programme PROG3 définit notamment, dans le mode de réalisation décrit ici, les modules fonctionnels de l’UE 3 suivants (représentés sur la FIG. 2 ) : un module 3A de transmission, configuré pour transmettre, à destination de la gNB 2, au moins une information relative à la consommation énergétique de l’UE 3, un module 3B de réception, configuré pour recevoir des données relatives au traitement visant à optimiser la consommation énergétique de l’UE 3 obtenu par la gNB 2 ; et un module 3C d’application, configuré pour appliquer le traitement visant à optimiser la consommation énergétique de l’UE 3 suite à la réception par le module 3B de réception des données relatives au traitement obtenu par la gNB 2. Le fonctionnement des modules 3A, 3B et 3C de l’UE 3 est détaillé davantage ultérieurement en référence aux étapes du procédé de communication selon l’invention. La FIG. 3 décrit les principales étapes d’un procédé de communication selon l’invention telles qu’elles sont mises en œuvre par l’UE 3 dans un mode particulier de réalisation. Les étapes du procédé de communication décrites ci-après illustrent comment l’UE 3 collecte des informations relatives à son statut énergétique et génère un message comprenant ces informations destiné à être transmis à la gNB 2 conformément à l’invention, dans un mode particulier de réalisation. Plus précisément, l’UE 3 collecte une pluralité d’informations relatives à son statut énergétique (étape E00). Une telle collecte peut être effectuée de façon continue ou ponctuelle selon les modes de mise en œuvre considérés. Une telle collecte d’informations relatives au statut énergétique de l’UE 3 s’effectue ici par application. En d’autres termes, la collecte d’informations relatives au statut énergétique de l’UE 3 s’effectue pour chacun des programmes informatiques utilisés pour fournir les différents services utilisés par l’UE 3. De manière plus spécifique, le système d’exploitation de l’UE 3 peut mettre en œuvre un ou plusieurs mécanismes pour surveiller et rapporter l'utilisation de l’énergie électrique stockée dans une batterie (non représentée sur les figures) de l’UE 3. Un premier mécanisme s’appuie sur l’outil connu Batterystats, conçu pour collecter des données sur la batterie de l’équipement sur lequel il est installé. Cet outil maintient une base de données interne dans laquelle est enregistrée l'utilisation de la batterie pour chaque application en cours d’exécution ou ayant été exécutée dans une fenêtre temporelle donnée, telle que les trois derniers jours écoulés ou depuis la dernière charge complète de la batterie, etc. Ces statistiques comprennent également le temps d'utilisation en arrière-plan, et d'autres détails pertinents. Dans un autre exemple, certaines applications déployées sur l’UE 3 peuvent également inclure nativement des fonctionnalités leur permettant de surveiller l'utilisation qu’elles font de la batterie de l’UE 3 et ensuite de partager cette connaissance avec le système d’exploitation. Il est important de noter que les données collectées relatives à la consommation de la batterie sont habituellement utilisées à des fins de diagnostic et d'amélioration des performances. Les informations relatives au statut énergétique de l’UE 3 collectées par l’UE 3 peuvent consister en des informations relatives à une consommation énergétique de l’UE 3 et/ou en des informations relatives au statut de la batterie de l’UE 3 telles que : un taux de consommation d’énergie, donné par exemple en pourcentage ; une durée de consommation, donnée par exemple en minutes, en heures ou en jours ; une valeur d’énergie consommée, donnée par exemple en milliwattheures (mWh), ou encore un taux d’autonomie, donné par exemple en pourcentage (un taux de 50% signifiant, par exemple, que la batterie a consomme la moitié de sa charge) ; une durée d’autonomie, donnée par exemple en minutes, en heures ou en jours ; un taux de charge, donné par exemple en pourcentage (un taux de 100% correspondant, par exemple, à une batterie totalement chargée) ; une durée de charge, donnée par exemple en minutes, en heures ou en jours. Une telle liste est donnée à titre d’exemple et se veut non exhaustive et non limitative de l’invention. Il convient de noter qu’une ou plusieurs de ces informations peuvent être utilisées par la gNB 2 pour obtenir un traitement visant à optimiser la consommation énergétique de l’UE 3 à appliquer. Dans la suite de la description et à des fins de simplification, l’information relative à un statut énergétique de l’UE 3 utilisée pour déterminer ce traitement est le taux d’autonomie de la batterie de l’UE 3. L’UE 3 ayant collecté des informations relatives à son statut énergétique par application (étape E00), il peut déterminer, de manière optionnelle, une information relative à son statut énergétique pour une slice SL(S1), SL(S2) ou pour une BWP. En effet, une application étant un programme informatique utilisé pour fournir un service ou une pluralité de services à l’équipement utilisateur, elle est nécessairement associée à une BWP et/ou à une slice SL(S1), SL(S2). Ainsi, l’UE 3 ayant collecté les informations relatives à son statut énergétique pour plusieurs applications et connaissant le type de service fourni par chacune d’entre elles, il est capable d’associer un identifiant de slice S-NSSAI1, S-NSSAI2 et/ou un indicateur de BWP à chacune d’entre elles (étape E10). Fort de ces informations relatives à son statut énergétique, l’UE 3 génère (étape E20) au moins un message comprenant au moins l’une de ces informations destiné à être transmis à la gNB 2. Un tel message est, par exemple, un message RRC particulier appelé « UEAssistanceInformation », par exemple tel que défini dans le standard 3GPP TS 38.331 version 16.1.0 Release 16, qui est modifié pour les besoins de l’invention afin de pourvoir transporter cette information relative à un statut énergétique de l’équipement utilisateur. Bien entendu, d’autres types de messages peuvent être utilisés pour transmettre ces informations. Un exemple des champs spécialement introduits pour les besoins de l’invention dans un message « UEAssistanceInformation » est le suivant : UEAssistanceInformation-v1540-IEs ::= SEQUENCE { powerPrefIndicationPerSlice ENUMERATED {very high for slice SL(S1), high for slice SL(S2), normal, lowPowerConsumption, very low} OPTIONAL powerPrefIndicationPerBWP ENUMERATED {very high for BWP 1, high for BWP 2, normal, lowPowerConsumption, very low} OPTIONAL powerPrefIndicationPerApplication ENUMERATED {very high for application App1, high, normal, lowPowerConsumption, very low} OPTIONAL powerPrefIndication-RelativePerSlice ENUMERATED {higher for slice SL(S1), much higher, lower, same, much lower} OPTIONAL powerPrefIndication-RelativePerBWP ENUMERATED { higher for BWP 1, much higher, lower, same, much lower } OPTIONAL powerPrefIndication-RelativePerApplication ENUMERATED { higher for application App1, much higher, lower, same, much lower } OPTIONAL batteryConsumptionDescriptionPerSlice ENUMERATED {low for slice SL(S1), medium for slice SL(S2), high} OPTIONAL batteryConsumptionDescriptionPerBWP ENUMERATED {low for BWP 1, medium for BWP 2, high} OPTIONAL batteryConsumptionDescriptionPerApplication ENUMERATED {low for application App1, medium for application App2, high for application 3} OPTIONAL batteryConsumptionPercentagePerSlice ENUMERATED {10; 80} for slice ENUMERATED {SL(S1), SL(S2)} OPTIONAL batteryConsumptionPercentagePerBWP ENUMERATED {15; 65} for BWP ID ENUMERATED {1;2} OPTIONAL batteryConsumptionPercentagePerApplication ENUMERATED {10; 25; 35} for Application ID ENUMERATED {App1; App2; App3} OPTIONAL batteryConsumptionHoursPerSlice ENUMERATED {1; 12} for slice ENUMERATED {SL(S1); SL(S2) } OPTIONAL batteryConsumptionHoursPerBWP ENUMERATED {4; 0.5} for BWP ID ENUMERATED {1;2} OPTIONAL batteryConsumptionHoursPerApplication ENUMERATED {3; 0; 5} for Application ID ENUMERATED {App1; App2, App3} OPTIONAL batteryConsumptionHours_mWhPerSlice ENUMERATED {0.5; 1.5} for slice ENUMERATED {SL(S1); SL(S2)} OPTIONAL batteryConsumptionHours_mWhPerBWP ENUMERATED {0.5; 2} for BWP ID ENUMERATED {1;2} OPTIONAL batteryConsumptionHours_mWhPerApplication ENUMERATED {1.5; 0.4; 2.7} for Application ID ENUMERATED {App1; App2; App3} OPTIONAL … } Dans l’exemple ci-dessus le message « UEAssistanceInformation » comprend des informations relatives au statut énergétique de l’UE 3 pour deux slices SL(S1) et SL(S2), deux BWP 1 et 2, et pour trois applications App1, App2 et App3. Il convient de préciser qu’un tel message « UEAssistanceInformation » conforme à l’invention peut comprendre des informations relatives au statut énergétique de l’UE 3 pour au moins deux slices et/ou deux BWP et/ou deux applications. Le contenu d’un tel message « UEAssistanceInformation » est déterminé en fonction de contraintes d’exploitation du réseau NW. Plus particulièrement, la valeur du champ « powerPrefIndicationPerSLice/PerBWP/PerApplication », du champ et « powerPrefIndication-RelativePerSLice/PerBWP/PerApplication » et du champ « batteryConsumptionDescriptionPerSLice/PerBWP/PerApplication » indique de manière nominative les préférences énergétiques d’une slice, d’une BWP ou d’une application. La valeur du champ « batteryConsumptionPercentagePerSLice/PerBWP/PerApplication », quant à elle comprend une liste ordonnée de nombres représentant chacun une valeur d’un pourcentage de consommation relatif à une slice ou une BWP ou une application lesquelles sont listées dans le champ « ENUMERATED ». Plus particulièrement, la première valeur 10 du champ « batteryConsumptionPercentagePerSlice » correspond à la première slice SL(S1) et la deuxième valeur 80 correspond à la slice SL(S2). Il en est de même pour le champ « batteryConsumptionPercentagePerBWP » où la première valeur 15 correspond à la BWP 1 ou encore pour le champ « batteryConsumptionPercentagePerApplication » où la troisième valeur 35 correspond à l’application App3. Le principe reste le même pour les champs « batteryConsumptionHoursPer SLice/PerBWP/PerApplication » dans lequel les nombres listés représentent chacun une valeur d’une durée d’autonomie de la batterie de l’UE 3 relative à une slice ou une BWP ou une application listées dans le champ « ENUMERATED » ; et pour le champ « batteryConsumptionHours_mWhPerSLice/BWP/Application » dans lequel les nombres listés représentent chacun une valeur d’une consommation en mWh de la batterie de l’UE 3 relative à une slice ou une BWP ou une application également listées dans le champ « ENUMERATED ». Une fois le message « UEAssistanceInformation » généré, l’UE 3 le transmet à destination de la gNB 2 via son module 3A de transmission (étape E30). L’UE 3 reçoit, via son module 3B de réception, un ou plusieurs messages en provenance du module 2B de la gNB 2 (étape E40). Ce ou ces messages comprennent des données relatives à un traitement visant à optimiser la consommation énergétique de l’UE 3. Suite à la réception de ces données, le module 3C d’application de l’UE 3 applique le traitement en question (étape E50). Les étapes E00 à E50 sont ensuite réitérées périodiquement. Dans un autre mode de réalisation, les étapes E00 à E50 peuvent être répétées sur détection d’un événement particulier par exemple, un nouveau service autorisé pour l’UE 3, et/ou l’apparition d’un trafic entrant pour un service donné et/ou une modification d’une valeur d’au moins l’une des informations relatives à un statut énergétique de l’UE 3. Il convient de noter que dans ces différents modes de réalisation, les étapes E00 à E50 sont exécutées pour déterminer de façon dynamique un traitement visant à améliorer l’efficacité énergétique de l’UE 3. La FIG. 4 décrit les principales étapes d’un procédé selon l’invention telles qu’elles sont mises en œuvre par la gNB 2 dans un mode particulier de réalisation. Un tel procédé permet l’obtention du traitement visant à optimiser la consommation énergétique de l’UE 3 en fonction des informations relatives à un statut énergétique de l’UE 3 reçues pour une slice et/ou une BWP et/ou une application. Plus particulièrement, la gNB 2 reçoit, en provenance de l’UE 3 et par exemple via ses moyens COM et son module 2A de réception, au moins un message « UEAssistanceInformation » tel que décrit précédemment comprenant des informations relatives au statut énergétique de l’UE 3 pour au moins deux slices et/ou deux BWP et/ou deux applications. (étape F10). Dans une première mise en œuvre de ce procédé, à réception de ce message « UEAssistanceInformation », la gNB 2 transmet (F20’) une demande d’obtention DOT du traitement à appliquer pour améliorer l’efficacité énergétique de l’UE 3 à une autre entité du réseau NW. La demande DOT peut comprendre tout ou partie des informations comprises dans le message « UEAssistanceInformation ». Des exemples de traitements sont discutés plus loin dans le document. L’autre entité du réseau NW détermine alors le traitement à appliquer pour améliorer l’efficacité énergétique de l’UE 3 en fonction des informations transmises par la gNB 2 et des contraintes d’exploitations du réseau NW. Un tel traitement peut consister en la détermination de paramètres de mise en veille de l’UE 3 ou encore en l’association d’un type de service à une autre slice que la slice courante, etc. Une fois le traitement à appliquer déterminé, l’autre entité du réseau transmet un ou plusieurs messages comprenant des données relatives à ce traitement à la gNB2 et/ou ou à destination d’une deuxième entité du réseau NW si tout ou partie du traitement déterminé est destinée à être mise en œuvre plus en amont dans le réseau NW (étape F30’). La gNB 2 peut alors appliquer le traitement (étape F40’) si certaines des données reçues lui sont destinées et/ou transmettre ces données à destination de l’UE 3 (étape E40 du procédé de communication). Dans une deuxième mise en œuvre de ce procédé, à réception de ce message « UEAssistanceInformation », la gNB 2 obtient elle-même le traitement à appliquer (étape F20). Là aussi, une fois le traitement à appliquer déterminé, la gNB 2 transmet (étape F30) un ou plusieurs messages comprenant des données relatives à ce traitement à destination de l’UE 3 (étape E40 du procédé de communication) et/ou à destination d’une autre entité du réseau NW si tout ou partie du traitement déterminé est destinée à être mise en œuvre plus en amont dans le réseau NW. La FIG. 5 décrit les principales étapes d’un premier exemple d’obtention d’un traitement visant à optimiser l’efficacité énergétique de l’UE 3 conforme à l’invention, dans un mode particulier de réalisation. Ces étapes peuvent être mises en œuvre soit par la gNB 2 au cours de l’étape F20, soit par une autre entité du réseau suite à l’étape F20’. A des fins de simplification, ce premier exemple d’obtention est décrit dans le cas de figure où les différentes étapes sont mises en œuvre par la gNB 2. La seule différence qui existe entre la mise en œuvre de ces étapes par la gNB 2 et l’autre entité du réseau concerne l’évènement déclenchant l’exécution de ces étapes. En effet, lorsque les étapes conduisant à l’obtention du traitement sont mises en œuvre par la gNB 2, leur exécution est déclenchée par la réception des informations relatives au statut énergétique de l’UE 3 au cours de l’étape F10. De manière alternative, lorsque les étapes conduisant à l’obtention du traitement sont mises en œuvre par l’autre entité du réseau, leur exécution est déclenchée par la réception de la demande DOT au cours de l’étape F20’. Ainsi, la gNB 2 reçoit un message « UEAssistanceInformation » contenant des informations relatives au statut énergétique de l’UE 3 (étape F10/G10). Dans un premier mode de mise en œuvre, la gNB 2 détermine si une valeur du taux d’autonomie TAut de la batterie de l’UE 3 est inférieure à un premier seuil Thr1. Le seuil Thr1 est défini comme étant un seuil bas indiquant que le statut énergétique de l’UE 3 nécessite de prêter une attention particulière pour faire fonctionner l’équipement utilisateur (étape test G20). A titre d’exemple non limitatif, la valeur du seuil Thr1 est fixée à 20%. Bien entendu, d’autres valeurs peuvent être envisagées pour le seuil Thr1, ces dernières étant déterminées pour satisfaire aux contraintes d’exploitation du réseau NW. Si la valeur du taux d’autonomie TAut de la batterie de l’UE 3 est inférieure au seuil Thr1 (réponse oui à l’étape test G20), la gNB 2 détermine, via son module 2B, une BWP par défaut BWP def /µ def pour l’ensemble des services S1, S2, S3 indépendamment de leurs contraintes respectives (étape G30). Une telle BWP par défaut BWP def /µ def est par exemple une BWP étroite, ou la BWP la plus étroite parmi une pluralité de BWP présentant la même numérologie µ def . Ainsi, l’indicateur de BWP identifiant la BWP par défaut BWP def /µ def constituant les données relatives au traitement à appliquer est transmis à l’UE 3qui n’a plus besoin de basculer d’une BWP à une autre. Tant que la situation énergétique de l’UE 3 reste inchangée, c’est-à-dire tant que la réponse au test de l’étape G20 est oui, l’indicateur de BWP compris dans les informations de de contrôle DCI transmises de façon régulière par la gNB 2 à destination de l’UE 3 reste l’indicateur de la BWP par défaut BWP def /µ def . Si la réponse au test de l’étape G20 est non, c’est-à-dire lorsque la valeur du taux d’autonomie TAut de la batterie de l’UE 3 est supérieure ou égale au seuil Thr1, la gNB 2 détermine si la valeur du taux d’autonomie TAut de la batterie de l’UE 3 est supérieure ou égale à un deuxième seuil Thr2 (étape test G40). Dans ce deuxième mode de mise en œuvre, le seuil Thr2 est considéré comme un seuil haut indiquant que le statut énergétique de l’UE 3 est optimal. C’est par exemple le cas lorsque la batterie de l’UE 3 est en charge, e.g. lorsque l’UE 3 est connecté à un réseau de fourniture d’électricité. A titre d’exemple non limitatif, la valeur du seuil Thr2 est fixée à 50%. Bien entendu, d’autres valeurs peuvent être envisagées pour le seuil Thr2, ces dernières étant déterminées, tout comme pour le seuil Thr1, pour satisfaire aux contraintes d’exploitation du réseau NW. Si la valeur du taux d’autonomie TAut de la batterie de l’UE 3 est supérieure ou égale au seuil Thr2 (réponse oui à l’étape test G40), la gNB 2 détermine alors si un indicateur de surchauffe HeatIdx est activé ou non (étape G50). Comme déjà évoqué plus haut, l’activation d’un tel indicateur de surchauffe HeatIdx peut indiquer une consommation d’énergie anormalement élevée laquelle a un impact sur l’autonomie de la batterie et de manière plus générale sur le fonctionnement de l’UE 3. Il est donc important d’adapter la transmission des données à cette situation. Lorsque la réponse au test de l’étape G50 est non, c’est-à-dire lorsque l’indicateur de surchauffe HeatIdx n’est pas activé, la gNB 2 détermine, de manière optionnelle, si un mode de réception discontinue de l’UE 3, tel que le mécanisme DRX précédemment décrit, est activé (test de l’étape G60) afin de déterminer si des mesures d’économie d’énergie sont déjà mises en œuvre au sein de l’UE 3. Cette information évite à la gNB 2 de déterminer une BWP à activer qui ne serait pas en adéquation avec la situation énergétique de l’UE 3. Lorsque la réponse au test de l’étape G60 est non, c’est-à-dire lorsque le mécanisme DRX n’est pas mis en œuvre au sein de l’UE, la gNB 2 décide d’utiliser la BWP la plus appropriée pour le service S1 et pour le service S2. A cette fin, la gNB 2 sélectionne une première BWP BWP optS1 /µ optS1 permettant de satisfaire le SLA du service S1 et une deuxième WP BWP optS2 /µ optS2 permettant de satisfaire le SLA du service S2 (étape G70). Les indicateurs identifiant la première BWP BWP optS1 /µ optS1 et la deuxième BWP BWP optS2 /µ optS2 constituent les données relatives au traitement à appliquer. Afin de pouvoir transmettre des données relatives au service S1 et au service S2, l’UE 3 bascule de manière classique de la première BWP BWP optS1 /µ optS1 à la BWP optS2 /µ optS2 au gré des informations de contrôle DCI reçues lesquelles comprennent l’indicateur de la BWP à activer à un horaire donné pour bénéficier du service correspondant. Les informations de contrôle DCI sont comprises dans des messages RRC transmis de manière épisodique au fil du temps. Il est néanmoins possible, de manière optionnelle, d’adapter la durée séparant la transmission de deux messages RRC consécutifs et, le cas échéant sortir d’un schéma de transmission périodique. Ainsi, dans l’exemple envisagé ici, la gNB 2 peut en outre décider d’augmenter, par rapport à sa valeur courante, la fréquence de transmission entre deux messages RRC consécutifs. Cela a pour conséquence d’augmenter la fréquence de basculement entre la première BWP BWP optS1 /µ optS1 et la deuxième BWP BWP optS2 /µ optS2 ce qui permet de contribuer davantage à la satisfaction des SLA respectifs des services S1 et S2. De retour à l’étape G60, si la réponse au test est oui, c’est-à-dire si le mécanisme DRX est mis en œuvre au sein de l’UE, la gNB 2 décide alors de prioriser un service parmi l’ensemble des services auxquels accède l’UE 3. Afin de déterminer quel service prioriser parmi l’ensemble des services auxquels accède l’UE 3, la gNB peut vérifier plusieurs critères. Plus particulièrement, la gNB 2 peut déterminer, parmi l’ensemble des services S1, S2 auxquels l’UE 3 est connecté lequel présente une volumétrie de trafic la plus élevée. La volumétrie représente, pour une durée donnée, le nombre de paquets de données à transmettre pour l’UE 3 pour un service donné. Si par exemple le service S1 présente une volumétrie plus élevée que le service S2, alors la gNB 2 détermine que le service prioritaire est le service S1. Dans le cas de figure où l’ensemble des services S1 et S2 présentent des volumétries suffisamment proches, la gNB peut déterminer si au moins l’un des services S1, S2 est un service de type uRLLC. De façon connue en soi, un service uRLLC, ici le service S2, est considéré comme prioritaire, en raison de la faible latence qu’il supporte (inférieure à un seuil donné à savoir, une milliseconde). Les autres services, tels que les services eMBB ou mMTC, sont considérés comme non prioritaires. Si plusieurs services S1, S2 auxquels l’UE 3 est connecté sont des services de type uRLLC ou si aucun service parmi les services S1 et S2 n’est un service de type uRLLC, la gNB 2 peut alors déterminer pour l’ensemble des services S1, S2 la largeur de la BWP BWP optS1 /µ optS1 et la largeur de la BWP BWP optS2 /µ optS2 permettant de satisfaire les SLA respectifs des services S1 et S2. Le service prioritaire est alors le service Sn pour lequel la BWP BWP optSn /µ optSn est la plus étroite parmi l’ensemble des BWP BWP optSn /µ optSn . Enfin, si malgré tout cela, la gNB 2 n’a toujours pas identifié un service prioritaire parmi les services S1 et S2, elle peut déterminer la disponibilité des ressources physiques caractérisant respectivement la BWP BWP optS1 /µ optS1 et la BWP BWP optS2 /µ optS2 . La gNB 2 identifie comme étant le service prioritaire le service pour lequel les ressources nécessaires à la transmission de données sont disponibles. Il convient de noter que la gNB 2 peut procéder à des tests se basant sur d’autres critères pour identifier un service prioritaire. Le nombre de tests effectués par la gNB 2 pour identifier un service prioritaire peut également varier et n’est pas limiter à 4 comme dans l’exemple décrit. Une fois encore, ces choix se fondent, entre autres, sur les contraintes d’exploitation du réseau NW et sont guidés par la recherche d’un compromis entre la satisfaction des exigences de QoS des services requis par l’UE 3 et l’efficacité énergétique de ce dernier. Une fois le service prioritaire identifié, la gNB 2 décide d’utiliser la BWP la plus appropriée pour le service S1 et pour le service S2 et sélectionne une première BWP BWP optS1 /µ optS1 permettant de satisfaire le SLA du service S1 et une deuxième WP BWP optS2 /µ optS2 permettant de satisfaire le SLA du service S2 tout comme elle l’a fait lorsque réponse au test de l’étape G60 est non (étape G80). Cependant, afin de prendre en compte l’activation du mode DRX, la gNB 2 décide également de modifier le schéma de transmission des messages RRC comprenant les informations de contrôle DCI relatives au service non prioritaire. Dans cette situation particulière, la gNB 2 réduit, par rapport à sa valeur courante, la fréquence de transmission entre deux messages RRC consécutifs comprenant des informations de contrôle DCI relatives au service non prioritaire. Parallèlement, la gNB 2 maintient la fréquence de transmission entre deux messages RRC consécutifs comprenant des informations de contrôle DCI relatives au service prioritaire à sa valeur courante. Cela a pour conséquence de réduire la fréquence de basculement entre la BWP BWP optSprioritaire /µ optSprioritaire affectée au service prioritaire et la BWP BWP optSnonprioritaire /µ optSnonprioritaire affectée au service non prioritaire. Une telle décision offre un compromis équilibré entre la satisfaction des SLA respectifs des services prioritaire et non prioritaire et l’efficacité énergétique de l’UE 3. De retour à l’étape G50, lorsque la réponse au test est oui, c’est-à-dire lorsque l’indicateur de surchauffe HeatIdx est activé, la gNB 2 détermine si le mode DRX est activé (test de l’étape G90) afin de déterminer si des mesures d’économie d’énergie sont déjà mises en œuvre au sein de l’UE 3. Lorsque le mode DRX n’est pas mis en œuvre au sein de l’UE, c’est-à-dire quand la réponse au test de l’étape G90 est non, la gNB 2 met en œuvre l’étape G80 précédemment décrite. Si au contraire, le mode DRX est activé (réponse oui à l’étape G90), la gNB met alors en œuvre l’étape G30. Les données relatives au traitement à appliquer comprennent l’indicateur de BWP identifiant la BWP par défaut BWP def /µ def ainsi déterminée. Ces données sont alors transmises à l’UE 3 qui n’a plus besoin de basculer d’une BWP à une autre. On peut également envisager un troisième mode de mise en œuvre adapté à la situation dans laquelle la valeur du taux d’autonomie TAut de la batterie de l’UE 3 est supérieure ou égale au premier seuil Thr1 et est inférieure au deuxième seuil Thr2 (étape G100). Dans un tel cas de figure, la gNB 2 détermine alors si un indicateur de surchauffe HeatIdx est activé ou non (étape G110). Lorsque la réponse au test de l’étape G110 est non, c’est-à-dire lorsque l’indicateur de surchauffe HeatIdx n’est pas activé, la gNB 2 met en œuvre l’étape E80. A contrario, lorsque l’indicateur de surchauffe HeatIdx est activé (réponse oui au test de l’étape G110), la gNB 2 met en œuvre l’étape G30. Des traitements autres que l’affectation d’une ou plusieurs BWP données à l’UE 3 permettent également d’optimiser l’efficacité énergétique de l’UE 3. Ainsi, la gNB2 ou l’autre entité du réseau peuvent déterminer des paramètres de mise en veille de l’UE 3. Un autre type de traitement peut consister à associer un type de service à une autre slice que la slice courante. Il est également possible de cesser d’utiliser une slice donnée, par exemple en la supprimant, etc. Procédé de communication mis en œuvre par un équipement utilisateur (3) d’un réseau de télécommunications (NW) via lequel ledit équipement utilisateur transmet des données, le procédé de communication comprenant l’envoi à une entité (2) du réseau de télécommunications, d’au moins une information relative à un statut énergétique de l’équipement utilisateur (3) pour : une pluralité de paramètres de transmission des données (SL(S1, SL(S2), BWP/µ), et/ou une pluralité d’applications (App1, App2, App3) impliquées dans la transmission des données. Procédé de communication selon la revendication 1 dans lequel un dit paramètre de transmission comprend au moins l’un parmi : un identifiant d’une tranche réseau (SL(S1), SL(S2)) supportée par le réseau, un indicateur d’une partie de bande passante (BWP/µ). Procédé de communication selon l’une quelconque des revendications 1 ou 2 dans lequel l’information relative à un statut énergétique de l’équipement utilisateur (3) comprend en outre au moins une information relative à un statut d’une batterie de l’équipement utilisateur. Procédé de communication selon l’une quelconque des revendications 1 à 3 dans lequel l’information relative à un statut énergétique de l’équipement utilisateur (3) appartient à un groupe comprenant : un taux de consommation d’énergie, une durée de consommation, une valeur d’énergie consommée. Procédé de communication selon la revendication 3 dans lequel l’information relative à un statut de la batterie de l’équipement utilisateur (3) appartient à un groupe comprenant : un taux d’autonomie, une durée d’autonomie, un taux de charge, une durée de charge. Procédé de communication selon l’une quelconque des revendications 1 à 5 comprenant en outre une étape de réception en provenance de l’entité réseau (2) de données relatives à un traitement visant à optimiser la consommation énergétique de l’équipement utilisateur (3). Procédé de communication selon l’une quelconque des revendications 1 à 6 dans lequel l’information relative au statut énergétique de l’équipement utilisateur (3) pour un paramètre de transmission des données (SL(S1, SL(S2), BWP/µ) est obtenue au moyen de l’information relative au statut énergétique de l’équipement utilisateur pour au moins une application (App1, App2, App3) transmettant des données conformément à ce paramètre de transmission. Procédé mis en œuvre par une entité (2) d’un réseau de télécommunications (NW) comprenant : la réception, depuis un équipement utilisateur (3) du réseau, d’au moins une information relative à la consommation énergétique de l’équipement utilisateur ; l’obtention d’un traitement visant à optimiser une consommation énergétique de l’équipement utilisateur en fonction de ladite au moins une information relative à la consommation énergétique de l’équipement utilisateur pour une pluralité de paramètres de transmission des données (SL(S1, SL(S2), BWP/µ), et/ou une pluralité d’applications (App1, App2, App3) impliquées dans la transmission des données. Procédé selon la revendication 8 dans lequel l’obtention du traitement est également fonction d’au moins une information relative à un statut d’une batterie de l’équipement utilisateur (3). Procédé selon les revendications 8 ou 9 dans lequel l’obtention du traitement visant à optimiser la consommation énergétique comprend : la détermination, en fonction de l’information relative à un statut énergétique de l’équipement utilisateur (3), d’une partie de bande passante (BWP/µ) destinée à être activée par l’équipement utilisateur pour transmettre un trafic relatif au service (S1, S2). Procédé selon l’une des revendications 8 à 10 comprenant l’envoi, à l’équipement utilisateur, de données relatives au traitement visant à optimiser la consommation énergétique de l’équipement utilisateur (3). Equipement utilisateur (3) d’un réseau de télécommunications (NW) via lequel il transmet des données comprenant un module de transmission (3A) configuré pour envoyer à une entité (2) du réseau de télécommunications, au moins une information relative à un statut énergétique de l’équipement utilisateur pour : une pluralité de paramètres de transmission des données (SL(S1, SL(S2), BWP/µ), et/ou une pluralité d’applications (App1, App2, App3) impliquées dans la transmission des données. Entité (2) d’un réseau de télécommunication (NW) comprenant : un module de réception (2A) configuré pour recevoir, depuis un équipement utilisateur (3) du réseau, au moins une information relative à la consommation énergétique de l’équipement utilisateur ; un module d’obtention (2B) configuré pour obtenir un traitement visant à optimiser une consommation énergétique de l’équipement utilisateur transmettant des données via le réseau en fonction d’au moins une information relative au statut énergétique de l’équipement utilisateur pour : une pluralité de paramètres de transmission des données (SL(S1, SL(S2), BWP/µ), et/ou une pluralité d’applications (App1, App2, App3) impliquées dans la transmission des données. Système de communication comprenant : au moins une entité d’un réseau de télécommunications selon la revendication 13 ; et au moins un équipement utilisateur selon la revendication 12, rattaché à ladite au moins une entité du réseau.