FR 3121568 A1 20221007 FR 2103445 A 20210402 Procédés de gestion, de communication et d’enregistrement, et entités configurées pour mettre en œuvre ces procédés. L’invention propose un procédé de gestion, par une entité (2) de contrôle d’un réseau (CN), d’une pluralité d’entités applicatives (NF1,…,NFN) proposant des services dans le réseau, ce procédé de gestion comprenant : - une étape d’enregistrement (E40) de chaque entité applicative gérée par l’entité de contrôle comprenant une mémorisation d’un profil de ladite entité applicative, ce profil comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle ; et - en réponse à une requête (F10) en provenance d’une première entité (3), une étape (F40) de fourniture à cette première entité, pour au moins une dite entité applicative gérée par l’entité de contrôle, d’au moins une partie de la pluralité d’attributs du profil de cette entité applicative, ladite partie comprenant ledit au moins un format d’encodage supporté par cette entité applicative. Figure 2 Procédés de gestion, d’enregistrement et de communication et entités configurées pour mettre en œuvre ces procédés L’invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement l’accès à des services offerts par des entités applicatives d’un réseau de télécommunications. L’invention a une application privilégiée mais non limitative dans le contexte des réseaux de télécommunications de 5 ème Génération (ou 5G) définis par le standard 3GPP (ou « Third Generation Partnership Project » en anglais). Les réseaux 5G tels que définis par le standard 3GPP exploitent de façon connue en soi des technologies de virtualisation de fonctions réseau (ou NFV pour « Network Function Virtualization » en anglais), de réseau défini par logiciel (ou SDN pour « Software Defined Networking » en anglais) et de découpage de réseaux en tranches, plus communément appelée « network slicing » en anglais. Ces technologies ouvrent des perspectives d’usage inédites des réseaux de télécommunications. Elles permettent notamment aux opérateurs de créer pour leurs clients des réseaux logiques virtuels de bout-en-bout, sur mesure et indépendants, évolutifs et agiles, et ce à partir d’une même infrastructure de réseau physique (réseau(x) d’accès, réseau cœur, etc.). Par le biais de ces réseaux logiques virtuels, les opérateurs sont capables de fournir à leurs clients des solutions optimisées pour des scénarii variés correspondant à des contraintes diverses en termes de fonctionnalités, de performances et de qualités de service. La virtualisation de fonctions réseau ou NFV s’appuie sur des serveurs standards pour exécuter des logiciels de services réseau (aussi appelées fonctions réseau ou NFs pour « Network Functions » en anglais), tandis que le réseau défini par logiciel ou SDN centralise le contrôle du réseau 5G par logiciel plutôt que via des équipements physiques. Grâce à cette virtualisation, les fonctions réseau peuvent être déployées et reconfigurées aisément, apportant ainsi plus d’élasticité. Diverses fonctions réseau d’un réseau cœur 5G peuvent être ainsi virtualisées, comme par exemple les fonctions réseau de gestion de l’accès et de la mobilité ou AMF (pour « Access Mobility Management Function » en anglais), de gestion de session ou SMF (pour « Session Management Function » en anglais), de sélection de tranche réseau ou NSSF (pour « Network Slice Selection Function » en anglais), de contrôle des politiques ou PCF (pour « Policy Control Function » en anglais), etc. Le contrôle de ces fonctions virtualisées dans le réseau cœur 5G est assuré par une autre fonction réseau appelée catalogue de fonctions réseau ou NRF (ou « Network Repository Function » en anglais). Cette fonction NRF est chargée de fournir à une fonction réseau cliente ou consommatrice (« consumer » en anglais) les informations lui permettant d’interagir, directement ou indirectement via un équipement intermédiaire (ou SCP pour « Service Communication Proxy » en anglais) avec une fonction réseau serveur (« producer » en anglais) proposant un ou plusieurs services dans le réseau. En effet, l’architecture de réseau 5G définie par le standard 3GPP est une architecture basée sur le service (ou SBA pour « Service Based Architecture » en anglais). Selon une telle architecture, les fonctionnalités d’un réseau 5G sont assurées par une pluralité de fonctions réseau (ou indifféremment fonctions NF dans la suite de la description) virtuelles qui fournissent des services à d’autres fonctions du réseau autorisées à accéder à ces services, une même fonction réseau pouvant offrir un ou plusieurs services. A cet effet, les fonctions NF du réseau cœur 5G présentent les services qu’elles offrent dans le contexte du cœur de réseau 5G (autrement dit leurs fonctionnalités) par l’intermédiaire d’interfaces se présentant sous forme d’APIs (pour « Application Programming Interfaces » en anglais) que les autres fonctions NF autorisées peuvent invoquer. Toutefois, au lieu d’interfaces prédéfinies entre les différentes fonctions NF pouvant interagir entre elles, un modèle de service est utilisé dans lequel les fonctions NF « consumer » interrogent la fonction réseau NRF pour découvrir les fonctions NF « producer » et communiquer avec elles sur les APIs qu’elles offrent. Ceci offre avantageusement aux opérateurs des réseaux 5G une grande flexibilité et une grande adaptabilité. La fonction réseau NRF est ainsi un catalogue gérant une pluralité de fonctions NF, et mémorisant les profils de chacune de ces fonctions NF. Chaque profil comprend une pluralité d’attributs, caractérisant l’état opérationnel de la fonction NF (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. type de fonction NF, comment elle peut être jointe, etc.), les services qu’elle offre, les ressources qu’elle gère, etc. Des attributs peuvent être définis également plus spécifiquement au niveau de chaque service (sinon ce sont ceux définis au niveau de la fonction NF qui s’appliquent). Ces profils permettent aux fonctions NF « consumer » de découvrir les fournisseurs de services et de caractéristiques particuliers dans le réseau. La fonction réseau NRF est mise à jour lors de l’activation et de la désactivation de chacune des fonctions NF qu’elle gère (i.e. lors de l’enregistrement et du désenregistrement de chacune d’entre elles) ainsi qu’à chaque redimensionnement d’une fonction NF (la fonction NRF peut gérer en effet plusieurs instances d’une même fonction NF). Elle propose aux fonctions NF du réseau cœur 5G différents services décrits notamment dans le document 3GPP TS 29.510 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 », v16.6.0, décembre 2020, à savoir : un service de découverte (service « Nnrf_NFDiscovery ») permettant à une fonction NF « consumer » de découvrir les instances d’une fonction NF « producer » offrant des services répondant à ses besoins ; un service de gestion (service « Nnrf_NFManagement »), assurant des opérations d’enregistrement, de désenregistrement et de mise à jour, et permettant à la fonction NRF d’être informée des instances de fonctions NF « producer » disponibles et des services offerts par ces fonctions NF ; un service d’autorisation de service (service « Nnrf_AccessToken »), permettant de s’assurer qu’une fonction NF « consumer » est autorisée à accéder aux services offerts par une fonction NF « producer ». Le standard 3GPP définit également une procédure de souscription via laquelle une fonction NF « consumer » peut demander à la fonction NRF d’être informée de tout changement affectant une fonction NF « producer » (par exemple, disponibilité d’une nouvelle instance, mise à jour d’un attribut du profil d’une fonction NF, etc.). La , extraite du document de Joe Wilke intitulé « 5G Network Architecture and FMC », IMT-2020/5G Workshop and Demo Day seminar, juillet 2017, illustre de façon schématique l’interface (API) basée sur le service (ou SBI pour « Service Based Interface » en anglais) mise en œuvre entre deux fonctions réseau NF A et NF B dans un réseau 5G conformément au standard 3GPP. Ces fonctions réseau sont tour à tour, en fonction du service considéré, « consumer » et « producer », et échangent entre elles en utilisant des méthodes spécifiques conformes au protocole client-serveur HTTP (« HyperText Transfer Protocol ») s’appuyant par exemple sur des requêtes GET, POST, PUT ou encore PATCH et les réponses associées, ces méthodes pouvant comprendre de façon optionnelle des paramètres en entête et des corps spécifiques, et visant des ressources spécifiques identifiées respectivement par des identifiants de ressources uniformes ou URI (pour « Uniform Resource Identifier » en anglais). Ces éléments spécifiques (ressources, méthodes HTTP, paramètres d’entête, structures du corps dans les requêtes ou les réponses) sont définis plus spécifiquement dans les documents 3GPP décrivant plus spécifiquement les fonctions NF. Les ressources du réseau cœur 5G ne sont pas extensibles indéfiniment, notamment pour ce qui concerne la bande passante et la capacité des fonctions NF de type « producers » (en nombre fixe) à traiter les requêtes HTTP émises par les fonctions NF de type « consumers ». Ainsi, en optimisant le trafic HTTP échangé entre les fonctions NF à bande passante constante, on améliore les performances du réseau cœur 5G, et plus particulièrement sa capacité à absorber du trafic ainsi que sa latence. Comme évoqué ci-dessus, le réseau cœur 5G utilise le protocole client-serveur HTTP pour ce qui est des échanges entre les fonctions NF, et plus particulièrement le protocole HTTP/2. De façon connue en soi, le protocole HTTP/2 est une évolution majeure du protocole HTTP/1.1 : il a été conçu pour réduire la latence et rendre les échanges plus sûrs, tout en restant compatible avec la version HTTP/1.1. A cet effet, il offre de nouvelles fonctionnalités comme notamment la possibilité le multiplexage des requêtes et des réponses, la compression des entêtes HTTP, ou encore la transmission des données en binaire. Il est important toutefois de noter que le protocole HTTP/2 ne modifie pas la sémantique applicative du protocole HTTP de quelle que manière que ce soit. Tous les concepts de base du protocole HTTP, telles que les méthodes, les codes d’état, les URIs, les champs des entêtes sont conservés. En revanche, le protocole HTTP/2 modifie comment les données sont formatées et transportées entre un client et un serveur. Grâce en particulier à la compression des entêtes des requêtes et des réponses, le protocole HTTP/2 permet de réduire et d’optimiser le volume de données transmises par rapport au protocole HTTP/1.1. On note que le corps des requêtes et des réponses reste le cas échéant conforme au protocole HTTP/1.1. Celui-ci est décrit en détail notamment dans le document IETF RFC 2616 intitulé « Hypertext Transfer Protocol – HTTP/1.1 », juin 1999. De façon connue en soi, le protocole HTTP est un protocole initialement développé pour le web. L’optimisation de l’encodage des contenus échangés par l’intermédiaire du protocole HTTP (ex. texte, images, polices, etc.), et plus particulièrement la compression de ces contenus, est un facteur clé aujourd’hui prôné par les acteurs du web pour réduire la latence et la consommation de la bande passante, et améliorer sensiblement l’expérience utilisateur. Le réseau cœur 5G s’appuyant sur le protocole HTTP comme le web, il est envisagé d’appliquer les bonnes pratiques issues du web en la matière aux échanges se tenant notamment entre les fonctions NF au sein du réseau cœur 5G. En effet, à titre indicatif, la charge utile d’un profil d’une fonction NF fournie dans une requête adressée lors de l’enregistrement d’une fonction NF ou dans une réponse fournie par la fonction NRF lors du mécanisme de découverte ou encore dans une notification envoyée par la fonction NRF lorsqu’un profil d’une fonction NF est mis à jour, peut facilement avoisiner les 2 mégaoctets, ce qui, rapporté aux nombres de ces messages échangés sur le réseau cœur 5G, peut constituer une charge totale importante. Par ailleurs, les APIs des services offerts par les fonctions NF d’un réseau cœur 5G comportent des dizaines d’opérations utilisant des requêtes HTTP de type POST, PUT ou PATCH comprenant un corps comportant un contenu, et ce nombre d’opérations est en constante augmentation. Un gain de réduction de la taille des contenus échangés de quelques pourcents voire plus via l’utilisation d’un encodage mettant en œuvre une compression des données aurait un impact non négligeable sur la bande passante et sur la latence du réseau pour toutes ces opérations. Conformément au protocole HTTP/1.1, lors d’un échange entre un client et un serveur, le client peut indiquer dans la requête qu’il émet à destination du serveur, et plus particulièrement dans un entête « Accept-Encoding » de la requête, les différents types d’encodage (« encoding » en anglais) qu’il supporte (par exemple un encodage mettant en œuvre une compression des données). Le serveur retourne alors une réponse au client dont le corps est conforme aux indications d’encodage fournies par le client. Le serveur indique quant à lui, dans un entête « Content-Encoding » de sa réponse, le type (ou format) d’encodage (et plus particulièrement de compression) appliqué au contenu servi au client. La négociation de l’encodage, lorsqu’elle est mise en œuvre, est donc à l’initiative du client et ne concerne que la réponse envoyée par le serveur au client. Le client n’a aucun moyen de savoir préalablement à la réception de la réponse du serveur quel format d’encodage ce dernier supporte. Dans le contexte des réseaux 5G, avant la Release 15.4.0, aucune négociation d’encodage n’est définie au niveau des interfaces APIs des fonctions NF. Dans la Release 15.4.0, le standard 3GPP introduit des règles d’ordre général pour la négociation d’encodage décrites notamment dans le document 3GPPP TS 29.500 v15.4.0, juin 2019, intitulé « Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 15) ». Selon ces règles : une fonction NF « consumer » peut déterminer les formats d’encodage supportés par une fonction NF « producer » en lui envoyant une requête de type OPTIONS, les formats d’encodage supportés par la fonction NF « producer » lui étant retournés dans la réponse à la requête OPTIONS ; une fonction NF « producer » peut retourner un entête « Accept-Encoding » tel que décrit précédemment contenant les formats d’encodage qu’elle supporte dans une réponse, par exemple une réponse à une requête comportant un corps telle qu’une requête HTTP POST, PUT ou PATCH. La fonction NF « consumer » peut alors utiliser l’un des formats d’encodage fournis par la fonction NF « producer » pour encoder le corps le cas échéant de sa prochaine requête adressée à la fonction NF « producer ». Une requête OPTIONS n’a toutefois été mise en œuvre par le standard 3GPP que pour le service Nnrf_NFManagement (qui comprend les opérations d’enregistrement, de désenregistrement et de mise à jour évoquées précédemment) supporté par la fonction réseau NRF. Une généralisation de cette solution imposerait de mettre en œuvre la requête OPTIONS pour toutes les ressources des différentes interfaces APIs de toutes les fonctions NF (actuellement définies et futures) comportant des requêtes HTTP pouvant mettre en œuvre un encodage de leur contenu, et plus particulièrement les requêtes HTTP POST, PUT et PATCH. Ceci aurait pour conséquence non seulement une lourdeur de maintenance des spécifications du réseau cœur 5G, mais également une augmentation du volume de la signalisation échangée dans le réseau cœur (une transaction dédiée pour chaque ressource sur chaque API), et la prise en compte d’une logique additionnelle pour chaque fonction NF « consumer ». L’autre solution proposée par le standard 3GPP (ajout d’un entête « Accept-Encoding » dans une réponse) est utilisée dans la Release 16 pour des services offerts par les fonctions réseau NSSF (service Nnssf_NSSAIAvailability) et NRF (services Nnrf_NFManagement, Nnrf_NFDiscovery, Nnrf_AccessToken). Toutefois, comme la solution précédente, la généralisation de cette solution imposerait de modifier toutes les APIs des fonctions NF actuelles et futures du réseau cœur 5G. En outre, elle ne permet malheureusement pas à une fonction « consumer » de tenir compte des formats d’encodage supportés par une fonction « producer » dans la première requête adressée par la fonction « consumer » à la fonction « producer » (l’entête « Accept-Encoding » n’étant fourni qu’en réponse à cette première requête). L’application des solutions proposées actuellement par le standard 3GPP à l’ensemble des fonctions NF du réseau cœur 5G, et à l’ensemble des services proposés par ces fonctions NF, paraît donc difficilement envisageable. L’invention offre une solution ne présentant pas de tels inconvénients, et pouvant être aisément appliquée notamment dans le contexte d’un réseau 5G tel que défini par le standard 3GPP. Il convient toutefois de noter que bien qu’introduite en référence à un réseau 5G, à des fonctions réseau virtuelles et au protocole HTTP/2, ces hypothèses ne sont nullement limitatives de l’invention et celle-ci peut être utilisée dans d’autres contextes. Par exemple, elle peut être utilisée dans d’autres réseaux qu’un réseau 5G, s’appuyant sur des procédures d’enregistrement et de découverte de services, tels que des architectures micro-services déployées dans un système informatique en nuage ou plus communément « cloud » en anglais. Un exemple d’une telle architecture est la solution de service mesh Consul proposée par la société Hashicorp. L’invention s’applique également à d’autres protocoles que le protocole HTTP/2 tels qu’une autre version du protocole HTTP (HTTP/1.1), ou aux protocoles SOAP (pour « Simple Object Access Protocol » en anglais), CORBA (pour « Common Object Request Broker Architecture » en anglais), gRPC (pour « Remote Procedure Call » en anglais), QUIC, etc., ou à tout autre protocole basé sur l’échange de requêtes et de réponses, et supportant un encodage du contenu du corps des requêtes et/ou des réponses, typiquement une compression de ce contenu. L’invention s’applique de manière générale à toute entité applicative (physique ou virtuelle) offrant un ou plusieurs services dans un réseau et susceptible de mettre en œuvre différents types ou formats d’encodage (et les décodages associés) pour encoder (et décoder), et notamment compresser, des contenus dans le cadre de ces services. Par exemple, une entité applicative au sens de l’invention peut être une instance virtuelle d’une fonction réseau d’un type donné. En outre, l’invention ne se limite pas à des encodages permettant de compresser des contenus, même si elle est particulièrement avantageuse dans ce contexte pour optimiser les performances et la latence d’un réseau comme évoqué ci-dessus. On peut envisager également d’autres formats d’encodage, comme par exemple un format d’encodage invariant (correspondant au maintien à l’identique du contenu), un encodage base64, ou toute transformation réversible réalisée dans un but particulier (ex. réduire la taille d’un contenu, obtenir un contenu compatible avec la majorité des systèmes, sécuriser un contenu, etc.), etc. Plus spécifiquement, l’invention propose un procédé de gestion, par une entité de contrôle d’un réseau, d’une pluralité d’entités applicatives proposant des services dans le réseau, ledit procédé de gestion comprenant : une étape d’enregistrement de chaque entité applicative gérée par l’entité de contrôle comprenant une mémorisation d’un profil de ladite entité applicative, ce profil comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle ; et en réponse à une requête en provenance d’une première entité, une étape de fourniture à cette première entité, pour au moins une dite entité applicative gérée par l’entité de contrôle, d’au moins une partie de la pluralité d’attributs du profil de cette entité applicative, ladite partie comprenant ledit au moins un format d’encodage supporté par cette entité applicative. Corrélativement, l’invention vise aussi une entité de contrôle d’un réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau, ladite entité de contrôle comprenant : un module d’enregistrement, configuré pour enregistrer chaque entité applicative gérée par l’entité de contrôle, ledit module d’enregistrement étant configuré pour mémoriser lors de l’enregistrement d’une entité applicative un profil de cette entité applicative comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle ; et un module de publication activé en réponse à une requête en provenance d’une première entité, et configuré pour fournir à cette première entité, pour au moins une dite entité applicative gérée par l’entité de contrôle, au moins une partie de la pluralité d’attributs du profil de cette entité applicative, ladite partie comprenant ledit au moins un format d’encodage supporté par cette entité applicative. Par entité applicative, on entend toute entité communicante (aussi appelée entité de communication ici) configurée pour mettre en œuvre une logique de traitement déterminée, comme par exemple une entité offrant et/ou consommant des services dans un réseau telle qu’une fonction réseau ou une instance de fonction réseau, etc. On note qu’une entité applicative peut être une entité de réseau (i.e. qui a une fonctionnalité donnée dans un réseau), mais il peut s’agir également d’un équipement utilisateur (ou UE pour « User Equipment » en anglais). La requête déclenchant la publication de tout ou partie du profil d’une entité applicative gérée par l’entité de contrôle auprès d’une autre entité (première entité au sens de l’invention) peut être notamment une requête de découverte d’au moins une entité applicative gérée par l’entité de contrôle répondant par exemple à au moins un critère déterminé spécifié implicitement ou explicitement dans la requête de découverte (ex. entités applicatives proposant un service donné, assurant une fonction réseau donnée, etc.). Aucune limitation n’est attachée à la nature de la première entité. Il peut s’agir par exemple d’une autre entité applicative, gérée par l’entité de contrôle ou par une autre entité de contrôle, d’une autre entité de contrôle, d’un équipement intermédiaire tel qu’un SCP agissant par exemple pour le compte d’une autre entité applicative, ou encore d’une entité du réseau situé en périphérie du réseau cœur, d’un équipement utilisateur, etc. La première entité peut appartenir ou non au même réseau que l’entité de contrôle. Dans le cas d’un réseau mettant en œuvre un découpage en tranches (ou « slicing »), la première entité, l’entité de contrôle et les entités applicatives peuvent appartenir à des tranches de réseau différentes. Ainsi, l’invention propose d’intégrer, parmi les attributs listés dans le profil d’une entité applicative de type « producer » et fournis par cette dernière à l’entité de contrôle qui la gère lors de son enregistrement, le ou les différents formats d’encodage qu’elle supporte. Ceci permet avantageusement à l’entité de contrôle d’être en mesure de publier auprès des entités « consumer » du réseau ou externes au réseau, intéressées par les services fournis par l’entité applicative « producer » et qui la sollicitent, ce ou ces formats d’encodage, et ce, en préliminaire de tout échange entre les entités « consumer » et l’entité applicative « producer ». De cette sorte, une entité « consumer » peut appliquer, dès la première requête qu’elle envoie à l’entité « producer » dans le cadre de l’accès à un service offert par celle-ci, l’un des formats d’encodage supportés par l’entité « producer ». Il convient de noter qu’au vu des bonnes pratiques rappelées précédemment, le support de formats d’encodage mettant en œuvre une compression de données est courant. De tels formats d’encodage sont par exemple gzip, compress, deflate. L’invention permet ainsi d’optimiser l’ensemble des échanges entre l’entité « consumer » et l’entité « producer », notamment en termes de bande passante et de latence. En outre, de façon particulièrement avantageuse, le ou les formats d’encodage ainsi publiés peuvent être des attributs considérés par l’entité « consumer » pour sélectionner une entité « producer » parmi plusieurs offrant un même service, ce qui permet d’optimiser encore davantage les performances du réseau. Ce peut être également un critère de recherche utilisé par une entité « consumer » lors de la découverte d’entités applicatives « producer », par exemple en complément ou en remplacement de critères plus fonctionnels. Dans le contexte plus spécifique d’un réseau 5G tel que défini par le standard 3GPP, les entités applicatives sont par exemple des fonctions NF, l’entité de contrôle, une fonction réseau NRF, et la première entité, une autre fonction NF, une autre fonction de contrôle (appartenant ou non au même réseau que l’entité de contrôle) ou un équipement intermédiaire SCP. La solution proposée par l’invention permet avantageusement d’éviter une définition laborieuse des interfaces APIs et/ou une lourdeur de maintenance des spécifications du réseau 5G. Elle requiert en effet uniquement la mise à jour des attributs listés dans le profil d’une fonction NF qui sont mémorisés par la fonction NRF, et publiés par cette dernière lors de procédures de découverte visant (directement ou indirectement) la fonction NF. Comme cette procédure de découverte est mise en œuvre en préliminaire de tout échange avec la fonction NF conformément au standard 3GPP, elle n’entraîne aucune logique supplémentaire ni aucun échange de messages supplémentaire (contrairement à la solution basée sur l’envoi d’une requête OPTIONS) au niveau du réseau. La mise en œuvre de l’invention s’intègre donc parfaitement dans la logique du réseau cœur 5G utilisant une fonction NRF et dans les procédures définies d’enregistrement des profils des fonctions NF auprès de la fonction NRF, de découverte des fonctions NF « producer » par les fonctions NF « consumer », et ce, notamment, dans les Releases 15 et 16, ou dans de futures Releases reprenant ces procédures ou des procédures similaires. Il en découle une facilité d’implémentation de l’invention pour les équipementiers, mais également de configuration pour les opérateurs des réseaux cœurs. L’invention offre ainsi une solution générale et pérenne, qui peut s’appliquer à toute opération d’un service offert par une entité applicative, et en particulier par une fonction réseau virtuelle, existante ou future, dans un réseau cœur 5G. Dans un mode particulier de réalisation, le procédé de gestion comprend en outre : une étape de réception d’une demande de souscription, en provenance d’une deuxième entité, pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l’entité de contrôle, cette souscription indiquant au moins un format d’encodage supporté par la deuxième entité ; et suite à une détection d’un évènement correspondant à ladite demande de souscription, une étape de notification de ladite deuxième entité comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la deuxième entité et indiqué dans la demande de souscription. Il convient de noter que les première et deuxième entités peuvent être une seule et même entité communicante (physique ou logicielle), ou être des entités distinctes. Elles peuvent appartenir au même réseau ou à des réseaux distincts. Comme pour la première entité, la deuxième entité peut être une entité applicative gérée par l’entité de contrôle ou par une autre entité de contrôle, une autre entité de contrôle, un équipement SCP, un équipement utilisateur, etc. Ce mode de réalisation permet d’optimiser également la transmission des notifications émises de façon asynchrone par l’entité de contrôle pour signaler divers événements affectant les profils des entités applicatives qu’elle gère, aux entités qui lui ont signalé leur intérêt pour ces événements via un mécanisme de souscription connu en soi. De tels événements sont par exemple la création, la modification ou encore la suppression d’un profil d’une entité applicative. L’invention selon ce mode de réalisation propose avantageusement que lors de la souscription, la deuxième entité indique le ou les formats d’encodage qu’elle supporte pour que l’entité de contrôle puisse exploiter ces formats d’encodage lorsqu’elle lui envoie des notifications. Suivant l’événement à l’origine de la notification et la configuration de l’entité de contrôle, une telle notification peut comprendre un ou plusieurs profils en tout ou partie (ex. partie publiée par l’entité de contrôle) ou seulement le cas échéant, les attributs du profil affectés par l’événement. L’application d’un format d’encodage aux informations véhiculées par les notifications, compte tenu du nombre important de notifications susceptibles d’être envoyées par une entité de contrôle et du volume de données véhiculé par chacune d’entre elle, est donc particulièrement avantageuse en matière de latence et de bande passante. Il convient de noter que ce mode de réalisation est avantageux que la deuxième entité du réseau soit gérée ou non par l’entité de contrôle, notamment dans le contexte du standard 3GPP. En effet, l’entité de contrôle connaît pour les entités applicatives qu’elle gère, les services offerts par ces entités applicatives en tant que « producers » (i.e. en tant que fournisseurs de services) et les attributs associés à ces services (et donc conformément à l’invention, les formats d’encodage supportés par ces services). Mais lorsqu’une entité communicante souscrit à un service de notification d’événements relatifs aux profils gérés par l’entité de contrôle, cette entité agit en tant que « consumer » (i.e. en tant que consommateur du service de notification). Par conséquent, quand bien même cette entité est une entité applicative enregistrée auprès de l’entité de contrôle, l’entité de contrôle ne connait pas les formats d’encodage supportés par cette dernière en tant que « consumer ». Le mode de réalisation qui vient d’être décrit permet à l’entité de contrôle de mémoriser cette information, par exemple dans le contexte de souscription associé à l’entité en question, pour une utilisation lors de futures notifications le cas échéant. Le stockage de cette information dans le contexte de souscription évite d’avoir à gérer et à mettre à jour cette information via une nouvelle logique de traitement. Les formats d’encodage stockés dans le profil et dans le contexte de souscription héritent en effet de façon avantageuse des mécanismes déjà existants mis en œuvre dans le réseau pour la gestion des autres attributs contenus dans le profil et des autres informations de souscription. L’invention est donc particulièrement simple à mettre en œuvre. Aucune limitation n’est attachée à la façon dont la deuxième entité signale le ou les formats d’encodage qu’elle supporte lors de la souscription auprès de l’entité de contrôle. Ils peuvent par exemple être indiqués dans le corps de la requête de souscription avec les autres informations de souscription, dans un champ prévu à cet effet. Dans un mode particulier de réalisation, le procédé de gestion comprend en outre : une étape de réception en provenance d’une troisième entité d’une requête d’amorçage visant à découvrir des services proposés par l’entité de contrôle et/ou des ressources gérées par celle-ci ; et une étape d’envoi d’une réponse à ladite requête d’amorçage de ladite troisième entité, ladite réponse comprenant en outre au moins un format d’encodage supporté par l’entité de contrôle. La troisième entité peut être distincte ou non des première et/ou deuxième entités évoquées précédemment. Il peut s’agir par exemple d’une autre entité de contrôle, pouvant appartenir à un réseau (ou PLMN pour « Public Land Mobile Network » en anglais) différent de l’entité de contrôle, ou d’une entité applicative qui veut accéder aux services proposés par l’entité de contrôle, et notamment aux services d’enregistrement, de souscription ou de découverte offerts par cette dernière, etc. Dans ce mode de réalisation avantageusement, outre les services proposés par l’entité de contrôle et les ressources gérées par celle-ci (ex. services d’enregistrement, de découverte, de notification, etc.), la réponse adressée par l’entité de contrôle à la requête d’amorçage qu’elle reçoit de la troisième entité contient les formats d’encodage supportés par l’entité de contrôle. Cela permet à la troisième entité d’utiliser l’un de ces formats dès qu’elle envoie une requête à l’entité de contrôle pour accéder à l’un des services offerts par cette dernière. A titre d’exemple, si la troisième entité est une entité applicative dépendant de l’entité de contrôle, cela permet à l’entité applicative lorsqu’elle s’enregistre auprès de l’entité de contrôle, d’utiliser pour fournir son profil l’un des formats d’encodage supportés par l’entité de contrôle. Les échanges entre l’entité applicative et l’entité de contrôle sont donc optimisés. Ce mode de réalisation est aisément compatible avec la Release 16 du standard 3GPP et en particulier avec la procédure d’amorçage Nnrf_Boostrapping permettant la découverte des services proposés par une fonction NRF par les entités NF du réseau cœur 5G ou par d’autres entités NRF appartenant au même réseau ou à un réseau (PLMN) différent. Comme il apparaît au vu de ce qui précède, l’invention s’appuie sur l’enregistrement et la publication par l’entité de contrôle des formats d’encodage supportés par les entités applicatives qu’elle gère, mais également sur ces entités applicatives qui, lors de leur enregistrement auprès de l’entité de contrôle, lui fournissent les formats d’encodage qu’elles supportent, ainsi que sur l’entité qui est informée de ces formats d’encodage et est en mesure de les exploiter dès ses premiers échanges avec les entités applicatives. Ainsi, selon un autre aspect, l’invention vise également un procédé d’enregistrement d’une entité applicative proposant au moins un service dans un réseau, auprès d’une entité de contrôle du réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau, ledit procédé d’enregistrement comprenant une fourniture par ladite entité applicative à l’entité de contrôle lors dudit enregistrement d’un profil de ladite entité applicative, ce profil comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle, ladite entité de contrôle étant configurée pour fournir au moins une partie de ladite pluralité d’attributs du profil de l’entité applicative, ladite partie comprenant ledit au moins un format d’encodage, en réponse à une requête en provenance d’une autre entité. Corrélativement, l’invention concerne aussi une entité applicative d’un réseau proposant au moins un service dans le réseau, ladite entité applicative comprenant un module d’enregistrement configuré pour enregistrer ladite entité applicative auprès d’une entité de contrôle du réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau, ledit module d’enregistrement étant configuré pour fournir à l’entité de contrôle lors dudit enregistrement un profil de ladite entité applicative, ce profil comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle, ladite entité de contrôle étant configurée pour fournir au moins une partie de ladite pluralité d’attributs du profil de l’entité applicative, ladite partie comprenant ledit au moins un format d’encodage, en réponse à une requête en provenance d’une autre entité. Dans un mode particulier de réalisation, le procédé d’enregistrement comprend, en outre, avant l’enregistrement, une étape d’envoi d’une requête d’amorçage à l’entité de contrôle visant à découvrir des services qu’elle propose et/ou des ressources gérées par celle-ci ; une étape de réception d’une réponse à ladite requête d’amorçage comprenant en outre au moins un format d’encodage supporté par l’entité de contrôle ; un dit format d’encodage supporté par l’entité de contrôle étant utilisé lors de l’enregistrement pour encoder le profil fourni à l’entité de contrôle. Selon un autre aspect encore, l’invention vise un procédé de communication d’une entité dite « quatrième » entité avec une entité de contrôle du réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau et mémorisant des profils de ces entités applicatives, ledit procédé de communication comprenant : une première étape d’envoi à ladite entité de contrôle d’une requête de découverte d’entités applicatives gérées par l’entité de contrôle ; et une étape de réception d’une réponse à ladite requête de découverte indiquant au moins une entité applicative dite candidate gérée par l’entité de contrôle et une pluralité d’attributs de cette entité applicative candidate extraits d’un profil de l’entité applicative mémorisé par l’entité de contrôle, ladite pluralité d’attributs incluant au moins un format d’encodage supporté par cette entité applicative candidate et pouvant être utilisé lors d’un accès à un service proposé par elle. Corrélativement, l’invention concerne également une entité dite « quatrième » entité comprenant : un premier module de communication configuré pour envoyer à une entité de contrôle du réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau et mémorisant des profils desdites entités applicatives, une première requête de découverte d’entités applicatives gérées par l’entité de contrôle ; et un module de réception, configuré pour recevoir une réponse à ladite requête de découverte indiquant au moins une entité applicative dite candidate gérée par l’entité de contrôle et une pluralité d’attributs de cette entité applicative candidate extraits d’un profil de l’entité applicative mémorisé par l’entité de contrôle, ladite pluralité d’attributs incluant au moins un format d’encodage supporté par cette entité applicative candidate et pouvant être utilisé lors d’un accès à un service proposé par elle. Dans un mode particulier de réalisation, le procédé de communication comprend une deuxième étape d’envoi, à une dite entité applicative candidate indiquée dans la réponse reçue, d’une requête comprenant un contenu encodé au moyen d’un format d’encodage supporté par cette entité applicative candidate et indiqué dans la réponse reçue. Corrélativement, la quatrième entité comprend, dans ce mode de réalisation, un deuxième module de communication, configuré pour envoyer à une dite entité applicative candidate indiquée dans la réponse reçue une deuxième requête comprenant un contenu encodé au moyen d’un format d’encodage supporté par ladite entité applicative candidate et indiqué dans la réponse reçue. On note que la quatrième entité peut être l’une quelconque des première, deuxième et troisième entités évoquées précédemment ou une entité distincte. Il peut s’agir, comme pour les autres entités, d’une entité applicative, d’une entité de contrôle, ou de toute autre entité comme une entité de réseau ou un équipement utilisateur. Ainsi, grâce à l’invention, la requête envoyée lors de la deuxième étape d’envoi est la première requête que la quatrième entité envoie à l’entité applicative candidate lors d’un accès à un service proposé par celle-ci. La quatrième entité n’a effectivement pas besoin d’envoyer une requête supplémentaire (ex. requête OPTIONS) à l’entité applicative candidate pour connaître un format d’encodage supporté par celle-ci. Elle peut, dès la première requête envoyée à l’entité applicative candidate, exploiter un format d’encodage qu’elle sait supporter par l’entité applicative candidate pour encoder un contenu qu’elle lui destine. L’entité applicative, la quatrième entité, le procédé d’enregistrement et le procédé de communication selon l’invention possèdent les mêmes avantages cités précédemment que le procédé de gestion et l’entité de contrôle selon l’invention. Dans un mode particulier de réalisation dans lequel la réponse à la requête de découverte indique une pluralité d’entités applicatives candidates, l’entité applicative candidate à laquelle est envoyée la requête par la quatrième entité lors de la deuxième étape d’envoi est sélectionnée parmi ladite pluralité d’entités actives candidates en tenant compte des formats d’encodage respectifs supportés par cette pluralité d’entités applicatives candidates. Autrement dit, les formats d’encodage supportés par les entités applicatives découvertes par la quatrième entité (entités applicatives candidates au sens de l’invention) sont utilisés comme critère de sélection par la quatrième entité pour sélectionner une entité applicative parmi ces entités applicatives découvertes. La quatrième entité peut ainsi favoriser une entité applicative parmi plusieurs car elle supporte un format d’encodage non supporté par les autres ou plus avantageux pour optimiser ses communications. Bien entendu, ce critère peut être combiné à d’autres critères de sélection, comme par exemple le service assuré par l’entité applicative en question, sa fonction, sa disponibilité, etc. Dans un mode particulier de réalisation, le procédé de communication comprend en outre une étape d’envoi d’une demande de souscription à l’entité de contrôle pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l’entité de contrôle, cette demande de souscription indiquant au moins un format d’encodage supporté par la quatrième entité ; et suite à une détection d’un évènement correspondant à ladite demande de souscription, une étape de réception d’une notification en provenance de l’entité de contrôle comprenant des informations relatives audit événement encodées au moyen d’un dit format d’encodage supporté par la quatrième entité et indiqué dans la demande de souscription. Les avantages de ce mode de réalisation ont déjà été discutés précédemment pour l’entité de contrôle. Un événement affectant au moins un profil mémorisé par l’entité de contrôle peut être notamment une création, une suppression ou une modification d’un tel profil. Dans un mode de réalisation particulier de l’invention, au moins un dit format d’encodage supporté par une dite entité (entité applicative, première, deuxième, troisième ou quatrième entité ou entité de contrôle) vise un encodage d’un contenu transmis dans un corps d’une requête ou d’une réponse conforme à une version du protocole HTTP (HyperText Transfer Protocol). Par ailleurs, au moins un dit format d’encodage est un format de compression de données. L’invention s’applique notamment de façon privilégiée dans le contexte des réseaux 5G définis par le standard 3GPP au protocole HTTP/2, pour la compression des contenus des requêtes conformes à ce protocole échangées entre les différentes entités impliquées dans l’invention. Toutefois comme évoqué précédemment, l’invention peut s’appliquer en association avec d’autres protocoles et d’autres formats d’encodage. Dans un mode particulier de réalisation de l’invention, dans au moins un profil d’une entité applicative gérée par l’entité de contrôle, au moins un dit format d’encodage est fourni dans un attribut s’appliquant : à l’ensemble des services proposés par cette entité applicative ; ou à un service donné ou à une version donnée d’un service proposé par cette entité applicative ; ou à une ressource donnée gérée par un service offert par cette entité applicative ; ou à une opération donnée appliquée à une ressource gérée par un service offert par cette entité applicative. Ce mode de réalisation s’applique aux différents procédés et entités objets de l’invention. Il offre la possibilité de définir différents niveaux de granularité pour les formats d’encodage des contenus lors de la mise en œuvre de l’invention : par type d’entités applicatives gérées par l’entité de contrôle, par type de services ou par version de service offerts par une entité applicative, par type d’opérations au sein d’un service, ou encore par type de ressources gérées par les services offerts par une entité applicative. Le choix de l’une ou l’autre de ces options dépend du comportement de chaque entité applicative, selon si on souhaite un comportement homogène pour l’ensemble des services qu’elle offre et des ressources gérées par ces services, ou au contraire si on souhaite adapter les formats d’encodage en fonction des services (incluant les versions des services) et/ou des ressources. L’invention offre une grande flexibilité à ce niveau, qui peut en outre différer d’une entité applicative à une autre, d’un service à un autre, d’une ressource à une autre, etc. Dans un mode particulier de réalisation de l’invention, les procédés de gestion, d’enregistrement et de communication 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é de contrôle conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de gestion 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 une entité applicative conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé d’enregistrement 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 une entité d’un réseau conforme à l’invention et comporte 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 de gestion, d’enregistrement et de communication selon l’invention. Selon un autre aspect encore, l’invention vise un système comprenant : au moins une entité applicative selon l’invention proposant au moins un service dans un réseau ; une entité de contrôle du réseau selon l’invention gérant ladite au moins une entité applicative ; et au moins une (quatrième) entité selon l’invention. Le système bénéficie des mêmes avantages cités précédemment que les procédés de gestion, d’enregistrement et de communication, l’entité de contrôle, l’entité applicative et la quatrième entité selon l’invention. On peut également envisager, dans d'autres modes de réalisation, que les procédés de gestion, d’enregistrement et de communication, l’entité de contrôle, l’entité applicative et la quatrième entité 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 : la , déjà décrite, représente, l’interface SBI proposée par le standard 3GPP entre deux fonctions réseau NF ; la représente dans son environnement, un système d’un réseau selon l’invention dans un mode particulier de réalisation ; la représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger l’une quelconque des entités selon l’invention appartenant au système de la ; la illustre des procédures d’amorçage et d’enregistrement mises en œuvre dans le système de la et s’appuyant sur des étapes des procédés de gestion, d’enregistrement et de communication selon l’invention dans un mode particulier de réalisation ; la illustre une procédure de découverte mise en œuvre dans le système de la et s’appuyant sur des étapes des procédés de gestion, d’enregistrement et de communication selon l’invention dans un mode particulier de réalisation ; la illustre une procédure de souscription mise en œuvre dans le système de la et s’appuyant sur des étapes des procédés de gestion et de communication selon l’invention dans un mode particulier de réalisation. Description de l’invention La représente, dans son environnement, un système 1 conforme à l’invention, dans un mode particulier de réalisation dans lequel le système 1 est intégré dans un réseau cœur CN d’un réseau de communications 5G tel que décrit dans le standard 3GPP. Le système 1 regroupe plusieurs entités du réseau cœur CN, à savoir : une pluralité d’entités applicatives NF1 NF2,…,NFN, conformes à l’invention, N désignant un entier supérieur 1. Par entité applicative, on entend toute entité communicante (aussi appelée entité de communication ici) configurée pour mettre en œuvre une logique de traitement déterminée, comme par exemple une entité offrant et/ou consommant des services dans un réseau telle qu’une fonction réseau ou une instance de fonction réseau, etc. On note qu’une entité applicative peut être une entité de réseau (i.e. qui a une fonctionnalité donnée dans un réseau), mais il peut s’agir également d’un équipement utilisateur (ou UE pour « User Equipment » en anglais). Dans le mode de réalisation décrit ici, chaque entité applicative NF1, NF2,…, NFN propose un ou plusieurs services dans le réseau (ex. assure une ou plusieurs fonctionnalités déterminées du réseau). De telles entités applicatives (dites de type « producer ») sont, dans le mode de réalisation décrit ici, des instances de fonctions réseau (NF), connues en soi comme par exemple des instances de fonctions AMF, SMF, NSSF, PCF, etc. évoquées avant. Il s’agit d’instances virtualisées, autrement dit d’entités logicielles, qui exécutent diverses logiques de service permettant d’assurer les principales fonctions du réseau cœur (ex. gestion de la mobilité et de l’accès au réseau cœur, définition et application de politiques réseau, facturation, sélection de tranches réseau, etc.). Chaque service offert par une entité applicative peut comprendre une ou plusieurs opérations ; et une entité 2 de contrôle gérant ces entités applicatives NF1, NF2,…, NFN, conforme à l’invention. Dans le mode de réalisation décrit ici, l‘entité 2 de contrôle est une fonction réseau NRF, autrement dit un catalogue mémorisant pour chacune des entités applicatives NF1,…,NFN, un profil référencé respectivement par NF_PROF1, NF_PROF2,…,NF_PROFN. les profils de chacune de ces fonctions NF. Chaque profil comprend une pluralité d’attributs, caractérisant l’état opérationnel de l’entité applicative associée (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. type de fonction NF, comment elle peut être jointe, etc.), les services qu’elle offre, les ressources qu’elle gère, etc. L’entité 2 de contrôle propose elle-même une pluralité de services comprenant notamment des services de découverte, de gestion (incluant les opérations d’enregistrement/désenregistrement/mise à jour), et d’amorçage, qui reprennent par exemple respectivement la logique des services Nnrf_NFDiscovery, Nnrf_NFManagement et Nnrf_Boostrapping décrits notamment dans les documents 3GPP TS 23.502 intitulé « Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2; (Release 16) », v16.7.0, décembre 2020, et TS 29.510 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 », v16.6.0, décembre 2020, aux aménagements près apportés par l’invention. Cette liste n’est pas exhaustive en soi et a pour seule visée d’identifier les services d’une entité NRF impactés par l’invention. Dans le mode de réalisation décrit ici, Le système 1 comprend également au moins une autre entité 3 communicante, conforme à l’invention. Aucune limitation n’est attachée à la nature de cette entité. Il peut s’agir indifféremment d’une autre entité applicative, gérée ou non par l’entité 2 de contrôle (autrement dit, l’entité 3 peut être l’une des entités applicatives NF1,…,NFN), d’un équipement intermédiaire de type SCP, d’une autre entité de contrôle de type NRF appartenant ou non au même réseau que l’entité 2 de contrôle, ou de toute autre entité de réseau ou encore d’un équipement d’utilisateur, etc. Dans le mode de réalisation décrit ici, cette entité 3 du réseau CN est une entité du réseau cœur CN, consommatrice (ou « consumer ») d’un ou de plusieurs services offerts par les entités applicatives NF1,…,NFN gérées par l’entité 2 de contrôle. Les entités du système 1 sont, dans le mode de réalisation décrit ici, des entités logicielles, hébergées par des dispositifs physiques du réseau cœur CN, comme par exemple des serveurs. Ces serveurs ont ici l’architecture matérielle d’un ordinateur 4, telle que représentée schématiquement sur la . L’ordinateur 4 comprend notamment un processeur 5, une mémoire vive 6, une mémoire morte 7, une mémoire non volatile 8, et des moyens de communication 9 permettant notamment aux entités du système 1 de communiquer entre elles et avec d’autres éléments le cas échéant du réseau cœur CN ou d’un autre réseau. Ces moyens de communication 9 s’appuient d’une part, sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici, mais également sur une ou plusieurs interfaces logicielles basées sur le service ou SBI. Ces interfaces logicielles sont des APIs qui utilisent ici le protocole HTTP/2. La mémoire morte 7 de l’ordinateur 4 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 5 et sur lequel est enregistré(s) un ou plusieurs programmes d’ordinateur conformes à l’invention. Plus spécifiquement, la mémoire morte 7 de l’ordinateur 4 comprend, lorsque l’ordinateur 4 héberge une entité applicative NFk, k=1,…,N conforme à l’invention, un enregistrement d’un programme d’ordinateur PROG-NFk, comportant des instructions définissant les principales étapes d’un procédé d’enregistrement selon l’invention. Ce programme PROG-NFk définit des modules fonctionnels d’une entité applicative NF-k, k=1,…,N selon l’invention qui s’appuient ou commandent les éléments matériels 5 à 9 de l’ordinateur 4 cités précédemment. Ces modules comprennent notamment dans le mode de réalisation décrit ici, comme illustré sur la : un module NFk-A, configuré pour offrir un ou plusieurs services (ou fonctionnalités) dans le réseau CN par l’intermédiaire d’une interface SBI, par exemple à d’autres entités applicatives telles que d’autres fonctions réseau ou encore, dans l’exemple envisagé ici, à l’entité 3. Les services offerts par le module NFk-A dépendent bien entendu du type de l’entité applicative NF-k considérée. Par exemple une entité applicative NF-k de type AMF offre les services suivants : gestion de l’enregistrement des équipements utilisateurs, gestion de leur joignabilité, gestion des sessions, gestion de la mobilité des équipements utilisateurs, gestion de l’accès (autorisation, etc.), etc. ; un module NFk-B de découverte pour découvrir les services offerts par l’entité de contrôle auprès de laquelle l’entité applicative NFk doit s’enregistrer. Plus particulièrement dans l’exemple envisagé ici d’un réseau cœur 3GPP 5G, on suppose que l’entité applicative NFk est configurée avec une adresse de joignabilité de l’entité de contrôle auprès de laquelle elle doit s’enregistrer (l’entité 2 de contrôle ici), mais qu’elle ne connaît pas a priori les services supportés par cette entité de contrôle (par exemple le service de gestion des fonctions NF auprès duquel elle doit s’enregistrer), ni les ressources gérées par l’entité 2 de contrôle. Pour obtenir ces informations, le module NFk-B de découverte est configuré pour envoyer une requête dite d’amorçage à l’entité 2 de contrôle dont il connaît l’adresse, et obtenir une réponse à cette requête d’amorçage comprenant les services supportés par l’entité 2 de contrôle, les ressources qu’elle gère, ainsi qu’au moins un format d’encodage que l’entité 2 de contrôle supporte ; et un module d’enregistrement NFk-C configuré pour enregistrer l’entité applicative NF-k auprès de l’entité 2 de contrôle du réseau cœur CN qui la gère. Le module d’enregistrement NFk-C est configuré pour fournir à l’entité 2 de contrôle lors de cet enregistrement un profil NF_PROFk de l’entité applicative NFk, encodé avec l’un des formats d’encodage fourni par l’entité 2 de contrôle en réponse à la requête d’amorçage. Le profil NF_PROFk comprend une pluralité d’attributs caractérisant l’entité applicative (ex. type, adresses de joignabilité, PMLN, etc.), un identifiant de cette entité applicative (identifiant de l’instance de la fonction réseau correspondante), son état (ex. enregistrée, non disponible), etc. Pour une entité applicative de type fonction NF comme dans l’exemple envisagé ici, de tels attributs comprennent notamment les attributs décrits dans le document 3GPP TS 29.510 cité précédemment. Conformément à l’invention, le profil NF_PROFk inclut en outre comme attribut(s) un ou plusieurs formats d’encodage supportés par l’entité applicative NFk, et pouvant être utilisés lors d’un accès via une interface SBI à un service proposé par celle-ci pour encoder les contenus des corps des requêtes et/ou des réponses HTTP/2 qui lui sont envoyées. En effet, selon l’invention, ce ou ces formats d’encodage font partie des attributs qui sont publiés par l’entité 2 de contrôle lors des procédures de découverte des entités applicatives, comme expliqué davantage ultérieurement. Ces formats d’encodage sont choisis parmi des formats d’encodage connus comme par exemple les formats de compression gzip, compress, deflate, ou encore le format invariant (« identity ») indiquant l’absence de transformation appliquée au contenu. Dans l’exemple envisagé ici, on suppose qu’un ou plusieurs profils comprennent au moins un format d’encodage de type format de compression. Les fonctions assurées par les modules NFk-A, NFk-B et NFk-C sont décrites plus en détail ultérieurement, en référence aux étapes du procédé d’enregistrement selon l’invention. De façon similaire, la mémoire morte 7 de l’ordinateur 4 comprend, lorsque l’ordinateur 4 héberge l’entité 2 de contrôle selon l’invention, un enregistrement d’un programme d’ordinateur PROG2, comportant des instructions définissant les principales étapes d’un procédé de gestion selon l’invention. Ce programme PROG2 définit des modules fonctionnels de l’entité 2 de contrôle (fonction NRF dans l’exemple envisagé) qui s’appuient ou commandent les éléments matériels 5 à 9 de l’ordinateur 4 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici, comme illustré sur la : un module 2A d’enregistrement, configuré pour enregistrer chaque entité applicative NF1,…,NFN gérée par l’entité 2 de contrôle. Dans l’exemple envisagé ici où l’entité 2 de contrôle est une fonction réseau NRF, le module 2A d’enregistrement est par exemple configuré pour exécuter des opérations de la logique du service de gestion Nnrf_NFManagement défini par le standard 3GPP, aménagées pour tenir compte de l’invention. Ainsi, le module 2A d’enregistrement est configuré notamment pour mémoriser, lors de l’enregistrement d’une entité applicative NFk, k=1,…,N, son profil NF_PROFk tel que décrit ci-avant, qui comprend un ou plusieurs formats d’encodage supportés par l’entité applicative NFk ; et un module 2B de publication, activé en réponse à une requête en provenance d’une entité communicante (par exemple une requête de découverte en provenance de l’entité 3), et configuré pour fournir à cette entité (ou de façon équivalente, publier auprès de cette entité), pour au moins une entité applicative NFk gérée par l’entité 2 de contrôle, au moins une partie de la pluralité d’attributs du profil NF_PROFk de cette entité applicative. La publication opérée par le module 2B de publication vise ici des entités applicatives répondant à au moins un critère déterminé (ex. type d’entités applicatives), qui peut être indiqué dans la requête de découverte. Dans l’exemple de la fonction NRF envisagé ici, le module 2B de publication est plus particulièrement configuré pour exécuter par exemple les opérations de la logique du service de découverte Nnrf_NFDiscovery défini par le standard 3GPP, aménagées pour tenir compte de l’invention : plus spécifiquement, parmi les attributs du profil NF_PROFk qui sont publiés, outre les attributs indiqués dans le document TS 29.510 cité précédemment, figure ledit au moins un format d’encodage supporté par l’entité applicative NFk concernée. Dans le mode de réalisation décrit ici, le programme PROG2 définit en outre les modules fonctionnels suivants : un module 2C de notification, configuré pour gérer les demandes de souscription d’entités (du réseau cœur CN ou extérieures au réseau cœur CN) en vue de recevoir des informations concernant des événements affectant les profils mémorisés par l’entité 2 de contrôle. Un tel événement est par exemple la création, la modification ou la suppression d’un ou de plusieurs profils gérés par l’entité 2 de contrôle. Dans l’exemple de la fonction NRF envisagé ici, le module 2C de notification est configuré pour exécuter par exemple des opérations de la logique du service de gestion Nnrf_NFManagement défini par le standard 3GPP, en complément de celles déjà exécutées par le module 2A, aménagées pour tenir compte de l’invention. Plus spécifiquement, conformément à l’invention, lorsqu’une entité communicante souscrit à un service de notification auprès de l’entité 2 de contrôle pour être informée à propos d’événements déterminés, elle lui fournit au moins un format d’encodage qu’elle supporte. Le module 2C de notification est alors configuré pour enregistrer dans un contexte CNT associé à la souscription de l’entité du réseau, le ou les événements indiqués lors de la souscription ainsi que le ou les formats d’encodage qui lui sont fournis, et pour appliquer l’un de ces formats d’encodage aux notifications qu’il envoie à l’entité communicante en question lorsqu’il détecte un événement correspondant à la souscription ; et un module 2D d’amorçage (ou « bootstrapping » en anglais), configuré ici pour, sur requête dite d’amorçage d’une entité communicante (par exemple une requête d’amorçage envoyée par le module NFk-B de découverte d’une entité applicative NFk décrit précédemment), fournir à cette entité communicante (autrement dit publier auprès de cette entité), les services que l’entité 2 de contrôle offre ainsi que les ressources qu’elle gère. Dans l’exemple de la fonction NRF envisagé ici, le module 2D d’amorçage est configuré pour exécuter par exemple des opérations de la logique du service d’amorçage Nnrf_Bootstrapping définis par le standard 3GPP, aménagées pour tenir compte de l’invention. Plus spécifiquement, en réponse à une requête d’amorçage d’une entité communicante (ex. fonction NF, fonction NRF ou autre entité de réseau ou encore équipement utilisateur, appartenant ou rattaché au réseau cœur CN ou à un autre réseau), le module 2D d’amorçage est configuré pour fournir en réponse à cette requête outre les informations qui lui sont demandées, au moins un format d’encodage que l’entité 2 de contrôle supporte. Les fonctions assurées par les modules 2A à 2D de l’entité 2 de contrôle sont décrites plus en détail ultérieurement, en référence aux étapes du procédé de gestion selon l’invention. Enfin, la mémoire morte 7 de l’ordinateur 4 comprend, lorsque l’ordinateur 4 héberge l’entité communicante 3 selon l’invention, un enregistrement d’un programme d’ordinateur PROG3, comportant des instructions définissant les principales étapes d’un procédé de communication selon l’invention. Ce programme PROG3 définit des modules fonctionnels de l’entité 3 qui s’appuient ou commandent les éléments matériels 5 à 9 de l’ordinateur 4 cités précédemment. Ces modules comprennent notamment dans le mode de réalisation décrit ici, comme illustré sur la : un premier module 3A de communication configuré pour envoyer à l’entité 2 de contrôle une requête de découverte d’entités applicatives gérées par celle-ci. Cette requête de découverte, qui est destinée à être traitée par le module 2B de l’entité 2 de contrôle décrit précédemment, peut contenir un ou plusieurs critères que les entités applicatives doivent vérifier, comme par exemple un type d’entité applicative, un service fourni par celle-ci, un format d’encodage supporté par l’entité applicative, etc. D’autres critères peuvent être envisagés en complément ou en variante ; un module 3B de réception, configuré pour recevoir une réponse à la requête de découverte indiquant au moins une entité applicative dite candidate gérée par l’entité 2 de contrôle répondant au(x) critère(s) requis. La réponse envoyée par l’entité 2 de contrôle comprend tout ou partie des profils des entités applicatives candidates, incluant au moins, pour chaque entité applicative candidate, un format d’encodage supporté par celle-ci ; un module 3C de sélection, configuré lorsque la réponse à la requête de découverte indique plusieurs entités applicatives, sélectionner l’une d’entre elles selon un ou plusieurs critères de sélection déterminés. Par exemple, un tel critère de sélection peut être un format d’encodage donné, mais d’autres critères peuvent être envisagés comme par exemple une charge ou un service proposé ; un deuxième module 3D de communication, configuré pour envoyer à l’entité applicative candidate sélectionnée, une requête comprenant un contenu encodé au moyen d’un format d’encodage supporté par cette dernière ; et un module 3E de souscription, configuré pour envoyer à l’entité 2 de contrôle une demande de souscription pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l’entité 2 de contrôle, par exemple les profils des entités applicatives candidates reçues par le module 3B de réception. Conformément à l’invention, le module 3E est configuré pour indiquer à l’entité 2 de contrôle dans sa demande de souscription au moins un format d’encodage supporté par l’entité 3. Le module 3E est en outre configuré pour recevoir et traiter, lorsqu’un événement correspondant à la demande de souscription est détecté par l’entité 2 de contrôle, une notification de l’entité 2 de contrôle comprenant des informations relatives à cet événement encodées au moyen d’un format d’encodage supporté par l’entité 3 et indiqué dans la demande de souscription. Les fonctions assurées par les modules 3A à 3E de l’entité 3 du réseau sont décrites plus en détail ultérieurement, en référence aux étapes du procédé de communication selon l’invention. On note que dans l’exemple envisagé ici, l’entité 3 est une entité du réseau cœur CN distincte des entités applicatives NF1,…,NFN gérées par l’entité 2 de contrôle. Toutefois, cette hypothèse n’est pas limitative en soi, et l’entité 3 peut être intégrée dans l’une des entités applicatives NF1,…,NFN. De même, elle peut appartenir à un réseau distinct du réseau cœur CN ou du réseau NW. Nous allons maintenant décrire les principales étapes d’un procédé de gestion, d’un procédé d’enregistrement et d’un procédé de communication selon l’invention telles qu’elles sont mises en œuvre respectivement par l’entité 2 de contrôle, par chacune des entités applicatives NF1,…,NFN gérées par l’entité 2 de contrôle, et par l’entité 3, dans un mode particulier de réalisation. Ces étapes sont mises en œuvre à travers différentes procédures mises en place ici dans le réseau cœur CN, entre les entités applicatives, l’entité 2 de contrôle et l’entité 3 : procédure d’amorçage, procédure d’enregistrement, procédure de découverte, procédure de souscription/notification, décrites plus en détail ci-après. Les figures 4 à 6 illustrent ces différentes procédures et les étapes des procédés selon l’invention impliquées dans celles-ci. La représente les procédures d’amorçage et d’enregistrement d’une entité applicative NFk auprès de l’entité 2 de contrôle. Dans le mode de réalisation décrit ici, comme mentionné précédemment, on suppose en préliminaire, que chacune des entités applicatives NF1,…,NFN sont rattachées à l’entité 2 de contrôle et ont été configurées avec une adresse de joignabilité (ex. URI) de cette dernière. Avant de s’enregistrer auprès de l’entité 2 de contrôle, chaque entité applicative NFk, k=1,…,N, initie une procédure de découverte des services offerts par l’entité 2 de contrôle et des ressources qu’elle gère. Cette procédure a pour but de permettre à chaque entité applicative NFk de déterminer dynamiquement comment accéder aux services offerts par l’entité 2 de contrôle et en particulier d’identifier vers quelles ressources (ex. quelles URIs) envoyer leurs requêtes lors de l’accès à ces services. A cet effet, l’entité applicative NFk envoie, par l’intermédiaire de son module NFk-B de découverte, une requête d’amorçage à l’entité 2 de contrôle, à l’adresse avec laquelle elle a été configurée (par exemple l’URI « URI2-BS »), visant à découvrir les services offerts par l’entité 2 de contrôle et les ressources qu’elle gère (étape E10). Cette requête d’amorçage est par exemple une requête HTTP GET/bootstrapping(URI2-BS) telle que définie dans le standard 3GPP dans le document TS 29.510 notamment. L’entité 2 de contrôle répond à cette requête via son module 2D d’amorçage (étape E20). Plus spécifiquement, celui-ci fournit dans le corps ici d’une réponse HTTP 200 OK, les informations requises, à savoir les services que l’entité 2 de contrôle offre (par exemple les services de gestion NRF_NFManagement, de découverte NRF_NFDiscovery, et d’autorisation NRF_AccessToken) et les URIs pour accéder aux services et aux ressources gérées par ces services. Le module 2D d’amorçage complète ces informations par un ou plusieurs formats d’encodage, référencé(s) par ENCOD-2, que l’entité 2 de contrôle supporte. On suppose ici que l’ensemble ENCOD-2 comprend un ou plusieurs formats d’encodage incluant au moins un format de compression, par exemple gzip. L’ensemble des informations précitées est référencé par BootstrappingData sur la . On note que les formats d’encodage ENCOD-2 peuvent être définis à différents niveaux, à savoir pour s’appliquer à tous les services proposés par l’entité 2 de contrôle et à toutes les ressources qu’elle gère, ou différer en fonction des services proposés par l’entité 2 de contrôle, ou encore en fonction des ressources gérées par l’entité 2 de contrôle, ou des opérations réalisées sur ces ressources. Sur réception de cette réponse 200 OK, l’entité applicative NFk mémorise les informations BootstrappingData en association avec l’entité 2 de contrôle (E30). Dans une variante de réalisation, l’entité applicative NFk indique dans la requête d’amorçage envoyée à l’entité 2 de contrôle, par exemple dans l’entête Accept-Encoding de la requête d’amorçage, au moins un format d’encodage qu’elle supporte. De cette sorte, l’entité 2 de contrôle peut utiliser un de ces formats d’encodage pour encoder les informations BootstrappingData qu’elle envoie à l’entité applicative NFk en réponse à la requête d’amorçage, et indiquer dans l’entête Content-Encoding de la réponse, le format d’encodage qu’elle a utilisé. On note que cette procédure d’amorçage ou de découverte des services et des ressources de l’entité 2 de contrôle peut être exécutée par d’autres entités que les entités applicatives destinées à s’enregistrer auprès d’elle. Par exemple, elle peut être exécutée par une autre entité de contrôle telle qu’une autre entité NRF appartenant ou non au même réseau (PLMN). Dans une variante de réalisation, l’entité applicative NFk obtient les formats d’encodage ENCOD-2 supportés par l’entité 2 de contrôle en lui envoyant une requête OPTIONS telle que décrite précédemment. L’entité 2 de contrôle répond à cette requête OPTIONS en fournissant, dans une réponse 200 OK, le ou les formats d’encodage supportés dans l’entête Accept-Encoding de la réponse. Suite à cette procédure de découverte, l’entité applicative NFk peut s’enregistrer auprès de l’entité 2 de contrôle, en utilisant les informations BootstrappingData dont elle dispose sur le service de gestion NRF_NFManagement offert par l’entité 2 de contrôle et la ressource (ex. URI) à pointer pour accéder à ce service. Plus particulièrement, l’entité applicative NFk envoie, par l’intermédiaire de son module NFk-C d’enregistrement, une requête d’enregistrement (requête HTTP PUT dans l’exemple envisagé ici) dans le corps de laquelle elle fournit son profil NF_PROFk (étape E40). Conformément à l’invention, le profil NF_PROFk est encodé par le module NFk-C au moyen d’un format d’encodage sélectionné parmi les formats d’encodage ENCOD-2 supportés par l’entité 2 de contrôle, par exemple le format de compression gzip. Le format d’encodage sélectionné (ex. gzip) est indiqué dans l’entête Content-Encoding de la requête d’enregistrement. La requête d’enregistrement est envoyée à une URI composée de l’URI du service d’enregistrement et de l’URI de la ressource associée à l’entité applicative NFk à enregistrer. Le profil NF_PROFk, comme détaillé précédemment, comprend une pluralité d’attributs, et notamment, dans l’exemple envisagé ici les attributs listés dans le document TS 29.510 dans la table 6.1.6.2.2-1 en section 6.1.6.2.2. Ces attributs comprennent notamment, de façon non exhaustive, l’identifiant ( nfInstanceId ) de l’entité applicative NF-k (qui est une instance d’une fonction réseau donnée) à créer, le type ( nfType ) de l’entité applicative NFk (i.e. type de la fonction réseau ici), l’état ( nfStatus ) de l’entité applicative, son nom ( nfInstanceName ), le PLMN ( plmnList ) auquel elle est rattachées, ses adresses IPv4 et IPv6 (ipv4Addresses, ipv6Addresses), sa priorité ( priority ) par rapport aux autres entités applicatives de même type (i.e. aux autres instances de la même fonction réseau), sa capacité ( capacity ), sa charge ( load ), sa localisation ( locality ), etc. En outre, conformément à l’invention, le profil NF_PROFk comprend un attribut contenant un ou plusieurs formats d’encodage supportés par l’entité applicative NF-k. On suppose ici qu’au moins l’un de ces formats d’encodage est un format de compression. Aucune limitation n’est attachée à la structure de l’attribut contenant le ou les formats d’encodage supportés par l’entité applicative NFk. Il peut s’agir d’un attribut dédié à ces formats d’encodage, nommé par exemple ContentEncoding, d’un attribut propriétaire réservé (« vendor-specific extensions » décrit dans le document TS 29.500 au paragraphe 6.6.3) que les opérateurs de réseau peuvent définir et utiliser comme l’autorise le standard 3GPP, ou encore d’un attribut plus global, nommé par exemple capInfo, composé d’une structure de données visant plus généralement les options de communication supportées par l’entité applicative NFk dont notamment les formats d’encodage. D’autres options de communication peuvent être spécifiées en plus des formats d’encodage, comme par exemple des algorithmes de chiffrement supportés par l’entité applicative NFk, des formats de contenus (ex. json, xml, multipart, etc.) supportés par celle-ci, etc. On note qu’il est possible en outre d’associer des éléments d’information complémentaires aux formats d’encodage supportés par l’entité applicative NFk, comme par exemple des priorités associées à chaque format d’encodage supporté. Par ailleurs, les formats d’encodage indiqués dans le profil NF_PROFk peuvent être définis à différents niveaux. De façon connue en soi, les attributs d’une entité applicative peuvent être définis dans le profil de l’entité applicative au niveau de l’entité applicative (ils concernent alors tous les services qu’elle propose et les ressources qu’elle gère ou que ces services gèrent) ou au niveau de chaque service individuellement. Dans le mode de réalisation décrit ici, les formats d’encodage supportés par l’entité applicative NF-k peuvent être fournis dans des attributs s’appliquant : à l’ensemble des services proposés par cette entité applicative ; ou à un service donné ou à une version donnée de service proposé par cette entité applicative ; ou à une ressource donnée gérée par cette entité applicative ou par un service offert par cette entité applicative ; ou à une opération donnée sur une ressource gérée par cette entité applicative ou par un service offert par cette entité applicative. Cette liste n’est pas exhaustive et d’autres niveaux de granularité peuvent être envisagés. Sur réception de la requête d’enregistrement, l’entité 2 de contrôle enregistre par l’intermédiaire de son module 2A d’enregistrement l’entité applicative NFk : elle mémorise son profil NF_PROFk à l’URI indiquée dans la requête d’enregistrement et associe à l’entité applicative NFk un état « disponible » (étape E50). L’entité 2 de contrôle confirme l’enregistrement de l’entité applicative NFk en lui envoyant une réponse HTTP 201 Created (étape E60). Suite à cet enregistrement, des mises à jour peuvent être apportées au profil de l’entité applicative NFk (non représentées sur la ) : par exemple, l’entité applicative NFk peut souhaiter enregistrer des modifications de certains attributs de son profil ou se désenregistrer auprès de l’entité 2 de contrôle. Pour enregistrer des modifications, l’entité applicative NFk peut soit resoumettre son profil NF_PROFk mis à jour dans son intégralité, par exemple ici au moyen d’une nouvelle requête HTTP PUT, soit uniquement les attributs modifiés, par exemple ici au moyen d’une requête HTTP PATCH. Dans l’une ou l’autre des options, l’entité applicative NFk fournit le profil NF_PROFk ou seulement les modifications dans le corps de la requête, encodé(es) au moyen d’un format d’encodage sélectionné parmi les formats d’encodage ENCOD-2 supportés par l’entité 2 de contrôle et indiqué dans l’entête Content-Encoding de la requête. Sur réception de ces éléments, l’entité 2 de contrôle met à jour le profil NF_PROFk qu’elle mémorise, et confirme la prise en compte de la mise à jour à l’entité applicative NFk. Comme mentionné ci-dessus, l’entité applicative NFk peut également souhaiter se désenregistrer : dans ce cas, elle adresse une requête de désenregistrement (requête HTTP DELETE dans l’exemple envisage ici) à l’entité 2 de contrôle, qui sur réception de cette requête, associe à l’entité applicative NFk un état « indisponible ». Le profil associé à l’entité applicative NFk est par ailleurs supprimé (par exemple à l’issue d’un laps de temps déterminé). On note que, comme décrit plus en détail ultérieurement, les trois événements qui viennent d’être décrits, à savoir la création d’un profil (ou de façon équivalente, l’enregistrement d’une entité applicative), sa modification ou sa suppression (ou de façon équivalente le désenregistrement de l’entité applicative), peuvent faire l’objet de notifications envoyées par l’entité 2 de contrôle aux entités qui ont souscrit le cas échéant auprès d’elle à la notification de ces événements. La représente une procédure de découverte par l’entité 3 d’entités applicatives gérées par l’entité 2 de contrôle. Aucune hypothèse n’est faite sur la nature de l’entité 3. Il peut s’agir par exemple d’une autre entité applicative cliente (« consumer ») des services des entités applicatives gérées par l’entité 2 de contrôle. Ainsi, on suppose par exemple que l’entité 3 souhaite découvrir toutes les entités applicatives gérées par l’entité 2 de contrôle vérifiant un ou plusieurs critères de recherche donnés, par exemple les entités applicatives fournissant un service particulier ou correspondant à une fonction réseau déterminée. L’invention ne se limite pas à des critères de recherche fonctionnels, et on peut également envisager en complément ou en variante, de fonder cette recherche d’autres critères telles que par exemple sur une option de communication supportée par les entités applicatives, et plus spécifiquement sur un format d’encodage particulier. L’entité 3, par l’intermédiaire de son premier module 3A de communication adresse une requête de découverte à l’entité 2 de contrôle (étape F10). Cette requête de découverte est par exemple ici une requête HTTP GET. Elle comprend des paramètres « query parameters » précisant le ou les critères de recherche fixés par l’entité 3. Sur réception de cette requête de découverte, l’entité 2 de contrôle vérifie que l’entité 3 est autorisée à découvrir les entités applicatives gérées par l’entité 2 de contrôle (étape F20). Elle procède à cet effet de façon connue de l’homme du métier et non détaillée ici. Le cas échéant, l’entité 2 de contrôle, par l’intermédiaire de son module 2B de publication, recherche la ou les entités applicatives enregistrées auprès d’elle qui vérifie le ou les critères de recherche indiqués par l’entité 3 (étape F30). Dans le mode de réalisation décrit ici, si plusieurs critères de recherche sont indiqués dans la requête de découverte, le module 2B de publication recherche les entités applicatives vérifiant chacun de ces critères. Dans une variante de réalisation, il peut rechercher les entités applicatives vérifiant au moins l’un de ces critères. On suppose qu’à l’issue de cette recherche, l’entité 2 de contrôle obtient un ensemble NF-MATCH comprenant une ou plusieurs entités applicatives dites « candidates » vérifiant les critères de recherche de l’entité 3. Par souci de simplification dans la suite, on parle « des entités candidates de l’ensemble NF-MATCH » y compris lorsque cet ensemble ne comprend qu’une entité candidate. L’entité 2 de contrôle envoie alors le résultat de sa recherche à l’entité 3 dans une réponse HTTP 200 OK (étape F40). Elle indique dans le corps de la réponse les entités applicatives candidates NF-MATCH correspondant au(x) critère(s) de recherche ainsi que les attributs de ces entités applicatives candidates utiles à l’entité 3 pour accéder aux services proposés par ces entités applicatives candidates. Dans le mode de réalisation décrit ici, il ne s’agit que d’une partie des attributs présents dans le profil NF_PROFk : seuls les attributs nécessaires au choix et à l’accessibilité des services sont fournis à l’entité 3 (ex. identifiant de l’entité applicative, type d’entité applicative, état de l’entité applicative, formats d’encodage, etc.). Conformément à l’invention, les attributs transmis incluent en particulier le ou les formats d’encodage supportés par les entités applicatives candidates de l’ensemble NF-MATCH. En variante, l’entité 2 de contrôle peut fournir à l’entité 3 tous les attributs listés dans les profils des entités applicatives candidates de l’ensemble NF-MATCH. Dans une variante de réalisation, l’entité 3 indique dans l’entête Accept-Encoding de la requête de découverte adressée à l’entité 2 de contrôle les formats d’encodage qu’elle supporte (par exemple au moins un format de compression), et l’entité 2 de contrôle encode l’ensemble NF-MATCH et les attributs associés au moyen de l’un de ces formats d’encodage (par exemple du format de compression), et indique dans l’entête Content-Encoding de la réponse le format d’encodage utilisé. Dans une autre variante encore, l’entité 2 de contrôle détermine les formats d’encodage supportés par l’entité 3 en lui envoyant une requête OPTIONS et utilise l’un de ces formats d’encodage comme décrit ci-avant. Dans le mode de réalisation décrit ici, suite à la réception de la réponse de l’entité 2 de contrôle, le module 3B de réception de l’entité 3 extrait les informations contenues dans la réponse et les stocke par exemple dans une mémoire cache pour une durée déterminée (étape F50). De cette sorte, lorsqu’il a besoin d’accéder à un service particulier correspondant au(x) critère(s) de recherche au(x)quel(s) répondent les entités applicatives candidates de l’ensemble NF-MATCH, il peut accéder rapidement aux attributs de ces entités applicatives candidates en consultant sa mémoire cache. On suppose maintenant que l’entité 3 souhaite effectivement accéder à un service offert par les entités applicatives candidates de l’ensemble NF-MATCH. Si l’ensemble NF-MATCH comprend plusieurs entités applicatives candidates, l’entité 3 peut, au moyen de son module 3D de sélection, sélectionner l’une d’entre elles en fonction d’un ou de plusieurs critères de sélection déterminés (étape F60). On désigne NFk0 l’entité applicative sélectionnée. Par exemple, le module 3D de sélection peut tenir compte pour sélectionner l’entité applicative NFk0 dans l’ensemble NF-MATCH des formats d’encodage supportés par les entités applicatives candidates et en sélectionner une qui supporte un format d’encodage spécifique (par exemple un format de compression tel que gzip). En variante ou en complément, d’autres critères de sélection peuvent être considérés par le module 3D de sélection, comme par exemple les charges des entités applicatives candidates ou leurs capacités respectives, ou une priorité associée à chacune d’entre elles, ou leurs localisations, ou encore une combinaison de plusieurs de ces critères ou d’autres critères. Suite à cette sélection, l’entité 3 via son deuxième module 3D de communication envoie une requête d’accès au service offert par l’entité applicative NFk0 sélectionnée (étape F70). Cette requête est par exemple ici une requête HTTP POST, PUT ou PATCH selon le service considéré comprenant un corps de requête embarquant un contenu. Grâce à l’invention, le module 3D de communication peut avantageusement encoder ce contenu au moyen d’un format d’encodage supporté par l’entité applicative NFk0 selon les informations stockées dans sa mémoire cache à l’étape F50. En d’autres mots, l’entité 3 peut exploiter un format d’encodage supporté par l’entité applicative NFk0 tel qu’un format de compression dès la première requête qu’elle lui envoie lors d’un accès à un service proposé par l’entité applicative NFk0. Elle n’est pas obligée d’attendre une réponse à cette première requête pour encoder les contenus qu’elle souhaite lui transmettre. Bien entendu, elle peut (et continue préférentiellement d’) appliquer ce format d’encodage dans les requêtes suivantes également. On note que dans certains contextes, il peut s’avérer inapproprié (voire interdit) d’appliquer un format de compression à un contenu envoyé dans le corps d’une requête ou d’une réponse. C’est le cas par exemple lorsque le contenu en question comprend un nombre faible d’octets : la compression d’un tel contenu peut alors avoir un effet opposé à celui recherché à savoir que le nombre d’octets du contenu compressé peut être supérieur à celui du contenu non compressé. De même, certains services offerts par certaines entités applicatives comme par exemple des entités de type AMF ou SMF comportent des opérations s’appuyant sur des requêtes et/ou des réponses qui ont des corps composés de plusieurs parties. Une compression de certaines de ces parties n’apporte pas nécessairement un gain significatif voire est interdit. Pour gérer ces situations, l’entité 3 peut être configurée pour vérifier avant d’appliquer un format d’encodage au contenu (en tout ou partie) d’une requête ou d’une réponse qu’elle envoie à une entité applicative, si le contenu est approprié (par exemple s’il vérifie un critère de taille déterminé ou si son encodage n’est pas interdit). Comme mentionné précédemment, le profil d’une entité applicative gérée par l’entité 2 de contrôle peut être affecté par différents événements (ex. création, suppression, modification), et évoluer dans le temps. Cela peut avoir pour conséquence que les informations stockées dans la mémoire cache de l’entité 3, et en particulier les formats d’encodage supportés par les entités applicatives, peuvent ne plus être d’actualité lorsque l’entité 3 cherche à accéder à un service offert par l’une des entités applicatives candidates, sans que celui-ci en soit informé. Dans l’exemple des formats d’encodage, si l’événement consiste en l’activation d’un nouveau format d’encodage au niveau d’une entité applicative candidate, cela ne pose pas de problème en soi dès lors que les autres formats d’encodage sont toujours supportés par l’entité applicative candidate. Un problème se pose lorsqu’un format d’encodage n’est plus supporté par l’entité applicative candidate. Plusieurs solutions sont alors possibles pour gérer ce cas de figure dans le contexte de l’invention. Une première solution, connue du standard 3GPP, consiste, si l’entité 3 utilise un format d’encodage qui n’est plus supporté par l’entité applicative avec laquelle elle interagit et reçoit une réponse de rejet avec un status 415, à envoyer de nouveau la requête sans encodage ou avec un encodage conforme à l’un des formats indiqués le cas échéant par l’entité applicative dans un entête de la réponse 415, par exemple dans un champ Accept-Encoding. Une deuxième option, connue également du standard 3GPP, consiste suite à la réception de la réponse de rejet 415, à envoyer une requête OPTIONS à l’entité applicative pour obtenir une mise à jour des formats d’encodage qu’elle supporte. Le choix de l’une ou l’autre de ces options dépend de la configuration de l’entité 3 du réseau (choix d’implémentation de l’équipementier de l’entité 3). Il convient toutefois de noter que ces deux solutions peuvent dégrader un peu les performances de l’entité 3. Selon une troisième option illustrée à la , l’entité 3 peut souscrire auprès de l’entité 2 de contrôle pour recevoir des notifications l’informant des événements qui affectent les profils des entités applicatives qu’elle gère. Lors de la souscription, l’entité 3 peut préciser l’étendue des informations qu’elle souhaite recevoir, et notamment le type d’événements (ex. création, modification, suppression d’un profil) dont elle souhaite être informée, et les ressources concernées. Plus précisément, dans le mode de réalisation décrit ici, l’entité 3 envoie, par l’intermédiaire de son module 3E de souscription, une requête de souscription à l’entité 2 de contrôle indiquant les événements dont elle souhaite être informée (étape G10). Il peut s’agir par exemple de changements (création, modification et suppression) affectant des profils d’un type d’entités applicatives donné (ex. fonction réseau AMF). Bien entendu cet exemple n’est donné qu’à titre illustratif et n’est pas limitatif en soi. Notamment, d’autres éléments peuvent être indiqués lors de la souscription comme par exemple un service particulier, un identifiant d’une entité applicative, etc. La requête de souscription est par exemple ici une requête HTTP POST. Elle contient les événements auxquels l’entité 3 souscrit. Elle contient en outre avantageusement au moins un format d’encodage supporté par l’entité 3, par exemple un format de compression. Sur réception de la requête de souscription, l’entité 2 de contrôle mémorise via son module 2C de notification, dans un contexte de la souscription de l’entité 3, le ou les formats d’encodage supportés par cette dernière (étape G20), et confirme la souscription auprès de l’entité 3 en lui envoyant une réponse 201 Created (étape G30). Puis, lorsqu’elle détecte un événement correspondant à la souscription de l’entité 3 (étape G40), l’entité 2 de contrôle par l’intermédiaire de son module 2D de notification, envoie une notification à l’entité 3 pour l’informer de l’événement détecté (étape G50). Cette notification est par exemple ici une requête HTTP POST. Elle comprend, dans le corps de la requête, les informations NotificationData relatives à l’événement détecté. Ces informations peuvent comprendre, suivant l’événement détecté, tout ou partie du profil affecté par l’événement (tout du moins de la partie publiée par l’entité 2 de contrôle lors de la procédure de découverte). Ainsi à titre d’exemple, si l’événement est une création de profil, la notification comprend tous les attributs du nouveau profil qui sont habituellement publiés lors de la procédure de découverte et qui permettent à l’entité 3 d’accéder au service associé à ce profil. Si l’événement est une modification d’un profil existant, la notification peut comprendre uniquement les attributs modifiés, ou récapituler l’ensemble des attributs habituellement publiés lors de la procédure de découverte. Avantageusement, les informations incluses dans le corps de la notification sont encodées par le module 2D de notification dans un format d’encodage supporté par l’entité 3 et fourni lors de sa souscription. Sur réception de cette notification, l’entité 3 met à jour les profils concernés mémorisés dans sa mémoire cache (étape G60). Cette solution permet avantageusement de diminuer le laps de temps pendant lequel l’entité 3 est susceptible d’utiliser des informations qui ne sont pas à jour pour accéder aux services proposées par les entités applicatives NF1,…,NFN. On note qu’il est possible au niveau d’une entité du réseau d’implémenter de façon complémentaire plusieurs des trois solutions proposées ci-dessus (par exemple les première et troisième solutions). Ainsi, comme il apparaît au vu de ce qui précède, l’invention permet de façon simple d’optimiser les échanges entre les différentes entités du système 1, en s’appuyant sur la connaissance des formats d’encodage supportés par ces différentes entités. Il convient de noter que dans toutes les procédures qui viennent d’être décrites, ces formats d’encodage peuvent indifféremment être fournis dans des champs ou des attributs dédiés, dans des champs ou des attributs propriétaires, ou encore dans des structures de données telles que la structure de données capInfo évoquée précédemment, comprenant au moins une option de communication (à savoir au moins un format d’encodage) supportée par l’entité considérée. Bien que l’invention ait été décrite dans le contexte d’un réseau 5G défini par le standard 3GPP, en référence à des entités applicatives et une entité communicante 3 de type fonctions réseau, et une entité de contrôle de type NRF, comme mentionné précédemment, l’invention peut s’appliquer d’autres entités. Par exemple l’entité 3 peut en variante être une autre entité de contrôle de type NRF, appartenant ou non au même PLMN que l’entité 2 de contrôle, ou un équipement intermédiaire de type SCP agissant pour le compte d’une entité applicative « customer », ou encore un équipement utilisateur rattaché au réseau ou une fonction applicative (ou « Application Function » en anglais), se trouvant dans le réseau ou externe au réseau. Dans le cas d’un équipement SCP, après avoir découvert les entités applicatives candidates et sélectionné l’une d’entre elles, l’équipement SCP peut encoder les contenus reçus de l’entité applicative « customer » au nom de laquelle il agit en utilisant un format d’encodage supporté par l’entité applicative candidate. Autrement dit, l’invention permet de mettre en œuvre un encodage sur le tronçon reliant l’équipement SCP à l’entité 2 de contrôle ; en revanche elle n’assure pas la mise en œuvre d’un tel encodage entre l’entité applicative « consumer » et l’équipement SCP agissant pour le compte de cette entité applicative. On note que l’équipement SCP est une entité applicative qui peut également s’enregistrer auprès de l’entité 2 de contrôle et être découverte par d’autres entités du réseau et notamment d’autres équipements SCP, dans l’hypothèse où plusieurs SCP se trouvent sur un chemin reliant une entité applicative « consumer » et une entité applicative « producer ». Cela permet d’appliquer également un encodage sur chaque segment du chemin de communication reliant deux équipements SCP. De même, il a été fait référence dans ce qui précède pour mieux illustrer l’invention aux procédures NRF_Bootstrapping, NRF_NFManagement et NRF_NFDiscovery définies par le standard 3GPP, mais l’invention peut s’appliquer à d’autres procédures visant un but similaire, et notamment à des procédures d’enregistrement ou de découverte propriétaires. L’invention peut aussi s’appliquer dans d’autres générations de réseau de communications ou dans d’autres contextes qu’un réseau 5G, comme par exemple à un réseau 6G ou de génération suivante, à un système informatique en nuage proposant des microservices, à un réseau propriétaire, etc., utilisant des procédures d’enregistrement et de découverte de ces microservices. Elle peut également s’appliquer à d’autres protocoles. En outre l’invention peut également s’appliquer à d’autres entités applicatives que des instances virtualisées de fonction réseau, comme par exemple des entités applicatives physiques. L’invention peut également s’appliquer à d’autres protocoles que le protocole HTTP/2, comme par exemple à une autre version du protocole HTTP (HTTP/1.1), ou aux protocoles SOAP, CORBA, gRPC, QUIC, ou de façon générale à tout autre protocole basé sur l’échange de requêtes et de réponses, et supportant un encodage du contenu du corps des requêtes et/ou des réponses, typiquement une compression de ce contenu. Ce qui vient d’être décrit dans le cadre de requêtes/réponses HTTP/2, et en particulier les données véhiculées par ces requêtes/réponses pour la mise en œuvre de l’invention, s’applique, transposé aux requêtes/réponses de ces protocoles. Procédé de gestion, par une entité (2) de contrôle d’un réseau (CN), d’une pluralité d’entités applicatives (NF1,…,NFN) proposant des services dans le réseau, ledit procédé de gestion comprenant : une étape d’enregistrement (E40) de chaque entité applicative gérée par l’entité de contrôle comprenant une mémorisation d’un profil de ladite entité applicative, ce profil comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle ; et en réponse à une requête (F10) en provenance d’une première entité (3), une étape (F40) de fourniture à cette première entité, pour au moins une dite entité applicative gérée par l’entité de contrôle, d’au moins une partie de la pluralité d’attributs du profil de cette entité applicative, ladite partie comprenant ledit au moins un format d’encodage supporté par cette entité applicative. Procédé de gestion selon la revendication 1 dans lequel ladite requête est une requête de découverte d’au moins une dite entité applicative gérée par l’entité de contrôle. Procédé de gestion selon la revendication 1 ou 2 comportant en outre : une étape (G10) de réception d’une demande de souscription, en provenance d’une deuxième entité (3), pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l’entité de contrôle, cette demande de souscription indiquant au moins un format d’encodage supporté par la deuxième entité ; suite à une détection (G40) d’un évènement correspondant à ladite demande de souscription, une étape (G50) de notification de ladite deuxième entité comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la deuxième entité et indiqué dans ladite demande de souscription. Procédé de gestion selon la revendication 3 dans lequel ledit événement comprend une modification, une suppression ou une création d’un profil d’une entité applicative gérée par l’entité de contrôle, et/ou lesdites informations comprises dans la notification comprennent tout ou partie dudit profil. Procédé de gestion selon l’une quelconque des revendications 1 à 4 comprenant en outre : une étape (E10) de réception en provenance d’une troisième entité (NFk) d’une requête d’amorçage visant à découvrir des services proposés par l’entité de contrôle et/ou des ressources gérées par celle-ci ; et une étape (E20) d’envoi d’une réponse à ladite requête d’amorçage de ladite troisième entité, ladite réponse comprenant en outre au moins un format d’encodage supporté par l’entité de contrôle. Procédé d’enregistrement d’une entité applicative (NFk) proposant au moins un service dans un réseau, auprès d’une entité de contrôle du réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau, ledit procédé d’enregistrement comprenant une fourniture (E40) par ladite entité applicative à l’entité de contrôle lors dudit enregistrement d’un profil de ladite entité applicative, ce profil comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle, ladite entité de contrôle étant configurée pour fournir au moins une partie de ladite pluralité d’attributs du profil de l’entité applicative, ladite partie comprenant ledit au moins un format d’encodage, en réponse à une requête en provenance d’une autre entité. Procédé d’enregistrement d’une entité applicative (NFk) selon la revendication 6 comprenant en outre, avant l’enregistrement, - une étape (E10) d’envoi d’une requête d’amorçage à l’entité de contrôle visant à découvrir des services qu’elle propose et/ou des ressources gérées par celle-ci ; - une étape (E20) de réception d’une réponse à ladite requête d’amorçage comprenant en outre au moins un format d’encodage supporté par l’entité de contrôle ; un dit format d’encodage supporté par l’entité de contrôle étant utilisé lors de l’enregistrement pour encoder le profil fourni à l’entité de contrôle. Procédé de communication d’une entité (3), dite « quatrième » entité, avec une entité (2) de contrôle du réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau et mémorisant des profils de ces entités applicatives, ledit procédé de communication comprenant : une première étape (F10) d’envoi à ladite entité de contrôle d’une requête de découverte d’entités applicatives gérées par l’entité de contrôle ; une étape (F20) de réception d’une réponse à ladite requête de découverte indiquant au moins une entité applicative dite candidate gérée par l’entité de contrôle et une pluralité d’attributs de cette entité applicative candidate extraits d’un profil de l’entité applicative mémorisé par l’entité de contrôle, ladite pluralité d’attributs incluant au moins un format d’encodage supporté par cette entité applicative candidate et pouvant être utilisé lors d’un accès à un service proposé par elle. Procédé de communication selon la revendication 8 comprenant en outre une deuxième étape (F70) d’envoi, à une dite entité applicative candidate indiquée dans la réponse reçue, d’une requête comprenant un contenu encodé au moyen d’un format d’encodage supporté par cette entité applicative candidate et indiqué dans la réponse reçue. Procédé de communication selon la revendication 8 ou 9 dans lequel la requête envoyée lors de la deuxième étape d’envoi est la première requête que la quatrième entité envoie à l’entité applicative candidate lors d’un accès à un service proposé par cette entité applicative candidate. Procédé de communication selon l’une quelconque des revendications 8 à 10 dans lequel la réponse à la requête de découverte indique une pluralité d’entités applicatives candidates et l’entité applicative candidate à laquelle est envoyée la requête lors de la deuxième étape d’envoi est sélectionnée (F60) parmi ladite pluralité d’entités actives candidates en tenant compte des formats d’encodage respectifs supportés par cette pluralité d’entités applicatives candidates. Procédé de communication selon l’une quelconque des revendications 8 à 11 comprenant en outre : une étape (G10) d’une demande de souscription à l’entité de contrôle pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l’entité de contrôle, cette demande de souscription indiquant au moins un format d’encodage supporté par la quatrième entité ; et suite à une détection (G40) d’un évènement correspondant à ladite demande de souscription, une étape (G50) de réception d’une notification en provenance de l’entité de contrôle comprenant des informations relatives audit événement encodées au moyen d’un dit format d’encodage supporté par la quatrième entité et indiqué dans la demande de souscription. Procédé selon l’une quelconque des revendications 1 à 12 dans lequel au moins un dit format d’encodage vise un encodage d’un contenu transmis dans un corps d’une requête ou d’une réponse conforme à une version du protocole HTTP (HyperText Transfer Protocol). Procédé selon l’une quelconque des revendications 1 à 13 dans lequel dans au moins un profil d’une entité applicative gérée par l’entité de contrôle, au moins un dit format d’encodage est fourni dans un attribut s’appliquant : à l’ensemble des services proposés par cette entité applicative ; ou à un service donné ou à une version donnée d’un service proposé par cette entité applicative ; ou à une ressource donnée gérée par un service offert par cette entité applicative ; ou à une opération donnée sur une ressource gérée par un service offert par cette entité applicative. Procédé selon l’une quelconque des revendications 1 à 14 dans lequel au moins un dit format d’encodage est un format de compression de données. Procédé selon l’une quelconque des revendications 1 à 15 dans lequel au moins un dit format d’encodage supporté par une dite entité est inclus dans une structure de données comprenant au moins une option de communications supportée par cette entité. Entité (2) de contrôle d’un réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau, ladite entité de contrôle comprenant : un module (2A) d’enregistrement, configuré pour enregistrer chaque entité applicative gérée par l’entité de contrôle, ledit module d’enregistrement étant configuré pour mémoriser lors de l’enregistrement d’une entité applicative un profil de cette entité applicative comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle ; et un module (2B) de publication activé en réponse à une requête en provenance d’une autre entité, et configuré pour fournir à cette autre entité, pour au moins une dite entité applicative gérée par l’entité de contrôle, au moins une partie de la pluralité d’attributs du profil de cette entité applicative, ladite partie comprenant ledit au moins un format d’encodage supporté par cette entité applicative. Entité applicative (NF1,…,NFN) d’un réseau proposant au moins un service dans le réseau, ladite entité applicative comprenant un module d’enregistrement (NFk-C) configuré pour enregistrer ladite entité applicative auprès d’une entité de contrôle du réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau, ledit module d’enregistrement étant configuré pour fournir à l’entité de contrôle lors dudit enregistrement un profil de ladite entité applicative, ce profil comprenant une pluralité d’attributs incluant au moins un format d’encodage supporté par ladite entité applicative et pouvant être utilisé lors d’un accès à un service proposé par elle, ladite entité de contrôle étant configurée pour fournir au moins une partie de ladite pluralité d’attributs du profil de l’entité applicative, ladite partie comprenant ledit au moins un format d’encodage, en réponse à une requête en provenance d’une autre entité. Entité (NFk, 3) comprenant : un module (3A) de communication configuré pour envoyer à une entité de contrôle d’un réseau gérant une pluralité d’entités applicatives proposant des services dans le réseau et mémorisant des profils desdites entités applicatives, une première requête de découverte d’entités applicatives gérées par l’entité de contrôle ; et un module (3B) de réception, configuré pour recevoir une réponse à ladite requête de découverte indiquant au moins une entité applicative dite candidate gérée par l’entité de contrôle et une pluralité d’attributs de cette entité applicative candidate extraits d’un profil de l’entité applicative mémorisé par l’entité de contrôle, ladite pluralité d’attributs incluant au moins un format d’encodage supporté par cette entité applicative candidate et pouvant être utilisé lors d’un accès à un service proposé par elle. Système (1) comprenant : au moins une entité applicative (NF1,…,NFN) selon la revendication 18 proposant au moins un service dans un réseau ; une entité(2) de contrôle du réseau selon la revendication 17 gérant ladite au moins une entité applicative ; et au moins une entité (3, NFk) selon la revendication 19.