FR3121562A1

FR3121562A1 - Procédés de souscription et de notifications, et entités configurées pour mettre en œuvre ces procédés.

Info

Publication number: FR3121562A1
Application number: FR2103448A
Authority: FR
Inventors: Michel Trefcon; Philippe Bertin; Alexandra ANSIAUX
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2021-04-02
Filing date: 2021-04-02
Publication date: 2022-10-07
Also published as: CN117063522A; WO2022208034A1; EP4315962A1

Abstract

Procédés de souscription et de notification, et entités configurées pour mettre en œuvre ces procédés. L’invention vise un procédé de souscription d’une première entité communicante (2) auprès d’une deuxième entité communicante (3), ledit procédé étant destiné à être mis en œuvre par la première entité et comprenant : - une étape de demande de souscription auprès de la deuxième entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d’encodage supporté par la première entité ; et - suite à une détection par la deuxième entité d’un dit événement correspondant à la demande de souscription, une étape de réception en provenance de la deuxième entité d’une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription. Figure 1

Description

Procédés de souscription et de notifications, 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 la notification d’événements dans 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^èmeGé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 fournissant 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 chaque instance 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). Outre le service de découverte évoqué précédemment, 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 événement affectant une fonction NF « producer », comme par exemple la disponibilité d’une nouvelle instance d’un type de fonction NF, la mise à jour d’un attribut du profil d’une fonction NF, etc.

De nombreuses autres fonctions NF du réseau cœur 5G proposent aujourd’hui des services d’exposition d’événements comme celui proposé par la fonction NRF. Citons par exemple le service « Nsmf_EventExposure » qui permet à des fonctions NF « consumers » d’être informées par la fonction SMF d’événements relatifs à une session PDU (pour « Protocol Data Unit » en anglais), ou encore le service « Namf_EventExposure » qui permet à des fonctions NF « consumers » d’être informées par la fonction AMF d’événements relatifs à l’accès et à la mobilité d’un équipement utilisateur, d’un groupe d’équipements utilisateurs ou de l’ensemble des équipements utilisateurs gérés par la fonction AMF.

Le réseau cœur 5G utilise, pour les échanges entre fonctions NF, et notamment la notification d’événements, le protocole client-serveur HTTP et plus particulièrement sa version HTTP/2. 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. L’application de ce principe aux échanges entre les fonctions NF au sein du réseau cœur 5G est également envisagée aujourd’hui. En effet, à titre indicatif, la charge utile d’un profil d’une fonction NF fourni dans une requête 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 messages échangés sur le réseau cœur 5G, peut constituer une charge totale importante.

Selon le 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 ou formats d’encodage (pour « encoding » en anglais) qu’il supporte (par exemple un encodage mettant en œuvre une compression tels que gzip ou deflate). Le serveur retourne alors une réponse au client dont le corps est conforme aux indications d’encodage fournies par le client, et indique dans un entête « Content-Encoding » de l’entête de sa réponse, le format d’encodage (et plus particulièrement de compression) qu’il a 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 dans l’API de la fonction NRF pour le service de gestion Nnrf_NFManagement (qui comprend les opérations d’enregistrement, de désenregistrement et de mise à jour évoquées précédemment) et dans l’API de la fonction AMF. 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 ou dans une requête) 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 et Nnrf_AccessToken), mais il n’est pas fait référence explicitement à son utilisation pour les notifications. Selon le document 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, les fonctions NF « consumers » devraient supporter l’utilisation du format d’encodage gzip dans les notifications envoyées par la fonction NRF. Toutefois, cette contrainte se limite aux notifications émises par la fonction réseau NRF, et à un seul format d’encodage à savoir le format gzip. En outre, il n’est pas sûr qu’une fonction NF « consumer » supporte en pratique le format d’encodage gzip : si ce format d’encodage n’est pas supporté, la fonction réseau NRF s’expose à un rejet de ses notifications.

Il existe donc un besoin d’une solution ne présentant pas les inconvénients précités et pouvant s’appliquer de façon homogène à toutes les fonctions réseau d’un réseau cœur 5G.

L’invention offre une telle solution en proposant un procédé de souscription d’une première entité communicante auprès d’une deuxième entité communicante, ledit procédé étant destiné à être mis en œuvre par la première entité et comprenant :
- une étape de demande de souscription auprès de la deuxième entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité relatif, cette demande de souscription indiquant au moins un format d’encodage supporté par la première entité ; et
- suite à une détection par la deuxième entité d’un dit événement correspondant à la demande de souscription, une étape de réception en provenance de la deuxième entité d’une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription.

Corrélativement, l’invention vise aussi une entité communicante, dite première entité, comprenant :
- un premier module configuré pour demander une souscription auprès d’une deuxième entité de réseau pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d’encodage supporté par la première entité ; et
- un deuxième module, activé suite à une détection par la deuxième entité d’un dit événement correspondant à la demande de souscription, ledit deuxième module étant configuré pour recevoir en provenance de la deuxième entité une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription.

L’invention vise aussi un procédé de notification d’événements à une première entité communicante, destiné à être mis en œuvre par une deuxième entité communicante, ce procédé de notification comprenant :
- une étape de réception d’une demande de souscription en provenance de la première entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d’encodage supporté par la première entité ; et
- suite à une détection par la deuxième entité d’un dit événement correspondant à la demande de souscription, une étape d’envoi à la première entité d’une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription.

Corrélativement, l’invention vise aussi une entité communicante, dit deuxième entité, comprenant :
- un module de réception, configuré pour recevoir une demande de souscription d’une première entité communicante pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d’encodage supporté par la première entité ; et
- un module d’envoi, activé suite à une détection d’un dit événement correspondant à la demande de souscription, et configuré pour envoyer à la première entité une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription.

