Titre de l'invention : Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants

Domaine de l'invention

[0001] Le domaine de l'invention est celui d'un réseau de communication, en particulier d'un réseau de communication mettant en œuvre une architecture orientée services et basée sur des fonctions réseau.

[0002] Dans un tel réseau, l'invention concerne en particulier la validation d'une requête d'exécution d'un service avant sa transmission à l'entité d'exécution du service.

Art antérieur

[0003] Le réseau cœur 5G est composé de multiples fonctions réseau NF (en anglais, « Network Function »), chacune ayant un rôle et une logique propre. Une NF est généralement en charge de l'exécution de plusieurs services. Chaque service a un rôle et une logique propres au sein de sa NF. Afin qu'un service communique avec un autre, chaque service est accessible sous la forme d'une interface de type interface de programmation ou API (en anglais, « Application Programming Interface »).

[0004] L'organisme de normalisation 3GPP spécifie l'API de chacun des services mis en œuvre par les fonctions réseau NF qu'il a définies pour le réseau cœur 5G, dans un document écrit dans un langage de description dédié (OpenAPI version 3). Ce document décrit entre autres les opérations supportées par le service et le format des structures des données échangées. Ces structures de données sont un ensemble d'attributs, chaque attribut étant caractérisé par un type simple (chaîne de caractères, nombre, booléen, etc.) ou le type d'une structure, d'un nom et des valeurs autorisées. Il peut, le cas échéant, préciser des contraintes applicables à des attributs ou à des groupes d'attributs. Le 3GPP spécifie en outre que toute requête d'exécution d'une opération du service qui n'est pas conforme au format de l'API de ce service doit être rejetée par le service sollicité et prévoit différents messages d'erreur à retourner à l'entité qui a émis la requête.

[0005] En effet, le traitement par un service donné de requêtes d'exécution d'opérations non conformes à l'API de ce service peut entraîner des dysfonctionnements, avec des conséquences indéterminées sur le fonctionnement du service lui-même, de la fonction réseau NF qui héberge le service voire du réseau cœur. On note à cet égard que l'émission d'une requête d'exécution d'une opération non valide (c'est-à-dire non conforme à l'API) peut être intentionnelle ou non, par exemple due à un défaut de conception d'un programme informatique (en anglais, « bug »). Compte tenu du fait que le réseau cœur 5G dans sa première version (version 15) compte déjà plus de 50 services, on comprend que la multiplication de ces dysfonctionnements peut impacter non seulement la qualité de service, mais aussi la sécurité générale du réseau cœur.

[0006] Aujourd'hui, un contrôle de la validité des requêtes d'exécution d'un service ou d'une opération d'un service est effectué par l'entité en charge d'exécuter le service. Ainsi, les fonctions réseau NF du réseau cœur et, par là même l'entité en charge d'exécuter un service de cette fonction réseau, sont typiquement des entités logicielles, comprenant une couche de validation des requêtes et une couche d'exécution du service. Toutefois, généralement, le fichier exécutable d'un service comporte de façon indissociable la logique métier du service et le contrôle de validité d'opérations. Il en résulte que dès qu'un changement survient pour l'exécution du service, l'ensemble du logiciel doit être mis à jour et retesté, même si la partie validation d'opérations n'est pas affectée par ce changement. [0007] Or, les fonctions réseau NF du réseau cœur sont des entités logicielles (c'est-à-dire des logiciels) qui peuvent être conçues à partir de langages informatiques issus d'environnements de conception (en anglais, « framework ») variés. Les choix de ces technologies logicielles appartiennent aux concepteurs de services et aux constructeurs des équipements serveurs qui hébergent ces services. Ils sont faits en fonction de l'adéquation des spécificités du service à concevoir et des technologies logicielles maîtrisées par leurs équipes de recherche et développement. Les écosystèmes logiciels actuels sont en effet multiples et variés, de sorte que la maîtrise de tous ces écosystèmes demande un investissement conséquent pour un constructeur. On comprendra aussi que l'écosystème logiciel le plus approprié pour la conception d'un service n'est pas forcément celui qui fournit le meilleur niveau de contrôle de la validité d'une opération exécutée par ce service.

[0008] En outre, les interfaces de programmation API des services du réseau cœur 5G sont complexes et évoluent régulièrement au rythme de plusieurs publications par an. Par conséquent, le développement d'une couche logicielle de validation d'opérations, dépendant d'une part de la version 3GPP du service en question et d'autre part, de l'éco système logiciel d'une couche logicielle d'exécution de ce service, est une tâche qui doit être répétée par les programmeurs fréquemment et dans un environnement de programmation non optimal, nécessitant un investissement conséquent pour un risque élevé de bugs et de régressions.

[0009] On connaît enfin des outils de génération automatique de code informatique de la couche de validation à partir des documents de description OpenAPI d'une API d'un service d'une fonction réseau NF donnée du réseau cœur 5G. Un avantage de ces outils est qu'ils sont capables de produire un nouveau code informatique de la couche de validation pour tout nouveau service ainsi que pour une nouvelle version 3GPP d'un service existant. Par rapport à une conception réalisée par un programmeur, la qualité du code produit est supérieure (risque de bugs et de régressions plus faible). Néanmoins, le format OpenAPI de description des API du réseau cœur évoluant lui aussi au gré de versions successives, il en découle que les outils de génération automatique de code informatique doivent eux aussi évoluer. [0010] Il existe donc un besoin d'une solution de validation des requêtes d'exécution d'un service qui soit à la fois plus efficace et plus simple à mettre en œuvre et à maintenir. L'invention vient améliorer la situation.

Exposé de l'invention

[0011] L'invention répond à ce besoin en proposant un procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, en provenance d'une entité dite consommatrice du service, à destination d'une entité d'exécution dudit service, ledit procédé étant mis en œuvre au niveau d'une entité intermédiaire configurée pour recevoir des messages en provenance de l'entité consommatrice du service et destinés à l'entité d'exécution du service ou en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service, et comprenant :

- la réception de ladite requête d'exécution du service en provenance de l'entité consommatrice du service;

- la prise de décision de transmettre ou non pour validation la requête d'exécution du service vers une entité de validation de ladite requête, distincte de l'entité d'exécution du service, avant transmission de ladite requête à l'entité d'exécution du service .

[0012] L'invention propose ainsi une approche tout-à-fait nouvelle et inventive du traitement d'une requête d'exécution d'un service opéré par un réseau de communication, qui consiste d'une part à séparer la validation préalable de la requête de l'exécution du service proprement dite et d'autre part à confier le traitement de ces requêtes et leur aiguillage vers l'une et/ou l'autre des entités de validation et d'exécution du service, à une entité intermédiaire placée en coupure des requêtes d'exécution de service émises par des entités consommatrices dans le réseau de communication et en frontal des entités de validation et d'exécution du service.

[0013] Par exemple, selon l'invention, ces fonctions de validation des requêtes et d'exécution du service, sont remplies par des entités distinctes du réseau de communication. De la sorte, chacune d'entre elles peut être conçue dans l'environnement de conception considéré comme le plus adapté par le concepteur/constructeur. L'invention permet aussi d'utiliser un unique environnement de conception pour concevoir les entités de validation de requêtes d'exécution de plusieurs services distincts, quelle que soit l'API qui leur est associée et l'environnement de conception utilisé pour développer l'entité d'exécution du service correspondant. Grâce à l'invention, un acteur du domaine peut donc se spécialiser dans la conception d'entités/composants de validation d'opérations d'API de services de fonctions réseau d'un réseau de communication. Avec l'invention, c'est l'entité intermédiaire qui a le contrôle du traitement des requêtes et de leur éventuelle validation préalable. Du fait de sa position en coupure du flux des requêtes entre des entités clientes (consommatrices d'un service) et des entités serveuses (qui produisent/exécutent les services), elle a la visibilité sur toutes les transactions relatives aux services en question et dispose d'informations pour décider s'il est nécessaire qu'une requête reçue fasse ou non l'objet d'une validation préalable, ce qui permet notamment une adaptation à un contexte de fonctionnement, comme par exemple un état de saturation du réseau, un niveau de qualité des requêtes reçues en fonction du service demandé etc. Elle peut mettre en œuvre, si besoin, une validation systématique de toutes les requêtes qu'elle reçoit ou au contraire choisir de ne soumettre à une validation préalable qu'une partie des requêtes en s'appuyant sur des informations dont elle dispose sur un état de fonctionnement du réseau de communication, comme l'état du trafic, un niveau de qualité des requêtes précédemment reçues etc.

