FR 3138710 A1 20240209 FR 2208145 A 20220805 Procédé de traitement d’une requête d’analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en œuvre ces procédés L’invention concerne un procédé de traitement d’une requête (REQ) d’analyse statistique ou prédictive reçue par une première entité applicative d’un réseau de communications en provenance d’une deuxième entité applicative du réseau, ce procédé comprenant : - une étape (F30) de détermination, à partir d’au moins une information véhiculée (P-CTX, P-DEF) par ladite requête, d’un contexte (CTX) de formulation de ladite requête par ladite deuxième entité applicative ; - une étape (F50) de réalisation de ladite analyse statistique ou prédictive requise au moyen d’un modèle (MOD(CTX)) d’analyse sélectionné (F40) en fonction dudit contexte déterminé ; et - une étape (F60) de fourniture d’au moins un résultat (RES) de l’analyse réalisée en réponse à ladite requête de la deuxième entité applicative. Figure 4 Procédé de traitement d’une requête d’analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en œuvre ces procédés L’invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement les réseaux de communication s’appuyant sur une pluralité d’entités applicatives implémentant diverses fonctionnalités ou services dans le réseau, comme par exemple un réseau cœur 5G (ou « 5GC » pour « 5G Core network » en anglais) tel que défini par le standard 3GPP. De telles entités applicatives sont par exemple des dispositifs (matériels ou logiciels) hébergeant des fonctions réseau (ou NF pour « Network Functions » en anglais) implémentant des fonctionnalités telles que l’accès au réseau, la mobilité des utilisateurs ou encore la gestion des sessions établies dans le réseau, le stockage et la publication des profils des fonctions réseau, etc. Afin d’optimiser les procédures au sein du réseau cœur 5G, les fonctions NF peuvent faire appel à une fonction NF spécifique chargée de collecter et d’analyser des données du réseau, appelée fonction NWDAF (pour « NetWork Data Analytics Function » en anglais). La fonction NWDAF propose aux fonctions NF du réseau qui la sollicitent, des analyses statistiques et/ou prédictives sur le comportement du réseau en termes notamment de qualité de service et/ou sur le comportement des équipements utilisateurs (ou UE pour « User Equipment » en anglais). Les analyses réalisées peuvent être globales, c’est-à-dire être établies au niveau du réseau, d’un serveur, d’une application ou encore d’une région (ex. taux de charge des ressources du réseau à un moment particulier de la journée ou de l’année, qualité de service moyenne, nombre d’utilisateurs connectés au réseau ou de sessions actives, etc.), ou être individuelles, c’est-à-dire porter sur un UE ou sur un groupe d’UE particulier (ex. future localisation d’un UE, volumétrie d’une future session de communication d’un UE, etc.). Les analyses sont réalisées sur la base de données brutes que la fonction NWDAF collecte auprès d’autres fonctions NF du réseau et/ou auprès de nœuds du réseau d’accès radio via l’entité de gestion du réseau en charge des opérations, de l’administration et de la maintenance, aussi connue sous le nom d’entité OAM (pour « Operations, Administration and Maintenance » en anglais), et auxquelles la fonction NWDAF applique un ou plusieurs modèles d’analyse en fonction des analyses qui lui sont demandées. De tels modèles d’analyse sont par exemple des modèles d’analyse statistique tels qu’une moyenne mobile, une moyenne exponentielle mobile, etc., ou des modèles d’analyse prédictive utilisant notamment des technologies d’apprentissage supervisé ou non supervisé. Une fois établies, les analyses statistiques et/ou prédictives permettent typiquement de mettre en œuvre de façon anticipée des modifications correctives sur les paramètres du réseau afin d’optimiser son fonctionnement. Plus spécifiquement, les entités utilisatrices de ces analyses, autrement dit les fonctions NF clientes de la fonction NWDAF (qui peuvent être distinctes ou non des fonctions NF ayant collecté et fourni les données brutes à la fonction NWDAF), sont en mesure, en fonction des analyses statistiques et/ou prédictives reçues de la fonction NWDAF, d’adapter leur comportement en vue d’optimiser le fonctionnement du réseau et la qualité du service délivré à chaque utilisateur sur son UE. Les fonctions NF clientes de la fonction NWDAF sont par exemple une fonction AMF (pour « Access and Mobility management Function » en anglais) de gestion d’accès, une fonction SMF (pour « Session Management Function » en anglais) de gestion de sessions, une fonction PCF (pour « Policy Control Function » en anglais) de contrôle des politiques, etc. Le document 3GPP TR 23.791, intitulé « Technical Specification Group Services and System Aspects ; Study of Enablers for Network Automation for 5G (Release 16) », v16.2.0, juin 2019, évoque différents cas d’usage de telles analyses statistiques et/ou prédictives dans un réseau 5G. Ainsi, par exemple, des prévisions de mobilité des UE peuvent être utilisées par la fonction AMF pour optimiser la gestion de la mobilité des UE, et en particulier la détermination de leur zone d’enregistrement (ou RA pour « Registration Area » en anglais), cette zone d’enregistrement permettant de localiser des UE en veille et de leur adresser des messages de sollicitation (ou « paging » en anglais) lorsque des données leur étant destinées parviennent au réseau, etc. Ce cas d’usage est également décrit dans le document 3GPP TS 23.501, intitulé « Technical Specification Group Services and System aspects ; System architecture for the 5G system (5GS) ; Stage 2 (Release 17) », v17.4.0, mars 2022, notamment au paragraphe 5.3.2. Selon un autre exemple également décrit dans le document 3GPP TS 23.501 au paragraphe 6.3.3.3, il peut s’avérer utile à la fonction SMF de disposer de statistiques ou de prédictions sur le trafic réseau (ex. charge) lors de la sélection d’une fonction UPF (pour « User Plane Function » en anglais) de plan utilisateur permettant d’acheminer les données des sessions PDU (pour « Packet Data Unit » en anglais). Selon un autre exemple encore décrit notamment dans le document 3GPP TS 23.503, intitulé « Technical Specification Group Services and System aspects ; Policy and charging control framework for the 5G system (5GS) ; Stage 2 (Release 17) », v17.4.0, mars 2022, notamment aux paragraphes 4.2.3 et 6.1.1.3, une fonction PCF peut demander des analyses statistiques de dispersion pour modifier des politiques ou pour déterminer le débit moyen pour une tranche (ou « slice » en anglais) d’un réseau. Il convient de noter en outre qu’une même analyse statistique et/ou prédictive peut être requise pour assister différentes fonctions NF du réseau dans différents contextes et/ou pour implémenter des fonctionnalités diverses. On comprend bien dès lors, au vu des nombreux cas d’usage des analyses statistiques et/ou prédictives délivrées par la fonction NWDAF et de leur importance dans le fonctionnement opérationnel du réseau, que ces analyses doivent être précises et pertinentes. L’invention répond notamment à ce besoin en proposant un procédé de traitement d’une requête d’analyse statistique ou prédictive reçue par une première entité applicative d’un réseau de communications en provenance d’une deuxième entité applicative du réseau, ce procédé comprenant : une étape de réalisation de ladite analyse statistique ou prédictive requise au moyen d’un modèle d’analyse sélectionné en fonction d’un contexte de formulation de ladite requête par ladite deuxième entité applicative, déterminé à partir d’au moins une information véhiculée par la requête ; et une étape de fourniture d’au moins un résultat de l’analyse réalisée en réponse à la requête de la deuxième entité applicative. Corrélativement, l’invention concerne également une entité applicative d’un réseau de communications, dite première entité applicative, comprenant : un module de réception configuré pour recevoir d’une deuxième entité applicative du réseau, une requête d’analyse statistique ou prédictive ; un module de traitement, configuré pour réaliser ladite analyse au moyen d’un modèle d’analyse sélectionné en fonction d’un contexte de formulation de ladite requête par ladite deuxième entité applicative, déterminé à partir d’au moins une information véhiculée par ladite requête ; et un module de fourniture, configuré pour fournir au moins un résultat de l’analyse réalisée en réponse à la requête de la deuxième entité applicative. Comme évoqué précédemment, l’invention a une application privilégiée mais non limitative dans le contexte d’un réseau cœur 5G. Ainsi, par exemple, la première entité applicative et la deuxième entité applicative hébergent des fonctions réseau, la fonction réseau hébergée par la première entité applicative étant une fonction de collecte et d’analyse de données du réseau. Il convient toutefois de noter que si le besoin d’analyses statistiques et/ou prédictives a été formulé dans le contexte d’un réseau 5G. il n’en demeure pas moins qu’un tel besoin peut se présenter dans d’autres situations, notamment dans d’autres réseaux de communication (par exemple des réseaux propriétaires), entre d’autres entités applicatives qu’une fonction NF et une fonction NWDAF, etc. Par entité applicative, on entend ici tout type de dispositif communicant, matériel ou virtuel (i.e. logiciel), configuré pour mettre en œuvre une logique de traitement déterminée, comme par exemple un dispositif offrant et/ou consommant des services dans un réseau telle qu’une fonction réseau (NF) ou une instance de fonction réseau d’un réseau cœur conforme au standard 3GPP, mais également une unité de gestion de routeurs ou encore un contrôleur SDN (pour « Software Defined Network » en anglais) dans un réseau IP (pour « Internet Protocol » en anglais), etc. Ainsi, l’invention propose d’améliorer la qualité et la précision des analyses statistiques et prédictives requises par une entité applicative (deuxième entité applicative au sens de l’invention) auprès d’une autre entité applicative (première entité applicative au sens de l’invention) en tenant compte du contexte dans lequel est formulée cette requête, c’est-à-dire le contexte d’usage de l’analyse prédictive et/ou statistique demandée. Un tel contexte de formulation (ou d’usage de l’analyse requise) peut typiquement comprendre la raison de cette requête, c’est-à-dire la destination du résultat d’analyse ou le cas d’usage pour lequel l’analyse statistique et/ou prédictive est requise. Ainsi, dans un mode particulier de réalisation, le contexte de formulation identifie une procédure destinée à être exécutée par la deuxième entité applicative dans le réseau en utilisant le résultat d’analyse fourni par la première entité applicative (ex. enregistrement d’un UE, ouverture d’une session de données, etc.). Les inventeurs ont en effet constaté que, dans un réseau cœur 5G, chaque procédure du réseau qui appelle la réalisation d’analyses statistiques et/ou prédictives (ex. enregistrement, ouverture de session, optimisation d’un profil d’usager, etc.) constitue un cas d’usage spécifique pour lequel il est souhaitable que la fonction NWDAF (première entité applicative au sens de l’invention) délivre le résultat le plus pertinent afin d’optimiser cette procédure. Par ailleurs, comme évoqué précédemment, une même analyse statistique et/ou prédictive peut être requise par une même entité applicative ou par des entités applicatives distinctes au cours de deux procédures différentes, autrement dit pour des usages différents (ex. besoins de long terme vs besoins de court terme). Or à ce jour, pour réaliser l’analyse qui lui est demandée, la fonction NWDAF s’appuie uniquement sur les paramètres fournis dans la requête qui définissent à proprement parler l’analyse qui est requise (ex. type d’analyse attendue et son niveau de précision, la cible de l’analyse, etc.) et sur les données brutes qu’elle collecte auprès de diverses entités du réseau. Le modèle d’analyse utilisé par la fonction NWDAF peut perdre en efficacité à devoir répondre à une pluralité de cas d’usage différents. La connaissance du contexte de formulation de la requête et en particulier la motivation pour laquelle cette requête a été faite, constitue une information précieuse pour la première entité applicative pour améliorer la précision et la pertinence de l’analyse statistique et/ou prédictive qu’elle réalise. En effet, cette information offre la possibilité à la première entité applicative de sélectionner de manière parfaitement adaptée le modèle d’analyse qui va délivrer la meilleure analyse statistique et/ou prédictive pour une situation applicative donnée, autrement dit pour un cas d’usage donné. Par exemple, pour une fonction AMF, savoir que l’on utilise une analyse pour une mise à jour d’une zone d’enregistrement ou pour localiser un UE (aussi plus communément désigné par l’appellation anglaise « paging ») peut conduire à choisir des modèles d’analyse très différents en termes de technique mathématique et/ou de paramètres de réglage. Pour mieux comprendre l’apport de l’invention, on peut faire l’analogie avec la vie courante et la situation d’un médecin qui devrait réaliser des analyses sur un patient sans disposer d’informations sur son patient (ex. son âge, s’il est fumeur ou non, etc.) ni la raison pour laquelle ces analyses sont nécessaires (ex. présence de douleurs). Le contexte de formulation obtenu constitue donc une aide externe qui permet de guider les choix faits par la première entité applicative pour réaliser l’analyse qui lui est demandée et de prendre des dispositions adéquates pour obtenir un résultat pertinent pour cette analyse. Différentes façons peuvent être envisagées pour obtenir le contexte de formulation. Ainsi, dans un mode particulier de réalisation, le contexte de formulation est indiqué par un paramètre inséré par la deuxième entité applicative dans un champ dédié de la requête. En d’autres mots, le contexte de formulation est renseigné explicitement par la deuxième entité applicative, dans un paramètre spécifique, lorsqu’elle formule sa requête. Un tel paramètre dédié est par exemple nommé UseCaseContext. Différents formats peuvent être envisagé pour ce paramètre dédié, tels que par exemple un entier, une chaîne de caractères, une liste d’entiers ou de chaînes de caractères, etc. Les valeurs du paramètre peuvent être prédéfinies ou non. Ce mode de réalisation est particulièrement simple à mettre en œuvre et permet à la première entité applicative d’obtenir une information fiable et précise du contexte de formulation de la requête. En variante, le contexte de formulation peut être déterminé par la première entité applicative à partir d’une pluralité de paramètres définissant l’analyse requise par la deuxième entité applicative et fournis dans la requête. De tels paramètres sont pris par exemple parmi : une identité de la deuxième entité applicative ; un paramètre représentatif d’un type d’analyse requis (ex. type et quantité de résultats obtenus, etc.) ; au moins un équipement sur lequel porte l’analyse ; un paramètre représentatif d’une condition de réalisation de l’analyse (ex. zone géographique, période de temps, tranche de réseau concernée, etc.) ; un niveau de précision attendu pour l’analyse ; un paramètre représentatif d’une modalité de notification dudit au moins un résultat de l’analyse (ex. périodicité, souscription, etc.). Certains groupes de paramètres fournis dans la requête et les valeurs associées à ces groupes de paramètres peuvent en effet être considérés comme des signatures représentatives de contextes distincts. Différentes possibilités peuvent alors être envisagées : la première entité applicative est configurée avec un certain nombre de signatures auxquelles sont associées des contextes. Sur réception de la requête, la première entité applicative détermine à partir des paramètres fournis dans la requête, s’ils correspondent à l’une des signatures dont elle dispose. Le cas échéant, le contexte de formulation de la requête est celui qui est associée à la signature ; la première entité applicative met en œuvre une phase d’apprentissage au cours de laquelle elle analyse les paramètres présents dans les requêtes reçues et détermine, par exemple au moyen d’un algorithme de classification, quels groupes de paramètres et valeurs associées sont significatifs et représentatifs d’un contexte particulier. Les différents groupes de paramètres et valeurs associées ainsi obtenus définissent un ensemble de signatures correspondant à des contextes de formulation distincts. Il convient de noter que dans ce cas, la première entité applicative est en mesure de faire le distinguo entre des contextes de formulation distincts, et d’associer un contexte de formulation donné à une requête, mais elle ne dispose pas nécessairement des informations nécessaires pour associer à ce contexte de formulation une opération spécifique exécutée ou destinée à être exécutée par la deuxième entité applicative (ex. détermination d’une zone d’enregistrement). Il convient par ailleurs de noter que certains des paramètres fournis dans la requête peuvent présenter une certaine variabilité pour un cas usage donné ; aussi il convient de bien sélectionner les paramètres permettant à la première entité applicative de déduire le contexte de formulation de la requête en fonction des différents cas d’usage. Dans une autre variante de réalisation, on peut envisager que le contexte de formulation renseigné par la deuxième entité applicative dans un champ spécifique de la requête soit affiné par la première entité applicative en exploitant les paramètres véhiculés par la requête définissant l’analyse requise par la deuxième entité applicative. Le contexte de formulation déterminé par la première entité applicative comprend alors le contexte renseigné par la deuxième entité applicative (ex. la procédure dans le cadre de laquelle la requête est formulée et le résultat d’analyse va être exploité) éventuellement complété par d’autres informations issues des paramètres de définition de l’analyse (ex. UE ou un groupe d’UE ou une cellule, etc.). Comme évoqué précédemment, conformément à l’invention, le contexte de formulation de la requête est utilisé par la première entité applicative pour sélectionner un modèle d’analyse pertinent pour réaliser l’analyse statistique et/ou prédictive qui lui est demandée. La sélection du modèle d’analyse peut s’opérer à différents niveaux. Ainsi, elle peut comprendre par exemple une sélection d’au moins un élément parmi : une technique d’analyse statistique ou prédictive à utiliser pour réaliser l’analyse ; au moins une caractéristique d’un jeu de données à utiliser pour réaliser l’analyse et/ou entraîner une technique d’analyse utilisée pour réaliser l’analyse ; un paramétrage d’une technique d’analyse utilisée pour réaliser l’analyse ; etc. L’ajustement de tout ou partie des éléments précités permet à la première entité applicative d’obtenir des résultats d’analyse très pertinents pour la deuxième entité applicative, ce qui permet à cette dernière d’optimiser les procédures qu’elle met en œuvre dans le cadre des fonctions qui lui sont confiées dans le réseau. Pour permettre la sélection par la première entité applicative d’un modèle d’analyse adapté au contexte de formulation de la requête, différentes façons de procéder peuvent être envisagées. Ainsi, dans un mode particulier de réalisation, le procédé de traitement comprend une étape préliminaire de configuration de la première entité applicative avec une liste de modèles d’analyse dans laquelle chaque modèle d’analyse est associé à au moins un contexte de formulation d’une requête, le modèle d’analyse appliqué lors de l’étape de réalisation étant un modèle d’analyse associé dans cette liste au contexte déterminé lors de l’étape d’obtention. Ce mode de réalisation consiste en une pré-configuration de la première entité applicative, par exemple par l’opérateur du réseau, avec une liste de modèles possibles adaptés à différents contextes. Il est relativement simple à mettre en œuvre. Il convient de noter qu’une mise à jour de la liste ainsi préconfigurée peut être effectuée à tout moment via un message de configuration approprié envoyé à la première entité applicative. Dans un autre mode de réalisation, le procédé de traitement comprend une étape d’apprentissage au cours de laquelle la première entité applicative : établit des corrélations entre des modèles d’analyse, des contextes de formulation d’une requête, et des indicateurs de qualité des analyses réalisées à partir desdits modèles dans lesdits contextes ; et associe, à partir des corrélations établies, à au moins un contexte de formulation d’une requête un modèle d’analyse optimisant ladite qualité, le modèle d’analyse appliqué lors de l’étape de réalisation étant sélectionné à partir des associations établies lors de l’étape d’apprentissage. Ce mode de réalisation a une application privilégiée lorsque la première entité applicative ne dispose pas de pré-configuration pour un contexte de formulation donné, ou de façon générale, ne dispose d’aucune pré-configuration. Dans ce mode de réalisation, c’est la première entité applicative qui optimise, par apprentissage, la sélection d’un modèle d’analyse en fonction du contexte de formulation de la requête d’analyse qui lui est adressée. Ce mode de réalisation est avantageusement évolutif et permet à la première entité applicative de tenir compte de la qualité des résultats d’analyse qu’elle obtient pour optimiser le choix des modèles d’analyse. Dans un autre mode de réalisation encore, le procédé de traitement comprend : - une étape préliminaire de configuration de la première entité applicative avec une liste comprenant au moins un modèle d’analyse associé à au moins un contexte de formulation d’une requête ; une étape d’apprentissage au cours de laquelle la première entité applicative : établit des corrélations entre des modèles d’analyse, des contextes de formulation d’une requête, et des indicateurs de qualité des analyses statistiques réalisées à partir desdits modèles dans lesdits contextes ; et met à jour et/ou complète ladite liste à partir desdites corrélations établies ; le modèle d’analyse appliqué lors de l’étape de réalisation étant un modèle d’analyse associé au contexte déterminé lors de l’étape d’obtention dans la liste mise à jour ou complétée lors de l’étape d’apprentissage. Ce mode de réalisation combine avantageusement les deux précédents, et bénéficie ainsi des avantages associés à chacun d’entre eux. Au vu de ce qui précède, l’invention s’appuie sur la première entité applicative qui obtient un contexte de formulation de la requête d’analyse qui lui est adressée et exploite ce contexte pour optimiser les résultats d’analyse qu’elle fournit en réponse à cette requête, mais également, dans un mode particulier de réalisation, sur la deuxième entité applicative à l’origine de la requête et qui fournit à la première entité applicative ledit contexte de formulation. Ainsi, selon un autre aspect, l’invention concerne un procédé de communication avec une première entité applicative d’un réseau de communications, ce procédé de communication étant mis en œuvre par une deuxième entité applicative du réseau et comprenant : une étape d’envoi à la première entité applicative d’une requête d’analyse statistique ou prédictive comprenant, dans un champ dédié de la requête, un paramètre indiquant un contexte de formulation de la requête ; et une étape de réception, en réponse à la requête, d’au moins un résultat de l’analyse requise réalisée par la première entité applicative au moyen d’un modèle d’analyse sélectionné en fonction de ce contexte. Corrélativement, l’invention vise aussi une entité applicative d’un réseau de communications, dite deuxième entité applicative, comprenant : un module d’envoi, configuré pour envoyer à une première entité applicative du réseau une requête d’analyse statistique ou prédictive comprenant, dans un champ dédié de la requête, un paramètre indiquant un contexte de formulation de la requête ; et un module de réception, configuré pour recevoir en réponse à ladite requête, au moins un résultat de l’analyse requise réalisée par la première entité applicative au moyen d’un modèle d’analyse sélectionné en fonction de ce contexte. Selon un autre aspect encore, l’invention concerne également un système dans un réseau de communications comprenant au moins une première entité applicative et au moins une deuxième entité applicative conformes à l’invention. Le procédé de communication, la deuxième entité applicative et le système selon l’invention bénéficient des mêmes avantages cités précédemment que le procédé de traitement et la première entité applicative. Dans un mode particulier de réalisation, les procédés de traitement et de communication sont mis en œuvre par un ordinateur. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une première entité applicative conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de traitement 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é applicative conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de communication tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash. D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de gestion, d’enregistrement et de communication selon l’invention. On peut également envisager, dans d'autres modes de réalisation, que les procédés de traitement et de communication, les première et deuxième entités applicatives et le système selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la représente, dans son environnement, un système dans un réseau conforme à l’invention, dans un mode particulier de réalisation ; la représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger l’une quelconque des entités selon l’invention appartenant au système de la ; la représente les modules fonctionnels des entités applicatives conformes à l’invention du système de la ; la représente les principales étapes d’un procédé de traitement selon l’invention telles qu’elles sont mises en œuvre par une première entité applicative du système de la ; la représente les principales étapes d’un procédé de communication selon l’invention telles qu’elles sont mises en œuvre par une deuxième entité applicative du système de la . Description de l’invention La représente, dans son environnement, un système 1 dans un réseau de communications CN, conforme à l’invention, dans un mode particulier de réalisation. Dans l’exemple envisagé à la , le réseau CN est un réseau cœur 5GC d’un réseau NW de communications 5G tel que défini par le standard 3GPP, s’appuyant sur une pluralité d’entités applicatives hébergeant des fonctions réseau (ou fonctions NF) implémentant diverses fonctionnalités ou services dans le réseau cœur, comme l’accès au réseau, la mobilité des utilisateurs ou encore la gestion des sessions établies dans le réseau, le stockage et la publication des profils des fonctions réseau, etc. Comme évoqué précédemment, afin d’optimiser les procédures au sein du réseau cœur CN, les fonctions NF peuvent faire appel à une fonction NF spécifique chargée de collecter et d’analyser des données du réseau, appelée fonction NWDAF (pour « NetWork Data Analytics Function » en anglais). Cette fonction NWDAF propose aux fonctions NF du réseau qui la sollicitent, des analyses statistiques et/ou prédictives sur le comportement du réseau CN, ou plus généralement du réseau NW, en termes notamment de qualité de service, et/ou sur le comportement des UE du réseau NW. Ces analyses peuvent être globales (ex. établies au niveau du réseau, d’un serveur, d’une application ou encore d’une région), ou être individuelles (i.e. porter sur un UE ou sur un groupe d’UE particulier). Elles sont réalisées à partir de données brutes collectées par la fonction NWDAF et de modèles d’analyse statistique et/ou prédictive appliqués à ces données brutes. Conformément à l’invention, le système 1 comprend : au moins une première entité applicative 2, conforme à l’invention. Dans le mode de réalisation décrit ici, l’entité applicative 2 héberge une fonction réseau NWDAF de collecte et d’analyse de données du réseau NW telle que décrite ci-avant, et est désignée dans la suite de la description par entité NWDAF 2 ; et au moins une deuxième entité applicative 3, conforme à l’invention, configurée pour consommer les services offerts par l’entité NWDAF 2, autrement dit, solliciter l’entité NWDAF 2 pour obtenir des analyses statistiques et/ou prédictives sur le comportement du réseau et/ou d’un UE ou d’un groupe d’UE. Dans le mode de réalisation décrit ici, la ou les entités applicatives 3 hébergent également des fonctions NF du réseau cœur CN. Aucune limitation n’est attachée aux fonctions NF hébergées par les entités applicatives 3. Ainsi, dans l’exemple représenté sur la , le système 1 comprend une pluralité d’entités applicatives 3 conformes à l’invention, parmi lesquelles notamment une entité applicative 3-1 hébergeant une fonction AMF d’accès au réseau (aussi désignée ci-après par entité AMF 3-1), une entité applicative 3-2 hébergeant une fonction SMF de gestion de sessions (ou entité SMF 3-2), une entité applicative 3-3 hébergeant une fonction PCF de contrôle de politique (ou entité PCF 3-3), et une entité applicative 3-4 hébergeant une fonction AF d’application (ou entité AF 3-4). Cette liste n’est pas limitative et n’est donnée qu’à titre illustratif. Chaque entité applicative du système 1 est un dispositif communicant, matériel ou virtuel (i.e. logiciel), configuré pour mettre en œuvre une logique de traitement déterminée, correspondant à la fonction réseau qu’elle héberge. Ainsi l’invention s’applique indifféremment à des entités applicatives logicielles ou virtuelles et à des entités applicatives matérielles hébergeant des fonctions réseau. Lorsque les entités applicatives considérées sont des dispositifs matériels (par exemple des serveurs d’une infrastructure du réseau cœur CN), elles ont alors l’architecture matérielle d’un ordinateur 4, tel qu’illustrée à la . Cette architecture matérielle s’appuie sur un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communications avec d’autres entités, par exemple, d’autres entités applicatives du réseau cœur CN, des entités d’un réseau d’accès au réseau cœur CN comme par exemple une entité OAM de gestion du réseau NW (non représentée sur la ), ou encore avec des UE du réseau NW. Ces moyens COM de communication peuvent notamment s’appuyer 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 telles qu’une interface de programmation applicative (ou API pour « Application Programming Interface » en anglais) ou une interface de communication point-à-point. Lorsque les entités applicatives considérées sont logicielles, elles sont elles-mêmes hébergés par un dispositif matériel ayant l’architecture matérielle de l’ordinateur 4, et peuvent alors s’appuyer sur les moyens matériels de l’ordinateur 4 évoqués ci-avant (PROC, MEM, ROM, NVM, COM). Dans la suite de la description, par souci de simplification, on fait indifféremment référence aux moyens PROC, MEM, ROM, NVM, COM de l’entité applicative considérée, que celle-ci soit matérielle ou logicielle. La mémoire non volatile NVM de l’ordinateur 4 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC et sur lequel est enregistré un programme d’ordinateur conforme à l’invention. Dans le cas d’une entité applicative 2, ce programme d’ordinateur est référencé par PROG2 et comporte des instructions définissant les principales étapes d’un procédé de traitement selon l’invention. Pour une entité applicative 3, le programme d’ordinateur en question est référencé par PROG3 et comporte des instructions définissant les principales étapes d’un procédé de communication selon l’invention. Le programme PROG2 définit les modules fonctionnels d’une entité applicative 2 et notamment de l’entité NWDAF 2 du système 1, qui s’appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 4, cités précédemment. Ces modules fonctionnels comprennent notamment, dans le mode de réalisation décrit ici, comme illustré sur la : un module 2A de réception configuré pour recevoir d’une entité applicative 3 du système 1 une requête REQ d’analyse statistique ou prédictive ; un module 2B de détermination, configuré pour obtenir à partir d’au moins une information véhiculée par cette requête REQ, un contexte CTX de formulation de la requête par l’entité applicative 3. Un tel contexte CTX de formulation est représentatif typiquement du cas d’usage de l’analyse statistique ou prédictive requise, il identifie par exemple une procédure que l’entité applicative 3 va exécuter en utilisant le résultat de l’analyse statistique ou prédictive demandée ; un module 2C de traitement, configuré pour réaliser l’analyse requise au moyen d’un modèle d’analyse sélectionné en fonction du contexte CTX déterminé par le module 2B de détermination ; et un module 2D de fourniture, configuré pour fournir au moins un résultat de l’analyse réalisée par le module 2C de traitement en réponse à la requête REQ de l’entité applicative 3. La configuration et le fonctionnement des modules 2A à 2D de l’entité applicative 2 et plus particulièrement de l’entité NWDAF 2 sont décrits plus en détail ultérieurement en référence aux étapes du procédé de traitement selon l’invention. De façon similaire, le programme PROG3 définit les modules fonctionnels d’une entité applicative 3, et plus particulièrement de chacune des entités AMF 3-1, SMF 3-2, PCF 3-3 et AF 3-4 du système 1, ces modules fonctionnels s’appuyant ou commandant les éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 4, cités précédemment. Dans le mode de réalisation décrit ici, les modules fonctionnels d’une entité applicative 3 conforme à l’invention comprennent notamment, comme illustré sur la : un module 3A d’envoi, configuré pour envoyer à l’entité applicative 2, et plus particulièrement ici à l’entité NWDAF 2, une requête REQ d’analyse statistique ou prédictive. Dans le mode de réalisation décrit ici, le module 3A d’envoi est configuré pour utiliser, pour envoyer la requête REQ, une API de l’entité NWDAF 2, comme détaillé davantage ultérieurement. Il est en outre configuré pour insérer dans la requête REQ, dans un champ dédié de la requête nommé à titre illustratif UseCaseContext, un paramètre indiquant le contexte CTX de formulation de la requête, autrement dit le contexte d’usage du ou des résultats de l’analyse requise ; un module 3B de réception, configuré pour recevoir en réponse à la requête REQ adressée à l’entité NWDAF 2, au moins un résultat de l’analyse requise réalisée par l’entité NWDAF 2 au moyen d’un modèle d’analyse sélectionné par celle-ci en fonction du contexte CTX ; et un module 3C d’exécution, configuré pour exécuter une procédure associée à la fonction réseau hébergée par l’entité applicative 3 en utilisant un résultat d’analyse reçu par le module 3B de réception. La procédure exécutée dépend bien entendu de la fonction réseau hébergée par l’entité applicative 3. Il peut s’agir par exemple d’une procédure d’enregistrement ou de détermination d’une zone d’enregistrement pour l’entité AMF 3-1, d’une procédure d’ouverture de session ou de sélection d’une fonction UPF du plan utilisateur du réseau cœur CN pour l’entité SMF 3-2, d’une procédure de modification d’une politique ou de détermination d’un débit moyen pour une tranche réseau donnée pour une entité PCF 3-3, d’une procédure d’optimisation d’un réglage pour un UE ou de détection d’une fraude pour une entité AF 3-4, etc. La configuration et le fonctionnement des modules 3A à 3C des entités applicatives 3 sont décrits plus en détail ultérieurement en référence aux étapes du procédé de communication selon l’invention. Nous allons maintenant décrire, en référence aux figures 4 et 5 respectivement, les principales étapes d’un procédé de traitement et d’un procédé de communication selon l’invention, telles que mises en œuvre dans un mode particulier de réalisation par l’entité NWDAF 2 et par l’une des entités applicatives 3 du système 1. On considère plus particulièrement ici, à titre illustratif, l’entité AMF 3-1 ; toutefois, les étapes du procédé de communication sont mises en œuvre de façon similaire ou identique par toute autre entité applicative 3 du système 1. On suppose donc ici que l’entité AMF 3-1 a besoin, pour exécuter l’une des procédures PROC dont elle a la charge dans le réseau cœur CN, d’analyses statistiques et/ou prédictives. Plus particulièrement, dans l’exemple illustratif envisagé ici, on suppose que l’entité AMF 3-1 a besoin d’une prédiction de la mobilité d’un UE donné, par exemple de l’UE 5 représenté sur la , et ce en vue de déterminer une zone d’enregistrement pour cet UE 5 (procédure PROC = détermination de la zone d’enregistrement de l’UE 5). Bien entendu, ces hypothèses ne sont pas limitatives en soi et uniquement formulées à titre illustratif. D’autres procédures peuvent être mises en œuvre par l’entité AMF 3-1 dans le cadre de la fonction réseau implémentée par cette entité, et nécessiter ou s’appuyer sur des analyses statistiques et/ou prédictives de l’entité NWDAF 2, qui peuvent porter par ailleurs sur d’autres types d’analyses qu’une prédiction de mobilité d’un UE, comme par exemple, une prédiction concernant la nature des communications d’un UE, etc.). Ainsi, le document 3GPP TR 23.791 évoqué précédemment évoque différents cas d’usage d’analyses statistiques et/ou prédictives réalisées par une fonction réseau NWDAF dans un réseau 5G. En référence à la , l’entité AMF 3-1, par le biais de son module 3A d’envoi, envoie une requête REQ à l’entité NWDAF 2, et plus particulièrement à son module 2A de réception, demandant une prédiction de la mobilité de l’UE 5 (étape E10). Dans le mode de réalisation décrit ici, le module 3A d’envoi de l’entité AMF 3-1 utilise à cet effet le service Nnwdaf_AnalyticsInfo de l’API de l’entité NWDAF 2, décrit dans les documents 3GPP TS 23.288 intitulé « Architecture Enhancements for 5G system (5GS) to support network data analytics services (Release 17) », v17.4.0, mars 2022, et TS 28.520 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Network Data Analytics Services; Stage 3; (Release 17) », v17.6.0, mars 2022. La requête REQ est ici une requête simple de type Nnwdaf_AnalyticsInfo Request . En variante, elle peut prendre la forme d’une souscription (service Nnwdaf_AnalyticsSubscription et souscription Nnwdaf_AnalyticsSubscription Subscribe) , comme décrit dans les documents 3GPP TS 23.288 et TS 29.520. Il convient d’ailleurs de noter que l’envoi de la requête REQ par le module 3A d’envoi, bien qu’étant lié à une procédure mise en œuvre par l’entité AMF 3-1 (et plus particulièrement exécutée ou destinée à être exécutée par son module 3C d’exécution), n’est pas nécessairement réalisé de façon synchrone avec cette procédure. Il peut être réalisé de façon asynchrone, typiquement en amont de la procédure en question, de façon anticipée, pour pouvoir disposer du résultat de l’analyse pour exécuter sans délai la procédure concernée. Comme défini par le standard 3GPP, le module 3A d’envoi de l’entité AMF 3-1 fournit dans la requête REQ divers paramètres P-DEF définissant l’analyse statistique et/ou prédictive demandée, et notamment : l’identité de l’entité applicative à l’origine de la requête, c’est-à-dire ici l’identité de l’entité AMF 3-1 ; un ou plusieurs paramètres représentatifs du type d’analyse demandé. Ce ou ces paramètres peuvent notamment définir la nature de l’analyse ou de façon équivalente le type de résultat attendu (ex. prédiction de mobilité ici), la quantité de résultats attendue, etc. ; la cible de l’analyse, c’est-à-dire le ou les équipements sur le(s)quel(s) porte l’analyse (ex. l’UE 5 ici) ; un ou plusieurs paramètres représentatifs de conditions de réalisation de l’analyse, par exemple la période de temps visée, la zone géographique visée, la tranche de réseau concernée, etc. ; un niveau de précision attendu pour l’analyse ; un ou plusieurs paramètres représentatifs des modalités de notification du réseau d’analyse (ex. périodicité, souscription, etc.). Bien entendu, cette liste n’est pas exhaustive, et l’homme du métier est invité à se référer aux documents 3GPP TS 23.288 et TS 29.520 précités pour obtenir la liste des paramètres P-DEF obligatoires, et le cas échéant optionnels, qui doivent ou peuvent être inclus par le module 3A d’envoi dans la requête REQ adressée à l’entité NWDAF 2. Conformément à l’invention, le module 3A d’envoi de l’entité AMF 3-1 insère en outre dans la requête REQ, dans un champ dédié et plus particulièrement dans le champ UseCaseContext introduit précédemment, un paramètre P-CTX indiquant le contexte CTX dans lequel est formulée la requête REQ, c’est-à-dire le contexte d’usage du ou des résultats de l’analyse demandée dans la requête REQ. Le paramètre P-CTX identifie ici la procédure PROC que s’apprête à exécuter l’entité AMF 3-1 en utilisant le résultat de la prédiction demandée dans la requête REQ. Ainsi, dans l’exemple illustratif envisagé, le paramètre P-CTX contenu dans le champ UseCaseContext de la requête REQ identifie comme procédure, la détermination de la zone d’enregistrement de l’UE 5. Ainsi, dans le mode de réalisation décrit ici, un nouveau champ UseCaseContent est ajouté dans les messages échangés en utilisant les services Nnwdaf_AnalyticsInfo et Nnwdaf_AnalyticsSubscription. Aucune limitation n’est attachée au format du paramètre P-CTX. Il peut s’agit d’un entier désignant de façon univoque le contexte CTX, d’une chaîne de caractères définissant ce contexte CTX, ou encore d’une liste d’entiers ou de chaînes de caractères, etc. En outre, on peut envisager que le paramètre en question prenne une valeur prédéfinie parmi un ensemble de valeurs prédéfinies, chacune associée de façon univoque à un contexte particulier (ex. 1 = « enregistrement d’un UE par une fonction AMF », 2 = « détermination d’une zone d’enregistrement d’un UE par une fonction AMF », etc.), ou a contrario , qu’il prenne une valeur quelconque dès lors que l’entité NWDAF 2 est capable d’associer cette valeur à un contexte particulier (il ne doit pas y avoir d’ambiguïté pour l’entité NWDAF 2 pour identifier à partir de la valeur en question quel contexte est désigné, autrement dit une même valeur ne doit pas identifier des contextes de formulation différents). L’Annexe 1 fournit, à titre illustratif, une liste non exhaustive établie par les inventeurs, de contextes et d’analyses prédictives ou statistiques associées susceptibles d’être demandées à une fonction NWDAF dans un réseau 5G, et donc incidemment dans le réseau CN. Dans les exemples donnés en Annexe 1, un même contexte CTX peut être associé à des analyses statistiques/prédictives différentes : par exemple, le contexte « Modification par une PCF de politiques RFSP » peut s’appuyer sur des analyses portant sur la charge de tranches du réseau ou sur des analyses portant sur les communications UE et l’expérience de service observée (ou OSE pour « Observed Service Experience » en anglais). Les requêtes correspondantes adressées dans cet exemple par l’entité PCF à l’entité NWDAF comprennent le même paramètre P-CTX désignant le contexte « Modification par une PCF de politiques RFSP », tandis que les paramètres P-DEF fournis dans les requêtes désignent pour l’une des requêtes, une analyse statistique/prédictive portant sur la charge des tranches du réseau, et pour l’autre, des analyses statistiques/prédictives portant sur les communications UE et sur l’OSE. En revanche, il est possible d’associer un contexte différent à la même opération de modification par une PCF de politiques RFSP dès lors qu’elle est réalisée dans un but spécifique, par exemple pour préserver la qualité d’un service de communication véhiculaire dit V2X (pour « Vehicule-to-everything » en anglais). Il convient d’ailleurs de noter que le X dans V2X peut désigner toute sorte d’entités, comme par exemple un autre véhicule, un drone, une infrastructure, un piéton, etc., de sorte qu’un contexte différent peut être associé à chaque X différent envisagé pour le service V2X, le type d’entité X considérée pouvant influer sur le choix du modèle d’analyse. Dans une variante de réalisation, on peut envisager d’inclure dans l’information de contexte les analyses statistiques/prédictives sur lesquelles s’appuie le cas échéant l’opération désignée par le contexte ou plus généralement le cas d’usage de ces analyses. Ainsi, à titre illustratif, dans l’exemple évoqué ci-avant, on peut envisager un premier contexte « Modification par une PCF de politiques RFSP sur la base d’analyse statistique/prédictive de la charge de tranches du réseau » et un deuxième contexte « Modification par une PCF de politiques RFSP sur la base d’analyses statistiques/prédictives de communications UE et d’OSE ». Il convient de noter que cette précision apportée dans le contexte n’implique pas nécessairement un changement du contenu des paramètres P-DEF fournis dans la requête. En effet, dans un souci de limiter l’impact de l’invention sur les messages existants déjà définis par le standard 3GPP (autrement dit de limiter les modifications à apporter à ces messages), on peut envisager de préciser à la fois dans le contexte et dans les paramètres P-DEF, les analyses statistiques/prédictives sur lesquelles s’appuient l’opération mise en œuvre par l’entité applicative à l’origine de la requête et qui sont requises auprès de l’entité NWDAF. On note que la détermination par le module 3A d’envoi de l’entité AMF 3-1 du contexte CTX de formulation de la requête REQ ne pose aucune difficulté en soi puisque celui-ci reflète la procédure PROC en cours d’exécution par l’entité AMF 3-1 (et plus particulièrement par son module 3C de traitement) ou une procédure PROC que cette entité AMF 3-1 s’apprête à exécuter (la requête REQ n’étant pas nécessairement envoyée de façon synchrone par rapport à l’exécution de la procédure en question). En référence à la , sur réception de la requête REQ par son module 2A de réception (étape F10), l’entité NWDAF 2, par l’intermédiaire de son module 2C de traitement, détermine à partir des paramètres P-DEF fournis dans la requête REQ, l’analyse statistique et/ou prédictive qui lui est demandée par l’entité AMF 3-1 (étape F20), à savoir dans l’exemple illustratif envisagé ici, une prédiction de la mobilité de l’UE 5 dans les conditions établies par les paramètres P-DEF. L’entité NWDAF 2, par l’intermédiaire de son module 2B de détermination, détermine également, à partir d’au moins une information véhiculée par la requête REQ, le contexte CTX dans lequel la requête REQ a été formulée (étape F30). Ce contexte CTX de formulation de la requête REQ donne à l’entité NWDAF 2 une indication sur la façon dont va être utilisée la prédiction demandée par l’entité AMF 3-1. A cet effet, dans le mode de réalisation décrit ici, le module 2B de détermination extrait le paramètre P-CTX contenu dans le champ UseCaseContext de la requête REQ qui identifie la procédure PROC sollicitant l’analyse statistique ou prédictive demandée dans la requête REQ. Il convient de noter que dans le mode de réalisation décrit ici, la requête REQ comprend le champ UseCaseContext, et ce champ est alimenté par l’entité AMF 3-1 avec le paramètre P-CTX identifiant le contexte dans lequel est formulée la requête REQ. Ainsi, le module 2B de détermination détermine le contexte CTX à partir du contenu du paramètre P-CTX inclus dans le champ UseCaseContext de la requête REQ. On peut envisager en variante que le champ UseCaseContext soit optionnel, et qu’en l’absence d’un tel champ dans la requête, le module 2B de détermination soit configuré pour déterminer le contexte CTX de formulation de la requête REQ à partir des informations véhiculées par cette dernière, et notamment à partir de tout ou partie des paramètres P-DEF évoqués précédemment, à savoir les paramètres P-DEF fournis par l’entité AMF 3-1 dans la requête REQ représentatifs de son identité, du type d’analyse demandé, de la cible de cette analyse (ex. un UE ou un groupe d’UE, une cellule, etc.), des conditions de réalisation de cette analyse, du niveau de précision attendu, des modalités de notification des résultats de l’analyse, etc. A cet effet, le module 2B de détermination peut s’appuyer sur une technique d’intelligence artificielle (ou IA) supervisée ou non, ou être configuré avec des règles préétablies, définies par exemple par l’opérateur du réseau cœur CN, établissant une correspondance entre les valeurs de tout ou partie des paramètres P-DEF précités véhiculés par la requête REQ et différents contextes de formulation de cette requête REQ. Dans une autre variante encore, on peut envisager un mode hybride dans lequel le module 2B de détermination détermine le contexte à partir du contenu du paramètre P-CTX compris dans le champ UseCaseContext et des autres informations véhiculées par la requête REQ, typiquement les paramètres P-DEF. Ce mode hybride permet d’obtenir un contexte plus précis (et une granularité plus fine dans le choix du modèle d’analyse). Par exemple, certains groupes de paramètres P-DEF fournis dans la requête REQ et les valeurs associées à ces groupes de paramètres peuvent être utilisés pour définir des signatures représentatives de contextes distincts. On peut alors envisager, selon une variante de réalisation, que l’entité NWDAF 2, et plus particulièrement son module 2B de détermination, soit configurée avec un certain nombre de signatures auxquelles sont associées des contextes, et que sur réception de la requête REQ, le module 2B de détermination détermine à partir des paramètres P-DEF fournis dans la requête REQ, s’ils correspondent à l’une des signatures avec lesquelles il a été configuré. Le cas échéant, le contexte de formulation de la requête déterminé par le module 2B de détermination est celui qui est associée à la signature. La configuration de l’entité NWDAF 2 peut être réalisée notamment par l’opérateur du réseau CN au moyen de signatures déterminées par celui-ci, par exemple lors d’une phase de configuration telle que classiquement mise en œuvre lors de l’introduction de nouveaux équipements ou services dans un réseau. Selon une autre variante de réalisation, le module 2B de détermination de l’entité NWDAF 2 peut mettre en œuvre une phase d’apprentissage au cours de laquelle il analyse les paramètres P-DEF présents dans un ensemble de requêtes REQ précédemment reçues par l’entité NWDAF 2, et détermine, par exemple au moyen d’un algorithme de classification, quels groupes de paramètres et valeurs associées sont significatifs et représentatifs d’un contexte particulier. Les différents groupes de paramètres et valeurs associées ainsi obtenus définissent un ensemble de signatures correspondant à des contextes de formulation distincts. Il convient de noter que dans cette variante de réalisation, le module 2B de détermination est en mesure de faire le distinguo entre des contextes de formulation distincts, et d’associer un contexte de formulation donné à une requête ; toutefois, il ne dispose pas nécessairement des informations nécessaires pour associer à ce contexte de formulation, une opération spécifique exécutée ou destinée à être exécutée par l’entité applicative à l’origine de la requête REQ (ex. détermination d’une zone d’enregistrement). A titre illustratif, supposons que les paramètres P-DEF comprennent trois paramètres X, Y, Z, et que le module 2B de détermination détermine pendant la phase d’apprentissage que : - si X=0 et Y=1, quelle que soit la valeur du paramètre Z, on est toujours dans un contexte auquel le module 2B de détermination associe une étiquette CTX1 ; et - si X=1 et Y=1, quelle que soit la valeur du paramètre Z, on est toujours dans un autre contexte auquel le module 2B de détermination attribue l’étiquette CTX2. Sur réception d’une nouvelle requête REQ, le module 2B de détermination est capable à partir de ces signatures, de déterminer si le contexte de formulation de la nouvelle requête REQ est le contexte CTX1 ou le contexte CTX2, mais en l’absence d’informations supplémentaires, il n’est pas capable d’identifier la procédure associée au contexte ainsi déterminé, c’est-à-dire par exemple, que CTX1 identifie une procédure de détermination d’une zone d’enregistrement et CTX2 identifie une procédure d’optimisation d’un paging. Pour remédier à cela, dans une autre variante encore, on peut envisager que le module 2B de détermination soit configuré, par exemple par l’opérateur du réseau CN, avec des règles de mise en correspondance des étiquettes déterminées lors de la phase d’apprentissage par le module 2B de détermination et des procédures susceptibles d’être mises en œuvre par les entités applicatives correspondant à ces étiquettes. Autrement dit, dans l’exemple illustratif envisagé ci-avant, le module 2B de détermination est configuré avec les associations suivantes : CTX1 = Détermination d’une zone d’enregistrement d’un UE CTX2 = Optimisation d’un paging Quelle que soit la variante retenue, il convient de noter que le groupe de signatures sur lesquelles s’appuie le module 2B de détermination peut être amené à évoluer dans le temps ; notamment, il peut être complété avec de nouvelles signatures, ou celles-ci peuvent être modifiées lorsque de nouvelles phases d’apprentissage sont réalisées. Conformément à l’invention, l’entité NWDAF 2 exploite (i.e. utilise) le contexte CTX de formulation de la requête REQ pour sélectionner un modèle d’analyse pertinent pour réaliser l’analyse demandée par l’entité AMF 3-1, et plus particulièrement ici, une prédiction de la mobilité de l’UE 5 (étape F40). En effet, de façon connue en soi, pour réaliser les analyses statistiques et/ou prédictives qui lui sont demandées, une fonction réseau NWDAF (et a fortiori l’entité NWDAF 2 et son module 2C de traitement) a à sa disposition une pluralité de techniques d’analyse qu’elle peut utiliser en fonction de la nature des analyses qui lui sont demandées. Par exemple, pour une analyse statistique portant sur des comportements passés, des modèles classiquement utilisés par une fonction réseau NWDAF sont notamment : un modèle réalisant une moyenne mobile sur tout ou partie des données collectées par la fonction réseau NWDAF ; un modèle réalisant une moyenne exponentielle mobile sur tout ou partie des données collectées par la fonction réseau NWDAF ; etc. Pour une analyse prédictive portant sur des comportements à venir, les modèles de prédiction classiquement utilisés par une fonction réseau NWDAF s’appuient notamment sur des techniques de modélisation de séries temporelles utilisant des techniques d’apprentissage automatique (ou « Machine Learning » en anglais), supervisé ou non supervisé, pouvant exploiter des algorithmes très variés, tels que des chaînes de Markov, des réseaux de neurones (ex. réseaux de neurones de type LSTM pour « Long Short Term Memory » en anglais), un lissage exponentiel (ou « exponential smoothing » en anglais), des modèles de type ARCH (pour « AutoRegressive Conditional Heteroskedasticity » en anglais), ou de type ARMA ou ARIMA qui combinent processus autorégressif (AR pour « AutoRegressive » en anglais), moyenne mobile (MA pour « Moving Average » en anglais) et éventuellement intégration (I pour « Integrated » en anglais), etc. En outre, chacune des techniques d’analyse précitées peut être paramétrée de façon différente, ou s’appuyer sur des jeux de données ayant des caractéristiques distinctes (outre la nature des données collectées, telles que la quantité de données, etc.) pour l’analyse ou pour l’entraînement de ladite technique d’analyse, ce qui conduit à autant de modèles distincts pouvant être sélectionnés par le l’entité NWDAF 2. Le contexte CTX fournit à cette dernière un guide qui lui permet de faire une sélection éclairée et pertinente du modèle d’analyse à appliquer pour répondre à la requête de l’entité AMF 3-1, et plus particulièrement d’au moins un élément parmi : une technique d’analyse statistique ou prédictive à utiliser pour réaliser l’analyse parmi une pluralité de techniques prédéfinies, comme par exemple, un modèle ARIMA, un modèle ARCH, un lissage exponentiel, une moyenne mobile, etc. La sélection peut être opérée par exemple parmi différentes familles de modèles connus tels que ceux précités ou des combinaisons de tels modèles ; et/ou au moins une caractéristique (ex. une quantité de données) d’un jeu de données à utiliser pour réaliser l’analyse et/ou entraîner une technique d’analyse utilisée pour réaliser l’analyse ; et/ou un paramétrage (ex. dans un réseau de neurones, nombre de couches, de neurones par couches, poids synaptiques, etc.) d’une technique d’analyse utilisée pour réaliser l’analyse. Il convient de noter qu’un tel paramétrage ne se limite pas à la prise en compte des paramètres d’entrée fournis par l’entité AMF 3-1 à l’origine de la requête REQ. Dans le mode de réalisation décrit ici, la sélection d’un modèle d’analyse par le module 2C de traitement en fonction du contexte CTX déterminé par le module 2B de détermination est permise via une (pré)configuration préalable de l’entité NWDAF 2. Plus spécifiquement, on suppose que lors d’une étape préliminaire de configuration (étape F00), l’entité NWDAF 2 a été configurée, par exemple par l’opérateur du réseau NW via une interface appropriée ou l’utilisation d’un protocole de configuration approprié, avec une liste LIST de modèles d’analyse statistique et prédictive, dans laquelle chaque modèle d’analyse est associé à au moins un contexte de formulation d’une requête. Cette liste LIST est mémorisée par exemple dans la mémoire non volatile NVM de l’entité NWDAF 2. Il convient de noter qu’un contexte de formulation peut être associé à plusieurs modèles d’analyse ou à une famille de modèles d’analyse. A titre illustratif, pour les contextes de définition d’une zone d’enregistrement d’un UE et d’optimisation du paging évoqués précédemment, on peut envisager dans la liste LIST les associations suivantes : Contexte CTX Modèle(s) d’analyse MOD(CTX) Détermination de la zone d’enregistrement d’un UE Réseau de neurones de type LSTM Optimisation du paging Chaîne de Markov Bien entendu, cet exemple n’est donné qu’à titre illustratif et n’est pas limitatif de l’invention, d’autres contextes, modèles d’analyse et associations pouvant être envisagés en variante ou en complément. Ainsi, lors de l’étape de sélection F40, le module 2C de traitement de l’entité NWDAF 2 consulte la liste LIST préconfigurée lors de l’étape F00, et sélectionne un modèle d’analyse MOD(CTX) dans la liste LIST, associé au contexte CTX. Si plusieurs modèles d’analyse sont possibles, le module 2C de traitement en choisit un, par exemple en tenant compte de critères comme le temps de calcul ou la puissance de calcul nécessaire au regard de tout ou partie des paramètres P-DEF fournis dans la requête REQ (par exemple, du niveau de précision et/ou du délai de fourniture des résultats d’analyse). Il convient de noter que la liste LIST stockée dans la mémoire non volatile NVM de l’entité NWDAF 2 n’est pas nécessairement figée, et peut être amenée à évoluer au cours du temps (étape F00’). Ainsi, la liste LIST peut être mise à jour et/ou complétée pour refléter cette évolution de façon similaire ou identique à ce qui a été décrit précédemment pour l’étape F00. En variante, elle peut être mise à jour par l’entité NWDAF 2 elle-même, par exemple par son module 2C de traitement, lors d’une phase d’apprentissage ou d’entraînement, au cours de laquelle le module 2C de traitement peut être amené à réviser les associations comprises dans la liste LIST entre modèles d’analyse et contextes de formulations, et/ou créer de nouvelles associations portant sur de nouveaux modèles d’analyse et/ou de nouveaux contextes de formulation. Ces nouveaux modèles d’analyse et/ou contextes de formulation peuvent être communiqués à l’entité NWDAF 2 par l’opérateur du réseau ou par un autre acteur, par exemple le concepteur de l’entité NWDAF 2, ou être déterminés également par apprentissage. Cette phase d’apprentissage peut s’appuyer comme données d’apprentissage sur les analyses précédemment réalisées par le module 2C de traitement. Elle peut également ou en variante exploiter des données d’apprentissage fournies par un tiers, comme par exemple par l’opérateur du réseau, par le concepteur de l’entité NWDAF 2, etc. Plus particulièrement, pour tout ou partie des analyses réalisées par le module 2C de traitement, celui-ci peut évaluer la qualité des résultats obtenus à l’aide d’indicateurs de qualité déterminés. A cet effet, le module 2C de traitement peut par exemple, suite à l’obtention d’un résultat d’analyse tel qu’une prédiction, continuer à collecter des données et vérifier que la prédiction obtenue est correcte, ou réévaluer à partir de ces nouvelles données une nouvelle prédiction et comparer la prédiction réévaluée avec la prédiction initiale. Bien entendu, d’autres techniques peuvent être envisagées pour évaluer la qualité des résultats obtenus par le module 2C de traitement. Lors de la phase d’apprentissage, le module 2C de traitement corrèle les modèles d’analyse statistique dont il dispose, les différentes valeurs possibles de contextes de formulation, et les indicateurs de qualité des analyses réalisées à partir de ces modèles d’analyse pour ces contextes de formulation. Puis il sélectionne, pour un contexte de formulation donné, le ou les modèles d’analyse conduisant aux meilleurs indicateurs de qualité. Il met alors à jour la liste LIST avec les (nouvelles) associations contexte – modèle(s) d’analyse ainsi obtenues le cas échéant (autrement dit, il met à jour/corrige certaines associations de la liste LIST et/ou complète la liste LIST avec de nouvelles associations obtenues lors de la phase d’apprentissage). Il convient de noter que le module 2C de traitement peut exécuter plusieurs phases d’apprentissage à différents instants en fonction des données d’apprentissage dont il dispose ; ainsi notamment, il peut lors d’une phase d’apprentissage, cibler les données d’apprentissage qu’il utilise en ne retenant que les données d’apprentissage associées à un contexte de formulation particulier, pour déterminer le(s) modèle(s) d’analyse le(s) plus pertinent(s) pour ce contexte, et faire évoluer ce contexte de formulation d’une phase d’apprentissage à une autre. Dans un autre mode de réalisation, aucune préconfiguration de l’entité NWDAF 2 n’est mise en œuvre, et c’est l’entité NWDAF 2 via son module 2C de traitement qui établit elle-même la liste LIST et la met à jour au fil du temps au cours d’au moins une phase d’apprentissage (ou d’entraînement) identique ou similaire à ce qui vient d’être décrit. Cette phrase d’apprentissage peut être supervisée ou non (c’est-à-dire s’appuyer sur des données d’apprentissage fournies par l’opérateur du réseau et/ou le concepteur de l’entité NWDAF 2 ou uniquement sur des données d’apprentissages collectées par l’entité NWDAF 2). En parallèle de cette sélection, ou indifféremment avant ou après cette sélection, le module 2C de traitement collecte les données de réseau INPUT_DATA nécessaires pour réaliser l’analyse statistique et/ou prédictive qui lui a été demandée. Cette collecte peut être réalisée auprès de différentes entités, en fonction du type d’analyse requis, en utilisant les procédures décrites notamment dans le document 3GPP TS 23.288 au paragraphe 6.7.2.4. Une fois les données INPUT_DATA collectées, le module 2C de traitement réalise l’analyse statistique et/ou prédictive (prédiction de mobilité de l’UE 5 dans l’exemple envisagé ici) qui lui a été demandée par l’entité AMF 3.1 en appliquant le modèle d’analyse MOD(CTX) aux données INPUT_DATA collectées (étape F50). Il convient de noter que par souci de simplification, on a considéré ici la fonction du module 2C de traitement dans son ensemble, sans préjuger la façon dont le module 2C de traitement est organisé à proprement parler pour assurer cette fonction. Conformément aux Releases 17 et suivantes du standard 3GPP, l’entité NWDAF dans un réseau cœur 5G peut être décomposée en deux fonctions ou modules, un module MLTF (pour « Model Training Logical Function » en anglais) chargé d’entraîner et de fournir les modèles d’analyse et un module AnLF (pour « Analytics Logical Function » en anglais) chargé de produire les analyses en utilisant les modèles fournis par le module MLTF. Les modèles d’analyse sont obtenus par le module AnLF en utilisant des services Nnwdaf_MLModelProvision et Nnwdaf_MLModelInfo définis par le standard 3GPP. Si une telle organisation est envisagée pour l’entité NWDAF 2, alors on peut ajouter aux services Nnwdaf_MLModelProvision et Nnwdaf_MLModelInfo un nouveau champ UseCaseContent, comme cela a été fait précédemment pour les services Nnwdaf_AnalyticsInfo et Nnwdaf_AnalyticsSubscription, afin que le module AnLF puisse préciser au module MLTF le contexte CTX de formulation de la requête REQ et que le module MLTF sélectionne le modèle d’analyse à appliquer en fonction de ce contexte CTX de formulaiton. Dans une variante de réalisation, le module AnLF sélectionne lui-même le modèle d’analyse à utiliser en fonction du contexte CTX puis demande le modèle sélectionné au module MTLF. Puis l’entité NWDAF 2 fournit, par le biais de son module 2D de fourniture, le résultat RES d’analyse obtenu par le module 2C de traitement (prédiction de la mobilité de l’UE 5 dans l’exemple envisagé ici) à l’entité AMF 3-1 en réponse à sa requête REQ (étape F60). Sur réception de la réponse de l’entité NWDAF 2 contenant le résultat d’analyse RES par le module 3B de réception de l’entité AMF-1 (étape E20), le module 2C d’exécution de l’entité AMF 3-1 exécute la procédure PROC dans le cadre de laquelle il a sollicité l’entité NWDAF 2 en utilisant le résultat d’analyse RES fourni par l’entité NWDAF 2 (étape E30). Ainsi, dans l’exemple illustratif envisagé ici, le module 3C d’exécution détermine la zone d’enregistrement de l’UE 5 en utilisant la prédiction de mobilité de l’UE 5 fournie par l’entité NWDAF 2, de façon connue en soi. L’invention vient d’être décrite dans le contexte d’un réseau cœur 5G, et notamment d’une fonction NWDAF d’un tel réseau, en s’appuyant avantageusement sur les API définies par le standard 3GPP, modifiées pour les besoins de l’invention. L’invention peut toutefois s’appliquer dans d’autres contextes, et notamment à d’autres réseaux, par exemple à des réseaux propriétaires, des réseaux de futures générations ou correspondant à d’autres versions (ou « Releases » en anglais) d’un réseau 5G, des réseaux IP, etc., à d’autres entités applicatives, comme par exemple à des routeurs, des contrôleurs SDN, etc. qui peuvent être sollicités par diverses entités applicatives du réseau en vue de délivrer des analyses statistiques et/ou prédictives, et exploiter d’autres interfaces que des API (ex. des interfaces point-à-point) pour mettre en œuvre l’invention. Annexe 1 Contexte CTX Type(s) d’analyse(s) statistique(s) ou predictive(s) requise(s) Sélection d’une SMF par une AMF ou un SCP (« Service Communication Proxy » en anglais) Charge de SMF Sélection et resélection d’une UPF par une SMF Charge d’UPF Sélection/modification par une AMF ou NSSF (pour « Network Slide Selection Function » en anglais) d’une tranche de réseau Charge de tranches de réseau Modification par une PCF de politiques RFSP (pour « RAT/Frequency Selection Priority » en anglais) Charge de tranches de réseau Mise à jour par une PCF d’une QoS autorisée Expérience de service observée Modification par une PCF de politiques BDT (pour « Background Data Transfer » en anglais) Performance du réseau Amélioration de la sélection d’un chemin du plan utilisateur par une PCF Expérience de service observée Détermination par une PCF d’un débit de données moyen par tranche de réseau Dispersion de données Mise à jour de politiques WLAN par une PCF Performance WLAN Modification d’une politique de gestion de session par une PCF Congestion de données utilisateur Décision d’une SMF d’une retransmission redondante Expérience de transmission redondante Prévention par une SMF d’une congestion de DNN (pour « Data Network Name » en anglais) ou de S-NSSAI Effet de l'application d'un mécanisme de prévention de la congestion dans la gestion des sessions. Mise à jour de politiques par une PCF pour préserver la qualité d’un service de communication véhiculaire dit V2X (pour « Vehicule-to-everything » en anglais) Durabilité de qualité de service (ou QoS pour « Quality of Service » en anglais) Décision d’une AMF sur le mode MICO (pour « Mobile Initiated Connection Only » en anglais) Mobilité UE, Communications UE Mise à jour par une AMF d’un motif de mobilité Mobilité UE Décision d’une AMF relative au paging Mobilité UE Dérivation par une AF d’un comportement UE attendu Mobilité UE, Communications UE Gestion par une PCF des restrictions de zones de service Comportements anormaux Décision d’une SMF relative à un temporisateur d’inactivité (ou « Inactivity Timer » en anglais) Communications UE Décision d’une SMF relative à la libération d’une UPF d’un point de terminaison N3 Mobilité UE Modification par une PCF de politiques RFSP Communications UE et Expérience de service observée Modification de politiques de gestion d’accès et/ou de gestion de sessions par une PCF Congestion de données Utilisateur et Dispersion de données Décision de gestion de session par une SMF sur la base d’analyses OSE et DN Expérience de Service observée, performance de réseau de données (ou DN pour « Data Network » en anglais) Fourniture d'analyses statistiques ou prédictives par une NEF (pour « Network Exposure Function » en anglais) à une entité externe Tout type d’analyses, congestion de données utilisateur Sélection d’une UPF par une SMF Charge d’UPF Expérience de service observée Performance DN Mobilité UE Communications UE Sélection/modification par une AMF/NSSF d’une tranche de réseau Charge de tranches de réseau Dispersion Mobilité UE … … Procédé de traitement d’une requête (REQ) d’analyse statistique ou prédictive reçue par une première entité applicative (2) d’un réseau (CN) de communications en provenance d’une deuxième entité applicative (3-1) du réseau, ledit procédé comprenant : une étape (F30) de détermination, à partir d’au moins une information véhiculée (P-CTX, P-DEF) par ladite requête, d’un contexte (CTX) de formulation de ladite requête par ladite deuxième entité applicative ; une étape (F50) de réalisation de ladite analyse statistique ou prédictive requise au moyen d’un modèle (MOD(CTX)) d’analyse sélectionné (F40) en fonction dudit contexte déterminé ; et une étape (F60) de fourniture d’au moins un résultat (RES) de l’analyse réalisée en réponse à ladite requête de la deuxième entité applicative. Procédé de traitement selon la revendication 1 dans lequel ledit contexte de formulation est indiqué par un paramètre (P-CTX) inséré par la deuxième entité applicative dans un champ dédié de la requête. Procédé de traitement selon la revendication 1 ou 2 dans lequel ledit contexte de formulation est déterminé par la première entité applicative à partir d’une pluralité de paramètres (P-DEF) définissant l’analyse requise par la deuxième entité applicative et fournis dans la requête. Procédé de traitement selon la revendication 3 dans lequel ladite pluralité de paramètres sont pris parmi : une identité de la deuxième entité applicative ; un paramètre représentatif d’un type d’analyse requis ; au moins un équipement sur lequel porte ladite analyse ; un paramètre représentatif d’une condition de réalisation de ladite analyse ; un niveau de précision attendu pour ladite analyse ; un paramètre représentatif d’une modalité de notification dudit au moins un résultat de l’analyse. Procédé de traitement selon l’une quelconque des revendications 1 à 4 dans lequel ledit contexte (CTX) de formulation identifie une procédure (PROC) destinée à être exécutée par la deuxième entité applicative dans le réseau en utilisant le résultat fourni par la première entité applicative. Procédé de traitement selon l’une quelconque des revendications 1 à 5 dans lequel la sélection (F40) du modèle d’analyse comprend une sélection d’au moins un élément parmi : une technique d’analyse statistique ou prédictive à utiliser pour réaliser l’analyse ; au moins une caractéristique d’un jeu de données à utiliser pour réaliser l’analyse et/ou entraîner une technique d’analyse utilisée pour réaliser l’analyse ; un paramétrage d’une technique d’analyse utilisée pour réaliser l’analyse. Procédé de traitement selon l’une quelconque des revendications 1 à 6 comprenant une étape préliminaire (F00) de configuration de la première entité applicative avec une liste (LIST) de modèles d’analyse dans laquelle chaque modèle d’analyse est associé à au moins un contexte de formulation d’une requête, ledit modèle d’analyse appliqué lors de l’étape de réalisation étant un modèle d’analyse associé dans ladite liste au contexte déterminé lors de l’étape d’obtention. Procédé de traitement selon l’une quelconque des revendications 1 à 6 comprenant une étape d’apprentissage au cours de laquelle la première entité applicative : établit des corrélations entre des modèles d’analyse, des contextes de formulation d’une requête, et des indicateurs de qualité des analyses réalisées à partir desdits modèles dans lesdits contextes ; et associe, à partir desdites corrélations établies, à au moins un contexte de formulation d’une requête un modèle d’analyse optimisant ladite qualité, ledit modèle d’analyse appliqué lors de l’étape de réalisation étant sélectionné à partir des associations établies lors de l’étape d’apprentissage. Procédé de traitement selon l’une quelconque des revendications 1 à 6 comprenant : une étape (F00) préliminaire (LIST) de configuration de la première entité applicative avec une liste comprenant au moins un modèle d’analyse associé à au moins un contexte de formulation d’une requête ; une étape (F00’) d’apprentissage au cours de laquelle la première entité applicative : établit des corrélations entre des modèles d’analyse, des contextes de formulation d’une requête, et des indicateurs de qualité des analyses statistiques réalisées à partir desdits modèles dans lesdits contextes ; et met à jour et/ou complète ladite liste à partir desdites corrélations établies ; le modèle d’analyse appliqué lors de l’étape de réalisation étant un modèle d’analyse associé au contexte déterminé lors de l’étape d’obtention dans la liste mise à jour ou complétée lors de l’étape d’apprentissage. Procédé de traitement selon l’une quelconque des revendications 1 à 9 dans lequel la première entité applicative (2) et la deuxième entité applicative (3-1) hébergent des fonctions réseau, ladite fonction réseau hébergée par la première entité applicative étant une fonction de collecte et d’analyse de données du réseau. Procédé de communication avec une première entité applicative (2) d’un réseau de communications, ledit procédé de communication étant mis en œuvre par une deuxième entité applicative (3-1) du réseau et comprenant : une étape (E10) d’envoi à ladite première entité applicative d’une requête d’analyse statistique ou prédictive comprenant, dans un champ dédié de la requête, un paramètre indiquant un contexte de formulation de ladite requête ; une étape (E20) de réception, en réponse à ladite requête, d’au moins un résultat de l’analyse requise réalisée par la première entité applicative au moyen d’un modèle d’analyse sélectionné en fonction dudit contexte. Programme d’ordinateur (PROG) comportant des instructions pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 11 lorsque ledit programme est exécuté par un ordinateur. Entité applicative (2) d’un réseau de communications, dite première entité applicative, comprenant : un module (2A) de réception configuré pour recevoir d’une deuxième entité applicative du réseau, une requête d’analyse statistique ou prédictive ; un module (2C) de traitement, configuré pour réaliser ladite analyse au moyen d’un modèle d’analyse sélectionné en fonction d’un contexte de formulation de ladite requête par ladite deuxième entité applicative, déterminé à partir d’au moins une information véhiculée par ladite requête ; et un module (2D) de fourniture, configuré pour fournir au moins un résultat de l’analyse réalisée en réponse à ladite requête de la deuxième entité applicative. Entité applicative (3) d’un réseau de communications, dite deuxième entité applicative, comprenant : un module (3A) d’envoi, configuré pour envoyer à une première entité applicative du réseau une requête d’analyse statistique ou prédictive comprenant, dans un champ dédié de la requête, un paramètre indiquant un contexte de formulation de ladite requête ; un module (3B) de réception, configuré pour recevoir en réponse à ladite requête, au moins un résultat de l’analyse requise réalisée par la première entité applicative au moyen d’un modèle d’analyse sélectionné en fonction dudit contexte. Système (1) dans un réseau de communications comprenant : au moins une première entité applicative (2) selon la revendication 13 ; et au moins une deuxième entité applicative (3,3-1) selon la revendication 14.