FR3113220A1 - Procédé de fourniture de données relatives à au moins un équipement d’un utilisateur d’un réseau, procédé d’obtention de données, et entités mettant en œuvre ces procédés - Google Patents

Abstract

Procédé de fourniture de données relatives à au moins un équipement d’un utilisateur d’un réseau, procédé d’obtention de données, et entités mettant en œuvre ces procédés L’invention vise un procédé de fourniture de données relatives à au moins un équipement d’utilisateur à une entité (DAF) d’analyse de données, comprenant : une étape de collecte, pour une pluralité d’événements ayant impacté au moins un état de l’équipement d’utilisateur dans le réseau, de données relatives audit au moins un état impacté ; et une étape de fourniture, à l’entité (DAF) d’analyse, pour au moins un dit état de l’équipement d’utilisateur, d’au moins une statistique obtenue pour cet état en agrégeant des données relatives à cet état collectées lors de l’étape de collecte et d’une partie desdites données correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements les plus récents de ladite pluralité d’événements. Fig. 1

Description

Procédé de fourniture de données relatives à au moins un équipement d’un utilisateur d’un réseau, procédé d’obtention de données, et entités mettant en œuvre ces procédés

L’invention appartient au domaine général des télécommunications.

Les réseaux de télécommunication modernes, tels que par exemple les réseaux de cinquième génération ou réseaux 5G définis par le standard 3GPP, sont confrontés à des situations complexes, qui sont la conséquence notamment d’un très grand nombre de terminaux à gérer, de la variété des usages faits du réseau (et des exigences en termes de latence, de débit, de volumétrie en découlant), ainsi que de la variété des comportements des utilisateurs du réseau dans le temps et dans l’espace.

Pour faire face à ces situations complexes, les opérateurs envisagent de mettre en place au sein de leurs réseaux une ou plusieurs entités spécialisées permettant d’opérer des analyses statistiques et des prédictions (aussi désignées de façon générale par « analytics » en anglais dans les documents 3GPP) sur la demande et la réponse apportées par le réseau en terme de qualité de service. Ces prédictions 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. Des exemples de prédictions globales sont un taux de charge des ressources du réseau, la qualité de service moyenne, le nombre d’utilisateurs connectés au réseau via leurs équipements d’utilisateurs (ou plus simplement ci-après UE pour « User Equipment » en anglais) ou de sessions actives. Des prédictions individuelles, c’est-à-dire portant sur un utilisateur ou sur un groupe d’utilisateurs peuvent également être établies, comme par exemple la future localisation de l’UE de l’utilisateur ou la volumétrie d’une future session de communication de l’utilisateur établie via son UE. De telles entités sont également appelées « fonctions d’analyse de données du réseau » (ou DAF pour « Data Analytics Functions » en anglais). A titre illustratif, dans un cœur de réseau mobile 5G, la fonction « Network Data Analytics Functions » ou NWDAF assure un tel rôle.

La réalisation de telles prédictions par une fonction DAF suppose la collecte préalable de données représentatives de faits réseau (ex. état connecté de l’UE, cellule dans laquelle il se trouve, etc., que l’on désigne par « données brutes » dans la suite) auprès de différentes entités composant le réseau, aussi communément désignées par « fonctions de réseau » (ou NF pour « Network Functions » en anglais). Ces données brutes peuvent être globales à chaque fonction NF, ou bien concerner chaque utilisateur. Une fois établies, les prédictions permettent de mettre en œuvre de façon anticipée des modifications correctives sur les paramètres du réseau afin d’optimiser son fonctionnement. Les entités utilisatrices de ces prédictions sont typiquement des fonctions NF, clientes de la fonction DAF, qui peuvent être distinctes ou non des fonctions NF ayant collecté et fourni les données brutes à la fonction DAF. Ces fonctions NF clientes sont alors en mesure d’adapter leur comportement en fonction des prédictions reçues de la fonction DAF en vue d’optimiser le fonctionnement du réseau et la qualité du service délivré à chaque utilisateur sur son UE. 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, décrit différents cas d’utilisations de telles prédictions dans un réseau 5G.

Le volume de données brutes globales à collecter par la fonction DAF auprès de chaque fonction NF (par exemple le niveau de charge de la fonction NF, son état de fonctionnement, etc.) peut être assez substantiel, mais le nombre de fonctions NF sollicitées par la fonction DAF est en pratique assez réduit, ce qui permet de limiter la complexité engendrée par la collecte de ces données brutes globales.

La situation est toutefois différente concernant les données brutes individuelles relatives aux utilisateurs ou aux groupes d’utilisateurs, comme par exemple leurs localisations ou activités, les variations des états respectifs de leurs UEs (enregistré, connecté, connecté en veille, etc.). La collecte de ces données brutes individuelles en vue d’établir des prédictions pour chaque utilisateur du réseau considéré nécessite de remonter à la fonction DAF tous les événements réseau relatifs à l’UE de cet utilisateur, la quantité de données brutes à remonter pouvant différer d’un événement à un autre. En raison du nombre élevé d’utilisateurs du réseau qu’est amenée à surveiller une fonction DAF, le volume de données brutes individuelles à collecter par la fonction DAF peut donc s’avérer extrêmement important, induisant non seulement une signalisation considérable échangée entre les fonctions NF remontant ces données brutes individuelles et la fonction DAF, mais également une charge de calcul substantielle pour la fonction DAF.

En outre, même si un utilisateur n’est pas directement visé à un instant donné par une analyse statistique ou une prédiction requise par une fonction NF cliente auprès de la fonction DAF, la fonction DAF se doit de collecter de façon continue des informations sur les événements réseau relatifs à l’UE de cet utilisateur pour être en mesure de réaliser une telle analyse statistique ou une telle prédiction lorsque la demande se présentera le cas échéant.

Il existe donc un besoin de réduire le volume des données brutes à collecter (et incidemment à traiter) par la fonction DAF auprès des différentes fonctions NF.

En réponse à ce besoin, il a été proposé au niveau du standard 3GPP, dans le document S2-186464 intitulé « Solution to Key Issues 9 », Ericsson, 2-6 juillet 2018, d’intégrer dans une fonction NF une fonction DAF locale afin de pouvoir effectuer directement sur la fonction NF des calculs de prédictions. Les prédictions ainsi réalisées localement par la fonction NF peuvent être soit exploitées directement par celle-ci, soit remontées à une fonction DAF centrale pour être utilisées pour des prédictions plus complexes. La fonction DAF centrale peut également souscrire à la remontée des informations brutes collectées par la fonction NF.

Dans la solution proposée dans le document S2-186464, une réduction de la volumétrie des informations échangées entre la fonction NW et la fonction DAF n’est permise que si la fonction DAF exploite les prédictions réalisées par la fonction NF. Il en résulte une perte potentielle d’informations, qui peut nuire aux analyses statistiques et prédictions effectuées par la fonction DAF, celle-ci étant contrainte par les prédictions réalisées par la fonction NF.

Des solutions alternatives à celle proposée dans le document S2-186464 peuvent être envisagées pour réduire la signalisation échangée entre la fonction DAF et les fonctions NF du réseau.

Ainsi une solution peut consister à collecter de façon continue des données brutes individuelles uniquement pour un échantillon d’utilisateurs considéré comme représentatif de l'ensemble des utilisateurs. Cette représentativité ne peut toutefois être établie que par comparaison avec le comportement réel des utilisateurs que l’on cible. La mise en œuvre de cette solution nécessite donc le recours à une technique permettant de classera priorile comportement de chaque utilisateur avant d’être en mesure d’appliquer un modèle de représentativité pertinent. L’exploitation de cette solution peut s’avérer compliquée dans certaines situations, notamment pour des utilisateurs très mobiles, très bavards ou encore sporadiques, pour des véhicules ou des drones.

Une autre solution peut consister à réaliser une journalisation continue ou par lots (ou « batchs » en anglais) des données brutes collectées par les fonctions NF dans un entrepôt de données (aussi désigné par « lac de données ») déjà présent dans le réseau, tel que par exemple un lac de données contenant des tickets de comptage (ou encore CDR pour « Charging Data Records » en anglais) reflétant les statistiques des appels et sessions de données établis sur le réseau. On obtient de cette sorte un historique des données brutes collectées par les fonctions NF sur les utilisateurs qu’elles gèrent.

Le recours à un tel entrepôt de données permet de limiter la signalisation échangée entre les fonctions NF et la fonction DAF. Lorsqu’une demande de statistiques et/ou de prédictions sur un utilisateur arrive au niveau de la fonction DAF, cette dernière peut inspecter l’entrepôt de données ainsi alimenté par les fonctions NF pour effectuer un ajustement des statistiques et des prédictions qu’elle maintient sur cet utilisateur. La fonction DAF peut également être amenée à consulter l’entrepôt de données à divers moments appropriés pour déterminer le comportement habituel d’un utilisateur.

Si cette solution s’appuie sur un lac de données déjà existant tel que le lac de données des tickets de comptage précédemment évoqué, ce lac de données peut ne contenir qu’une partie des données brutes requises pour optimiser le fonctionnement du réseau. En outre, le problème de la volumétrie des données brutes échangées subsiste entre l’entrepôt de données et les fonctions NF.

Une autre solution consiste à introduire dans le réseau une entité spécialisée de médiation proche des fonctions NF. Cette entité spécialisée de médiation est configurée pour collecter les données brutes auprès des fonctions NF et les distribuer aux fonctions DAF qui en ont besoin. Cette solution présente l’inconvénient d’introduire de nouvelles entités fonctionnelles dans le réseau et donc de requérir de nouveaux échanges de signalisation. Elle peut avoir des impacts de déploiement importants en termes notamment de complexité, de charge de calcul, ou encore de gestion opérationnelle.

On note que les considérations précédentes, bien qu’introduites en référence aux réseaux 5G définis par le standard 3GPP, et à des entités NF et NWDAF, s’appliquent à tout type de réseau de télécommunication dans lequel les opérateurs cherchent à collecter auprès de diverses fonctions du réseau des données et opérer des prédictions à partir de ces données afin d’améliorer le fonctionnement du réseau.

L’invention remédie notamment aux inconvénients précités de l’état de la technique en proposant un procédé de fourniture de données relatives à au moins un équipement d’utilisateur à une entité d’un réseau, dite d’analyse de données, ce procédé comprenant :

• une étape de collecte, pour une pluralité d’événements ayant impacté au moins un état dudit équipement d’utilisateur dans le réseau, de données relatives audit au moins un état impacté par lesdits événements ; et
• une étape de fourniture, à ladite entité d’analyse, pour au moins un dit état impacté dudit équipement d’utilisateur, d’au moins une statistique obtenue pour cet état en agrégeant des données relatives à cet état collectées lors de l’étape de collecte, et d’une partie des données relatives à cet état collectées lors de l’étape de collecte et correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements les plus récents de ladite pluralité d’événements.

Corrélativement, l’invention concerne aussi une entité comprenant des modules, activés pour au moins un équipement d’utilisateur, comprenant :

• un module de collecte, configuré pour collecter pour une pluralité d’événements ayant impacté au moins un état dudit équipement d’utilisateur dans un réseau, des données relatives audit au moins un état impacté par lesdits événements ;
• un module d’obtention de statistiques, configuré pour obtenir, pour au moins un dit état impacté dudit équipement d’utilisateur, au moins une statistique en agrégeant des données relatives à cet état, collectées par le module de collecte ; et
• un module de transmission, configuré pour fournir à une entité du réseau dite d’analyse de données, pour ledit au moins un état impacté dudit équipement d’utilisateur, ladite au moins une statistique obtenue pour cet état par le module d’obtention de statistiques et une partie des données collectées par le module de collecte relatives à cet état et correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements les plus récents de ladite pluralité d’événements.