Aucune limitation n’est attachée à la nature des première et deuxième entités communicantes. Il peut s’agir d’entités physiques ou logicielles, appartenant à un même réseau ou à des réseaux distincts. De telles entités communicantes sont par exemple des entités de réseau, des fonctions d’applications (ou « Application Functions » en anglais) ou encore des équipements utilisateurs. Il peut s’agir notamment d’entités applicatives, c’est-à-dire d’entités configurées pour mettre en œuvre des logiques de traitement déterminées, comme notamment des entités offrant et/ou consommant des services dans un réseau telles que des fonctions réseau ou des instances de fonctions réseau (ex. fonctions AMF, SMF, NRF, etc.). Mais il peut également s’agir d’autres entités telles que des équipements intermédiaires situés sur le chemin de communication entre deux fonctions réseau comme par exemple des équipements SCP (pour « Service Communication Proxy » en anglais), ou encore des équipements utilisateurs.

On note en outre que bien qu’introduite en référence à un réseau cœur 5G, l’invention ne se limite pas à ce contexte. Elle peut s’appliquer à d’autres générations de réseaux (ex. 4G, 6G, et suivantes), à des réseaux propriétaires, ou encore à d’autres types de réseaux, mettant en œuvre des services d’exposition d’événements, comme par exemple à des architectures micro-services « event-driven » dont un exemple illustratif est décrit à l’URL https://www.theodo.fr/digital-et-strategie/architectures-event-driven-construisez-des-applications-performantes-et-d%C3%A9coupl%C3%A9es-avec-rabbitmq.

L’invention permet avantageusement d’optimiser la transmission des notifications émises de façon asynchrone par la deuxième entité communicante pour signaler, aux entités communicantes qui en ont fait la demande, divers événements relatifs aux éléments qu’elle gère et/ou surveille (ex. équipements d’utilisateurs, fonctions réseau, sessions de données, etc.). Elle n’impose avantageusement aucun format d’encodage spécifique, mais s’adapte aux capacités des entités ayant souscrit à la notification des événements. Un tel format peut être bien entendu un format de compression tel que gzip, deflate, compress, ce qui permet d’optimiser les performances des échanges entre les entités en termes de latence et de bande passante notamment, mais d’autres formats d’encodage peuvent être envisagés également, comme par exemple un format d’encodage base64, un format invariant (ou « identity ») prônant l’absence de transformation du contenu, 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. L’invention offre ainsi une grande flexibilité et permet d’appliquer des formats d’encodage différents aux notifications envoyées à des entités différentes, ou en fonction du contexte dans lesquels se trouvent les première et deuxième entités, ou encore en fonction des caractéristiques des informations à notifier (sensibilité, taille, etc.).

Grâce à cette flexibilité, l’invention peut s’appliquer à de nombreuses entités communicantes, et à leurs spécificités respectives. Elle offre ainsi une solution homogène qui peut être transposée notamment aux différentes fonctions réseau d’un réseau cœur, ce qui facilite sa mise en œuvre dans un réseau standardisé tel qu’un réseau 3GPP.

Aucune limitation n’est attachée à la nature des événements notifiés. Ils dépendent bien entendu de la fonction de la deuxième entité communicante et des éléments qu’elle gère et/ou qu’elle surveille. Par exemple, pour une fonction réseau de type catalogue de fonctions réseau (i.e. une fonction NRF) qui gèrent des fonctions réseau, ces événements peuvent être la création, la modification ou encore la suppression d’un profil d’une fonction réseau. Pour une fonction réseau gérant l’accès et la mobilité (i.e. une fonction AMF) dans un réseau, ces événements peuvent comprendre la localisation ou la présence dans une zone d’intérêt d’un équipement utilisateur ou UE (pour « User Equipment » en anglais), ou d’un groupe d’UEs, le nombre d’UEs dans une zone donnée, une perte de connectivité d’un UE ou d’un groupe d’UEs, etc. Pour une fonction réseau gérant des sessions PDU (i.e. une fonction SMF), ces événements peuvent comprendre un changement de réseau ou PLMN (pour « Public Land Mobile Network » en anglais), une libération ou un établissement d’une session PDU, un changement de type d’accès, etc.

La solution offerte par l’invention s’intègre aisément aux procédures de souscription existantes, et en particulier dans le contexte d’un réseau 3GPP, aux procédures de souscription définies pour les différentes entités de réseau offrant un service d’exposition d’événements tels que les fonctions NRF, AMF, SMF mentionnées ci-avant. Elle nécessite seulement d’ajouter parmi les indications fournies lors de la souscription, les formats d’encodage supportés par la première entité. Par exemple, ce ou ces formats peuvent être notamment fournis dans le corps de la requête de souscription (ex. dans un champ prévu à cet effet) avec d’autres données relatives à la souscription comme les événements pour lesquels la première entité souhaite être notifiée, etc.

L’invention ne requiert donc pas de définition d’une logique complémentaire, ni l’échange de messages supplémentaires (comme par exemple une requête OPTIONS et la réponse associée, ou une requête contenant un champ Accept-Encoding et la réponse associée), ce qui permet de préserver les performances du réseau. Au niveau de la deuxième entité, le(s) format(s) d’encodage supporté(s) par la première entité peut(vent) avantageusement être mémorisé(s) dans le contexte de souscription de la première entité : l’invention est donc particulièrement facile à mettre en œuvre.

Dans un mode particulier de réalisation, la deuxième entité de réseau est une entité de contrôle gérant une pluralité d’entités applicatives d’un réseau.

Ce mode de réalisation a une application privilégiée lorsque la deuxième entité est par exemple une fonction NRF d’un réseau cœur 5G gérant une pluralité de fonctions réseau NF ou d’instances de fonctions NF. Comme mentionné précédemment, la fonction NRF est un catalogue gérant une pluralité de fonctions NF, et mémorisant les profils de chacune de ces fonctions NF, chaque profil comprenant 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.