[0014] L'invention offre ainsi une grande flexibilité, tout en ne dérogeant pas aux critères de qualité requis. Elle laisse également la possibilité de faire évoluer la politique de validation choisie dans le temps.

[0015] L'invention permet aussi d'augmenter la modularité d'un réseau de communication.

[0016] Elle permet également d'optimiser et de rationaliser les efforts d'investissement d'un constructeur de solutions logicielles de validation de requêtes d'exécution de service dans un contexte d'écosystèmes logiciels hétéroclites.

[0017] Elle est particulièrement adaptée à un réseau de communication, tel que le réseau cœur 5G, mettant en œuvre une architecture d'informatique en nuage, (en anglais, « cloud computing »), virtualisée et distribuée de fonctions réseau, qui favorise le partage, via des réseaux, de ressources qui donnent accès à une infrastructure, des services, des plateformes et des applications à la demande. [0018] Dans une telle architecture, les ressources physiques ou matérielles, par exemple d'équipements serveurs disposant de capacités de calcul et de mémoire importantes, sont exploitées par un or- chestrateur qui supervise en temps réel l'allocation de quotas de mémoire et de calcul, appelés machines virtuelles ou instances de conteneurisation, à des entités logicielles de type fonction réseaux NF, des services de ces fonctions réseau NF ou encore des opérations de ces services, surveille la quantité de mémoire et le temps de calcul ou CPU (« Central Processing Unit », en anglais) effectivement utilisés par chaque entité et réplique/supprime la machine virtuelle ou les instances de conteneurisation d'une entité logicielle donnée pour répondre à des besoins accrus/décrus. [0019] Par exemple, le service requis par l'entité consommatrice de services est mis en œuvre dans une fonction réseau donnée. Une telle fonction réseau est composée d'entités organisées entre elles en réseau et qui ne sont pas atteignables/routables directement depuis l'extérieur. On comprend que ces entités (et la fonction réseau associée) forment une sorte de sous-réseau dont l'entité consommatrice du service ne connaît généralement qu'un identifiant public, par exemple une URI. Cette fonction réseau peut rendre un ou plusieurs services.

[0020] L'entité intermédiaire joue ainsi le rôle de passerelle entre l'entité consommatrice du service, qui demande l'exécution de ce service, et l'entité d'exécution (ou de production) du service demandé. Il s'agit par exemple d'un équipement proxy inversé (en anglais, « reverse proxy ») qui masque à l'entité consommatrice du service la présence des entités appartenant à la fonction réseau et qui contribuent à l'exécution du service demandé.

[0021] L'invention s'inscrit donc dans la tendance de désagrégation ou décomposition de la logique du réseau cœur 5G.

Avantageusement, l'invention est mise en œuvre au niveau d'une entité intermédiaire placée en coupure (en frontal) du chemin réseau emprunté par les requêtes d'exécution d'un service et configurée pour transmettre les requêtes à valider à une entité de validation distincte de l'entité d'exécution du service.

[0022] Selon un autre aspect de l'invention, le procédé comprend :

- la transmission de ladite requête d'exécution du service à l'entité de validation du service ;

- la réception d'au moins un message de réponse parmi un message d'information de validation et un message de rapport d'exécution ; et

- la transmission du message de réponse reçu à l'entité concernée parmi l'entité consommatrice du service et l'entité d'exécution du service, en fonction du message de réponse reçu.

[0023] Un avantage est que l'entité intermédiaire intègre l'intelligence nécessaire pour transmettre les messages de requête et/ou de réponse qu'il reçoit à la bonne entité. En outre, son rôle et sa position lui donnent une visibilité sur la qualité de requêtes, ce qui lui permet de décider de suspendre ou non la validation systématique des prochaines requêtes à traiter.

[0024] L'invention permet ainsi la mise en œuvre d'au moins deux modes de réalisation :

- selon un premier mode de réalisation, l'entité de validation et l'entité d'exécution du service ne communiquent pas directement entre elles. L'entité intermédiaire est le passage obligé de messages entre l'entité de validation et l'entité d'exécution de service. Selon ce mode de réalisation, l'entité intermédiaire reçoit le message d'information de validation en provenance de l'entité de validation du service. Si la requête n'est pas validée, ce message d'information de validation comprend un corps de message décrivant la cause du rejet et un code de statut. Par exemple, un message de réponse conforme aux spécifications du 3GPP comprend un code de statut HTTP de la classe 4xx. Lorsque la requête a été validée, le message d'information comprend un code de statut qui indique à quelle entité la requête doit être transmise, qui vaut validation de la requête. Dans le mode de réalisation décrit ici, ce code de statut est un code HTTP de classe 3xx.

[0025] Par conséquent, l'entité intermédiaire reçoit toujours au moins le message d'information de validation et, le cas échéant, le rapport d'exécution ;

- selon un deuxième mode de réalisation de l'invention, l'entité de validation et l'entité d'exécution du service communiquent directement entre elles. En cas de validation positive, l'entité de validation transmet directement la requête d'exécution du service à l'entité d'exécution et reçoit en retour le rapport d'exécution qu'elle transmet à l'entité intermédiaire. Si la requête n'est pas validée, l'entité de validation envoie un message d'information de validation à l'entité intermédiaire. Par conséquent, l'entité intermédiaire reçoit toujours au moins soit un message de validation négatif, soit un rapport d'exécution.

[0026] Selon encore un autre aspect de l'invention, le au moins un message de réponse reçu comprend un message d'information de validation de l'entité de validation comprenant un résultat de validation, le message d'information de validation est transmis vers l'entité consommatrice du service lorsque le résultat de validation est négatif, et la requête d'exécution du service est transmise vers l'entité d'exécution du service lorsque le résultat de validation est positif.

[0027] Selon ce premier mode de réalisation, l'entité intermédiaire est aussi le passage obligé entre l'entité de validation et l'entité d'exécution du service, qui ne communiquent pas directement l'une avec l'autre. Cette configuration est particulièrement adaptée au cas où elles n'appartiennent pas au même sous-réseau ou à la même fonction réseau.

[0028] L'entité consommatrice du service reçoit un message d'erreur de validation et la requête n'est pas transmise à l'entité d'exécution du service. Un avantage est que l'entité consommatrice du service est ainsi informée que la requête d'exécution du service est rejetée parce qu'elle n'est pas valide.

[0029] Selon encore un autre aspect de l'invention, le procédé comprend, en réponse à un résultat de validation positif, l'obtention par l'entité intermédiaire d'un identifiant de l'entité d'exécution du service), et la requête d'exécution du service est transmise à l'entité d'exécution du service en utilisant ledit identifiant obtenu.

[0030] Un avantage est que l'identifiant permettant d'accéder à l'entité d'exécution du service n'est obtenu par l'entité intermédiaire qu'en cas de validation réussie. On garantit ainsi que l'entité d'exécution du service ne traite que des requêtes valides. Cet identifiant peut être privé, lorsque l'entité d'exécution de service est comprise dans une fonction de réseau ou un sous-réseau d'un autre type, et public sinon, de sorte à permettre d'atteindre directement l'entité d'exécution du service. L'identifiant de l'exécution du service peut être obtenu par l'entité intermédiaire à partir du message d'information de validation reçu en provenance de l'entité de validation (par exemple, il est contenu dans ce message), ou en variante être déterminé par l'entité intermédiaire.

[0031] Selon encore un autre aspect, ledit au moins un message de réponse reçu comprend un message de rapport d'exécution du service émis par l'entité d'exécution du service et en ce que ledit message de rapport d'exécution du service est transmis vers l'entité consommatrice du service.

[0032] Avantageusement, lorsque la requête a été validée, l'entité intermédiaire reçoit dans tous les cas (que l'entité de validation soit connectée ou non à l'entité d'exécution du service) un message de rapport d'exécution comprenant un résultat ou au moins une confirmation de l'exécution du service en provenance de l'entité d'exécution du service, qu'il transmet à l'entité consommatrice du service.

[0033] Selon un autre aspect de l'invention, la décision de transmettre ou non ladite requête à l'entité de validation du service est prise en fonction d'au moins un critère de décision donné relatif à au moins un indicateur de fonctionnement du réseau et/ou un type de la requête d'exécution du service.