Par souci de simplification, cette entité est désignée par entité de fourniture de données ou entité de fourniture dans la suite.

Dans un mode particulier de réalisation, cette entité est une entité du réseau, et plus particulièrement une entité NF (pour « Network Function ») hébergeant une fonction réseau telle que par exemple une entité AMF (pour « Access and Mobility Management Function » en anglais) ou SMF (pour « Session Management Function » en anglais) d’un réseau 5G conforme au standard 3GPP.

Bien que le problème technique que cherche à résoudre l’invention ait été souligné en référence aux échanges entre une entité NF et une entité d’analyse de données du réseau DAF ou NWDAF, comme déjà évoqué précédemment l’invention ne se limite pas à ce contexte. Ainsi, l’entité de fourniture des données peut également, dans un autre mode de réalisation, être un équipement de l’utilisateur (c’est-à-dire un UE) comme par exemple un terminal, un capteur, un autocommutateur privé (ou PABX pour « Private Automatic Branch eXchange » en anglais) pour une entreprise, un équipement client de type CPE (pour « Customer Premises Equipment »,), etc. Aucune limitation n’est attachée à la nature de l’équipement d’utilisateur auquel se rapporte l’invention. On fait référence dans la suite à cet équipement d’utilisateur en utilisant indifféremment les expressions « équipement d’utilisateur », « équipement de l’utilisateur » ou encore « UE » par souci de simplification. L’invention permet ainsi à l’entité d’analyse d’obtenir des données relatives à un utilisateur d’un réseau en provenance de différentes sources, qui peuvent avoir accès à différents types ou niveaux de données sur l’utilisateur.

L’invention vise également un procédé d’obtention de données relatives à au moins un équipement d’utilisateur par une entité d’un réseau dite d’analyse de données, ladite entité d’analyse étant apte à communiquer avec au moins une autre entité configurée pour collecter, pour une pluralité d’événements ayant impacté au moins un état dudit équipement d’utilisateur dans le réseau, des données relatives audit au moins un état impacté, ledit procédé comprenant une étape de réception, pour au moins un dit état impacté dudit équipement d’utilisateur :

• d’au moins une statistique obtenue par ladite autre entité pour cet état en agrégeant des données relatives à cet état collectées par ladite autre entité pour ladite pluralité d’événements ; et
• d’une partie des données relatives à cet état collectées par ladite autre entité pour ladite pluralité d’événements, ladite partie des données correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements les plus récents de ladite pluralité d’événements.

Corrélativement, l’invention concerne aussi une entité d’un réseau dite d’analyse de données, apte à communiquer avec une autre entité configurée pour collecter, pour une pluralité d’événements ayant impacté au moins un état d’au moins un équipement d’utilisateur dans le réseau, des données relatives audit au moins un état impacté, ladite entité d’analyse comprenant un module de réception, activé pour ledit au moins un équipement d’utilisateur et configuré pour obtenir, en provenance de ladite autre entité, pour au moins un dit état impacté dudit équipement d’utilisateur :

• au moins une statistique obtenue par ladite autre entité pour ledit état en agrégeant des données relatives à cet état collectées par ladite autre entité pour ladite pluralité d’événements ; et
• une partie des données relatives à cet état collectées par ladite autre entité pour ladite pluralité d’événements, cette partie correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements les plus récents de ladite pluralité d’événements.

Dans un mode particulier de réalisation, le procédé d’obtention comprend une étape d’élaboration d’une prédiction ou d’une analyse statistique consolidée à partir de ladite au moins une statistique obtenue et de ladite partie de données.

Corrélativement, l’entité dite d’analyse comprend en outre un module d’analyse configuré pour élaborer une prédiction ou une analyse statistique consolidée à partir de ladite au moins une statistique obtenue et de ladite partie de données.

L’entité dite d’analyse peut être une entité d’analyse de données du réseau dédiée à cette fonction d’analyse et centralisée, que l’on désigne dans la suite par entité DAF par souci de simplification. Une telle entité est par exemple une entité NWDAF d’un réseau 5G.

Toutefois, l’invention peut également s’appliquer à d’autres entités. Ainsi, l’entité dite d’analyse peut être une autre entité du réseau qu’une entité DAF ou NWDAF dédiée et centralisée, dès lors que cette entité est configurée pour analyser des données du réseau (c’est-à-dire relatives au réseau, à son fonctionnement, etc.). On peut envisager par exemple que l’entité dite d’analyse au sens de l’invention soit une entité NF, dûment configurée pour réaliser des analyses statistiques ou des prédictions.

On note qu’aucune limitation n’est attachée à la nature des entités impliquées dans l’invention, c’est-à-dire à l’entité de fourniture des données et à l’entité dite d’analyse. Il peut en effet s’agir d’entités ou de fonctions logicielles hébergées par divers dispositifs physiques du réseau ou d’entités physiques.

Aucune limitation n’est attachée non plus à la nature des états d’un équipement d’utilisateur dans le réseau pouvant être envisagés dans le cadre de l’invention, l’utilisateur pouvant désigner un usager unique ou un groupe d’usagers comme par exemple une entreprise ou même encore une machine (ex. un capteur, un actionneur, un robot, etc.) exploitée par un usager ou un groupe d’usagers. On associe ici à la notion d’utilisateur, l’existence d’une souscription auprès de l’opérateur du réseau pour cet utilisateur. Les états d’un équipement d’utilisateur au sens de l’invention peuvent désigner aussi bien des états généraux de cet équipement d’utilisateur comme par exemple « enregistré », « connecté », « non connecté », ou des états plus spécifiques tels que « présent dans la cellule A », « ayant une communication vocale en cours », etc.

Un événement au sens de l’invention se traduit alors par une transition entre deux états de l’équipement d’utilisateur (ex. transition d’un état « non enregistré » à un état « enregistré », ou « arrivée d’un équipement d’utilisateur dans une cellule A »). Les états impactés de l’équipement d’utilisateur peuvent être déduits des événements détectés dans le réseau pour cet équipement d’utilisateur (ex. début ou fin d’une communication, entrée dans une cellule, etc.).

L’invention propose avantageusement la remontée par une entité de fourniture de données (ex. entité NF) à une entité d’analyse (ex. entité DAF), pour lui permettre notamment d’établir des analyses statistiques et/ou des prédictions, de deux types d’informations collectées à partir d’événements déterminés que l’entité de fourniture a détectés dans le réseau pour un utilisateur donné :

• d'une part, des statistiques, obtenues en agrégeant des données brutes (c’est-à-dire des faits réseau) collectées respectivement lors de ces événements sur des états de l’équipement d’utilisateur impactés par ces événements. On note qu’une statistique au sens de l’invention est construite en regroupant (c’est-à-dire en agrégeant) au moyen d’une fonction mathématique donnée (ex. moyenne, variance, etc.) des données brutes collectées sur une durée déterminée (par exemple sur un nombre d’événements déterminé ou lors d’une fenêtre temporelle déterminée), c’est-à-dire qu’elle est obtenue uniquement à partir de données brutes passées (par opposition à une prédiction par exemple qui fournit une indication sur le futur). Il s’agit en quelque sorte d’un condensé représentatif des données brutes passées, qui peut être obtenue de façon très simple par l’entité de fourniture ; et
• d’autre part, de données brutes collectées sur les événements les plus récents relatifs à l’utilisateur qui ont impacté un ou plusieurs états de son équipement d’utilisateur. Ces données reflètent le passé récent de l’équipement de l’utilisateur observé dans le réseau. Il convient de noter que ce passé récent peut avoir une durée temporelle différente selon les utilisateurs considérés et leurs activités respectives dans le réseau (pour certains utilisateurs, les X événements peuvent s’étaler sur une fenêtre temporelle plus longue que pour d’autres plus versatiles dans le réseau). On peut envisager, dans un mode particulier de réalisation, de paramétrer le nombre d’événements X en fonction du type d’utilisateur considéré (ex. utilisateur mobile, fixe, etc.).

Ces deux types d’informations permettent avantageusement de minimiser les échanges entre l’entité de fourniture de données et l’entité d’analyse tout en préservant la pertinence des informations remontées. En remontant des données brutes relatives uniquement au passé récent de l’équipement d’utilisateur considéré combinées à des statistiques représentatives d’une période de temps plus longue, l’invention offre la possibilité à l’entité d’analyse de combiner deux niveaux distincts d’informations et de compléter sa connaissance du comportement de l’utilisateur en effectuant des rapprochements féconds entre ces deux niveaux d’informations. Ce rapprochement peut être effectué par tout moyen, comme par exemple au moyen d’un algorithme de prédiction évolué s’appuyant sur des chaînes de Markov. Les données brutes correspondant au passé récent de l’équipement d’utilisateur fournissent en effet des informations contextuelles (perdues lors de l’agrégation des données pour constituer les statistiques), mais sur une fenêtre temporelle réduite ce qui permet de limiter la volumétrie des informations remontées vers l’entité d’analyse. Le nombre X d’événements remontés peut bien entendu être paramétré en fonction notamment des événements auxquels on s’intéresse pour l’utilisateur.

L’entité de fourniture, comme l’entité d’analyse, n’ont ainsi pas besoin de stocker de façon exhaustive toutes les données brutes collectées sur les événements relatifs à un utilisateur détectés dans le réseau. L’entité de fourniture n’a pas non plus besoin de transmettre à l’entité d’analyse toutes les données qu’elle a collectées. En outre, les statistiques pré-agrégées fournies par l’entité de fourniture permettent d’alléger la charge de calcul et de gestion de protocole de l’entité d’analyse.

A titre illustratif, l’entité de fourniture est par exemple une fonction réseau AMF de gestion de l’accès et de la mobilité d’un réseau 5G. Cette fonction AMF peut fournir à une entité DAF du réseau 5G (entité d’analyse au sens de l’invention) comme statistiques agrégées, les localisations les plus fréquentes sur différents horizons de temps d’un équipement d’utilisateur ainsi que les derniers événements relatifs à la mobilité et à l’accès de cet équipement d’utilisateur au réseau (incluant ses dernières localisations). Il est ainsi possible pour l’entité DAF de déterminer, via la liste des derniers événements remontés, quand un utilisateur muni de son UE se rapproche de l’une de ses localisations favorites (fournies par le biais des statistiques remontées). En outre, la connaissance de la topologie du réseau par l’entité DAF, combinée aux modèles établis par l’entité DAF sur le comportement de l’utilisateur à long terme, grâce aux deux types d’informations remontées par l’entité NF, peut lui permettre de prédire les prochaines localisations de l’utilisateur (autrement dit de son UE).

Bien entendu cet exemple n’est donné qu’à titre illustratif, et d’autres fonctions NF (ex. une fonction SMF de gestion de session), et/ou d’autres événements et/ou d’autres statistiques (ex. statistiques de communication) peuvent être envisagés.

Dans un mode particulier de réalisation, au moins une dite statistique relative à un état de l’équipement d’utilisateur est mise à jour de façon incrémentale à chaque événement détecté concernant l’équipement d’utilisateur et impactant cet état.

Autrement dit, à chaque nouvel événement E(N) détecté affectant l’état considéré, N désignant un entier supérieur à 1, la statistique en question relative à cet état, notée par exemple G(N), est obtenue à partir de la valeur G(N-1) de la statistique obtenue lors de la détection du précédent événement affectant ledit état et du seul événement E(N).