Dans un mode particulier de réalisation, chaque profil d’entité applicative gérée par la deuxième entité, mémorisé par elle, comprend une pluralité d’attributs incluant au moins un format d’encodage supporté par cette entité applicative.

Ce mode de réalisation est particulièrement avantageux, car il permet à la deuxième entité non seulement de connaître les formats d’encodage supportés par une entité applicative en tant que « consumer » (lorsqu’elle reçoit les notifications de la deuxième entité), mais également, lorsque la deuxième entité gère cette entité applicative, de connaître les formats d’encodage supportés par elle en tant que « producer ». La deuxième entité est alors en mesure de publier ce ou ces formats d’encodage auprès d’entités le requérant, par exemple au cours d’une procédure de découverte d’entités applicatives gérées par la deuxième entité vérifiant un ou plusieurs critères donnés.

Dans un mode particulier de réalisation, ledit événement détecté est une création, une suppression ou une modification d’un élément géré par la deuxième entité.

Un tel élément est par exemple un profil d’une entité applicative gérée par l’entité de contrôle, dans l’exemple d’une fonction réseau NRF. Mais d’autres applications de ce mode de réalisation peuvent être envisagées. Par exemple pour une fonction AMF, un tel élément peut être un profil ou un contexte utilisateur regroupant les utilisateurs enregistrés dans un réseau et gérés par la fonction AMF.

L’élément en question peut être une ressource quelconque surveillée par la deuxième entité (ex. une session PDU, un équipement utilisateur ou un groupe d’équipements utilisateurs, une adresse IP, une entité virtuelle, une entité physique, etc.). Aucune limitation n’est attachée à la nature de cet élément.

Dans un mode particulier de réalisation, la notification envoyée par la deuxième entité est une requête conforme à une version du protocole HTTP.

Comme mentionné précédemment, l’invention a une application privilégiée dans le cadre d’un réseau 5G s’appuyant sur le protocole HTTP et notamment sur la version HTTP/2 de ce protocole, pour la compression des contenus des requêtes de notification conformes à ce protocole échangées entre les différentes entités impliquées dans l’invention.

Toutefois, 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.

Dans un mode particulier de réalisation, au moins un format d’encodage supporté par la première entité et indiqué dans la demande de souscription est un format de compression. Ainsi, le format d’encodage utilisé pour encoder les informations relatives à l’événement détecté dans la notification peut être un format de compression.

Ce mode de réalisation permet d’optimiser les performances et la latence du réseau. En effet, selon l’événement à l’origine de la notification et la configuration de la deuxième entité, une telle notification peut comprendre un volume de données important. Par exemple, pour une fonction réseau NRF, une telle notification peut comprendre un ou plusieurs profils en tout ou partie de fonctions réseau, ou seulement le cas échéant, les attributs du profil ou des profils affectés par l’événement. L’application d’un format d’encodage de type compression aux informations véhiculées par les notifications, compte tenu du nombre important de notifications susceptibles d’être envoyées par les différentes entités d’un réseau et du volume de données transmis par chacune d’entre elles, est donc particulièrement avantageuse en matière de latence et de bande passante.

Dans un mode particulier de réalisation, dans la demande de souscription, ledit au moins un format d’encodage supporté par la première entité est fourni dans une structure de données comprenant au moins une option de communication supportée par la première entité.

L’usage d’une telle structure de données permet de signaler de façon synthétique à la deuxième entité, lors de la souscription, plusieurs options de communication supportées par la première entité et qui peuvent être exploitées lors de l’envoi des notifications. Par exemple, outre les formats d’encodage, on peut envisager de signaler dans cette structure de données des formats de contenus (ex. json, xml, atom, etc.) supportés par la première entité permettant à la deuxième entité d’ajuster le format des informations qu’elle transmet dans les notifications à la première entité.

Ce mode de réalisation offre une grande flexibilité et est évolutif : il facilite l’application de l’invention à de nouvelles contraintes, en matière d’options de communication.

Dans un mode particulier de réalisation de l’invention, les procédés de souscription et de notification 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 première entité de réseau conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de souscription 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 deuxième entité de réseau conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de notification 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 souscription et de notification selon l’invention.

Selon un autre aspect, l’invention vise un système comprenant au moins une première entité communicante et une deuxième entité communicante selon l’invention.

Le système bénéficie des mêmes avantages cités précédemment que les procédés de souscription et de notification, et que les première et deuxième entités communicantes selon l’invention.

On peut également envisager, dans d'autres modes de réalisation, que les procédés de souscription, de notification, les première et deuxième entités communicantes 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 représente dans son environnement, un système 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 communicantes selon l’invention appartenant au système de la ;
la illustre, sous forme d’ordinogramme, les principales étapes d’un procédé de souscription mises en œuvre par une entité communicante du système de la dans un mode particulier de l’invention ; et
la illustre, sous forme d’ordinogramme, les principales étapes d’un procédé de notification mises en œuvre par une entité communicante du système de la dans un mode particulier de l’invention.

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.

Dans l’exemple envisagé à la , le système 1 comprend une première entité communicante 2 et une deuxième entité communicante 3 conformes à l’invention mettant en œuvre au sein du réseau cœur CN un mécanisme de souscription/notification d’événements. On suppose plus particulièrement ici que l’entité 3 est une entité de réseau gèrant différents éléments du réseau cœur CN, mis en œuvre dans le réseau cœur CN ou rattachés au réseau cœur CN, comme par exemple des fonctions réseau (NFs), des équipements utilisateurs (UEs), des sessions PDU, etc., et surveille différents types d’événements relatifs à ces éléments. Les événements surveillés par l’entité 3 et susceptibles d’être publiés (autrement dit d’être partagés avec d’autres entités comme par exemple avec l’entité 2) sont généralement prédéfinis, de sorte qu’une entité communicante peut souscrire à la notification de tout ou partie de ces événements si elle est intéressée par leur connaissance.