[0034] Par exemple, ledit au moins un indicateur de fonctionnement du réseau appartient à un groupe d'indicateurs d'un état de fonctionnement du réseau, comprenant au moins un indicateur de trafic, de latence, d'occupation (saturation) des ressources physiques du réseau sur une période temporelle donnée, un indicateur de qualité des requêtes d'exécution de service tel que par exemple un taux de requêtes non validées par l'entité de validation pendant la période temporelle donnée, un taux de messages d'erreurs générés par l'entité d'exécution du service pour des requêtes n'ayant pas fait l'objet d'une validation préalable, etc. Il peut s'agir aussi d'un compteur de requêtes d'exécution de service précédemment soumises à validation pendant une période temporelle écoulée. Par exemple, une requête est transmise directement toutes les dix requêtes soumises à validation. Quant au critère de décision, il comprend un seuil de valeur du dit au moins un indicateur.

[0035] En variante, on peut envisager que le critère pour décider de transmettre ou non la requête à l'entité de validation soit en lien avec un type de requêtes d'exécution de service (par exemple, selon si ces requêtes concernent la création, la modification, la suppression ou encore la consultation d'une ressource).

[0036] De la sorte, l'invention permet de réaliser un compromis entre l'effort mis sur la validation des requêtes d'exécution d'un service et la préservation des ressources du réseau.

[0037] L'invention concerne également une entité intermédiaire d'un réseau de communication, configurée pour recevoir des messages en provenance en provenance d'une entité, dite consommatrice d'un service, et à destination d'une entité d'exécution dudit service et pour recevoir des messages en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service, et configurée pour mettre en œuvre :

- la réception d'une requête d'exécution du service en provenance de l'entité consommatrice du service ;

- la prise de décision de transmettre ou non pour validation la requête d'exécution du service vers une entité de validation de ladite requête, distincte de l'entité d'exécution du service, avant transmission de ladite requête à l'entité d'exécution du service.

[0038] Avantageusement, ladite entité intermédiaire est configurée pour mettre en œuvre les étapes du procédé de traitement d'une requête tel que décrit précédemment.

[0039] Corrélativement, l'invention concerne aussi un procédé de validation d'une requête d'exécution d'un service dans un réseau de communication, ladite requête ayant été émise par une entité dite consommatrice du service dudit réseau à destination d'une entité d'exécution du service , ledit procédé étant mis en œuvre au niveau d'une entité de validation du service distincte de ladite entité d'exécution et en ce qu'il comprend :

- la réception de ladite requête d'exécution du service en provenance d'une entité intermédiaire configurée pour recevoir des messages à destination de ou en provenance de l'entité d'exécution du service;

- la vérification d'une validité de ladite requête d'exécution du service, comprenant l'obtention d'un résultat de validation ; et

- l'exécution d'au moins une action en fonction du résultat de validation obtenu.

[0040] Avec l'invention, la validation des requêtes est donc assurée par une entité distincte de l'entité d'exécution du service. Cette entité indépendante reçoit les requêtes à valider de l'entité intermédiaire. Elle peut donc être conçue dans un environnement différent de celui de l'entité d'exécution. Elle peut aussi être mutualisée pour plusieurs services.

[0041] Selon un aspect de l'invention, ladite au moins une action comprend la transmission d'un message d'information de validation comprenant le résultat de validation à l'entité intermédiaire.

[0042] Un avantage est que la responsabilité de décider si une requête d'exécution d'un service doit être transmise ou non à l'entité d'exécution du service est entièrement confiée à l'entité intermédiaire. L'entité de validation a pour unique charge de valider les requêtes d'exécution de service qu'elle reçoit de cette entité intermédiaire et de lui renvoyer un résultat de validation.

[0043] Selon un mode de réalisation particulier, une réponse de validation positive peut comprendre en outre un identifiant de l'entité d'exécution du service.

[0044] Cet identifiant permet à l'entité intermédiaire de transmettre à l'entité d'exécution du service la requête d'exécution du service. Un avantage est qu'il n'est obtenu par l'entité intermédiaire que lorsque la requête d'exécution a été considérée comme valide par l'entité de validation du service.

[0045] Selon un autre aspect de l'invention, lorsque le résultat de validation est positif, ladite au moins une action comprend la transmission de ladite requête d'exécution du service à l'entité d'exécution du service.

[0046] Un avantage est que l'entité de validation redirige directement une requête d'exécution de service considérée comme valide à l'entité d'exécution du service concernée. De la sorte, la latence introduite par la phase de validation est réduite au minimum.

[0047] Selon encore un autre aspect de l'invention, ladite au moins une action comprend en outre la réception d'un message de réponse en provenance de l'entité d'exécution du service comprenant un rapport d'exécution du service et la transmission dudit message de réponse à destination de l'entité intermédiaire.

[0048] L'invention concerne également une entité de validation d'une requête d'exécution d'un service dans un réseau de communication, ladite requête ayant été émise par une entité consommatrice du service à destination d'une entité d'exécution du service. L'entité de validation est configurée pour mettre en œuvre :

- la réception de ladite requête d'exécution, ladite requête ayant été transmise à l'entité de validation par une entité intermédiaire configurée pour recevoir des messages en provenance en provenance d'une entité, dite consommatrice d'un service, et à destination d'une entité d'exécution dudit service et pour recevoir des messages en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service;

- la vérification d'une validité de ladite requête ; et

- la transmission d'un message de réponse à destination de l'entité intermédiaire comprenant au moins un résultat de validation.

[0049] Avantageusement, ladite entité de validation est configurée pour mettre en œuvre les étapes du procédé de validation d'une requête tel que décrit précédemment.

[0050] Avantageusement, ladite entité intermédiaire et ladite entité de validation sont comprises dans un système de gestion d'un service dans un réseau de communication, ledit système comprenant une entité consommatrice du service et une entité d'exécution du service, ladite entité consommatrice étant configurée pour transmettre une requête d'exécution du service à l'entité d'exécution du service. [0051] Le système présente au moins les mêmes avantages que ceux conférés par le procédé de traitement et le procédé de validation précités.

[0052] L'invention concerne également des produits programmes d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés de traitement et de validation tels que décrits précédemment, lorsqu'ils sont exécutés par un processeur.

[0053] Un programme 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.

[0054] L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel sont enregistrés les programmes d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes des procédés selon l'invention tel que décrits ci-dessus.

[0055] Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. 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 support mobile (carte mémoire) ou un disque dur ou un SSD.

[0056] D'autre part, un tel support 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 radio ou par d'autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.

[0057] Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé précité.

[0058] Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

[0059] Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set- top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). Par la suite, on entend par ressources tous ensembles d'éléments matériels et/ou logiciels support d'une fonction ou d'un service, qu'ils soient unitaires ou combinés.

[0060] De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (« firmware » en anglais), etc.

[0061] Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.

[0062] Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique.

Brève description des dessins

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

[0064] [Fig. 1] : illustre de façon schématique un exemple d'architecture d'un système de gestion d'une requête d'exécution d'un service dans un réseau de communication selon un mode de réalisation de l'invention ;

[0065] [Fig. 2] : Idécrit sous forme d'un logigramme les étapes d'un procédé de traitement d'une telle requête d'exécution d'un service, selon l'invention ;

[0066] [Fig. 3A] : décrit sous forme d'un logigramme les étapes d'un procédé de validation d'une telle requête d'exécution d'un service, selon un premier exemple de réalisation de l'invention ;

[0067] [Fig. 3B] : décrit sous forme d'un logigramme les étapes d'un procédé de validation d'une telle requête d'exécution d'un service, selon un deuxième exemple de réalisation de l'invention ;

[0068] [Fig. 3C] : décrit sous forme d'un logigramme les étapes d'un procédé de validation d'une telle requête d'exécution d'un service, selon un troisième exemple de réalisation de l'invention ;

[0069] [Fig. 4] [Fig. 5] [Fig. 6] [Fig. 7] [Fig. 8] [Fig. 9] : illustrent de façon schématique les messages échangés entre les différentes entités du système de gestion d'une requête d'exécution d'un service selon un premier exemple de réalisation de l'invention ;

[0070] [Fig. 10] [Fig. 11] [Fig. 12] : illustrent de façon schématique les messages échangés entre différentes entités du système de gestion d'une requête d'exécution d'un service selon un deuxième exemple de réalisation de l'invention ;

[0071] [Fig. 13] : illustre de façon schématique un exemple de structure matérielle d'une entité intermédiaire configurée pour traiter une requête d'exécution d'un service selon un mode de réalisation de l'invention ; et

[0072] [Fig. 14] : illustre de façon schématique un exemple de structure matérielle d'une entité de validation d'une requête d'exécution d'un service selon un mode de réalisation de l'invention.

Description de l'invention