De cette sorte, on limite encore davantage la quantité de données à mémoriser par l’entité de fourniture (il n’est pas nécessaire de conserver les événements les plus anciens en dehors de ceux appartenant au passé récent remonté à l’entité d’analyse et l’événement E(N)) et donc les contraintes en termes de capacité de stockage de l’entité de fourniture. En outre, les calculs effectués par cette dernière pour obtenir les statistiques sont simplifiés.

Ainsi des informations sont disponibles au niveau de l’entité d’analyse pour tous les utilisateurs gérés par l’entité de fourniture moyennant un effort raisonnable en termes de mémoire et de calcul pour l’entité de fourniture.

Différents types de statistiques peuvent être évalués par l’entité de fourniture.

Ainsi, une statistique peut être évaluée par exemple sur une fenêtre temporelle glissante ou sur un nombre d’événements glissant.

Une statistique peut également être évaluée sur une fenêtre temporelle périodique de période notée T ou sur une fenêtre temporelle de largeur égale à un multiple entier de la période T.

Ceci permet d’obtenir des statistiques exactes évaluées sur une durée fixe, plus ou moins longue selon la variante envisagée. Notamment si une fenêtre de largeur égale à un multiple entier Q d’une période T est envisagée pour évaluer une statistique, cela permet d’obtenir une statistique sur une période assez longue de durée Q.T, représentative d’un comportement long terme de l’utilisateur. Une telle statistique peut être dérivée des statistiques obtenues sur une fenêtre temporelle périodique de période T sans avoir à stocker de données supplémentaires autres que les statistiques évaluées périodiquement sur chaque période.

L’entité de fourniture peut ainsi évaluer plusieurs statistiques relatives à un état de l’utilisateur selon l’une et/ou l’autre de ces techniques. D’autres techniques peuvent bien entendu être envisagées en variante.

Dans un mode particulier de réalisation, une statistique peut être évaluée en utilisant une moyenne mobile exponentielle (ou MME).

Ce mode de réalisation (MME) permet par exemple d’obtenir des statistiques estimatives sur l’espacement entre deux événements affectant un même état (ex. moyenne et variance).

Comme détaillé précédemment, conformément à l’invention, l’entité de fourniture fournit à l’entité d’analyse des statistiques évaluées sur les données brutes qu’elle a collectées pour l’équipement d’utilisateur considéré ainsi que des données brutes représentatives du passé récent de l’utilisateur dans le réseau. On peut toutefois envisager que l’entité de fourniture fournisse d’autres informations en plus de celles précitées à l’entité d’analyse.

Ainsi, dans un mode particulier de réalisation, le procédé de fourniture comprend en outre une fourniture à ladite entité d’analyse, pour chaque type d’événement de ladite pluralité d’événements, d’au moins un indicateur d’activité pour ce type d’événement.

Corrélativement, le procédé d’obtention comprend l’obtention, pour chaque type d’événement de ladite pluralité d’événements, d’au moins un indicateur d’activité pour ce type d’événement.

Un tel indicateur d’activité pour un type d’événement donné (ex. présence dans une cellule, perte de communication, etc.) comprend par exemple une estimation (moyenne et variance) d’une durée d’espacement entre deux événements de ce type détectés dans le réseau pour l’équipement d’utilisateur. Bien entendu, d’autres types d’indicateur d’activité peuvent être envisagés, comme par exemple une estimation de la régularité des événements de ce type indiquant si les événements de ce type sont espacés de façon à peu près constante ou variable.

Les indicateurs d’activité permettent avantageusement d’établir un profil d’activité de l’utilisateur dans le réseau (ex. fréquence de ses déplacements, qualité de son environnement radio proche, etc.), de sorte à mieux caractériser l’utilisateur. Par exemple, ceci permet de distinguer un comportement de stationnement long dans une cellule puis dans une autre, d’un comportement de va-et-vients fréquents entre ces deux cellules pour des durées cumulées identiques.

Cette connaissance des indicateurs d’activité par type d’événement offre en outre la possibilité de sélectionner un modèle de calcul plus pertinent pour les analyses statistiques et les prédictions réalisées par l’entité d’analyse pour cet utilisateur.

Dans un mode particulier de réalisation, le procédé de fourniture selon l’invention comprend une étape de filtrage des données collectées en fonction d’une représentativité desdites données d’un état habituel dudit équipement d’utilisateur.

Ce filtrage permet de ne retenir que les valeurs les plus significatives des comportements de l’utilisateur et de limiter ainsi la capacité de stockage requise pour la mise en œuvre de l’invention.

En variante, on peut envisager de conserver au contraire les valeurs les moins significatives de l’état habituel de l’équipement d’utilisateur et de supprimer certaines valeurs plus cohérentes avec cet état habituel, considérées comme redondantes avec d’autres données déjà remontées ou n’apportant pas d’informations complémentaires par rapport aux statistiques remontées.

Différents critères peuvent être appliqués pour filtrer les données collectées. Ainsi, par exemple, les données peuvent être filtrées en fonction de leurs instants de collecte (ex. les données les plus anciennes sont supprimées), le nombre d’événements associés auxdites données, la durée totale des événements, etc.

Dans un mode particulier de réalisation, l’étape de fourniture est conditionnée par une demande explicite de notification de l’entité d’analyse.

Une telle demande explicite de notification peut par exemple prendre la forme d’une souscription ou d’un abonnement auprès de l’entité de fourniture par l’entité d’analyse pour être notifiée des éléments d’information collectés par l’entité de fourniture sur un utilisateur déterminé ou, de manière équivalente, un équipement d’utilisateur déterminé. Ceci permet la notification automatique de l’entité d’analyse.

En variante, il peut s’agir d’une demande ponctuelle ou récurrente (par exemple de façon périodique) de l’entité d’analyse.

Dans un mode particulier de réalisation, l’étape de fourniture du procédé d’obtention selon l’invention est mise en œuvre périodiquement et/ou en réponse à une requête de l’entité d’analyse.

En variante, l’étape de fourniture peut être déclenchée par la détection d’un critère spécifique, par exemple le dépassement d’un seuil.

Dans un mode particulier de réalisation de l’invention, les procédés de fourniture et d’obtention sont mis en œuvre par un ordinateur.

L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité de fourniture de données conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de fourniture tel que décrit ci-dessus.

L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité d’analyse conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé d’obtention 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 fourniture et d’obtention selon l’invention.

Selon un autre aspect, l’invention concerne un système de télécommunication comprenant au moins une entité de fourniture de données et une entité d’analyse conformes à l’invention.

Le système selon l’invention bénéficie des mêmes avantages cités précédemment que les entités de fourniture et d’analyse selon l’invention.

Dans un mode particulier de réalisation, l’entité de fourniture de données est une entité du réseau gérant une pluralité d’équipements d’utilisateurs du réseau, comme par exemple une entité NF hébergeant une fonction réseau.

Dans un autre mode réalisation, l’entité de fourniture de données est l’équipement d’utilisateur considéré, c’est-à-dire par exemple le terminal de l’utilisateur.

On peut également envisager, dans d'autres modes de réalisation, que les procédés de fourniture et d’obtention, les entités de fourniture et d’analyse 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 figure 1 représente dans son environnement, un système de télécommunication selon l’invention dans un mode particulier de réalisation ;
la figure 2 représente schématiquement l’architecture matérielle d’une entité de fourniture et d’une entité d’analyse du système de la figure 1 ;
la figure 3 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé d’obtention tel qu’il est mis en œuvre dans un mode particulier de réalisation par l’entité d’analyse (entité DAF) du système de la figure 1 ;
la figure 4 représente sous forme d’ordinogramme, les principales étapes d’un procédé de fourniture tel qu’il est mis en œuvre dans un mode particulier de réalisation par une entité de fourniture de données (entité NF) du système de la figure 1 ;
les figures 5A et 5B illustrent différentes façons d’évaluer des statistiques (fenêtre périodique et fenêtre glissante respectivement).

Description de l’invention

Lafigure 1représente, dans son environnement, un système 1 de télécommunication conforme à l’invention, dans un mode particulier de réalisation. Le système 1 offre la possibilité, moyennant une complexité réduite, de collecter des informations sur divers événements détectés dans un réseau de télécommunication NW et relatifs à des utilisateurs ou à des groupes d’utilisateurs du réseau (et plus spécifiquement à leurs équipements d’utilisateurs (UE) respectifs), en vue d’effectuer des analyses statistiques et/ou des prédictions permettant d’optimiser le fonctionnement du réseau NW.

Par « événement relatif à ou concernant un équipement d’utilisateur », on entend ici un événement détecté dans le réseau conduisant à une transition entre deux états de l’équipement d’utilisateur (par exemple le déplacement de l’équipement d’utilisateur d’une cellule vers une autre, le passage de l’équipement d’utilisateur d’un état « non enregistré » à un état « enregistré », etc.). Aucune limitation n’est attachée à la nature des événements considérés, ni à la nature des états de l’équipement d’utilisateur considérés. Comme mentionné précédemment, un état d’un équipement d’utilisateur au sens de l’invention peut désigner aussi bien des états généraux de cet équipement d’utilisateur comme par exemple « enregistré », « connecté », « non connecté », que des états plus spécifiques tels que « présent dans la cellule A », « ayant une communication en cours », etc.

Dans l’exemple envisagé à la figure 1, le réseau de télécommunication NW est un réseau 5G tel que défini dans le standard 3GPP (à l’exception des fonctions propres à l’invention). Toutefois, cette hypothèse n’est pas limitative en soi et l’invention s’applique à d’autres types de réseau (6G, réseaux de télécommunication propriétaires, etc.).

Conformément à l’invention, le système 1 comprend, au moins une entité de fourniture de données, conforme à l’invention. Dans le mode de réalisation envisagé ici, cette entité de fourniture est une entité NF (ou encore fonction NF pour « Network Function ») gérant une pluralité d’équipements d’utilisateurs du réseau et hébergeant au moins une fonction réseau.

De façon connue en soi, une entité NF est un bloc fonctionnel (logiciel ou physique) caractérisé par un comportement (pour assurer le service associé à ladite fonction réseau) et des interfaces externes définis. Aucune limitation n’est attachée aux fonctions réseau hébergées par les entités NF : gestion des accès au réseau, gestion de la mobilité des utilisateurs (c’est-à-dire de leurs équipements d’utilisateurs), gestion des sessions de communication des utilisateurs via leurs équipements d’utilisateurs, stockage des profils utilisateurs, passerelle entre réseaux, etc. Les entités NF peuvent être situées dans le plan de commande comme dans le plan utilisateur. A titre d’exemple, une telle entité NF est par exemple une fonction AMF de gestion de la mobilité et de l’accès des utilisateurs ou une fonction SMF de gestion des sessions, etc.