En variante, on peut envisager une découverte dynamique des événements susceptibles d’être publiés par l’entité 3, par exemple en l’interrogeant.

Dans une autre variante encore, on peut envisager qu’une entité souscrive inconditionnellement à tous les événements susceptibles d’être exposés par l’entité 3 ou à des événements vérifiant un ou plusieurs critères donnés.

L’invention ne se limite pas à une utilisation particulière de la connaissance des événements en question : l’entité, et en particulier l’entité 2, qui a souscrit à une notification d’événements surveillés par l’entité 3 peut utiliser cette connaissance par exemple pour gérer des éléments dont elle a la charge, pour mettre en œuvre des traitements qui lui sont confiés, etc.

Dans le mode de réalisation décrit ici, les deux entités sont des entités de réseau applicatives, c’est-à-dire des entités de réseau configurées pour mettre en œuvre des logiques de traitement déterminées dans le réseau cœur CN, comme notamment des entités offrant et/ou consommant des services dans le réseau cœur. Plus particulièrement, on suppose ici que les entités 2 et 3 sont des instances virtualisées de fonctions réseau telles que des fonctions AMF, SMF, NRF, etc., 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 telle fonction réseau peut comprendre une ou plusieurs opérations. Dans la suite de la description, une fonction réseau désigne une instance virtuelle d’une fonction réseau, chaque fonction réseau du réseau cœur CN pouvant être instanciée de façon multiple.

A titre illustratif et pour mieux comprendre l’invention, on considère dans la suite de la description que l’entité communicante 2 est une fonction réseau AMF et l’entité communicante 3 est une fonction réseau NRF (entité de contrôle au sens de l’invention) gérant une pluralité de fonctions réseau NF, telles que des fonctions réseau AMF, SMF, NRF, etc. (entités applicatives au sens de l’invention). De façon connue, une telle fonction NRF est un catalogue mémorisant pour chacune des fonctions NF qu’elle gère, un profil comprenant une pluralité d’attributs caractérisant l’état opérationnel de la fonction NF 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 que ces services gèrent, etc. La fonction NRF propose elle-même une pluralité de services comprenant notamment des services de découverte des fonctions NF qu’elle gère (et plus particulièrement de certains attributs du profil de ces fonctions NF dites « producers » permettant à des fonctions NF « consumers » d’accéder aux services offerts par les fonctions NF « producers »), de gestion (incluant les opérations d’enregistrement/désenregistrement/mise à jour évoquées précédemment), d’autorisation et d’amorçage (ou « bootstrapping » en anglais), qui reprennent la logique des services Nnrf_NFDiscovery, Nnrf_NFManagement, Nnrf_AccessToken et Nnrf_Boostrapping décrits notamment dans le document 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.

L’invention ne se limite toutefois pas aux hypothèses qui viennent d’être formulées. Comme évoqué précédemment, elle s’applique en effet à d’autres configurations du système 1 (plusieurs « premières » et « deuxièmes » entités communicantes selon l’invention), à d’autres réseaux (ex. d’autres générations de réseaux définis par le standard 3GPP ou par d’autres standards, des réseaux propriétaires, des architectures micro-services, etc.), ainsi qu’à d’autres entités communicantes physiques ou logicielles (ex. à des équipements intermédiaires SCP situés sur le chemin de communication entre deux fonctions réseau, à des fonctions d’applications, à des équipements d’utilisateurs, à des entités de réseau, etc.), dès lors que des mécanismes de souscription/notification sont mis en œuvre.

En outre, dans l’exemple envisagé ici, les première et deuxième entités communicantes appartiennent au même réseau cœur CN, mais l’invention s’applique également lorsque les première et deuxième entités communicantes appartiennent à des réseaux différents, ou lorsqu’une des entités est externe au réseau auquel appartient l’autre entité. Il peut s’agir par exemple de deux fonctions réseau NRF appartenant à deux réseaux PLMN distincts, ou d’une fonction réseau et d’une fonction d’application externe, etc.

Il convient également de noter qu’une même entité, qu’elle soit physique ou logicielle (virtuelle), peut être configurée pour être « une première entité » au sens de l’invention au regard de certaines entités (c’est-à-dire souscrivant à la notification d’événements donnés), et « une deuxième entité » au sens de l’invention au regard d’autres entités (c’est-à-dire notifiant des événements donnés). Par exemple, dans un réseau cœur 5G tel que défini par le standard 3GPP, la fonction réseau AMF peut être une première entité au regard de la fonction réseau NRF, et une deuxième entité au regard des fonctions réseau SMF, NEF (pour « Network Exposure Function » en anglais) ou UDM (pour « Unified Data Management » en anglais).

Dans le mode de réalisation décrit ici, les entités 2 et 3 sont 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 entités le cas échéant du réseau cœur CN ou externes au réseau CN. 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 (pour « Service Based Interface » en anglais). 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 l’entité 2, un enregistrement d’un programme d’ordinateur PROG2, comportant des instructions définissant les principales étapes d’un procédé de souscription selon l’invention.

Ce programme PROG2 définit des modules fonctionnels d’une première entité au sens de 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 premier module 2A de communication, configuré pour demander une souscription auprès de l’entité 3 pour obtenir des informations concernant au moins un événement surveillé par l’entité 3, la demande de souscription indiquant au moins un format d’encodage supporté par l’entité 2 ; et
un deuxième module 2B de communication, activé suite à une détection par l’entité 3 d’un dit événement correspondant à la demande de souscription, ce deuxième module 2B étant configuré pour recevoir en provenance l’entité 3 une notification comprenant des informations relatives à l’événement détecté, encodées au moyen d’un format d’encodage supporté par l’entité 2 et indiqué dans la demande de souscription.