[0073] Le principe général de l'invention consiste à séparer, dans un réseau de communication, la validation des requêtes d'exécution d'un service en provenance d'une entité consommatrice du service, de l'exécution proprement dite de ce service et en même temps de centraliser le traitement de telles requêtes au niveau d'une entité intermédiaire. Cette entité intermédiaire est avantageusement placée en frontal de l'entité consommatrice du service et des requêtes qu'elle envoie, par rapport aux entités de validation et d'exécution du service concerné. Autrement dit, cette entité intermédiaire est la première entité qui reçoit la requête d'une entité consommatrice, c'est-à-dire qui est visible de cette entité consommatrice. Elle est ainsi placée en coupure des flux de requêtes adressées des entités consommatrices à l'entité d'exécution. De ce fait, elle masque les entités de validation et d'exécution aux entités consommatrices du service.

[0074] Plus précisément, l'invention propose de confier les tâches de validation d'une requête d'exécution d'un service et d'exécution de cette requête à deux entités distinctes du réseau placées sous la responsabilité d'une même entité intermédiaire qui les pilote. Ces deux entités sont par exemple deux entités logicielles qui peuvent, de ce fait, avoir été conçues dans des environnements de conception distincts et en utilisant des langages de programmation différents. Selon l'invention, ces deux entités ont des localisations distinctes (typiquement sont représentées par deux fichiers exécutables distincts) et chacune dispose de son propre identifiant, par exemple de type U RI (en anglais, « Universal Resource Identifier »), qui permet à une autre entité du réseau de l'atteindre, et de communiquer avec elle.

[0075] L'invention permet ainsi de rendre le réseau de communication plus modulaire, et de ce fait, de rationaliser les efforts de conception et donc les investissements nécessaires pour mettre en œuvre une validation efficace des requêtes d'exécution de services dans un réseau de communication. En effet, puisque la tâche de validation d'une requête d'exécution d'un service est dissociée de l'exécution du service proprement dit, la contrainte de s'adapter à l'environnement logiciel de l'entité d'exécution du service est relâchée et un constructeur de solutions de validation peut choisir l'environnement de conception le plus adapté.

[0076] L'invention permet aussi de contrôler le traitement de ces requêtes et leur validation préalable par cette entité intermédiaire, qui a de la visibilité sur les flux de requêtes, reçoit des informations représentatives d'un état de fonctionnement du réseau et d'un niveau de qualité des requêtes d'exécution de service reçues et peut décider en conséquence de déclencher ou non la validation d'une nouvelle requête en fonction de ces informations. Un avantage est de limiter une latence et une consommation de ressources induites par la validation d'opérations tout en garantissant un taux de conformité acceptable des requêtes d'exécution effectivement par l'entité d'exécution du service. De la sorte, l'invention contribue à améliorer la gestion de la charge et plus généralement la qualité de service au sein de ce réseau.

[0077] L'invention concerne tout type de réseau mettant en œuvre une architecture orientée service (demandeur de services/fournisseur de services) basée sur des dispositifs applicatifs. Dans la suite de la description, on considère en particulier le cas de fonctions réseaux NF configurées pour réaliser une ou plusieurs tâches ou services et échanger des informations les uns vers les autres à travers une interface de service SBI (Service Based Interface). Toutefois, l'invention s'applique également à d'autres types de dispositifs applicatifs tels que par exemple des dispositifs applicatifs de type services web. [0078] Dans une architecture orientée services, virtualisée et distribuée, l'allocation de ressources physiques pour l'implémentation de ces fonctions réseau est supervisée par un équipement orchestrate ur.