Chaque entité NF du système 1 est configurée ici pour collecter des données « brutes » (c’est-à-dire des faits ou des informations sur les faits se déroulant dans le réseau) sur un ensemble d’événements déterminés qu’elle expose, relatifs aux équipements d’utilisateurs qu’elles gèrent, ces événements étant en relation avec la ou les fonctions réseau qu’elle assure. Les types d’événements exposés par une entité NF sont en nombre fixé, typiquement pour un réseau 5G 3GPP, une dizaine de types d’événements différents en général. Ainsi, par exemple, une entité AMF est en mesure de collecter des données sur des événements de mobilité relatifs aux équipements d’utilisateurs qu’elle gère, tels que le déplacement d’un équipement d’utilisateur d’une cellule à une autre, etc. En outre, conformément à l’invention et comme détaillé davantage ultérieurement, chaque entité NF du système 1 est configurée pour évaluer diverses statistiques à partir des données brutes qu’elle collecte. Les événements exposés par une entité NF sont définis pour chaque entité NF et connus des autres entités du réseau. Par exemple pour une entité AMF, ces événements, au nombre de 16, sont décrits dans le document 3GPP TS 29.518 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Access and Mobility Management Services; Stage 3 (Release 16) », v16.4.0, juin 2020, section 6.2.6.3.3. Pour une entité SMF, ces événements sont au nombre de 10 et sont décrits dans le document 3GPP TS 29.508 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Session Management Event Exposure Service; Stage 3 (Release 16) », v16.4.0, juin 2020, section 5.6.3.3.

Le système 1 comprend également une entité dite d’analyse DAF conforme à l’invention. Dans le mode de réalisation décrit ici, cette entité d’analyse est une entité NWDAF (ou fonction NWDAF pour « NetWork Data Analytics Function ») centralisée, chargée de l’analyse des données du réseau NW, et configurée pour réaliser de manière centralisée diverses analyses statistiques et/ou prédictions à partir d’éléments d’information collectés auprès d’une ou de plusieurs entités NF. Ces analyses statistiques et/ou prédictions peuvent être notamment réalisées par l’entité NWDAF sur requête d’entités NF dites clientes, qui peuvent être identiques ou distinctes des entités NF qui collectent les données brutes sur les événements relatifs aux utilisateurs du réseau NW. Aux fins des analyses statistiques et des prédictions qu’elle doit réaliser, l’entité NWDAF peut en outre collecter des éléments d’information d’autres entités que les entités NF, comme par exemple d’une entité de gestion du réseau aussi connue sous la désignation d’entité OAM (pour « Operation, Administration and Maintenance » en anglais), ou de fonctions d’application ou AF (pour « Application Function » en anglais), ou encore d’équipements d’utilisateurs du réseau.

Pour collecter ces éléments d’information, l’entité NWDAF peut souscrire, pour un utilisateur ou un groupe d’utilisateurs particulier, et pour tout ou partie des types d’événements exposés par une entité NF, à la notification par cette entité NF d’éléments d’information relatifs à ces types d’événements dès lors qu’ils sont détectés par l’entité NF dans le réseau et qu’ils impactent l’état de l’équipement (UE) de cet utilisateur. Cette notification peut être réalisée par exemple de façon périodique, ou sur détection de tout autre critère (par exemple dépassement d’un seuil donné par un paramètre observé par l’entité NF). Dans une variante de réalisation, l’entité NWDAF peut également solliciter de sa propre initiative, périodiquement ou à des instants déterminés, une entité NF pour qu’elle lui fournisse des éléments d’information sur les types d’événements qu’elle expose en relation avec un utilisateur ou un groupe d’utilisateurs déterminé. Dans le mode de réalisation décrit ici, cette souscription permet à l’entité NWDAF de bénéficier des éléments d’information que l’entité NF a collectés conformément à l’invention suite à l’occurrence d’événements correspondant aux types d’événements spécifiés dans la souscription de l’entité NWDAF et qui ont impacté l’état d’un équipement (UE) d’un utilisateur donné. Dans le mode de réalisation décrit ici, comme détaillé davantage ultérieurement, ces éléments d’information comprennent les statistiques agrégées par l’entité NF sur les différents états de l’équipement d’utilisateur détectés lors de ces événements, les données brutes collectées relatives à un nombre entier X d’événements les plus récents détectés pour l’utilisateur (X pouvant être défini par l’entité NWDAF lors de sa souscription, ou déterminé par l’entité NF2 ou encore fixé par défaut), et pour chaque type d’événement spécifié dans la souscription de l’entité NWDAF, un indicateur d’activité de ce type d’événement pour l’équipement d’utilisateur. On note qu’en variante, l’entité NWDAF peut demander à ne recevoir qu’une partie de ces éléments d’informations (ex. uniquement les statistiques et les événements récents).

Les entités NF et DAF du système 1 sont configurées respectivement ici pour mettre en œuvre un procédé de fourniture de données et un procédé d’obtention de données conformes à l’invention. A cet effet, ces entités s’appuient, dans le mode de réalisation décrit ici, sur l’architecture matérielle d’un ordinateur telle que représentée schématiquement à lafigure 2. Cette architecture matérielle peut être celle de l’entité considérée ou du dispositif physique qui l’héberge qu’utilise alors l’entité lorsque celle-ci est implémentée sous la forme d’une fonction logicielle.

Cette architecture comprend notamment un processeur 2, une mémoire vive 3, une mémoire morte 4, une mémoire non volatile 5, et des moyens de communication 6 comprenant notamment diverses interfaces physiques et protocolaires permettant aux entités NF et DAF de communiquer entre elles, mais également avec d’autres entités du réseau. De telles interfaces sont décrites par exemple dans le document 3GPP TS 29.500 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 16) », v16.4.0, juin 2020, et plus particulièrement pour les entités AMF et SMF dans les documents 3GPP TS 29.518 et TS 29.508 cités précédemment.

La mémoire morte 4 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 2 et sur lequel est un programme d’ordinateur conforme à l’invention, à savoir le programme PROG-NF pour l’entité NF et le programme PROG-DAF pour l’entité DAF.

Le programme PROG-NF définit des modules fonctionnels d’une entité NF conforme à l’invention, qui s’appuient ou commandent les éléments matériels 2 à 6 précités. Ces modules sont activés ici, pour au moins un équipement (UE) d’un utilisateur géré par l’entité NF et pour des événements de types déterminés qu’elle expose, et comprennent, dans le mode de réalisation décrit ici, comme représenté sur la figure 1 :
- un module 7 de collecte, configuré pour collecter des données (que l’on désigne ici par « brutes ») pour une pluralité d’événements concernant cet équipement d’utilisateur détectés dans le réseau NW (aucune limitation n’est attachée au dispositif détectant ces événements). Ces données sont relatives aux états de l’équipement d’utilisateur impactés par les événements détectés. Il s’agit par exemple des caractéristiques que l’entité NF se doit d’exposer avec les événements qu’elle détecte, mais d’autres données peuvent également être collectées ;
- un module 8 d’évaluation de statistiques (module d’obtention de statistiques au sens de l’invention), configuré pour évaluer, pour au moins un état de l’équipement d’utilisateur, une ou plusieurs statistiques en agrégeant des données brutes relatives à cet état et collectées par le module 7 de collecte ;
- un module 9 d’estimation de statistiques dites de profilage des utilisateurs et des événements du réseau, configuré ici pour évaluer pour chaque type d’événement exposé par l’entité NF et pour l’équipement d’utilisateur considéré, un indicateur d’activité de ce type d’événement. Un tel indicateur d’activité d’un type d’événement donné est par exemple une estimation (ex. moyenne et variance) de la durée d’espacement entre deux événements de ce type pour l’équipement d’utilisateur, ou une estimation de la régularité de l’occurrence des événements de ce type reflétant si les événements de ce type sont espacés de façon à peu près constante ou variable pour l’équipement d’utilisateur ; et
- un module 10 de transmission, configuré pour fournir à l’entité NWDAF, via l’interface prévue à cet effet, différents éléments d’information sur l’équipement d’utilisateur, à savoir une ou des statistiques évaluées par le module 8 d’évaluation de statistiques sur des états de l’équipement d’utilisateur, des données brutes collectées par le module 7 de collecte sur les X derniers événements détectés dans le réseau pour l’équipement d’utilisateur et ayant impacté ces états, X désignant un entier supérieur ou égal à 1, et les indicateurs d’activité de chaque type d’événement exposé par l’entité NF et concernant l’équipement d’utilisateur, estimés par le module 9 d’estimation de statistiques de profilage.

Les fonctions assurées par ces modules 7 à 10 sont décrites plus en détail ultérieurement en référence aux étapes du procédé de fourniture selon l’invention.

De façon similaire, le programme PROG-DAF définit des modules fonctionnels d’une entité NWDAF conforme à l’invention, qui s’appuient ou commandent les éléments matériels 2 à 6 précités. Ces modules sont activés pour au moins un équipement d’utilisateur et comprennent, dans le mode de réalisation décrit ici, comme représenté sur la figure 1 :
- un module 11 d’émission/réception, configuré pour obtenir de chaque entité NF que l’entité NWDAF sollicite, via l’interface prévue à cet effet, différents éléments d’information sur l’équipement d’utilisateur, et plus particulièrement, les éléments d’information décrits ci-avant et fournis par le module 10 de transmission de l’entité NF ; et
- un module 12 d’analyse et de prédiction, configuré pour réaliser, à partir des éléments d’information obtenus par le module 11 d’émission/réception pour un ou plusieurs utilisateurs, des analyses statistiques et/ou des prédictions. Les analyses statistiques et les prédictions conduites peuvent être requises par une ou plusieurs entités NF clientes du réseau NW comme mentionné précédemment, et la nature de ces analyses statistiques et de ces prédictions dépend des entités NF à l’origine de ces requêtes. Il peut s’agir notamment de prédictions globales (portant sur le réseau, sur une région, etc., telles que par exemple le taux de charge des ressources du réseau, la qualité de service moyenne assurée, le nombre d’équipements d’utilisateurs connectés ou de sessions actives, etc.) ou individuelles (portant sur un utilisateur particulier ou sur un groupe d’utilisateurs, par exemple « Un équipement (UE) d’un utilisateur U1 sera dans la cellule A dans 10 minutes », ou « 80% des équipements (UE) des utilisateurs du groupe G seront dans la cellule B dans 15 minutes », etc.). De telles prédictions peuvent être réalisées à l’aide de modèles et d’algorithmes de prédiction connus de l’homme du métier et non détaillés ici, comme par exemple des techniques d’apprentissage automatique (ou « Machine Learning » en anglais), et plus particulièrement pour les prédictions relatives à la localisation d’un équipement d’utilisateur, la technique LSTM (ou « Long-Short Term Memory » en anglais). On note que le module 12 d’analyse et de prédiction peut également être configuré pour effectuer une surveillance ciblée d’un utilisateur particulier sur une fenêtre temporelle courte et à cet effet, être en mesure d’activer le module 11 d’émission/réception pour requérir auprès des entités NF du système 1 des éléments d’information sur l’équipement (UE) de cet utilisateur particulier sur une période de temps donnée.

Les fonctions assurées par les modules 11 et 12 de l’entité NWDAF sont décrites plus en détail ultérieurement en référence aux étapes du procédé d’obtention selon l’invention.

Nous allons maintenant décrire, en référence auxfigures 3 et 4respectivement, les principales étapes d’un procédé d’obtention et d’un procédé de fourniture selon l’invention telles qu’elles sont mises en œuvre, dans un mode particulier de réalisation, par l’entité NWDAF du système 1 et par chaque entité NF du système 1 sollicitée par l’entité NWDAF.

En référence à la figure 3, on suppose ici au préalable qu’une entité NF du réseau NW, par exemple l’entité cliente NF1 identifiée sur la figure 1, sollicite l’entité NWDAF pour réaliser une analyse statistique ou une prédiction donnée (étape E10). A titre illustratif, on suppose ici que la prédiction sollicitée par l’entité NF1 vise à déterminer quelles seront les trois prochaines cellules visitées par l’équipement (UE) d’un utilisateur U, référencé par UE(U) dans la suite de la description et indifféremment désigné par équipement d’utilisateur UE(U) ou encore équipement UE(U) de l’utilisateur U ou encore tout simplement équipement UE(U). Comme mentionné précédemment, aucune limitation n’est attachée à la nature de l’équipement UE(U) de l’usager U ; il s’agit par exemple ici d’un terminal.