Dans le mode de réalisation décrit ici, le programme PROG2 définit également un module 2C de traitement, configuré pour utiliser le cas échéant les notifications reçues par le deuxième module 2B de communication pour gérer, dans l’exemple envisagé ici, des éléments du réseau cœur CN ou rattachés à celui-ci dont l’entité 2 a la charge. Ainsi, dans l’exemple illustratif introduit précédemment où l’entité 2 est une fonction réseau AMF, le module 2C d’exploitation est configuré pour utiliser notamment les notifications reçues pour gérer efficacement l’accès et la mobilité des équipements utilisateurs dont il a la charge.

Les fonctions assurées par les modules 2A à 2C de l’entité 2 sont décrites plus en détail ultérieurement, en référence aux étapes du procédé de souscription 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é 3, un enregistrement d’un programme d’ordinateur PROG3, comportant des instructions définissant les principales étapes d’un procédé de souscription selon l’invention.

Ce programme PROG3 définit des modules fonctionnels d’une deuxième entité au sens de 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 3A de réception, configuré pour recevoir une demande de souscription d’une autre entité, par exemple ici de l’entité 2, pour obtenir des informations concernant au moins un événement surveillé par l’entité 3, cette demande de souscription indiquant au moins un format d’encodage supporté par l’entité 2. Dans l’exemple illustratif envisagé ici d’une fonction réseau NRF gérant plusieurs fonctions réseau NF et mémorisant pour chacune de ces fonctions réseau un profil d’attributs, un tel événement est par exemple la création, la suppression ou la modification d’un tel profil d’attributs, ou de façon équivalente, l’enregistrement et le désenregistrement de fonctions réseau gérées par la fonction NRF (qui se traduisent respectivement par la création et la suppression d’un profil au niveau de la fonction NRF), et la modification d’un profil d’attributs d’une fonction réseau. Bien entendu, les événements surveillés par l’entité 3 dépendent des services (fonctionnalités) assurés par cette entité 3, dans le réseau cœur CN ici, et/ou des éléments gérés par cette entité 3. Par exemple, un tel événement peut être la création, la suppression ou la modification d’un élément géré et/ou surveillé par l’entité 3. Mais d’autres événements peuvent être envisagés. Ainsi, pour une fonction réseau AMF, de tels événements peuvent comprendre par exemple, comme évoqué précédemment, la localisation ou la présence dans une zone d’intérêt d’un UE ou d’un groupe d’UEs, le nombre d’UEs dans une zone donnée, une perte de connectivité d’un UE ou d’un groupe d’UEs, etc. Pour une fonction réseau SMF, ces événements peuvent comprendre un changement de réseau ou PLMN, une libération ou un établissement d’une session PDU, un changement de type d’accès, etc. ;
un module 3B de surveillance, configuré pour surveiller de façon continue ou quasi-continue les éléments gérés par l’entité 3 et détecter le cas échéant les événements évoqués ci-avant relatifs à ces éléments ; et
un module 3C d’envoi, activé suite à une détection par le module 3B de surveillance d’un événement correspondant à la demande de souscription de l’entité de réseau 2 reçue par le module 3A de réception, et configuré pour envoyer à l’entité de réseau 2 une notification comprenant des informations relatives à cet événement détecté encodées au moyen d’un format d’encodage supporté par l’entité de réseau 2 et indiqué dans la demande de souscription.

Les fonctions assurées par les modules 3A à 2C de l’entité 3 sont décrites plus en détail ultérieurement, en référence aux étapes du procédé de notification selon l’invention.

Nous allons maintenant décrire en référence auxfigures 3 et 4respectivement les principales étapes d’un procédé de souscription et d’un procédé de notification selon l’invention telles qu’elles sont mises en œuvre respectivement par l’entité 2 et par l’entité 3, dans un mode particulier de réalisation.

On suppose ici que les événements surveillés par l’entité 3 et les éléments qu’elle gère et/ou surveille (dans l’exemple envisagé ici, des éléments du réseau cœur CN ou rattachés au réseau cœur CN) sont connus, et donc en particulier de l’entité 2.

Aucune limitation n’est attachée à la façon dont ces informations sont obtenues par l’entité 2. Elle peut être configurée par l’équipementier fournissant l’entité 2, à partir notamment de spécifications décrivant l’entité 3. C’est le cas notamment des fonctions réseau dans un réseau cœur 5G, ou plus généralement dans un réseau cœur défini par le standard 3GPP, ces événements et ces éléments étant décrits dans les spécifications relatives à ces fonctions réseau. Ainsi, dans l’exemple illustratif envisagé ici d’une entité 3 comprenant une fonction réseau NRF, ces informations sont décrites dans le document TS 29.510 introduit précédemment, au paragraphe 5.2.2.5 notamment. Conformément à ce document, les événements surveillés par la fonction réseau NRF sont l’enregistrement et le désenregistrement d’une fonction NF gérée par la fonction NRF, ainsi que la modification d’un profil d’une fonction NF gérée par la fonction NRF, c’est-à-dire de façon équivalente comme déjà évoqué, la création, la suppression et la modification d’un profil d’une fonction réseau gérée par l’entité 3, susceptible d’être publié par celle-ci auprès d’entités tierces. Un tel profil est un élément géré par l’entité 3 au sens de l’invention.

En variante, ces informations peuvent être obtenues par l’entité 2 de façon dynamique, en interrogeant l’entité 3.

En référence à la , on suppose que l’entité 2 (i.e. la fonction AMF dans l’exemple illustratif envisagé) est intéressée par être notifiée de la détection de tout ou partie des événements surveillés par l’entité 3, pour au moins l’un des éléments du réseau cœur CN gérés par l’entité 3.