[0079] Les services sont exposés par exemple en utilisant des protocoles standards pour représenter de façon sérialisée (i.e. sous forme d'une chaîne) leurs données (SOAP, Thrift, JSON) permettant d'imposer le format des messages échangés.

[0080] Chaque dispositif applicatif intègre par exemple une composante logicielle conçue pour réaliser une tâche ou des tâches précises comme récupérer des informations (exemple : l'identité d'un terminal mobile lors de son attachement) ou exécuter une opération (exemple : mettre en œuvre un tunnel). A titre d'exemple, une fonction réseau contient le code logiciel et les données nécessaires pour réaliser la liste des tâches ou services associées à cette fonction.

[0081] L'accès à de tels services se fait par l'intermédiaire d'interfaces de programmation applicative ou API (en anglais, « Applicative Programming Interface »), par exemple de type API REST (pour « RE- presentational State Transfer », en anglais), configurées pour exécuter un service ou une opération d'un service en réponse à des requêtes en provenance d'entités consommatrices dont le concepteur souhaite contrôler la validité.

[0082]

[0083] Un exemple de réseau auquel l'invention est particulièrement adaptée est un réseau cœur 5G, tel que spécifié par la norme 3GPP.

[0084] Dans le cas de la norme 5G, le format des données est le format JSON et le protocole d'échange est le protocole HTTP/2. Chaque service récupère, crée, modifie ou supprime une ressource. L'écriture se fait en utilisant les commandes POST ou PUT ou encore DELETE, et la lecture en utilisant la commande GET.

[0085] Bien entendu, l'invention s'applique à d'autres formats de données, à d'autres protocoles (par exemple au protocole HTTP/3), ainsi que dans d'autres contextes (par exemple un réseau cœur 6G). [0086] La figure 1 illustre de façon schématique un exemple d'architecture d'un système S de gestion d'une requête d'exécution d'un service dans un réseau de communication RC, par exemple un réseau cœur mobile 5G tel que spécifié par le 3GPP.

[0087] Le réseau RC comprend une entité ECS de consommation d'un service fourni par le réseau RC. Il s'agit d'un élément matériel et/ou logiciel du réseau RC, configuré pour exécuter une ou plusieurs tâches dans le réseau RC et qui, pour ce faire, fait appel à ce service. Par simplicité, sur la figure 1, on a représenté une seule entité ECS, mais on comprend que le réseau RC peut en comprendre plusieurs. Il s'agit par exemple d'une fonction réseau NF particulière qui requiert l'exécution d'un service d'une entité EES de production ou d'exécution de ce service, par exemple une autre fonction NF de ce réseau. On comprend aussi qu'une fonction réseau peut être à la fois productrice d'un service pour une autre fonction réseau et consommatrice à son tour d'un service rendu par cette autre fonction réseau.

[0088] Le réseau RC comprend en outre une entité de validation EVS d'une requête d'exécution du service rendu par l'entité d'exécution EES. Selon l'invention, il s'agit d'une entité distincte de l'entité d'exécution EES. Elle est configurée pour valider notamment un format (par exemple un nom et/ou une valeur) des données spécifiées dans la requête d'exécution. Ces données comprennent des attributs et des paramètres inclus dans le corps de la requête et/ou dans un ou plusieurs en-têtes de cette requête (par exemple, l'identifiant unique ou URI).

[0089] Selon ce mode de réalisation de l'invention, le système S comprend donc l'entité consommatrice d'un service ECS, l'entité d'exécution du service EES et l'entité de validation EVS de la requête d'exécution du service émise par l'entité consommatrice ECS. Le système S comprend en outre une entité intermédiaire du réseau de communication RC, placée en frontal de l'entité consommatrice du service ECS par rapport à l'entité d'exécution EES du service. Il s'agit par exemple d'un équipement proxy, qui est configuré pour recevoir des messages en provenance et/ou destinés à l'entité d'exécution du service EES et joue un rôle de passerelle entre l'entité consommatrice du service et l'entité d'exécution de ce service, en transformant un identifiant public de ce service connu de l'entité consommatrice du service et indiqué dans sa requête en un autre identifiant de l'entité d'exécution du service, non connu de l'entité consommatrice du service.

[0090] Selon l'invention, l'entité intermédiaire est configurée pour recevoir ladite requête d'exécution du service en provenance de l'entité consommatrice du service, décider de transmettre ou non la requête d'exécution du service vers une entité de validation EVS de ladite requête, distincte de l'entité d'exécution du service EES, pour validation, avant transmission (27) de ladite requête à l'entité d'exécution du service EES. [0091] Ladite entité intermédiaire met ainsi en œuvre le procédé de traitement d'une requête d'exécution d'un service selon l'invention qui sera détaillé ci-après en relation avec la figure 2.

[0092] Par exemple, l'entité d'exécution du service EES est comprise dans un sous-réseau ou réseau privé (non représenté) de ce réseau RC, par exemple celui d'une fonction réseau NF en charge de l'exécution de ce service. L'entité intermédiaire peut faire partie ou non du réseau privé et sert donc à masquer les différentes entités qui appartiennent au réseau privé aux autres entités du réseau RC. A l'inverse, les entités de ce réseau privé ne communiquent avec le reste du réseau RC que via cette entité intermédiaire. Ainsi, l'entité consommatrice du service ECS envoie sa requête REQ à un identifiant (par exemple une URI) associé à l'entité d'exécution du service EES dans le réseau RC ou à la fonction réseau qui met en œuvre ce service et qu'elle peut ou non avoir préalablement découverte, et l'entité intermédiaire, qui reçoit cette requête REQ, la transmet alors vers un identifiant privé de cette entité d'exécution du service ou d'une autre entité dans le réseau privé auquel elle appartient. Selon un premier mode de réalisation de l'invention, l'entité intermédiaire est un équipement proxy dit inversé (en anglais, « Reverse Proxy ») du fait qu'il remplace un identifiant « public » en identifiant privé, contrairement aux équipements intermédiaires classiques. Dans le cas d'un réseau cœur 5G, cet équipement proxy traite des requêtes conformes au protocole HTTP2. Selon un autre mode de réalisation de l'invention, l'entité intermédiaire est de type SCP (en anglais, « Service Communication Proxy »). Il s'agit d'un autre type d'équipement proxy, défini notamment dans la version 16 (ou « Release 16 » en anglais) du 3GPP, constituant un point d'entrée unique pour un groupe de fonctions réseaux NF. Il est donc externe à ces fonctions réseau. Il traite lui aussi des requêtes conformes au protocole HTTP2. On note que dans ce cas, l'identifiant utilisé par cet équipement proxy SCP est une adresse routable, donc publique.

[0093] Selon l'exemple de réalisation de la figure 1, le système S de gestion d'une requête d'exécution d'un service comprend en outre l'entité de validation EVS configurée pour recevoir ladite requête d'exécution du service en provenance de l'entité intermédiaire RP, SCP, vérifier une validité de ladite requête d'exécution du service, comprenant l'obtention d'un résultat de validation, et exécuter au moins une action de traitement de la requête en fonction du résultat de validation obtenu.

[0094] L'entité de validation EVS met ainsi en œuvre le procédé de validation d'une requête de validation selon l'invention qui sera détaillé ci-après en relation avec les figures 3A à 3C.

[0095] On présente désormais, en relation avec la figure 2, sous une forme de logigramme, un exemple de mise en œuvre d'un procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication RC selon un mode de réalisation de l'invention. Avantageusement, le procédé est mis en œuvre par l'entité intermédiaire RP, SCP.

[0096] En 20, une requête d'exécution d'un service Si est reçue en provenance d'une entité consommatrice ECS, par exemple une première fonction réseau du réseau RC. On note que, suite à l'émission de cette requête, l'entité consommatrice ECS enclenche généralement un compteur (en anglais, « timer ») et qu'en l'absence de réponse reçue à l'expiration d'une période donnée, elle peut éventuellement retransmettre la requête.

[0097] Cette requête indique l'identifiant public du service demandé par l'entité consommatrice du service, qui correspond par exemple à celui de la fonction réseau NF ou du dispositif applicatif qui fournit le service demandé. Cet identifiant unique ou URI est défini dans un profil de la fonction réseau ou du dispositif applicatif, lequel est enregistré dans le réseau, par exemple par une fonction réseau dédiée à l'enregistrement de tels profils.

[0098] En 21 au moins un indicateur de fonctionnement IND est obtenu, par exemple d'une mémoire Ml de l'entité intermédiaire RP, SCP. Il s'agit par exemple d'un indicateur de charge ou de trafic, de latence, d'occupation (saturation) des ressources physiques du réseau sur une période temporelle donnée du réseau RC et/ ou d'un indicateur de qualité des requêtes précédemment traitées pendant une période temporelle écoulée, d'un taux de requêtes non validées par l'entité de validation pendant la période temporelle donnée, d'un taux de messages d'erreurs générés par l'entité d'exécution du service pour des requêtes n'ayant pas fait l'objet d'une validation préalable, etc. Ces indicateurs sont par exemple déterminés à partir de données de mesure collectées dans le réseau par télémétrie.

[0099] En 22, ce ou ces indicateurs sont exploités pour décider si la requête REQ reçue est soumise à validation préalable ou directement transmise à l'entité d'exécution EES concernée. Avantageusement un identifiant (par exemple URI) d'une entité EVS en charge de la validation des requêtes d'exécution de ce service est obtenu, comme détaillé ci-après. Au moins un critère de décision CRT est pris en compte. Il s'agit par exemple d'un seuil de valeur du dit au moins un indicateur.

[0100] Selon un premier cas, la décision est prise de transmettre la requête REQ à l'entité de validation EVS en charge pour le service Si demandé. Elle est transmise en 23. Pour ce faire, un identifiant URI2 de l'entité de validation EVS a été préalablement obtenu, par exemple, à l'aide de règles de configuration associant à chaque service rendu par le réseau RC, ou une fonction réseau NF ou encore un groupe de fonctions réseaux du réseau RC, l'identifiant de l'entité de validation EVS correspondante. En variante, ces règles de configuration sont regroupées dans une table de données, accessible depuis l'entité intermédiaire RP, SCP. Par exemple, ces informations ont été obtenues lors d'une phase de découverte préalable des fonctions de service disponibles dans le réseau RC et des services qu'elles fournissent.

[0101] Les opérations de validation conduites par l'entité de validation EVS sur la requête REQ sont détaillées ultérieurement.

[0102] Selon un premier mode de réalisation de l'invention, un message de réponse REP est reçu en 24. Il comprend un message d'information de validation de l'entité de validation EVS et comprend donc un résultat RES de validation qui peut être positif ou négatif. En fonction du résultat de validation, il est décidé en 25 de transmettre la requête REQ en Tl à l'entité d'exécution du service EES lorsque ce résultat de validation est positif et au contraire de rejeter la requête REQ sinon.

[0103] Avantageusement, lorsque le résultat de validation RES est positif, le message de réponse comprend au moins une information de localisation de l'entité d'exécution EES du service demandé, par exemple une réponse conforme au protocole HTTP de code de statut de la classe « 3xx » indiquant une redirection, et plus précisément du type « 307 Location : URI3 ». Une telle réponse comprend par exemple un identifiant privé de la fonction réseau ou du dispositif applicatif qui met en œuvre le service et éventuellement complétée par un identifiant de l'entité de validation EVS concernée, lorsque l'entité intermédiaire se trouve à l'intérieur de cette fonction réseau.

[0104] Au contraire, en cas de rejet de la requête REQ pour défaut de conformité (par exemple format du corps de la requête non conforme, nom d'un attribut non conforme, type d'un attribut non conforme, valeur d'un attribut non conforme, contrainte multi-attributs non conforme, etc.), la réponse REP comprend un corps et un code de statut. Dans le mode de réalisation envisagé ici, il s'agit d'une réponse conforme au protocole HTTP et la valeur du code de statut est de la classe « 4xx ». Le corps et le code de statut sont conformes à des spécifications du 3GPP qui sont énoncées dans un ou plusieurs documents OpenAPI décrivant les opérations du service.

[0105] En cas de rejet, le message de réponse REP est transmis à l'entité consommatrice du service ECS, qui est donc informée que sa requête est rejetée car elle n'est pas valide.

[0106] En cas de résultat positif, un message de réponse REP' comprenant un rapport d'exécution du service est reçu en 28 de l'entité d'exécution EES et transmis à l'entité consommatrice du service ECS en 29.

[0107] On comprend que selon ce premier mode de réalisation, l'entité intermédiaire RP, SCP est destinataire de tous les messages émis par l'entité de validation EVS et l'entité d'exécution EES qui ne communiquent pas directement. Il reçoit donc potentiellement deux messages de réponse, à savoir le message de réponse REP comprenant le résultat de validation RES transmis par l'entité de validation EVS, et en cas de résultat de validation positif, le message de réponse REP' comprenant le rapport d'exécution du service par l'entité d'exécution EES.

[0108] Selon un deuxième mode de réalisation de l'invention, un seul message de réponse est reçu par l'entité intermédiaire RP, SCP. Dans le cas où l'entité de validation EVS a validé la requête, seul le message de réponse REP' est reçu en 28, car l'entité de validation EVS transmettant directement la requête REQ à l'entité d'exécution du service EES dans ce deuxième mode de réalisation. Au contraire, lorsque l'entité de validation EVS a rejeté la requête, un message d'information de validation REP comprenant un résultat négatif est reçu par l'entité intermédiaire RP, SCP en 24. Le message d'information de validation REP comprenant le résultat négatif, respectivement le message de réponse REP', est transmis le cas échéant par l'entité intermédiaire RP, SCP à l'entité ECS en 29, respectivement 26.

[0109] Selon un deuxième cas, il est décidé de ne pas transmettre la requête REQ à l'entité de validation EVS. Elle est donc transmise directement à l'entité d'exécution EES en 27. Les étapes 28 et 29 sont identiques à celles déjà décrites.

[0110] On comprend que, selon l'invention, une requête REQ n'est pas forcément soumise à validation ce qui permet de limiter le temps de latence introduit par la mise en œuvre de l'invention. Dans ce cas, un message d'erreur peut être émis par l'entité d'exécution EES, lorsque la requête REQ présente des non-conformités rendant impossible l'exécution du service ou de l'opération demandée. Dans le mode de réalisation décrit ici, ce message d'erreur peut indiquer un code de statut HTTP dans la classe 5xx ou un code de statut 404 Not Found.

[0111] On présente désormais, en relation avec les figures 3A à 3C, sous forme de logigramme, des exemples de mise en œuvre d'un procédé de validation d'une requête d'exécution d'un service dans un réseau de communication selon plusieurs modes de réalisation de l'invention. Avantageusement, le procédé est mis en œuvre par l'entité de validation EVS.

[0112] En relation avec la figure 3A, une requête d'exécution d'un service REQ est reçue en 30 par l'entité de validation EVS en provenance de l'entité intermédiaire RP, SCP. En 31, les champs d'information composant cette requête REQ sont vérifiés. En particulier, dans le cas d'un réseau cœur 5G, la vérification concerne le corps de la requête (en anglais, « request body ») et d'éventuels paramètres et entêtes associés. Nativement, l'entité de validation EVS a par exemple été conçue à partir d'un document de description de l'interface de programmation API du service de l'entité d'exécution du service considérée, par exemple au format OpenAPI, qui décrit tous les champs d'information du corps de la requête, ainsi que d'éventuels paramètres et en-têtes associés. On note que ce format OpenAPI décrit aussi la structure des messages de réponse.

[0113] L'entité de validation EVS vérifie ainsi que le corps de la requête et les éventuels paramètres et entêtes associés sont conformes à ceux définis dans le document de description de l'interface de programmation du service. A l'issue de cette vérification, l'entité de validation EVS fournit un résultat RES (positif en cas de conformité de l'ensemble des éléments de la requête REQ qui ont été vérifiés par l'entité de validation EVS, négatif en cas de non-conformité de l'un au moins de ces éléments), qui est pris en compte en 32 pour décider d'une action ACT à déclencher.

[0114] A ce stade, deux cas sont possibles : selon un premier mode de réalisation de l'invention illustré par la figure 3B, l'action décidée est l'envoi en 321 d'une réponse REP à l'entité intermédiaire RP, SCP. Lorsque la requête REQ a été validée, ce message de réponse REP est un message d'information de validation comprenant un résultat RES positif. Optionnellement, il comprend une information d'identifi- cation/localisation de l'entité d'exécution du service EES dans le réseau RC et par exemple dans le réseau privé de la fonction réseau à laquelle elle appartient. Par exemple, ladite information d'identification/lo- calisation est un identifiant universel de type URI (URI3) qui n'est pas connu de l'entité consommatrice du service ECS.

[0115] Au contraire, lorsque la requête REQ est rejetée (i.e. n'est pas validée), le message de réponse REP comprend, dans le corps du message, un code d'erreur ; il peut en outre comprendre une description des erreurs (autrement dit des non-conformités) identifiées. Par exemple, le code de statut est de type HTTP 400, qui signifie « mauvaise requête » (en anglais, « Bad Request »). On note que le corps du message de réponse d'erreur est conforme à la description OpenAPI pour toute opération de service considérée.

[0116] Selon un deuxième mode de réalisation de l'invention, illustré par la figure 3C, lorsque la requête REQ est validée, l'action ACT décidée est de transmettre directement la requête d'exécution de service REQ en 322 vers l'entité d'exécution EES (en utilisant l'identifiant URI3). Selon ce deuxième mode de réalisation, un message de réponse REP' comprenant un rapport d'exécution émis par l'entité d'exécution EES est reçu en 323 et transmis en 324 à l'entité intermédiaire RP, SCP. On comprend que selon ce deuxième mode de réalisation, l'entité de validation EVS joue un rôle d'intermédiaire entre l'entité intermédiaire RP, SCP et l'entité d'exécution du service ECS. En variante, l'entité de validation EVS est intégrée dans l'entité intermédiaire RP, SCP.

[0117] On détaille maintenant, en relation avec les figures 4 à 12 des exemples de réalisation de l'invention dans le cas d'un réseau cœur 5G.

[0118] Comme précédemment évoqué, un réseau cœur 5G tel que spécifié par le 3GPP est composé de différentes fonctions réseau NF, chacune ayant un rôle bien défini. Une fonction réseau NF est généralement en charge d'exécuter plusieurs services distincts. Un service d'une fonction réseau est décrit par le 3GPP sous la forme d'une ou plusieurs interfaces de programmation applicative API, elles- mêmes spécifiées dans un document de description conforme au format OpenAPI. Un objectif d'une API est notamment de définir le contenu des requêtes d'exécution d'un service envoyées par une entité consommatrice du service et le contenu des réponses envoyées par l'entité d'exécution ou de production du service.

[0119] Par exemple, il s'agit d'une API de type API REST, c'est-à-dire conforme à un ensemble de contraintes architecturales définies par REST. On note que les API de type API REST sont très communes aujourd'hui dans l'informatique en nuage (en anglais, « cloud computing ») qui consiste à recourir à des serveurs distants pour traiter, stocker et gérer des données, et s'appliquent à tout domaine métier. L'invention concerne plus généralement toute interface de programmation applicative, par exemple de type API REST, conçue pour exécuter un service en réponse à des requêtes en provenance d'entités consommatrices dont le concepteur souhaite contrôler la validité.

[0120] [0121] On considère à titre d'exemple, la fonction réseau NRF (de l'anglais, « Network function Repository Function » ) d'enregistrement de fonctions réseau NF, dont le rôle est de fournir un annuaire à jour de l'état des fonctions réseau NF d'un réseau cœur 5G et de leurs données définies dans un profil (en anglais, « NFProfile »). Ce profil comprend notamment un identifiant (URI) permettant de localiser chaque fonction réseau NF dans le réseau cœur 5G. Cet identifiant pointe généralement sur une adresse logique.

[0122] Cet annuaire est mis à jour au moment de l'instanciation de chaque fonction NF (enregistrement) et lorsqu'une fonction NF voit ses caractéristiques modifiées, par exemple lorsqu'elle est redimensionnée. La fonction réseau NRF propose ainsi un service de découverte de fonctions NF. Elle met pour cela en œuvre un service appelé « Nnrf_NFManagement » de gestion des profils et des souscriptions de fonctions réseau NF. Les opérations proposées pour gérer un profil de fonction réseau NF comprennent l'enregistrement, la mise à jour, la suppression et la consultation.

[0123] Par exemple, la requête pour l'exécution d'une opération d'enregistrement d'un profil de fonction NF est PUT/nf-instances/{nflnstancelD}. Elle comporte un corps de requête de type NFProfile. La description OpenAPI de la requête de cette opération est la suivante: put: summary: Register a new NF Instance operationld: RegisterNFInstance tags:

- N F Instance ID (Document) parameters:

- name: nflnstancelD in: path reguired: true description: Unigue ID of the N F Instance to register schema:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Nflnstanceld'

- name: Content-Encoding in: header description: Content-Encoding, described in IETF RFC 7231 schema: type: string

- name: Accept-Encoding in: header description: Accept-Encoding, described in IETF RFC 7231 schema: type: string reguestBody: content: application/json: schema:

$ref: 'ff/components/schemas/NFProfile' reguired: true [0124] Cet exemple ne comporte pas de paramètre de requête (en anglais, « query parameter »), mais il comprend un paramètre dans l'URI (en anglais, « path parameter ») spécifié par {nflnstancelD}. On note qu'en règle générale, les requêtes de types POST, PUT, DELETE ne comportent pas de paramètres de requête, contrairement aux requêtes GET.

[0125] En relation avec les figures 4 à 9, on considère une fonction réseau NFx du réseau RC, configurée pour rendre N services, avec N entier supérieur ou égal à 1, et comprenant une entité intermédiaire RP de type proxy inversé et des entités d'exécution EES et de validation EVS de N services. Selon ces exemples de réalisation de l'invention, cette entité intermédiaire RP est configurée pour mettre en œuvre le procédé de traitement d'une requête d'exécution d'un service, tel que précédemment décrit. Sur les figures 4 à 9, on n'a, par simplicité, représenté que les entités EVS et EES relatives à un service Si donné, avec i entier compris entre 1 et N. On a représenté un deuxième rectangle derrière chaque rectangle EVS et EES pour figurer que plusieurs instances de ces entités EVS et EES ont pu être allouées par un orchestrateur du réseau RC, en fonction des besoins, comme précédemment évoqué.

[0126] En relation avec les figures 4 à 7, on décrit maintenant des exemples de mise en œuvre du premier mode de réalisation de l'invention, selon lequel le proxy inversé RP sert d'intermédiaire à tous les échanges de messages, non seulement entre l'entité consommatrice du service ECS et la fonction réseau NFx, mais aussi entre les entités de validation EVS et d'exécution EES du service Si.

[0127] Sur la figure 4, une requête REQ est reçue par le proxy inversé RP de la fonction réseau NFx en provenance d'une entité consommatrice ECS du réseau, par exemple une autre fonction réseau du réseau RC. Cette requête identifie le service Si en spécifiant un identifiant unique de ce service Si dans le réseau RC, par exemple l'URI U RI 1. Cet identifiant URI1 a par exemple été obtenu par l'entité consommatrice ECS auprès du service Nnrf_NFmanagement de gestion des profils de la fonction réseau NRF précédemment évoquée.

[0128] La requête REQ est ensuite transmise à l'entité de validation EVS. Pour ce faire, l'identifiant « public» URI1 a été remplacé par le proxy inversé RP par un identifiant privé de type URI, URI2, associé à l'entité de validation EVS, qui est interne à la fonction réseau NFx, et donc n'est pas connu en dehors de la fonction réseau NFx. A réception de la requête REQ, l'entité de validation EVS vérifie qu'elle est conforme au document de spécification de l'API du service Si demandé. Dans l'exemple de la figure 4, la requête REQ est validée. L'entité de validation EVS retourne une réponse REP au proxy inversé RP lui indiquant, dans un en-tête dédié, par exemple l'en-tête de localisation « location », l'identifiant privé URI3 de l'entité d'exécution EES du service Si. Cette réponse REP comprend un code de statut, qui correspond ici, dans le cas d'une requête validée, au code HTTP de redirection 307. Il s'agit d'une réponse HTTP standard de type redirection (avec un code de statut HTTP de la classe 3xx). On note que l'entité qui sert une réponse de ce type indique l'URL de Redirection dans l'en-tête de localisation.

[0129] Le proxy inversé RP transmet la requête REQ à l'entité d'exécution EES en utilisant l'identifiant URI3. Il reçoit une réponse REP' comprenant un rapport d'exécution qu'il transmet alors à l'entité consommatrice du service ECS.

[0130] En relation avec la figure 5, on décrit maintenant, le cas d'une requête REQ non validée par l'entité de validation EVS. Le message de réponse REP adressé par l'entité de validation EVS au proxy inversé RP comprend un code d'erreur, à savoir dans le mode de réalisation décrit ici, un code d'erreur HTTP de la classe « 4xx ». A réception, le proxy inversé RP le transmet à l'entité consommatrice du service ECS.

[0131] En relation avec la figure 6, on décrit maintenant un exemple selon lequel le proxy inversé RP a reçu la requête REQ, mais a décidé de ne pas la soumettre à la validation de l'entité EVS, sur la base d'un ou plusieurs indicateurs de fonctionnement représentatifs par exemple d'un état du réseau RC, ou de la charge de la fonction NFx ou encore d'un taux de rejet des requêtes précédemment traitées pour le service Si demandé, etc. La requête REQ est donc transmise directement à l'entité d'exécution de service EES, dont l'identifiant privé URI3 de la fonction réseau NFx est obtenu par d'autres moyens, par exemple basés sur des règles de configuration. Cette requête est traitée par l'entité d'exécution de service EES qui renvoie une réponse REP' comprenant un résultat d'exécution au proxy inversé RP. Elle est reçue par le proxy inversé RP qui la transmet à l'entité consommatrice de service ECS.

[0132] On décrit maintenant des exemples de mises en œuvre du deuxième mode de réalisation de l'invention en relation avec les figures 7 à 9. Comme pour les figures 4 à 6, le procédé de traitement d'une requête d'exécution d'un service est mis en œuvre par une entité intermédiaire, par exemple de type proxy inversé RP, qui fait partie de la fonction réseau NFx.

[0133] En relation avec la figure 7, à réception de la requête REQ, le proxy inversé RP la transmet à l'entité de validation EVS comme précédemment décrit. L'entité de validation EVS la vérifie mais ne la valide pas. Elle émet donc une réponse REP à destination du proxy inversé RP comprenant un message d'erreur MERR. Dans le mode de réalisation décrit ici, ce message d'erreur utilise le code de statut HTTP de la classe « 4xx ». L'entité intermédiaire le reçoit et le transmet à l'entité consommatrice ECS comme précédemment décrit.

[0134] En relation avec la figure 8, on considère maintenant le cas où la requête REQ a été validée par l'entité EVS. Selon ce deuxième mode de réalisation, l'entité EVS transmet directement la requête REQ à l'entité d'exécution EES du service Si demandé, en utilisant son identifiant privé URI3. Elle reçoit une réponse REP' de l'entité d'exécution EES, qu'elle transmet au proxy inversé RP. A réception, l'entité intermédiaire RP transmet la réponse à l'entité consommatrice de service ECS.

[0135] En relation avec la figure 9, la requête REQ est reçue par l'entité intermédiaire RP qui décide sur la base d'au moins un critère de décision basé sur au moins un indicateur de fonctionnement, de ne pas la soumettre à la validation de l'entité de validation EVS. Il obtient l'identifiant URI4 de l'entité d'exécution du service EES via des règles de configuration et lui transmet donc directement la requête REQ. L'entité d'exécution du service EES exécute le service et lui renvoie une réponse REP' comprenant un résultat de cette exécution.

[0136] En relation avec les figures 10 à 12, on décrit maintenant des exemples de réalisation selon lesquels l'entité de validation EVS et l'entité intermédiaire sont externes à la fonction de réseau NFx qui met en œuvre le service Si demandé par l'entité consommatrice du service ECS et l'entité de validation EVS. Par exemple, l'entité intermédiaire est un équipement SCP tel que précédemment décrit. Dans le cas de fonctions NF multi-distribuées et dans certains modèles de déploiement, cet équipement SCP est configuré pour constituer un point d'entrée unique pour un groupe de fonctions réseau qui sont enregistrées dans la fonction NRF, dont la fonction NFx. Autrement dit, seul le SCP connaît la NFx productrice du service Si demandé.

[0137] Par exemple l'entité de validation EVS est comprise dans une autre fonction réseau (non représentée sur les figures 10 à 12), qui peut regrouper plusieurs entités de validation de services distincts. On note que dans ce qui suit, certaines étapes ne seront pas décrites en détail car elles sont réalisées de façon similaire aux exemples des figures 4 à 9.

[0138] En relation avec la figure 10, l'équipement SCP reçoit la requête REQ de l'entité consommatrice de service ECS. Cette requête REQ est adressée à l'identifiant public URI1 de l'équipement SCP et comprend un identifiant du service Si souhaité, par exemple le nom de l'API du service de la fonction réseau NFx qui met en œuvre le service Si (par exemple, « nsmf-pdusession/vl »). L'équipement SCP la transmet vers l'entité de validation EVS concernée en utilisant l'identifiant URI2 de cette entité EVS qu'elle a préalablement obtenu à partir de l'identifiant de la fonction réseau NFx et d'informations de profil de la fonction NFx obtenues auprès de la fonction réseau NRF. Il ne s'agit pas ici d'un identifiant privé, mais d'une adresse routable dans le réseau RC. L'entité EVS vérifie la requête REQ reçue et envoie à l'équipement SCP (URI1) un message de réponse REP de validation comprenant un résultat positif (par exemple avec un code de statut 307). Selon ce mode de réalisation, la réponse REP ne comprend pas d'identifiant privé URI3 permettant d'accéder à l'entité d'exécution EES du service Si demandé. Par exemple, l'équipement SCP obtient l'identifiant URI3 en question à partir de l'identifiant du service Si produit par la fonction réseau NFx et d'informations de profil de la fonction réseau qui rend le service Si, obtenues précédemment de la fonction réseau NRF. Il transmet la requête REQ à l'entité d'exécution EES à l'aide de l'identifiant URI3. Dans cet exemple, la requête REQ n'est pas reçue directement par l'entité d'exécution du service EES, mais par une entité intermédiaire comprise dans la fonction réseau NFx, par exemple un équipement proxy inversé RP tel que précédemment décrit et qui se charge de transmettre la requête REQ vers l'identifiant privé de l'entité EES à l'intérieur de la fonction réseau NFx. On comprend que dans ce cas, URI3 est l'identifiant de l'équipement proxy inversé RP de la fonction réseau NFx et que l'identifiant privé de l'entité EES n'est pas connu de l'extérieur de la fonction réseau NFx. A réception, l'entité EES exécute le service Si demandé et envoie un message de réponse REP' à l'équipement RP, qui le transmet vers l'entité intermédiaire SCP. A réception, l'équipement SCP le transmet à l'entité consommatrice du service ECS.

[0139] En relation avec la figure 11, un en-tête de la requête REQ reçue par l'équipement SCP est modifié par l'équipement SCP pour y insérer l'identifiant URI3 de la fonction réseau NFx (« 3gpp-Sbi-Tar- get-apiRoot » = URI3). On note que le SCP est configuré pour déterminer cet identifiant URI3 avant la validation effective de la requête REQ. Néanmoins, il convient de noter également que, selon la norme 3GPP actuelle, l'entité intermédiaire SCP n'est configurée que pour l'insérer ensuite dans un message de réponse et pas dans la requête elle-même comme proposé par la présente invention.

[0140] On suppose ici encore que l'entité de validation EVS valide la requête REQ. Sa réponse REP, par exemple une réponse HTTP standard de type redirection (avec un code de statut HTTP de la classe 3xx), comprend l'identifiant privé URI3 de la fonction réseau NFx précédemment reçu, ce qui permet à l'équipement SCP de transmettre directement la requête REQ vers cet identifiant URL La suite correspond à ce qui a été précédemment décrit en relation avec la figure 11. On note que l'utilisation de l'entête « 3gpp-Sbi-Target-apiRoot » de localisation qui vient d'être décrite est conforme aux spécifications de la norme 3GPP. Néanmoins, selon la version actuelle de cette norme, l'entité intermédiaire SCP est le seul récipiendaire de l'en-tête de localisation « 3gpp-Sbi-Target-apiRoot » contenu dans une requête et la seule entité/fonction du réseau cœur 5G configurée pour être placée en coupure d'une transaction client-serveur. L'entité intermédiaire SCP est configurée pour traiter cet en-tête et transmettre ensuite la requête à l'identifiant URI que cet en-tête porte. Cet en-tête permet de forcer le passage d'une requête par l'entité intermédiaire SCP.

[0141] La présente invention propose de définir une nouvelle entité/fonction EVS de validation des requêtes, de l'insérer en coupure des échanges clients/serveur et de la configurer pour qu'elle transmet les requêtes validées directement vers l'entité d'exécution du service EES. Pour ce faire, elle s'appuie sur cet en-tête de localisation. Il en résulte que la mise en œuvre de l'en-tête « 3gpp-Sbi-Target-apiRoot » faite à la fig.ll diffère strictement de ce qui est décrit dans le standard 3GPP aujourd'hui.

[0142] En relation avec la figure 12, on considère maintenant, comme dans l'exemple de la figure 12 qu'un entête de la requête REQ est modifié, par exemple l'entête 3gpp-Sbi-Target-apiRoot, par l'équipement SCP pour y insérer l'identifiant public URI3 de la fonction réseau NFx qui met en œuvre le service Si demandé. La différence est qu'une fois la requête REQ validée par l'entité EVS, cette dernière la transmet directement vers la fonction réseau NFx en utilisant l'identifiant URI3 qu'elle a récupéré de l'en-tête modifié. Comme précédemment décrit, elle est reçue par l'équipement proxy inversé RP qui la transmet vers l'identifiant de l'entité d'exécution EES, interne à la fonction réseau NFx. Une fois le service Si exécuté, une réponse REP' est retournée par l'entité EES au proxy inversé RP qui la transmet vers le SCP qu'il la transmet lui-même à l'entité consommatrice du service ECS. On comprend que ce mode de réalisation implique que l'entité de validation soit configurée pour traiter l'entête « 3gpp-Sbi-Target-api- Root », comme décrit dans la norme 3GPP pour l'entité intermédiaire SCP.

[0143] Selon encore un autre exemple de réalisation (non représenté), l'entité de validation EVS du service pourrait être intégrée directement dans le SCP.

[0144] On présente ensuite, en relation avec la figure 13, un exemple de structure matérielle d'une entité intermédiaire RP, SCP configurée pour traiter une requête d'exécution d'un service dans un réseau de communication, en provenance d'une entité, dite entité consommatrice du service, à destination une entité d'exécution dudit service dans ledit réseau, ladite entité intermédiaire étant configurée pour recevoir des messages en provenance et/ou destinés à l'entité d'exécution du service, et comprenant un module de transmission de la requête d'exécution vers une entité de validation de ladite requête, distincte de l'entité d'exécution du service, pour validation, et un module de transmission d'une réponse à ladite requête à l'entité consommatrice du service.

[0145] Avantageusement, l'entité intermédiaire RP, SCP comprend un module de réception d'un message de réponse de validation en provenance de l'entité de validation, ledit message comprenant le résultat de validation, et un module de prise de décision de transmettre ou non la requête d'exécution à l'entité d'exécution du service en fonction du résultat de validation reçu. Avantageusement, il comprend en outre un module de transmission de la requête d'exécution du service à l'entité d'exécution du service, ledit module étant configuré pour être mis en œuvre en réponse à un résultat de validation positif. [0146] Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions. [0147] Plus généralement, une telle entité intermédiaire RP, SCP comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pgl, représentatif des modules précités, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 103 avant d'être exécutées par le processeur de l'unité de traitement 102. La mémoire vive 103 peut aussi contenir par exemple des informations relatives à l'entité de validation du service et/ou à l'entité d'exécution du service, comme par exemple des identifiants, permettant d'accéder à cette ou ces entités, par exemple obtenus lors d'une phase préalable de découverte. Elle peut comprendre en outre un ou plusieurs critères de décision relatifs au déclenchement de la transmission de la requête d'exécution du service EVS reçue à l'entité de validation de service. [0148] La figure 13 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser l'entité intermédiaire RP, SCP afin qu'elle effectue les étapes du procédé de traitement d'une requête d'exécution d'un service tel que détaillé ci-dessus, en relation avec les figures 2 et 3, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

[0149] Dans le cas où l'entité intermédiaire RP, SCP est réalisée avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

[0150] Les différents modes de réalisation ont été décrits ci-avant en relation avec une entité intermédiaire de type équipement réseau de type proxy inversé ou équipement SCP.

[0151] On présente enfin, en relation avec la figure 14, un exemple de structure matérielle d'une entité de validation EVS d'une requête d'exécution d'un service dans un réseau de communication, ladite requête ayant été émise par une entité consommatrice du service à destination d'une entité d'exécution du service, comprenant un module de réception de ladite requête d'exécution en provenance d'une entité intermédiaire RP, SCP configurée pour traiter ladite requête d'exécution, ladite entité de validation étant configurée pour recevoir des messages en provenance de et/ou destinés à l'entité d'exécution du service de l'entité d'exécution, un module de vérification d'une validité de ladite requête, comprenant l'obtention d'un résultat de validation et un module de déclenchement d'une action de traitement de la requête en fonction du résultat de validation obtenu.

[0152] Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.

[0153] Plus généralement, une telle entité de validation EVS comprend une mémoire vive 203 (par exemple une mémoire RAM), une unité de traitement 202 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg2, représentatif des modules précités, stocké dans une mémoire morte 201 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 203 avant d'être exécutées par le processeur de l'unité de traitement 202. La mémoire vive 203 peut aussi contenir par exemple des informations d'identification de l'entité d'exécution du service demandé et/ou de l'entité intermédiaire RP, SCP.

[0154] La figure 14 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser l'entité de validation EVS afin qu'elle effectue les étapes du procédé de validation d'une requête d'exécution d'un service tel que détaillé ci-dessus, en relation avec les figures 4 à 12, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

[0155] Dans le cas où l'entité de validation EVS est réalisée avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD- ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

[0156] Les modes de réalisation qui viennent d'être décrits peuvent être combinés entre eux.