Cet exemple n’est bien entendu donné qu’à titre illustratif et d’autres prédictions ou analyses statistiques peuvent être envisagées, portant sur un utilisateur unique, sur une pluralité d’utilisateurs ou encore sur un groupe d’utilisateurs déterminé, de même que d’autres équipements d’utilisateurs (ex. CPE, PABX, capteur, etc.).

Suite à cette sollicitation, dans le mode de réalisation décrit ici, l’entité NWDAF souscrit auprès des entités NF pertinentes du système 1 (c’est-à-dire celles susceptibles de lui fournir des informations pour la réalisation de l’analyse statistique ou de la prédiction requise par l’entité cliente NF1) à la notification, pour l’équipement UE(U) de l’utilisateur U et pour tout ou partie des événements exposés par ces dernières, des éléments d’information collectés par ces entités sur l’équipement UE(U) de l’utilisateur U lors de ces événements (étape E20). Cette souscription constitue une demande explicite de notification de la part de l’entité NWDAF. On suppose ici que l’entité NWDAF souscrit à une notification périodique (de période Tnotif) des éléments d’information exposés par les entités NF.

Les événements auxquels elle souscrit pour l’équipement UE(U) de l’utilisateur U sont sélectionnés par l’entité NWDAF en fonction de l’analyse statistique ou de la prédiction qu’elle doit réaliser.

L’entité NWDAF peut également, indépendamment de cette souscription, relever auprès de l’entité NF, de manière asynchrone et de sa propre initiative via une requête prévue à cet effet, pour les événements relatifs à l’équipement UE(U) de l’utilisateur U détectés par l’entité NF, les éléments d’information que l’entité NF a collectés lors de ces événements, par exemple comme évoqué précédemment, pour réaliser une surveillance ciblée de l’utilisateur U (i.e. de son équipement d’utilisateur UE(U)) sur une période temporelle courte, ou pour renforcer ses modèles de prédiction sur l’utilisateur U.

Dans l’exemple envisagé ici, par souci de simplification, on suppose que l’entité NWDAF envoie une demande de souscription à une seule entité NF, à savoir l’entité NF 2 identifiée sur la figure 1, et qu’elle souscrit à la notification de tous les éléments d’information collectés par l’entité NF2 lors des événements correspondant à tous les types d’événements E1,….,EZ exposés par l’entité NF, Z désignant un entier supérieur ou égal à 1, (statistiques des états de l’équipement UE(U), X derniers événements avec X entier supérieur ou égal à 1, chaque événement étant défini au moyen d’un certain nombre de caractéristiques dépendant du type de l’événement, et indicateurs d’activité pour chaque type d’événement E1,…,EZ).

En variante, elle peut souscrire à ce type de notifications auprès de plusieurs entités NF, et sélectionner seulement un sous-ensemble des événements exposés par chacune des entités NF. On note que le mode de fonctionnement décrit ci-après pour l’entité NF2 s’applique à toute entité NF du système 1 conforme à l’invention.

A titre illustratif, lorsque l’entité NF2 est une fonction AMF telle qu’évoquée précédemment, 16 types d’événements peuvent être exposés par la fonction AMF sur son API Namf_EventExposure, comme indiqué dans le document 3GPP TS 29.518 cité précédemment. Ces événements comprennent par exemple : la localisation de l’équipement d’utilisateur considéré (« Location-Report »), la présence de l’équipement d’utilisateur dans une zone d’intérêt (« Presence-In-AOI-Report), le fuseau horaire de l’équipement d’utilisateur (« Time-Zone-Report »), le type de réseau d’accès de l’équipement d’utilisateur (« Access-Type-Report »), l’état d’enregistrement de l’équipement d’utilisateur (« Registration-State-Report »), l’état de connexion de l’équipement d’utilisateur (« Connectivity-State-Report »), l’état d’accessibilité de l’équipement d’utilisateur (« Reachability Report »), un échec de la communication de l’équipement d’utilisateur (« Communication-Failure-Report »), etc.

Comme mentionné précédemment, chaque événement est modélisé au moyen de plusieurs caractéristiques. Les données collectées par les entités NF (et donc l’entité NF2) sont en partie conditionnées par ces caractéristiques. Dans l’exemple illustratif précédent de la fonction AMF, l’événement « Location-Report » est par exemple modélisé par les caractéristiques suivantes : identifiant de l’équipement d’utilisateur et localisation de l’équipement d’utilisateur (sous la forme d’un identifiant TAI (pour « Tracking Area Identity »), d’un identifiant de cellule (ou Cell-ID), d’un identifiant de ligne filaire (ou Global Line ID), etc.). L’événement « Presence-In-AOI-Report » est modélisé par l’identifiant de l’équipement d’utilisateur, l’identifiant de la zone et l’état de présence (« in », « out » ou « unknown »).

En référence à la figure 4, l’entité NF2 enregistre la souscription de l’entité NWDAF relative aux types d’événements E1,..,EZ pour l’équipement UE(U) de l’utilisateur U et la période de notification Tnotif associée (étape F10).

En parallèle des souscriptions reçues par l’entité NF2, celle-ci maintient de façon continue pour chaque équipement d’utilisateur du réseau NW qu’elle est amenée à gérer (c’est-à-dire pour lequel elle est impliquée lors de son usage du réseau NW), et donc en particulier pour l’équipement UE(U) de l’utilisateur U, un contexte CNT dans lequel elle enregistre diverses informations en relation avec les événements de types E1,…,EZ détectés dans le réseau pour les équipements (UE) de ces utilisateurs. Les contextes CNT sont stockés par exemple dans la mémoire non volatile 5 de l’entité NF2. Dans la suite de la description, on s’intéresse plus particulièrement au contexte de l’équipement UE(U) de l’utilisateur U (aussi désigné ci-après par souci de simplification par contexte de l’utilisateur U), noté CNT(U), mais tous les contextes d’utilisateurs maintenus par l’entité NF2 sont gérés par cette dernière de façon identique au contexte CNT(U).

Plus particulièrement, le contexte CNT(U) de l’utilisateur U comprend ici une table TAB(U) listant les états de l’équipement UE(U) de l’utilisateur U impactés par les événements détectés dans le réseau pour cet équipement. Chaque état distinct pris par l’équipement UE(U) lors d’un tel événement est mémorisé dans la table TAB(U) en association avec les caractéristiques qui le définissent. Comme mentionné précédemment, la table TAB(U) peut lister des états généraux de l’équipement UE(U), tel que « connecté », « enregistré », mais également des états plus spécifiques de l’équipement UE(U) comme « présent dans la cellule A », « présent dans la cellule B », etc. On note qu’un événement peut impacter plusieurs états de l’équipement UE(U) dans la table TAB(U).

La table TAB(U) comprend également, pour chaque état de l’équipement UE(U) de l’utilisateur U, des statistiques relatives à cet état, évaluées par l’entité NF2, comme décrit plus en détail ultérieurement. Comme indiqué précédemment, il convient de noter qu’une statistique au sens de l’invention telle qu’elle est évaluée par l’entité NF2, est obtenue en regroupant (i.e. en agrégeant) au moyen d’une fonction mathématique élémentaire (par exemple une fonction moyenne, variance, etc.) des données brutes en relation avec les états pris par l’équipement UE(U) au cours des événements détectés, collectées par l’entité NF2 jusqu’à un instant donné (par exemple, l’instant où est requis la statistique, ou l’instant où est évaluée la statistique, etc.) : elle est donc obtenue uniquement à partir de données brutes passées collectées par l’entité NF2 (par opposition à une prédiction qui fournit une indication sur le futur). Il s’agit en quelque sorte d’un condensé représentatif des données brutes passées, qui peut être obtenue de façon très simple par l’entité NF2. De telles statistiques sont typiquement la durée moyenne d’un état de l’équipement UE(U) et sa variance, l’espacement moyen entre deux occurrences de cet état et sa variance, le nombre d’occurrences de cet état, etc. La façon dont ces statistiques peuvent être évaluées est décrite davantage ultérieurement.

En outre, on suppose également ici que pour chaque état de l’équipement UE(U) de l’utilisateur U, autrement dit pour chaque entrée de la table TAB(U), celle-ci comprend un horodatage du début et de la fin de la dernière occurrence de cet état.

Dans le mode de réalisation décrit ici, outre la table TAB(U), le contexte CNT(U) de l’utilisateur U comprend également :
- des statistiques dites de profilage relatives à chacun des types d’événements possibles pour l’équipement UE(U). Ces statistiques de profilage consistent ici en des indicateurs d’activité des types d’événement possibles pour l’équipement UE(U). Ces indicateurs d’activité sont également détaillés davantage ultérieurement ; et
- une table PAST(U) destinée à comprendre les données collectées par l’entité NF2 sur les X événements les plus récents relatifs à l’équipement UE(U) ayant impacté les états de cet équipement d’utilisateur. X désigne ici un nombre entier qui peut être fixé par défaut, ou choisi par l’entité NF2 ou encore par l’entité NWDAF. Ce nombre X peut être choisi en tant que tel ou déduit d’une fenêtre temporelle maximale fixée pour définir le passé récent des événements que l’on souhaite considérer.

L’entité NF2 alimente alors chaque contexte d’utilisateur CNT qu’elle maintient de la façon suivante.

Lorsqu’un nouvel événement est détecté par l’entité NF2 pour un équipement d’utilisateur (réponse oui à l’étape test F20), par exemple pour l’équipement UE(U) de l’utilisateur U, l’entité NF2 traite cet événement de façon connue en soi (dans l’exemple envisagé ici d’un réseau NW conforme au standard 3GPP, comme défini par le standard) (étape F30), puis met à jour le contexte CNT(U) de l’utilisateur U dans sa mémoire non volatile 5 (étape F40).

Pour effectuer cette mise à jour, l’entité NF2 collecte, via son module 7 de collecte, les données relatives à l’événement détecté caractérisant le ou les états de l’équipement UE(U) impactés par cet événement (par exemple pour un changement de localisation, les données relatives à sa nouvelle localisation et notamment l’identifiant de la nouvelle cellule, l’horodatage de la fin de présence dans la localisation précédente, etc.) et les mémorise dans la table PAST(U) (étape F42). Si la table PAST(U) comprend déjà X événements, l’événement le plus ancien est supprimé afin de pouvoir stocker les données relatives au nouvel événement détecté. On note que le module 7 de collecte peut déterminer directement ces données ou les recevoir d’autres entités du réseau.

Les données relatives à un état de l’équipement UE(U) impacté par le nouvel événement détecté sont soit consignées par le module 7 de collecte dans une entrée existante de la table TAB(U) du contexte CNT(U) de l’utilisateur U correspondant au même état de l’équipement d’utilisateur UE(U) (ex. présence dans la même cellule), soit, si aucune entrée existante ne correspond au même état (ex. nouvelle cellule, nouvelle communication, etc.), font l’objet de la création par le module 7 de collecte d’une nouvelle entrée dans la table TAB(U) (étape F44).

En variante, la mise à jour du contexte CNT(U) avec les données relatives à l’événement détecté peut être réalisée par un autre module de l’entité NF2 que le module 7 de collecte de données.