L’entité 2, par l’intermédiaire de son premier module 2A de communication, envoie donc une demande de souscription à l’entité 3, pour obtenir des informations concernant ces événements (étape E10). Dans l’exemple envisagé ici d’un réseau cœur 5G défini par le standard 3GPP, cette demande de souscription est réalisée via l’envoi d’une requête de souscription HTTP POST. Elle contient, dans son corps, les données de la souscription SubscriptionData, à savoir notamment ici des informations indiquant le type de notifications que l’entité 2 souhaite recevoir (et plus particulièrement quel(s) événement(s) associé(s) à quel(s) élément(s) géré(s) par l’entité 3), ainsi qu’un identifiant ou URI dit de rappel (« callback » en anglais) sur laquelle l’entité 2 souhaite recevoir les notifications. On note que la demande de souscription de l’entité 2 peut porter sur un ou plusieurs éléments gérés et/ou surveillés par l’entité 3, par exemple sur des éléments vérifiant un critère donné (par exemple toutes les fonctions NF assurant un service donné ou d’un type donné). Dans l’exemple illustratif d’une entité 2 de type fonction AMF, l’entité 2 peut indiquer qu’elle souhaite recevoir des notifications lorsque l’un quelconque des événements de création/suppression ou modification d’un profil est détecté pour les instances des fonctions réseau AUSF (pour « AUthentication Server Function » en anglais), 5G-EIR (pour « Equipment Identity Register » en anglais), SMF, UDM et PCF gérées par l’entité 3 (fonction NRF dans cet exemple).

D’autres informations peuvent être spécifiées dans les données SubscriptionData comme par exemple une durée de validité de la souscription, ou un ou plusieurs paramètres conditionnels, propres au type de l’entité 3, qui peuvent être surveillés pour déterminer s’il convient ou non de déclencher une notification. Dans l’exemple d’une fonction NRF, de tels paramètres conditionnels peuvent être par exemple les attributs d’un profil qui doivent être changés pour déclencher une notification ou ceux qui n’ont pas besoin d’être surveillés à l’inverse. Ces paramètres conditionnels permettent d’apporter une granularité supplémentaire et de limiter l’envoi de notifications aux événements réellement pertinents pour l’entité 2.

En outre, conformément à l’invention, la demande de souscription comprend avantageusement parmi les données SubscriptionData, au moins un format d’encodage supporté par l’entité 2 et pouvant être utilisé pour encoder le contenu des notifications envoyées par l’entité 3 à l’entité 2. Dans le mode de réalisation décrit ici, le ou les formats d’encodage indiqués dans la demande de souscription comprennent au moins un format de compression, tel que gzip, deflate ou compress. Toutefois en complément ou en variante, d’autres formats d’encodage peuvent être supportés par l’entité 2 (ex. formats d’encodage base64, invariant (« identity »), etc.), et indiqués par elle dans la demande de souscription.

Il convient de noter que l’entité 2 n’est pas contrainte d’indiquer dans la demande de souscription tous les formats d’encodage qu’elle supporte. Elle peut sélectionner un ou plusieurs formats d’encodage spécifiques parmi ceux qu’elle supporte pour que l’un d’eux soit utilisé lors des notifications.

Par ailleurs, dans un mode particulier de réalisation, on peut envisager que l’entité 2 définisse des formats d’encodage éventuellement distincts en fonction des événements surveillés par l’entité 3 ou des éléments auxquels se rapportent ces événements. Par exemple, on peut envisager de définir un format de compression avec un plus fort taux de compression pour des contenus qu’on sait de taille importante (ex. profils de fonctions réseau), tandis qu’un format de compression avec un taux de compression plus faible ou un format d’encodage invariant peut être indiqué 2 pour des contenus de notification de taille moindre. Cet exemple n’est bien entendu donné qu’à titre illustratif.

En outre, les formats d’encodage indiqués par l’entité 2 peuvent évoluer dans le temps : l’entité 2 peut en effet mettre à jour sa souscription auprès de l’entité 3, en utilisant par exemple une requête HTTP PATCH comprenant dans son corps, les données de souscription modifiées le cas échéant.

Par ailleurs, dans le mode de réalisation décrit ici, le ou les formats d’encodage supportés par l’entité 2 et indiqués dans les données de souscription SubscriptionData sont fournis dans une structure de données, nommée par exemple capInfo, comprenant au moins une option de communication supportée par l’entité 2, chaque option de communication étant fournie dans un champ ou dans un attribut distinct (par exemple dans un champ ou attribut Content-Encoding de la structure capInfo pour les formats d’encodage). Avantageusement, cette structure de données peut comprendre d’autres options de communication pouvant être utilisées par l’entité 3 lors de l’envoi des notifications, comme par exemple des formats de contenus (ex. json, xml ou autres), supportés par l’entité 2 (fournis par exemple dans un champ ou attribut Content-Type de la structure capInfo), ou des algorithmes de chiffrement permettant de chiffrer des informations critiques fournies le cas échéant dans les notifications émises par l’entité 3 (fournis par exemple dans un champ ou attribut Encrypt-type de la structure capInfo), etc.

En variante, le ou les formats d’encodage peuvent être fournis dans un champ ou attribut simple dédié, par exemple dans un champ ou attribut Content-Encoding. Dans une autre variante encore, ils peuvent être fournis dans un champ ou attribut propriétaire prévu par le standard 3GPP (connu sous l’appellation de « vendor-specific extension »).

En référence à la , l’entité 3 reçoit, via son module 3A de réception, la demande de souscription de l’entité 2 (étape F10).

Dans le mode de réalisation décrit ici, l’entité 3 vérifie, par l’intermédiaire de son module 3A de réception, si la demande de souscription formulée par l’entité 2 est autorisée (étape test F20). Elle peut vérifier notamment que les données de souscription indiquées dans la requête de souscription sont cohérentes avec les informations qu’elle peut publier.

Si la demande de souscription n’est pas autorisée (réponse non à l’étape test F20), elle est rejetée par l’entité 3 et l’entité 2 en est informée (étape F30).

Sinon (la demande de souscription est autorisée) (réponse oui à l’étape test F20), l’entité 3 crée un contexte de souscription CNT_SUBS(2) pour l’entité 2 et stocke dans le contexte de souscription les données de souscription SubscriptionData incluant les formats d’encodage supportés par l’entité 2 (étape F40). Une réponse HTTP 201 Created est alors retournée à l’entité 2 par l’entité 3 pour l’informer du succès de sa demande de souscription (étape E20, ).