Puis, l’entité NF2 évalue les statistiques associées à chaque entrée qui vient d’être créée ou complétée dans la table TAB(U) (étape F46). Dans le mode de réalisation décrit ici, afin de préserver les ressources de stockage de l’entité NF2 et notamment la place occupée par les contextes d’utilisateur CNT dans la mémoire non volatile 5, les statistiques sont en effet mises à jour de façon incrémentale. En d’autres mots, à chaque fois (indexée par l’entier n) qu’une grandeur statistique G de la table TAB(U) est évaluée pour un état noté ST de l’équipement d’utilisateur considéré, sa valeur G(n) est calculée en considérant uniquement la valeur G(n-1) de la grandeur statistique obtenue lors de l’évaluation précédente de la grandeur G stockée dans la table TAB(U) et la valeur courante de l’état notée ST(n) associée au nouvel événement détecté. De cette sorte, on peut se contenter de ne conserver en mémoire que les statistiques évaluées et le nombre courant d’événements considéré pour évaluer ces statistiques.

Des statistiques de différents types peuvent être évaluées par le module 8 d’évaluation de l’entité NF2 et stockées dans la table TAB(U) de l’utilisateur U. Dans l’exemple envisagé ici, on considère :

• des statistiques STAT1 évaluées sur un nombre Ne déterminé d’événements ;
• des statistiques STAT2 évaluées sur une fenêtre temporelle périodique de largeur et de période T (ex. T = 1 heure), comme illustré àla figure 5A(sur cette figure, ST1, ST2, …, ST5 représentent des états de l’équipement d’utilisateur UE(U)) ; et
• des statistiques STAT3 évaluées sur des fenêtres temporelles plus longues de largeurs Tlong égales à des multiples entiers Q1, Q2, ... de la période T (ex. Tlong = 6 heures, 24 heures, etc.), comme représenté également sur la figure 5A.

Bien entendu, cet exemple n’est donné qu’à titre illustratif et d’autres configurations de statistiques peuvent être considérées pour chaque état de la table TAB(U) (ex. une statistique pour chaque type de statistiques précité, ou uniquement des statistiques évaluées sur un nombre déterminé d’événements, ou des statistiques périodiques et des statistiques sur des fenêtres temporelles égale à des multiples de la période, etc.).

En outre, d’autres types de statistiques peuvent être considérées dans le cadre de l’invention, comme par exemple des statistiques évaluées au moyen d’une fenêtre mobile continue (i.e. glissante). Comme illustré sur lafigure 5B, l’utilisation d’une fenêtre glissante continue consiste à faire glisser de manière continue une fenêtre de calcul de largeur temporelle T_mobsur les données collectées pertinentes pour évaluer les statistiques : ainsi à un instant d’évaluation t, les statistiques obtenues portent sur les données collectées dans la plage temporelle située entre les instants t-T_mobet t. Pour pouvoir obtenir des statistiques exactes avec une fenêtre glissante continue, il est nécessaire de stocker les données relatives aux états et aux événements détectés sur cette fenêtre temporelle, ainsi que la totalité des horodatages (début et durée) des états en plus des statistiques. Les statistiques sont en outre évaluées en temps réel même si l’arrivée des données est asynchrone. Cela peut représenter une complexité importante si des dizaines de statistiques sont à maintenir pour chaque utilisateur. Il est préférable d’utiliser cette technique sur des éléments fixes (ex. événements), c’est-à-dire qui ne sont pas susceptibles de varier au cours de la fenêtre glissante.

Comme indiqué précédemment, dans le mode de réalisation décrit ici, on considère une approche incrémentale pour évaluer les statistiques STAT1, STAT2, STAT3.

Plus particulièrement, le module 8 d’évaluation utilise ici la technique dite de Moyenne Mobile Exponentielle ou MME pour obtenir les statistiques STAT1 et STAT3. Ces statistiques portent ici, pour un état donné de l’équipement UE(U) de l’utilisateur U, sur la durée d’occurrence de cet état (moyenne et variance), et sur l’espacement entre deux occurrences de cet état (moyenne et variance). Le nombre d’occurrences de l’état est incrémenté simplement à chaque nouvelle occurrence.

De façon connue en soi, en reprenant les notations précédentes, selon la technique MME, lorsque la grandeur statistique G que l’on cherche à évaluer est une moyenne, sa valeur G(n) lors d’une étape indexée par un entier n est déduite de celle calculée à l’étape précédente n-1 de la façon suivante :
G(n) = (1-A).G(n-1) + A.E(n),
où A désigne une constante de lissage comprise entre 0 et 1. La valeur de la constante de lissage A détermine si l’on accorde ou non une grande importance au passé pour estimer la grandeur statistique G(n). Par exemple, on peut choisir A= 2/(1+P), P étant le nombre d’échantillons de moyenne mobile que l’on veut moyenner. Ainsi par exemple, A=0,25 correspond à une moyenne mobile estimée sur 9 échantillons.

Dans le mode de réalisation décrit ici, pour les statistiques STAT1, P désigne le nombre d’événements Ne que l’on souhaite moyenner pour obtenir ces statistiques. Pour les statistiques STAT3, P désigne le multiple Q1, Q2,… de la période T considéré pour évaluer ces statistiques à partir des statistiques STAT2.

Grâce à cette technique MME, le module 8 d’évaluation de l’entité NF2 peut ainsi aisément estimer la durée moyenne passée par l’équipement UE(U) dans un état considéré ou le délai moyen écoulé entre deux occurrences de cet état.

La technique MME peut également être utilisée par le module 8 d’évaluation de l’entité 2 pour estimer des variances. En effet, par définition, la variance correspond à la moyenne des carrés des écarts par rapport à la moyenne. On peut donc appliquer la technique de la Moyenne Mobile Exponentielle, en considérant la moyenne des carrés des écarts des données par rapport à l’estimation de la moyenne.

On note que la technique MME en tant que telle ne permet pas de savoir si les statistiques ainsi évaluées correspondent à une fenêtre temporelle de largeur identique pour différents utilisateurs. La fenêtre temporelle considérée dépend en effet du taux d’activité de l’utilisateur, celui-ci pouvant varier d’un utilisateur à l’autre : selon que l’utilisateur est plus ou moins actif, il peut générer plus ou moins d’états sur une même période de temps. Si l’on souhaite relier les statistiques obtenues au temps réel, il est préférable de considérer des fenêtres temporelles périodiques. Le recours à la technique MME peut être privilégié pour des données produites périodiquement, ou bien si l’on cherche, comme c’est le cas ici, une moyenne évaluée sur un nombre déterminé de données sans relier cette moyenne à la notion de temps.

Comme mentionné précédemment, pour obtenir les statistiques STAT2, le module 8 d’évaluation considère une fenêtre temporelle périodique de largeur et de période T. Cette technique consiste à déplacer la fenêtre de calcul par sauts successifs de durée T. Il obtient ainsi des statistiques évaluées sur plusieurs plages successives de largeur T. A un instant d’évaluation t=kT, Les statistiques obtenues portent donc sur les données collectées relatives aux états détectés dans la plage temporelle courante [(k-1)T,kT], où k désigne un entier.

Les statistiques STAT2 évaluées sur une fenêtre temporelle périodique de largeur T permettent avantageusement d’obtenir des statistiques périodiques sur des données élémentaires qui ne le sont pas, et ne requièrent pas de stockage de données à l’exception du nombre courant d’événements et des horodatages des premier et dernier états détectés dans la fenêtre. Ces statistiques STAT2 sont réinitialisées ici à zéro au début de chaque période de largeur T pour chaque état de l’équipement de chaque utilisateur géré par l’entité NF2, et évaluées sur la période considérée en effectuant une opération de cumul incrémental à chaque nouvel événement détecté impactant les états auxquels elles se rapportent pour un équipement d’un utilisateur donné.

Dans le mode de réalisation envisagé ici, l’opération de cumul incrémental mise en œuvre est une récurrence simple. Plus spécifiquement, si la grandeur statistique G(N) que le module 8 d’évaluation cherche à évaluer sur n occurrences d’un état survenues depuis le début de la période de durée T est une moyenne (ex. une durée moyenne de l’équipement d’utilisateur dans un état donné ou espacement moyen entre deux occurrences de cet état), le module 8 d’évaluation obtient la valeur G(n) via la récurrence simple suivante :
G(n) = (G(n-1).(n-1) + E(n))/n

Si la grandeur statistique G(n) est une variance, il suffit de considérer la moyenne des carrés diminuée du carré de la moyenne, chaque moyenne étant calculée à l’aide de la formule par récurrence donnée ci-dessus.

D’autres méthodes incrémentales qu’une récurrence simple peuvent bien entendu être envisagées en variante.

Comme indiqué précédemment, le module 8 d’évaluation évalue les statistiques STAT3 sur des fenêtres temporelles de largeur égale à des multiples entiers Q1,Q2,… de la période T, par exemple Tlong = Q1.T, Q2.T, etc.

A cet effet, il suffit alors à la clôture de chaque période de largeur T de mettre à jour les statistiques STAT3 sur Tlong. La mise à jour de chaque statistique est effectuée, dans le mode de réalisation décrit ici, en utilisant la technique MME décrite précédemment sur les valeurs des statistiques STAT2, en choisissant la constante de lissage A en fonction du multiple Q1, Q2,…. considéré pour choisir la fenêtre temporelle Tlong sur laquelle les statistiques STAT3 sont évaluées. Par exemple, si Tlong = Q1.T, le module 8 d’évaluation choisit comme constante de lissage A= 2/(1+Q1)), selon la formule de l’état de la technique introduite précédemment. Cette dernière formule peut être appliquée car les éléments (statistiques STAT2) que l’on considère dans le calcul de MME sont périodiques de période T.

On peut bien sûr en variante utiliser une autre technique de calcul incrémental, comme par exemple une formule de récurrence simple telle qu’introduite précédemment pour le calcul des statistiques STAT2.

Autrement dit, si l’on évalue par exemple une statistique STAT2 initiale via une technique de fenêtre périodique sur une période T de quelques minutes, on peut aisément ensuite via une technique MME ou une autre technique incrémentale comme une récurrence simple, évaluer de manière périodique des statistiques STAT3 sur une heure, sur 24 heures, sur les jours précédents, etc., avec peu de calcul et sans avoir besoin de stocker d’autres éléments que les statistiques elles-mêmes.

Comme mentionné précédemment, dans le mode de réalisation décrit ici, l’entité NF2 adopte une approche incrémentale pour calculer les statistiques STAT1, STAT2, STAT3 : cette approche permet de réduire la quantité de données à stocker en mémoire pour mettre en œuvre l’invention. Toutefois, dans un autre mode de réalisation, on peut envisager de mémoriser, pour chaque période de temps considérée sur laquelle on évalue les statistiques STAT1, STAT2 et STAT3, les données nécessaires à leur évaluation, et évaluer à l’issue de cette période les statistiques à partir des données stockées.

Dans le mode de réalisation décrit ici, lors de la mise à jour du contexte CNT(U), outre la mise à jour de la table TAB(U), l’entité NF2 estime par ailleurs pour l’utilisateur U, au moyen de son module 9 d’estimation, une statistique dite de profilage associée au type d’événement détecté (étape F48). Cette statistique de profilage consiste ici en un indicateur estimatif de l’activité de ce type d’événement pour l’équipement UE(U) sur une période mobile longue, par exemple égale à plusieurs fois la période T considérée précédemment pour l’évaluation des statistiques STAT2 ou correspondant à un nombre Ne d’événements déterminés. Dans le mode de réalisation décrit ici, l’indicateur d’activité d’un type d’événement comprend une estimation de la moyenne et de la variance de l’espacement temporel entre deux événements de ce type, que le module 9 d’estimation estime ici de façon incrémentale au moyen de la technique MME précédemment décrite.