Comme évoqué précédemment, le module 3B de surveillance de l’entité 3 est configuré pour surveiller de manière continue ou quasi-continue (et en temps réel), les éléments gérés et/ou surveillés par l’entité 3 et plus particulièrement l’occurrence des événements que l’entité 3 est susceptible d’exposer (dans l’exemple de la fonction NRF, la création/suppression ou modification de profil(s) de fonction(s) réseau gérée(s) par la fonction NRF) (étape de surveillance F50 et étape test F60).

Dès lors, si le module 3B de surveillance de l’entité 3 détecte l’un de ces événements pour au moins l’un des éléments qu’il gère et/ou surveille (réponse oui à l’étape test F60), il vérifie si l’événement détecté correspond à l’une des demandes de souscription qu’il a reçues (étape test F70), et plus particulièrement ici, si l’événement détecté correspond à la demande de souscription faite par l’entité 2. Il consulte à cet effet les données de souscription contenues dans le contexte CNT_SUBS(2) et les compare avec les caractéristiques de l’événement détecté (par exemple, avec la nature de l’événement, l’élément concerné par cet événement, etc.).

Si aucune demande de souscription concerne l’événement détecté (réponse non à l’étape test F70), aucune notification n’est envoyée, et l’entité 3 continue sa surveillance (étape F50 et suivantes).

On suppose ici que l’événement détecté correspond à la demande de souscription formulée par l’entité 2, autrement dit, l’événement détecté par le module 3B de surveillance de l’entité 3 correspond à un événement pour lequel l’entité 2 souhaite être notifiée (réponse oui à l’étape test F70).

L’entité 3 envoie alors, via son module 3C d’envoi, une notification à l’entité 2 pour l’informer de l’événement détecté (étape F80). Cette notification est par exemple ici une requête HTTP POST. Elle comprend, dans son corps, des informations NotificationData relatives à l’événement détecté, propres à cet événement. Par exemple, pour une fonction NRF, ces informations NotificationData peuvent comprendre tout ou partie du profil de la fonction réseau affecté par l’événement, ou plus précisément tous les attributs de ce profil destinés à être publiés s’il s’agit d’un événement de type création d’un profil, ou s’il s’agit d’un événement de type modification d’un profil, tous les attributs de ce profil destinés à être publiés ou seulement ceux qui ont été modifiés. Si l’événement concerne une suppression d’un profil (ou de façon équivalente le désenregistrement de la fonction NF associée à ce profil), les informations NotificationData comprennent l’URI de l’instance de fonction NF concernée et le type d’événement détecté (i.e. la suppression du profil ou le désenregistrement de la fonction NF). Conformément à l’invention, les informations NotificationData fournies dans la requête de notification sont encodées au moyen d’un des formats d’encodage supportés par l’entité 2 et mémorisés dans le contexte CNT_SUBS(2) de sa souscription. Par exemple ici, le module 3C d’envoi sélectionne dans le contexte CNT_SUBS(2) un format de compression pour encoder les informations NotificationData. Il indique, conformément au protocole HTTP, dans l’entête Content-Encoding de la requête de notification, le format d’encodage appliqué.

Dans le mode de réalisation décrit ici, si la structure de données capInfo comprend d’autres options de communication qu’un ou des formats d’encodage supportés par l’entité 2, le module 3C d’envoi peut également appliquer ces options de communication aux informations NotificationData en plus de l’encodage.

En référence à la de nouveau, l’entité 2 reçoit, via son deuxième module 2B de communication, la notification émise par l’entité 3 et l’informant de l’événement détecté (étape E30).

L’entité 2 extrait les informations NotificationData contenues dans la notification et les décode en fonction du format d’encodage appliqué par le module 3C d’envoi de l’entité 3 et signalé conformément au protocole HTTP dans les entêtes de la requête de notification. Puis le module 2C de traitement exploite, les informations ainsi décodées, par exemple pour gérer les éléments du réseau cœur CN ou rattachés à celui-ci dont l’entité 2 a la charge. Comme mentionné précédemment, la façon dont le module 2C de traitement utilise ces informations dépend des services offerts par l’entité 2, dans le réseau cœur CN ici, et/ou de la pertinence de ces informations.

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, et plus particulièrement les notifications envoyées par l’entité 3 à l’entité 2. Avantageusement, les formats d’encodage supportés par l’entité 2, incluant préférentiellement un format de compression, sont fournis lors de la souscription de l’entité 2 aux événements surveillés par l’entité 3 de sorte que l’entité 3 peut compresser les informations qu’elle envoie à l’entité 2 sans avoir à mettre en œuvre des échanges complémentaires pour la négociation du format d’encodage à utiliser. Bien entendu, des mesures additionnelles peuvent être mises en œuvre par ailleurs, dans le réseau cœur ici, pour encoder d’autres contenus de requêtes et/ou de réponses. Ainsi, dans l’exemple illustratif envisagé ici d’une entité 3 comprenant une fonction NRF, on peut envisager par exemple que les profils des fonctions réseau gérées par la fonction NRF comprennent chacun un attribut contenant au moins un format d’encodage supporté par la fonction réseau associée et que cet attribut soit publié par la fonction NRF en réponse aux requêtes de découverte qu’elle reçoit dans le cadre du service Nnrf_NFDiscovery. Avantageusement, ces formats d’encodage peuvent être fournis lors de l’enregistrement des fonctions réseau auprès de la fonction NRF. De cette sorte, les entités à l’origine des requêtes de découverte adressées à la fonction NRF peuvent utiliser sans délai les formats d’encodage fournis pour accéder aux services proposés par les fonctions réseau (i.e. sans avoir à émettre de requêtes OPTIONS ou à attendre une réponse à une requête indiquant les formats d’encodage supportés par les fonctions réseau).