En variante, d’autres indicateurs d’activité d’un type d’événement peuvent être estimés lors de la mise à jour du contexte CNT(U) de l’utilisateur U, comme par exemple une estimation de la régularité de l’occurrence de ce type d’événement pour l’équipement UE(U) de l’utilisateur U.

La mise à jour des contextes CNT des utilisateurs du réseau gérés par l’entité NF2 est réalisée à chaque nouvel événement détecté dans le réseau en relation les équipements UE de ces utilisateurs. Les étapes F20 à F40 qui viennent d’être décrites sont alors réitérées pour traiter ce nouvel événement.

On note que dans le mode de réalisation décrit ici, pour limiter le nombre d’entrées dans la table TAB(U) de chaque utilisateur U (pour des raisons évidentes de complexité et d’espace mémoire requis), l’entité NF2 met en œuvre un mécanisme de filtrage des entrées de la table TAB(U). En effet, comme indiqué précédemment, lors de l’étape F42, lors de la détection d’un nouvel événement relatif à l’équipement UE(U), chaque état de l’équipement UE(U) impacté par cet événement est consigné dans la table TAB(U) soit dans une entrée existante soit dans une nouvelle entrée. La table TAB(U) peut donc être amenée à comprendre un grand nombre d’entrées en cas d’états très versatiles de l’équipement UE(U). Pour pallier cet inconvénient, on fixe un nombre K maximum d’entrées dans la table TAB(U) afin de garder une table TAB(U) de dimension raisonnable pour chaque utilisateur U. La valeur choisie pour K peut varier d’une entité NF à une autre (selon la nature de la fonction réseau hébergée par l’entité NF), et/ou en fonction d’autres paramètres comme par exemple, la période de temps observée, l’usage qui est fait du réseau, le contexte dans lequel est mise en œuvre l’invention, etc.

L’entité NF2 met alors en œuvre un mécanisme de filtrage des entrées (autrement dit des données collectées et stockées dans la table TAB(U)) en fonction de la représentativité de ces données de l’état de l’équipement UE(U) de l’utilisateur U. Plus particulièrement :
- si une entrée doit être ajoutée, l’entité NF2 créée via son module 7 de collecte une entrée dans une table temporaire TAB_TEMP(U) (limitée à un nombre entier M d’entrées, M pouvant être différent de K), avec les données collectées et des informations d’horodatage des données collectées qui permettent d’initialiser les statistiques ;
- si une entrée est mise à jour, l’entité NF2 met à jour via son module 7 de collecte une des entrées déjà existantes parmi les K entrées de la table TAB(U) ou les M entrées temporaires de la table temporaire TAB_TEMP(U). Dans ce cas, une entrée de la table temporaire TAB_TEMP(U) est candidate à devenir pérenne et à être stockée dans la table TAB(U) de l’utilisateur U. Si la table TAB(U) comprend déjà K entrées, alors une entrée de la table TAB(U) est supprimée par le module 7 de collecte de l’entité NF2. A cet effet, le module 7 de collecte identifie l’entrée de la table TAB(U) de moindre importance au regard d’un critère déterminé tel que par exemple, la durée de séjour de l’équipement UE(U) dans l’état associé à cette entrée, l’espacement entre deux occurrences de cet état, l’horodatage de la dernière occurrence de cet état, etc. On peut également envisager une combinaison de plusieurs critères : par exemple, le module 7 de collecte conserve les entrées correspondant aux plus grandes durées de séjour dans les états associés à ces entrées, puis considère les entrées présentant les plus faibles espacements entre deux occurrences des états qui leur sont associés, puis les entrées associées aux états ayant les horodatages les plus récents. Bien entendu d’autres critères peuvent être envisagés en variante.

Si la table temporaire TAB_TEMP(U) est saturée, le module 7 de collecte procède également à un filtrage des entrées contenues dans cette table temporaire, par exemple sur la base d’un critère d’horodatage des données consignées.

En variante, ou en complément du mécanisme de filtrage précédent, le module 7 de collecte peut également filtrer (i.e. supprimer)a prioriles données correspondant à une durée de séjour brève de l’équipement UE(U) dans un état, c’est-à-dire en dessous d’une durée seuil prédéterminée, avant même toute insertion dans la table temporaire TAB(U).

Le mécanisme de filtrage qui vient d’être décrit permet avantageusement de ne conserver dans la table TAB(U) que les données les plus significatives (c’est-à-dire les plus représentatives) des états habituels de l’équipement UE(U) de l’utilisateur U. Dans le mode de réalisation décrit ici, il est complété par un filtrage, autrement dit une suppression, des contextes trop anciens d’utilisateurs inactifs maintenus par l’entité NF2 de sorte à ne garder dans sa mémoire non volatile 5 qu’un nombre limité de contextes d’utilisateurs actifs et inactifs.

A partir de l’horodatage du dernier événement détecté pour l’équipement d’utilisateur d’un utilisateur donné, l’entité NF2 peut estimer depuis combien de temps l’équipement d’utilisateur en question est inactif le cas échéant, et supprimer le contexte associé à cet utilisateur si l’estimation dépasse une durée maximale de rétention de contexte inactif donnée. Ce filtrage peut être mis en œuvre périodiquement ou si un nombre maximal donné de contextes inactifs stockés dans la mémoire non volatile 5 de l’entité NF2 est atteint.

Bien entendu, d’autres mécanismes de filtrage et d’autres critères peuvent être mis en œuvre par l’entité NF2 pour préserver ses ressources mémoires. Par exemple, au lieu de filtrer les données les moins représentatives des états habituels de l’équipement UE(U), on peut au contraire décider de garder ces données qui peuvent fournir une information contextuelle intéressante pour l’entité NWDAF, et au contraire supprimer certaines données stockées qui sont plus conformes à un état attendu ou habituel de l’équipement UE(U), par exemple parce qu’elles sont redondantes avec d’autres données ou conformes aux statistiques évaluées par l’entité NF2 (c’est-à-dire qu’elles n’apportent pas d’information supplémentaire).

Comme mentionné précédemment, dans le mode de réalisation décrit ici, l’entité NWDAF a souscrit auprès de l’entité NF2 pour être notifiée périodiquement, par exemple toutes les périodes temporelles de durée Tnotif, des éléments d’information collectés par l’entité NF2 en relation avec les événements détectés par celle-ci pour l’équipement UE(U). Ainsi, si la période temporelle Tnotif pour notifier l’entité NWDAF est atteinte (réponse oui à l’étape test F50), l’entité NF2 informe l’entité NWDAF, via son module 10 de transmission, de tous les éléments d’information qu’elle a collectés pour l’équipement UE(U) de l’utilisateur U sur la période temporelle Tnotif (étape F60).

Plus particulièrement, elle fournit pour l’équipement UE(U) les éléments d’informations suivants :
- la dernière mise à jour des statistiques qu’elle a évaluées pour les états de l’équipement UE(U) qui ont été modifiés durant la période Tnotif, autrement dit ici, les statistiques STAT1, STAT2, STAT3 des états de l’équipement UE(U) évaluées jusqu’à l’expiration de la période temporelle Tnotif ;
- les données collectées par le module 7 de collecte de l’entité NF2 sur les X derniers événements uniquement, détectés pour l’équipement UE(U) et mémorisées dans la table PAST(U) (pas de fourniture des autres données collectées au-delà de ce passé « récent »). Dans une variante, l’entité NF2 ne remonte les données collectées que pour les X derniers événements ayant impacté les états modifiés durant la période Tnotif ; et
- les statistiques de profilage estimées pour chaque type d’événement détecté durant la période temporelle de notification Tnotif.

On note qu’en variante, la notification par l’entité NF2 des éléments d’information précités à l’entité NWDAF peut se faire sur d’autres critères qu’un critère périodique. Par ailleurs, dans une variante de réalisation, plutôt que de souscrire auprès de l’entité NF2 à la notification de ces éléments d’information, l’entité NWDAF peut demander périodiquement ou ponctuellement à l’entité NF2 de lui notifier les éléments d’information qu’elle a collectés durant la période précédente.

En référence à la figure 3, sur réception des éléments d’information notifiés par l’entité NF2 via son module 11 de réception (étape E30), l’entité NWDAF exploite ces éléments d’information (ainsi que ceux qui lui ont été fournis par le passé) pour effectuer l’analyse statistique ou la prédiction qui lui a été demandée par l’entité cliente NF1 (étape E40). Elle procède à cet effet de façon connue en soi en utilisant son module 12 d’analyse et de prédiction. L’entité NWDAF dispose avantageusement à cet effet non seulement de statistiques préétablies par l’entité NF2, mais également d’informations contextuelles venant compléter ces statistiques, grâce à la fourniture des données brutes collectées relatives aux X derniers événements détectés pour l’équipement UE(U), ces informations contextuelles pouvant s’avérer utiles pour mener l’analyse statistique et/ou la prédiction requise par l’entité NF1.

Grâce à l’invention, on limite la quantité d’éléments d’information échangés entre l’entité NF2 et l’entité NWDAF, et la quantité d’information stockée par l’entité NF2, sans pour autant sacrifier la représentativité de ces éléments d’information et leur utilité pour l’entité NWDAF.

Dans la suite de la description, on donne un exemple illustratif des éléments d’information pouvant être collectés/évalués et fournis par une entité NF de type AMF à une entité NWDAF. L’entité AMF peut maintenir, pour chacun des utilisateurs U qu’elle gère :
- des statistiques STAT2 des états de l’équipement UE(U) évaluées sur une période temporelle de durée T précédente. Par exemple, l’entité AMF comptabilise les emplacements les plus fréquents de l’équipement UE(U) sur une période de durée T=1 heure ;
- des statistiques STAT3 des états de l’équipement UE(U) évaluées sur une période temporelle longue précédente, c’est-à-dire des moyennes des statistiques STAT2 évaluées sur des périodes de durée T. Par exemple, l’entité AMF peut comptabiliser les emplacements les plus fréquents de l’équipement UE(U) sur les 8 derniers heures (Q1=8), sur 24 heures (Q2=24) avant ou sur la semaine précédente (Q3=168) ;
- la liste PAST(U) des derniers événements détectés pour l’équipement UE(U) sur une fenêtre temporelle maximale (par exemple les X=30 derniers événements ou les événements détectés sur les 120 dernières minutes) et les données collectées lors de ces événements. Il est à noter que le choix d’un nombre X d’événements plutôt qu’une durée permet de s’affranchir du cas où les rythmes d’arrivées sont très variables pour les utilisateurs ; et
- des statistiques de profilage mesurant le délai moyen et la variance entre deux événements d’un même type pour l’équipement UE(U) pour tous les événements pouvant être exposés pour l’équipement d’utilisateur UE(U) par l’entité AMF (par exemple perte de connectivité, accessibilité des terminaux des utilisateurs, rapport de localisation, etc.).

Dans le mode de réalisation qui vient d’être décrit, des mécanismes sont prévus pour limiter la quantité d’informations stockée par les entités NF ainsi que la quantité d’informations remontées par ces dernières à l’entité NWDAF. Outre ces mécanismes, un choix judicieux des paramètres de déploiement de l’invention (dimensions des tables maintenues par les entités NF, largeurs des fenêtres temporelles considérées pour construire les statistiques, etc.) peut permettre de limiter encore davantage le coût de mise en œuvre de l’invention et rendre plus efficace cette mise en œuvre.