Par ailleurs, 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 de réseau de type fonctions réseau, et plus particulièrement à une fonction AMF et une fonction NRF appartenant à un même réseau cœur, l’invention peut s’appliquer à d’autres entités.

Typiquement elle peut s’appliquer à d’autres fonctions réseau d’un réseau 3GPP, consommatrice d’événements et exposant de tels événements. A titre d’autre exemple, le standard 3GPP définit dans le document TS 29.518 intitulé : « Technical Specification Group Core Network and Terminals; 5G System; Access and Mobility Management Services; Stage 3 », v16.7.0, mars 2021, que des fonctions réseau NEF, SMF ou UDM peuvent souscrire à la notification d’événements auprès d’une fonction réseau AMF en utilisant le service Namf_EventExposure. Ces fonctions réseau peuvent choisir alors d’être notifiées pour des événements concernant l’accès et la mobilité d’un UE, d’un groupe d’UEs voire de tous les UEs gérés par cette fonction AMF. Les différents événements exposés par la fonction AMF sont décrits dans le document TS 29.518 par exemple au paragraphe 6.2.6.3.3 dans la table 6.2.6.3.3-1. D’autres documents 3GPP définissent des mécanismes de souscription/notification entre d’autres fonctions réseau d’un réseau 5G, et les événements exposés par ces fonctions réseau.

L’invention peut s’appliquer également à d’autres réseaux qu’un réseau 5G, par exemple à un réseau 4G, 6G ou de génération suivante, ou à des réseaux propriétaires, ou à des architectures de micro-services « event-driven », etc., dès lors qu’un mécanisme de souscription/notification est mis en œuvre dans ce réseau et que les entités impliquées dans ce mécanisme sont susceptibles de supporter plusieurs formats d’encodage, et en particulier au moins un format de compression. En outre, l’invention est décrite en référence à des entités virtualisées, mais elle s’applique également à des entités physiques. Ces entités peuvent appartenir à un même réseau ou à des réseaux différents. Ainsi par exemple, les entités 2 et 3 peuvent être des fonctions NRF appartenant à deux PLMN différents, ou l’entité 3 une fonction réseau d’un réseau cœur et l’entité 2 une fonction d’application interne ou externe au réseau cœur, ou encore un équipement d’utilisateur.

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.

Claims

Procédé de souscription d’une première entité communicante (2) auprès d’une deuxième entité communicante (3), ledit procédé étant destiné à être mis en œuvre par la première entité et comprenant :
- une étape (E10) de demande de souscription auprès de la deuxième entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d’encodage supporté par la première entité ; et
- suite à une détection (F70) par la deuxième entité d’un dit événement correspondant à la demande de souscription, une étape (E30) de réception en provenance de la deuxième entité d’une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription.
Procédé de notification d’événements à une première entité communicante (2), destiné à être mis en œuvre par une deuxième entité communicante (3), ledit procédé comprenant :
- une étape (F10) de réception d’une demande de souscription en provenance de la première entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d’encodage supporté par la première entité ; et
- suite à une détection (F70) par la deuxième entité d’un dit événement correspondant à la demande de souscription, une étape (F80) d’envoi à la première entité d’une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription.
Procédé selon la revendication 1 ou 2 dans laquelle au moins une entité parmi la première entité et la deuxième entité (2,3) est une entité de réseau, une fonction d’application ou un équipement utilisateur.
Procédé selon l’une quelconque des revendications 1 à 3 dans lequel au moins une entité parmi la première entité et la deuxième entité est une fonction réseau ou une instance d’une fonction réseau.
Procédé selon l’une quelconque des revendications 1 à 4 dans laquelle la deuxième entité est une entité de contrôle gérant une pluralité d’entités applicatives d’un réseau.
Procédé selon l’une quelconque des revendications 1 à 5 dans lequel ledit événement détecté est une création, une suppression ou une modification d’un élément géré par la deuxième entité.
Procédé selon l’une quelconque des revendications 1 à 6 dans lequel la notification est une requête conforme à une version du protocole HTTP.
Procédé selon l’une quelconque des revendications 1 à 7 dans lequel ledit format d’encodage utilisé pour encoder les informations relatives audit événement détecté dans la notification est un format de compression.
Procédé selon l’une quelconque des revendications 1 à 8 dans lequel dans la demande de souscription, ledit au moins un format d’encodage supporté par la première entité est fourni dans une structure de données comprenant au moins une option de communication supportée par la première entité.
Programme d’ordinateur (PROG2,PROG3) comportant des instructions pour l’exécution d’un procédé selon l’une quelconque des revendications 1 à 9, lorsque ledit programme est exécuté par un ordinateur.
Support d’enregistrement (7) lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 10.
Entité communicante (2), dite première entité, comprenant :
- un premier module (2A) configuré pour demander une souscription auprès d’une deuxième entité communicante pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, la demande de souscription indiquant au moins un format d’encodage supporté par la première entité ; et
- un deuxième module (2B) activé suite à une détection par la deuxième entité d’un dit événement correspondant à la demande de souscription, ledit deuxième module de réception étant configuré pour recevoir en provenance de la deuxième entité une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription.
Entité communicante (3), dit deuxième entité, comprenant :
- un module (3A) de réception, configuré pour recevoir une demande de souscription d’une première entité communicante pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d’encodage supporté par la première entité ;
- un module (3C) d’envoi, activé suite à une détection d’un dit événement correspondant à la demande de souscription, et configuré pour envoyer à la première entité une notification comprenant des informations relatives audit événement détecté encodées au moyen d’un dit format d’encodage supporté par la première entité et indiqué dans la demande de souscription.
Système (1) comprenant :
au moins une première entité communicante (2) selon la revendication 12 ; et

au moins une deuxième entité communicante (3) selon la revendication 13.