Les paramètres de déploiement peuvent notamment être dimensionnés en fonction de l’activité moyenne des utilisateurs dans le réseau NW. Ils peuvent varier suivant la nature du réseau également, et notamment l’application à laquelle il est destiné (ex. atelier flexible, réseau téléphonique d’entreprise, réseau public, réseau de compteurs à gaz, réseau de véhicules).

Dans le mode de réalisation qui a été décrit, il peut être nécessaire de fixer les paramètres suivants selon l’implémentation retenue pour évaluer les statistiques :
- nombre d’événements Z observés et exposés par chaque entité NF, par exemple pour une entité AMF Z=16 selon le document TS 29.518, v16.4.0 ;
- nombre K d’entrées de la table TAB(U), par exemple pour une entité NF, 10 à 15 localisations favorites. Ce nombre peut toutefois varier en fonction de l’utilisateur U ;
- la largeur T de la fenêtre périodique considérée pour évaluer les statistiques STAT2, par exemple T=30 minutes pour un réseau NW public ;
- le nombre N1 de statistiques STAT3 de périodes longues évaluées, par exemple N1=3 ;
- les multiples Q1, Q2, …, QN1 de la période T pour définir les périodes longues considérées pour calculer les statistiques STAT3, par exemple pour N1=3 et T=30 minutes, Q1=4 (conduisant à une période longue de 2 heures), Q2=16 (conduisant à une période longue de 8 heures) et Q3=48 (conduisant à une période longue de 24 heures) ;
- le nombre Ne d’événements considérés dans la fenêtre glissante pour calculer les statistiques de profilage (indicateurs d’activité de chaque type d’événement), par exemple Ne = 40 ;
- le nombre X d’événements récents stockés dans la table PAST(U) et conservés en mémoire, par exemple X = 10.

Le nombre d’éléments d’information fournis périodiquement par une entité NF à l’entité NWDAF est donné dans la table 1 (la taille de chaque élément d’information fourni est omise ici par souci de simplification, celle-ci dépendant du nombre de données comprises dans chaque élément et de la dimension de ces données). On fait ici l’hypothèse que l’entité NF fournit des statistiques STAT1, STAT2, STAT3 pour chaque état de l’équipement UE(U) de l’utilisateur U, le passé récent des X derniers événements, et un indicateur de profilage pour chaque type d’événement exposé par l’entité NF.

Eléments d’information	Quantité
Statistiques STAT1	K
Statistiques STAT2 évaluées sur période récente de largeur T	K
Statistiques STAT3 évaluées sur périodes plus longues (T.Qi)	N1.K
Données collectées pour les X derniers événements	X
Indicateurs de profilage pour chaque type d’événement	Z
TOTAL	(N1+2).K+X+Z

Ainsi, au vu de ce qui précède, pour fixer les paramètres de déploiement, on peut chercher par exemple un compromis entre :
- une taille raisonnable d’informations à conserver et à stocker sur chaque entité NF ;
- des flux de notifications trop importants (notamment notifications périodiques) lors de la remontée des statistiques ; et
- une bonne observabilité des états de l’UE de chaque utilisateur.

La table 2 fournit à titre illustratif, deux exemples de stratégies pour fixer les paramètres pouvant être retenus pour atteindre ce compromis pour une entité AMF :

Paramètres	Stratégie 1 court terme	Stratégie 2 long terme
Z	16	16
K	10	20
T	5 minutes	30 minutes
N1	2	4
Q1,Q2,…QN1	- Q1=3 (période longue d’un quart d’heure) - Q2=12 (période longue d’une heure)	- Q1=2 (période longue d’une heure) - Q2=16 (période longue de 8 heures) - Q3=48 (période longue d’un jour) - Q4=336 (période longue d’une semaine)
Ne	40	40
X	10	20
TOTAL	66 éléments d’information	156 éléments d’information
Période de notification Tnotif	1 notification par heure	1 notification par jour

Bien entendu, ces exemples ne sont donnés qu’à titre illustratif et d’autres critères peuvent être envisagés pour fixer les paramètres de déploiement de l’invention.

Dans le mode de réalisation et dans les exemples illustratifs décrits ici, on a considéré que l’entité de fourniture des données est une entité NF hébergeant une fonction réseau et que l’entité d’analyse des données est une entité DAF ou NWDAF centralisée du réseau NW. L’invention s’applique toutefois dans d’autres contextes, comme évoqué précédemment. Ainsi, par exemple, l’entité de fourniture des données peut être un équipement (UE) de l’utilisateur, tel que son terminal, et on s’intéresse à des données collectées lors d’événements détectés par cet équipement d’utilisateur ou par le réseau ayant impacté au moins un état de l’équipement d’utilisateur. L’entité d’analyse peut être une entité NF ou une autre entité du réseau capable d’analyser des données qui lui sont fournies, et par exemple de réaliser à partir de ces données des prédictions ou des analyses statistiques.

Claims (18)

1. Procédé de fourniture de données relatives à au moins un équipement d’utilisateur à une entité (DAF) d’un réseau, dite d’analyse de données, ledit procédé comprenant :

   • une étape de collecte (F42), pour une pluralité d’événements ayant impacté au moins un état dudit équipement d’utilisateur dans le réseau, de données relatives audit au moins un état impacté par les événements ; et
   • une étape de fourniture (F60), à ladite entité dite d’analyse (DAF), pour au moins un dit état impacté dudit équipement d’utilisateur :
     • d’au moins une statistique obtenue pour cet état en agrégeant des données relatives à cet état collectées lors de l’étape de collecte, et
     • d’une partie des données relatives à cet état collectées lors de l’étape de collecte et correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements les plus récents de ladite pluralité d’événements.
2. Procédé de fourniture selon la revendication 1 dans lequel l’étape de collecte (F42) et l’étape de fourniture (F60) sont mises en œuvre par une entité du réseau (NF2) gérant une pluralité d’équipements d’utilisateurs.
3. Procédé de fourniture selon la revendication 1 dans lequel l’étape de collecte et l’étape de fourniture sont mises en œuvre par ledit équipement d’utilisateur.
4. Procédé de fourniture selon l’une quelconque des revendications 1 à 3 comprenant en outre une fourniture (F60) à ladite entité d’analyse (DAF), pour chaque type d’événement de ladite pluralité d’événements, d’au moins un indicateur d’activité pour ce type d’événement.
5. Procédé de fourniture selon la revendication 4 dans lequel un dit indicateur d’activité d’un dit type d’événement comprend une estimation d’une durée d’espacement entre deux événements de ce type détectés pour ledit équipement d’utilisateur.
6. Procédé de fourniture selon l’une quelconque des revendications 1 à 5 dans lequel au moins une dite statistique relative à un dit état dudit équipement d’utilisateur est mise à jour de façon incrémentale (F44) à chaque événement détecté concernant ledit équipement d’utilisateur et impactant ledit état.
7. Procédé de fourniture selon l’une quelconque des revendications 1 à 6 dans lequel au moins une dite statistique est évaluée sur une fenêtre temporelle glissante ou sur une fenêtre temporelle périodique de période notée T ou sur une fenêtre temporelle de largeur égale à un multiple entier de la période T.
8. Procédé de fourniture selon l’une quelconque des revendications 1 à 7 dans lequel au moins une dite statistique et/ou un indicateur d’activité est évalué en utilisant une moyenne mobile exponentielle.
9. Procédé de fourniture selon l’une quelconque des revendications 1 à 8 comprenant une étape de filtrage des données collectées en fonction d’une représentativité desdites données d’un état habituel de l’équipement d’utilisateur.
10. Procédé de fourniture selon l’une quelconque des revendications 1 à 9 dans lequel l’étape de fourniture est mise en œuvre périodiquement et/ou en réponse à une requête de l’entité d’analyse.
11. Procédé d’obtention de données relatives à au moins un équipement d’utilisateur, par une entité (DAF) d’un réseau (NW) dite d’analyse de données, ladite entité d’analyse (DAF) étant apte à communiquer avec au moins une autre entité configurée pour collecter, pour une pluralité d’événements ayant impacté au moins un état dudit équipement d’utilisateur dans le réseau, des données relatives audit au moins un état impacté, ledit procédé comprenant, une étape de réception (E30), pour au moins un dit état impacté dudit équipement d’utilisateur:
    - d’au moins une statistique obtenue par l’autre entité pour cet état en agrégeant des données relatives à cet état collectées par ladite autre entité pour ladite pluralité d’événements ; et
    - d’une partie des données relatives à cet état collectées par ladite autre entité pour ladite pluralité d’événements, ladite partie des données correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements plus récents de ladite pluralité d’événements.
12. Programme d’ordinateur (PROG-NF, PROG-DAF) comportant des instructions pour la mise en œuvre d’un procédé de fourniture selon l’une quelconque des revendications 1 à 10 ou d’un procédé d’obtention selon la revendication 11 lorsque le programme est exécuté par un ordinateur.
13. Support d’enregistrement (4), lisible par un ordinateur et comportant des instructions d’un programme d’ordinateur selon la revendication 12.
14. Entité (NF) comprenant des modules, activés pour au moins un équipement d’utilisateur, et comprenant :
    - un module (7) de collecte, configuré pour collecter pour une pluralité d’événements ayant impacté au moins un état de l’équipement d’utilisateur dans un réseau, des données relatives audit au moins un état impacté par lesdits événements ;
    - un module (8) d’obtention de statistiques, configuré pour obtenir, pour au moins un dit état impacté de l’équipement d’utilisateur, au moins une statistique en agrégeant des données relatives à cet état, collectées par le module de collecte ; et
    - un module (10) de transmission, configuré pour fournir à une entité du réseau dite d’analyse de données, pour ledit au moins un dit état impacté de l’équipement d’utilisateur, ladite au moins une statistique obtenue pour cet état par le module d’obtention et une partie des données collectées par le module de collecte, relatives à cet état, et correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements les plus récents de ladite pluralité d’événements.
15. Entité (DAF) d’un réseau (NW) dite d’analyse de données, apte à communiquer avec une autre entité (NF) configurée pour collecter, pour une pluralité d’événements ayant impacté au moins un état d’au moins un équipement d’utilisateur dans le réseau, des données relatives audit au moins un état impacté, ladite entité d’analyse comprenant un module (11) de réception activé pour ledit au moins un équipement d’utilisateur, et configuré pour obtenir, en provenance de ladite autre entité pour au moins un dit état impacté dudit équipement d’utilisateur :
    - au moins une statistique obtenue par ladite autre entité pour ledit état impacté en agrégeant des données relatives à cet état collectées par ladite autre entité pour ladite pluralité d’événements ; et
    - une partie des données relatives à cet état collectées par ladite autre entité pour ladite pluralité d’événements, ladite partie des données correspondant à un nombre entier X supérieur ou égal à 1 d’événements parmi les événements les plus récents de ladite pluralité d’événements.
16. Système (1) de télécommunication comprenant au moins une entité (NF) selon la revendication 14 et une entité d’analyse (DAF) selon la revendication 15.
17. Système (1) selon la revendication 16 dans lequel ladite entité selon la revendication 14 est une entité (NF2) du réseau gérant une pluralité d’équipements d’utilisateurs.
18. Système selon la revendication 16 dans lequel ladite entité selon la revendication 14 est ledit équipement d’utilisateur.