FR3137244A1

FR3137244A1 - Procédés de fourniture et de collecte, station de base, dispositif de collecte et d’analyse de données et système

Info

Publication number: FR3137244A1
Application number: FR2206373A
Authority: FR
Inventors: Charles Hartmann; Antoine Mouquet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2022-06-27
Filing date: 2022-06-27
Publication date: 2023-12-29
Also published as: WO2024002868A1

Abstract

Procédés de fourniture et de collecte, station de base, dispositif de collecte et d’analyse de données et système L’invention concerne un procédé de fourniture d’informations par une station de base d’un réseau de communications cellulaire, ledit procédé comprenant, suite à une sollicitation (E40) d’un dispositif de collecte et d’analyse de données du réseau, une étape (E60) de transmission audit dispositif de collecte et d’analyse, d’informations (INFO_CURR) représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par la station de base. Figure 4

Description

Procédés de fourniture et de collecte, station de base, dispositif de collecte et d’analyse de données et système

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

Elle concerne plus particulièrement la fourniture d’informations permettant d’améliorer certaines fonctionnalités implémentées par des entités d’un réseau de communication cellulaire. L’invention a une application privilégiée mais non limitative dans le contexte d’un système ou réseau de communication cellulaire s’appuyant sur un réseau cœur 5G (ou 5GC pour « 5G Core network » en anglais) défini par le standard 3GPP. Elle permet notamment dans ce contexte d’améliorer les fonctionnalités implémentées par un dispositif de collecte et d’analyse de données du réseau aussi désigné par NWDAF (pour « NetWork Data Analytics Function » en anglais).

Les réseaux de communication modernes, tels que les 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 d’équipements utilisateurs (ou UEs pour « User Equipments » en anglais) à 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 mettent en place au sein de leurs réseaux une ou plusieurs entités spécialisées, chargées de collecter des données du réseau et de réaliser à partir de ces données des analyses statistiques et des prédictions (aussi désignées par « analytics » en anglais) par exemple sur la demande et la réponse apportées par le réseau en matière 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 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. A titre illustratif, dans un réseau cœur 5G, la fonction NWDAF assure un tel rôle.

La réalisation de prédictions par une fonction NWDAF suppose la collecte préalable de données brutes représentatives de faits réseau (ex. état connecté de l’UE, cellule dans laquelle il se trouve, etc.) auprès de différentes entités composant le réseau, aussi communément désignées par « fonctions 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 NWDAF, qui peuvent être distinctes ou non des fonctions NF ayant collecté et fourni les données brutes à la fonction NWDAF, telles que par exemple une fonction AMF (pour « Access and Mobility management Function » en anglais) de gestion d’accès, une fonction SMF (pour « Session Management Function » en anglais) de gestion de sessions, etc. Ces fonctions NF clientes sont alors en mesure d’adapter leur comportement en fonction des prédictions reçues de la fonction NWDAF 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, évoque différents cas d’usage de telles prédictions dans un réseau 5G. Ainsi, par exemple, les prévisions de mobilité des UEs peuvent être utilisées par la fonction AMF pour optimiser la gestion de la mobilité des UE, et en particulier la détermination de leur zone d’enregistrement (ou RA pour « Registration Area » en anglais), cette zone d’enregistrement permettant de localiser des UE en veille et de leur adresser des messages de paging lorsque des données leur étant destinées parviennent au réseau, etc. Selon un autre exemple, il peut s’avérer utile à la fonction SMF de disposer de statistiques ou de prédictions sur le trafic réseau lors de la sélection d’une fonction UPF (pour « User Plane Function » en anglais) de plan utilisateur permettant d’acheminer les données des sessions PDU (pour « Packet Data Unit » en anglais).

On comprend bien dès lors, au vu de leur importance dans le fonctionnement opérationnel du réseau, que les statistiques et/ou les prédictions délivrées par la fonction NWDAF doivent être précises et pertinentes.

L’invention permet d’améliorer la précision et la pertinence des statistiques et/ou prédictions délivrées par un dispositif de collecte et d’analyse de données d’un réseau tel qu’une fonction réseau NWDAF dans un réseau 5G. A cet effet, elle propose un procédé de fourniture d’informations par une station de base d’un réseau de communications cellulaire, ce procédé comprenant, suite à une sollicitation d’un dispositif de collecte et d’analyse de données du réseau, une étape de transmission audit dispositif de collecte et d’analyse d’informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par la station de base.

Corrélativement, l’invention vise une station de base d’un réseau de communications cellulaire comprenant un module de transmission activé suite à une sollicitation d’un dispositif de collecte et d’analyse de données du réseau, ledit module étant configuré pour transmettre audit dispositif de collecte et d’analyse des informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par la station de base.

L’invention propose donc de fournir au(x) dispositif(s) de collecte et d’analyse de données du réseau des informations représentatives des conditions de déploiement courantes des cellules du réseau (comme par exemple des relations d’adjacence des cellules), afin que le(s)dit(s) dispositif(s) puisse(nt) s’en servir lors de l’établissement des prédictions et/ou des statistiques qui lui (leur) sont demandées. Ces informations peuvent être exploitées pour fournir des prédictions et/ou des statistiques plus précises et plus pertinentes tenant compte du contexte de déploiement des cellules du réseau.

En outre, la fourniture de telles informations au(x) dispositif(s) de collecte et d’analyse du réseau permet d’alimenter les modèles d’intelligence artificielle (ou IA) exploités le cas échéant par ce(s) dispositif(s) avec des données d’entrée enrichies, et ainsi de construire des modèles d’IA plus précis et plus pertinents pour les besoins/objectifs des fonctions réseau sollicitant le(s) dispositif(s) de collecte. Typiquement, grâce à l’enrichissement des données d’entrée des modèles d’IA avec les informations représentatives des conditions de déploiement courantes des cellules du réseau, il est possible de faire apparaître des associations nouvelles et/ou d’éliminer des variables peu pertinentes par rapport aux finalités des traitements mis en œuvre par les fonctions réseau clientes.

Grâce à l’invention, la qualité des décisions prises dans le réseau cœur peut ainsi être améliorée.

Par informations représentatives de conditions de déploiement courantes d’une cellule, on entend des informations qui traduisent les conditions réelles dans laquelle la cellule est déployée à l’instant considéré. Différents types d’informations sont concernés. Par exemple, au moins une dite information représentative de conditions de déploiement courantes est relative à :

une disposition de la cellule dans une architecture du réseau (ex. couverture, voisinage radio),
un environnement géographique de la cellule,
un type de déploiement de la cellule,
une configuration d’au moins une antenne de la cellule,
au moins une infrastructure couverte par la cellule (ex. route, voie ferrée, bâtiment, etc.), et/ou
un état de la cellule (ex. charge de la cellule, charge au niveau de chaque tranche de réseau (« network slice » en anglais), nombre d’utilisateurs actifs, débit en liaison montante (UL pour « UpLink » en anglais) ou descendante (DL pour « DownLink » en anglais), indicateurs de congestion, état d’alarme, état en termes de sécurité, etc.).

Ces informations sont dynamiques et susceptibles d’évoluer dans le temps, typiquement du fait d’une reconfiguration des stations de base, de l’apparition de nouvelles infrastructures, de l’extinction de certaines cellules (ex. des petites cellules ou « small cells » prévues pour des raisons capacitaires, pendant des périodes où le réseau est peu utilisé comme la nuit, afin de réduire la consommation énergétique du réseau), etc. La connaissance du déploiement réel des cellules du réseau peut être exploitée pour améliorer l’efficacité des procédures mises en œuvre dans le réseau, et incidemment la qualité de service en résultant. Par exemple, les prédictions de mobilité d’un UE réalisées par une fonction réseau NWDAF dans un réseau 5G peuvent être facilitées et rendues plus précises si l’on sait que l’UE se déplace sur un axe routier principal. Selon un autre exemple, les informations de congestion d’une cellule ou de débit moyen atteint en UL et/ou en DL peuvent influencer les prédictions de qualité de service, et incidemment les décisions prises à partir de ces prédictions.

Il convient de noter que d’autres informations relatives à ladite au moins une cellule gérée par la station de base, en plus des informations de conditions de déploiement courantes de la cellule, peuvent être transmises au dispositif de collecte et d’analyse, comme par exemple des informations de configuration statique de la cellule telles que :

une identité de ladite au moins une cellule ; et/ou
une bande de fréquence allouée à ladite au moins une cellule ; et/ou
au moins une technologie d’accès radio associée à ladite au moins une cellule ;
etc ;

ou d’autres informations davantage liées au fonctionnement opérationnel du réseau comme par exemple l’appartenance d’une cellule à une zone de localisation ou TA (pour « Tracking Area » en anglais), une TA pouvant comprendre une ou plusieurs cellules du réseau cellulaire.

Cette liste n’est pas exhaustive bien entendu, et on peut envisager d’enrichir les connaissances du dispositif de collecte et d’analyse avec d’autres informations encore, comme par exemple des informations relatives à la station de base, déjà connues et partagées par cette dernière dans l’état de la technique telle que son identité, la liste des TA et/ou des tranches de réseau qu’elle supporte, ou des informations relatives à un état de la station de base (ex. niveau de charge, niveau de congestion), etc.

Dans un mode particulier de réalisation, les informations sont transmises par la station de base au dispositif de collecte et d’analyse en les exposant via une interface de programmation applicative de la station de base.

Corrélativement, la station de base peut être configurée pour implémenter une interface de programmation applicative pour exposer lesdites informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par la station de base, ladite interface de programmation applicative étant utilisée par ledit module de transmission.

L’exposition via une interface de programmation applicative de la station de base ou API (pour « Application Programming Interface » en anglais) telle que par exemple une API RESTful, permet de faciliter la mise en œuvre de l’invention et de s’appuyer sur le plan de contrôle (ou « Control Plane » en anglais) du réseau. Elle permet de réutiliser certains principes et protocoles déjà mis en œuvre par le réseau cœur en particulier dans le contexte d’un réseau cœur 5GC. Il n’est pas nécessaire de recourir à une couche de gestion supplémentaire, qui rendrait le système plus complexe et limiterait la dynamicité des échanges d’information, par exemple en cas de modification des conditions de déploiement (ex. liée à une reconfiguration automatique d’une station de base et à la modification des informations de voisinage pouvant en découler).

De façon connue en soi, une API est un ensemble normalisé de classes, de méthodes/fonctions, de types de données et/ou de constantes, qui sert d’interface à une entité (en l’occurrence ici à la station de base) pour fournir à d’autres entités des services (à savoir ici, fournir des informations relatives aux conditions de déploiement courantes des cellules gérées par la station de base). L’exposition de ces informations par la station de base via une API permet donc en outre de faciliter l’accès à ces informations par d’autres dispositifs du réseau qu’un dispositif de collecte et d’analyse de données, tels que par exemple par tout autre dispositif du réseau cœur hébergeant une fonction réseau dès lors qu’il a la capacité d’appeler cette API.

Comme évoqué ci-dessus, l’invention s’applique de façon privilégiée dans le contexte d’un réseau 5G. Elle peut toutefois être utilisée dans d’autres contextes. En effet, certains acteurs du domaine des télécommunications anticipent pour la 6^èmegénération de réseaux mobiles (aussi appelée plus communément 6G), un effacement des frontières entre réseau(x) d’accès et réseau cœur. Dans cette perspective, les architectures de réseau basées sur des interfaces de signalisation du plan de contrôle, peuvent présenter des avantages importants, rendant possible l’accès aux contextes internes propres aux équipements/fonctions virtualisées du réseau. L’invention peut donc aisément s’appliquer dans un tel contexte également.

Aucune limitation n’est attachée à la façon dont la station de base est sollicitée par le dispositif de collecte et d’analyse pour transmettre les informations représentatives des conditions de déploiement courantes de tout ou partie des cellules qu’elle gère.

Ainsi, dans un mode particulier de réalisation, la sollicitation de la station de base comprend une réception d’une requête du dispositif de collecte et d’analyse portant sur lesdites informations, lesdites informations étant envoyées dans une réponse à ladite requête.

Autrement dit, la sollicitation déclenchant la transmission des informations représentatives des conditions de déploiement courantes des cellules gérées par la station de base peut répondre à une requête ponctuelle ou récurrente du dispositif de collecte et d’analyse. Via l’envoi d’une telle requête, le dispositif de collecte et d’analyse peut avantageusement cibler une station de base particulière et/ou des informations spécifiques qu’il souhaite obtenir.

Dans un autre mode de réalisation, ladite sollicitation comprend une souscription du dispositif de collecte et d’analyse auprès de la station de base à une notification d’événements susceptibles d’affecter lesdites conditions de déploiement courantes de ladite au moins une cellule, lesdites informations étant envoyées dans une notification d’au moins un dit événement.

Ce mode de réalisation permet avantageusement au dispositif de collecte et d’analyse d’être informé automatiquement et sans délai des changements affectant les conditions de déploiement courantes des cellules gérées par la station de base.

Il convient de noter que de telles informations représentatives des conditions de déploiement courantes des cellules ne sont, à l’exception de certaines informations relatives à l’état de la cellule, pas connues aujourd’hui des stations de base : la station de base n’a pas connaissance du contexte de déploiement réel des cellules qu’elle gère, elle dispose uniquement de paramètres radio qu’elle utilise pour gérer la qualité des liaisons radio, maintenir les communications à l’aide de mesures qu’elle réalise et/ou qui sont remontées par les UE et/ou diffuser des paramètres de sélection/resélection de cellules aux UE. Ce type d’informations n’est en effet pas exploité aujourd’hui par les stations de base dans les traitements qui leur sont confiés. Quant aux informations relatives à l’état de la cellule et/ou de la station de base, elles ne sont pas partagées avec le réseau cœur.

Dans un mode particulier de réalisation, tout ou partie des informations relatives aux conditions de déploiement courantes des cellules du réseau peuvent être configurées au niveau des stations de base par l’opérateur du réseau (par exemple sous forme de métadonnées non structurées (ex. formats XML, JSON, YAML, etc.) dans un référentiel de données normalisé ou propre à l’opérateur du réseau) ou être acquises ou déterminées par les stations de base elles-mêmes.

Ainsi, le procédé de fourniture peut comprendre une étape d’évaluation d’au moins une partie desdites informations avant de les transmettre au dispositif de collecte et d’analyse.

A titre illustratif, on peut envisager que la station de base évalue l’étendue géographique de la zone de couverture d’une cellule à partir des positions géographiques des UE que la cellule dessert, ces positions pouvant être fournies par des modules de positionnement par satellite (ex. GPS (pour « Global Positioning System » en anglais), GNSS (pour « Global Navigation Satellite Systems » en anglais)) équipant les UE ou déduites par la station de base à partir d’informations dont elle dispose sur ces UE comme leur vitesse ou une différence observée de temps d’arrivée (ou OTDOA pour « Observed Time Difference of Arrival » en anglais)).

En variante, le procédé de fourniture comprend en outre une étape d’obtention, en provenance d’un système de planification radio adapté audit réseau, d’au moins une partie desdites informations avant de les transmettre audit dispositif de collecte et d’analyse.

Un système de planification radio peut typiquement fournir des informations sur le type de déploiement envisagé pour la cellule : en zone dense, suburbaine ou rurale, en visibilité directe (ou LOS pour « Line Of Sight » en anglais) ou non (ou NLOS pour « Non Light Of Sight » en anglais), déploiement événementiel ou temporaire, configuration de la cellule (ex. macro, micro ou pico cellule), configuration des antennes de la cellule (ex. système d’antennes distribuées ou DAS (pour « Distributed Antenna System » en anglais), etc. Il peut aussi fournir des informations sur les infrastructures couvertes par la cellule, par exemple si celle-ci est déployée pour couvrir un axe routier, une voie navigable, un port, une voie ferrée, une gare, et le cas échéant identifier les infrastructures en question.

Comme il apparaît au vu de ce qui précède, l’invention s’appuie sur les stations de base du réseau cellulaire configurées pour transmettre au(x) dispositif(s) de collecte et d’analyse du réseau des informations représentatives des conditions de déploiement courantes des cellules qu’elle gère, mais également sur le ou les dispositifs de collecte et d’analyse, configurés pour recevoir de telles informations et le cas échéant, les exploiter.

Ainsi, selon un autre aspect, l’invention vise également un procédé de collecte de données par un dispositif de collecte et d’analyse de données d’un réseau de communication cellulaire, ledit procédé comprenant :

une étape de réception en provenance d’au moins une station de base du réseau sollicitée par ledit dispositif de collecte et d’analyse, d’informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par ladite au moins une station de base ; et
une étape d’utilisation de tout ou partie desdites informations reçues lors d’une analyse de données du réseau.

Corrélativement, l’invention concerne aussi un dispositif de collecte et d’analyse de données d’un réseau de communications cellulaire comprenant :
- un module de sollicitation, configuré pour solliciter au moins une station de base du réseau ;
- un module de réception configuré pour recevoir en provenance de ladite au moins une station de base sollicitée des informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par ladite au moins une station de base ; et
- un module d’analyse configuré pour utiliser tout ou partie desdites informations reçues lors d’une analyse de données du réseau.

Le procédé et le dispositif de collecte bénéficient des mêmes avantages cités précédemment que le procédé de fourniture et la station de base.

Comme évoqué précédemment, dans un mode particulier de réalisation, au moins une dite station de base est sollicitée par le dispositif de collecte et d’analyse en envoyant une requête portant sur lesdites informations, lesdites informations étant reçues dans une réponse de la station de base à ladite requête.

Dans un autre mode de réalisation, au moins une dite station de base est sollicitée par le dispositif de collecte et d’analyse en souscrivant auprès d’elle à une notification d’événements susceptibles d’affecter lesdites conditions de déploiement courantes d’au moins une dite cellule gérée par la station de base, lesdites informations étant reçues dans une notification de la station de base d’au moins un dit événement.

Ces deux modes de réalisation peuvent être utilisés de façon exclusive ou combinée.

Dans un mode particulier de réalisation, le procédé de collecte comprend une étape d’envoi d’un résultat de ladite analyse à un autre dispositif du réseau ayant sollicité cette analyse.

Un tel résultat est par exemple une prédiction (par exemple une prédiction de la mobilité d’un équipement utilisateur géré par ledit autre dispositif) et/ou des statistiques exploitant les informations de conditions de déploiement des cellules fournies par les stations de base du réseau.

Dans un mode particulier de réalisation, le procédé de collecte comprend en outre une étape préliminaire de sélection d’au moins une dite station de base sollicitée, ladite sélection étant réalisée en fonction d’au moins un critère de sélection donné et/ou d’au moins une dite information représentative de conditions de déploiement courante d’au moins une dite cellule.

Comme évoqué précédemment, l’invention offre une grande flexibilité. Le dispositif de collecte et d’analyse peut décider quelle(s) station(s) de base il souhaite solliciter, et le cas échéant, quelle(s) information(s) sur quelle(s) cellule(s) il souhaite obtenir, en fonction par exemple des statistiques et/ou des prédictions qui lui sont demandées par les autres dispositifs du réseau. Cela permet de limiter la quantité d’informations échangées sur le réseau entre les stations de base et le dispositif de collecte et d’analyse, et stockées par le dispositif de collecte et d’analyse.

Dans un mode particulier de réalisation, les procédés de fourniture et de collecte 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 station de base 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 un dispositif de collecte et d’analyse conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de collecte 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 de collecte selon l’invention.

Selon un autre aspect, l’invention concerne un système dans un réseau de communication cellulaire comprenant :

au moins une station de base conforme à l’invention ; et
au moins un dispositif de collecte et d’analyse conforme à l’invention.

Dans un mode particulier de réalisation, la station de base implémente une interface de programmation applicative pour exposer les informations relatives aux conditions de déploiement courantes de ladite au moins une cellule qu’elle gère et le système comprend au moins un autre dispositif du réseau hébergeant une fonction réseau et configuré pour appeler l’interface de programmation applicative implémentée par la station de base.

Ce mode de réalisation permet notamment à d’autres fonctions réseau du réseau cœur que le dispositif de collecte et d’analyse d’accéder aux informations relatives aux conditions de déploiement courantes des cellules gérées par la station de base.

On peut également envisager, dans d'autres modes de réalisation, que les procédés de fourniture et de collecte, la station de base et le dispositif de collecte 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 représente, dans son environnement, un système dans un réseau conforme à l’invention, dans un premier mode de réalisation ;
la représente schématiquement l’architecture matérielle d’une station de base et d’un dispositif de collecte et d’analyse du système de la , conformes à l’invention ;
la représente les modules fonctionnels d’une station de base et d’un dispositif de collecte et d’analyse du système de la , conformes à l’invention ;
la illustre les étapes des procédés de fourniture et de collecte mis en œuvre par le système de la dans un mode particulier de réalisation.

Description de l’invention

La représente un système 1 dans un réseau NW de communication cellulaire, conforme à l’invention dans un mode particulier de réalisation. Le réseau NW est ici un réseau 5G tel que défini par le standard 3GPP, géré par un opérateur OP ; il comprend au moins un réseau d’accès AN et un réseau cœur CN.

De façon connue en soi, le réseau cœur CN s’appuie sur une pluralité de fonctions réseau ou NF proposant divers services et implémentant diverses fonctionnalités dans le réseau cœur CN, comme par exemple une fonction AMF gérant l’accès au réseau et la mobilité des UE rattachés au réseau, une fonction SMF gérant les sessions établies dans le réseau, une fonction NRF maintenant les profils des fonctions NF du réseau, une fonction NWDAF de collecte et d’analyses de données du réseau, etc. Une ou plusieurs instances de chacune des fonctions NF du réseau cœur CN peuvent être déployées pour assurer le fonctionnement opérationnel de ce dernier. Dans l’exemple de la , on considère notamment un dispositif 2 hébergeant une instance de fonction réseau AMF, un dispositif 3 hébergeant une instance de fonction réseau SMF et un dispositif 4 hébergeant une instance de fonction réseau NWDAF. Bien entendu, cet exemple n’est donné qu’à titre illustratif et est nullement limitatif de l’invention.

Pour accéder aux services offerts par le réseau NW, un équipement utilisateur ou UE 5 se connecte au réseau cœur CN par l’intermédiaire du réseau d’accès AN, et plus particulièrement d’une station de base gNB 6 de ce réseau d’accès. Aucune limitation n’est attachée à la nature de l’UE 5 : il peut s’agir d’un téléphone intelligent (ou « smartphone » en anglais), d’un ordinateur portable, d’une tablette, d’un objet, d’une machine ou d’un véhicule connecté, etc.

De façon connue en soi, chaque station de base gNB (et en particulier la station de base 6) est configurée pour gérer une ou plusieurs cellules du réseau NW. Par « cellule », on entend ici une zone géographique « unitaire » du réseau NW à laquelle on associe un identifiant de cellule (ou « NR Cell Identity » en anglais) la désignant de manière unique, et des paramètres de transmission (ex. une bande de fréquence). Il convient de noter que les mêmes paramètres de transmission peuvent être utilisés simultanément par plusieurs cellules du réseau dûment réparties pour limiter les interférences. Ainsi, dans l’exemple de la , on suppose que la station de base 6 est une gNB tri-sectorielle et gère ainsi trois cellules du réseau C1, C2 et C3 correspondant respectivement aux trois secteurs couverts par la station de base 6.

Aucune limitation n’est attachée au type de stations de base considérées pour le réseau AN. On peut envisager des stations de base fixes et/ou mobiles (par exemple embarquées dans un véhicule, dans un drone ou plus généralement dans tout système susceptible de se déplacer).

Conformément à l’invention, le système 1 comprend :

au moins une station de base gNB gérant au moins une cellule du réseau NW et conforme à l’invention, à savoir dans l’exemple de la , la station de base 6 gérant les cellules C1, C2 et C3 ; et
au moins un dispositif de collecte et d’analyse de données du réseau NW, conforme à l’invention, à savoir dans l’exemple de la , le dispositif 4 hébergeant l’instance de fonction NWDAF.

Dans le premier mode de réalisation décrit ici, chaque station de base du système 1 conforme à l’invention (incluant la station de base 6) a l’architecture matérielle d’un ordinateur telle que représentée à la . Cet ordinateur comprend notamment un processeur 7, une mémoire vive 8, une mémoire morte 9, une mémoire non volatile 10, et des moyens de communication 11 permettant notamment à chaque station de base de communiquer avec l’UE 5 ainsi qu’avec d’autres éléments du réseau NW, et notamment avec des dispositifs du réseau cœur CN tels que le dispositif NWDAF 4, ou avec d’autres éléments externes au réseau NW, comme par exemple avec un système 12 de planification radio adapté au réseau NW (ex. celui utilisé par l’opérateur OP du réseau NW pour déployer son réseau). Les moyens de communication 11 mettent en œuvre notamment dans le mode de réalisation décrit ici, pour communiquer avec les dispositifs du réseau cœur CN, une interface de programmation ou API qui lui permet d’exposer des informations à destination de ces dispositifs du réseau cœur CN.

La mémoire non volatile 10 de l’ordinateur constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 7 et sur lequel est enregistré un programme d’ordinateur PROG conforme à l’invention, comportant des instructions définissant les principales étapes d’un procédé de fourniture selon l’invention.

Le programme PROG définit les modules fonctionnels d’une station de base du système 1 (telle que la station de base 6), qui s’appuient ou commandent les éléments matériels 7 à 11 de l’ordinateur cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici, comme illustré sur la :

un module 13 de réception, configuré pour recevoir des sollicitations (i.e. des demandes, des interrogations) de dispositifs de collecte et d’analyse de données du réseau NW, et en particulier ici du dispositif NWDAF 4 ; et
un module 14 de transmission, configuré pour transmettre aux dispositifs de collecte et d’analyse ayant sollicité la station de base en question des informations notées ici INFO_CURR représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par elle.

Dans le mode de réalisation décrit ici, la station de base selon l’invention implémente une interface de programmation applicative (API) pour exposer notamment les informations INFO_CURR représentatives des conditions de déploiement courantes des cellules du réseau qu’elle gère, sur laquelle s’appuient les modules 13 de réception et 14 de transmission. L’avantage d’une telle API est qu’elle est universelle et permet l’accès aux informations INFO_CURR à tout dispositif du réseau NW (en particulier aux dispositifs du réseau cœur CN hébergeant des fonctions réseau ou NF) configuré pour l’appeler.

Dans une variante de réalisation, on peut envisager un autre type d’interface pour communiquer ces informations, et en particulier une interface point-à-point utilisant un protocole similaire ou identique au protocole NGAP (pour « NG Application Protocol » en anglais) défini dans le document 3GPP TS 38.413 intitulé « Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP); (Release 17) », v17.0.0, avril 2022, implémentée entre la station de base selon l’invention (ex. gNB 6) et le dispositif NWDAF 4.

Le fonctionnement des modules 13 et 14 est décrit plus en détail ultérieurement en référence aux étapes du procédé de fourniture selon l’invention.

De façon similaire, dans le mode de réalisation décrit ici, chaque dispositif de collecte et d’analyse du système 1 conforme à l’invention (incluant le dispositif NWDAF 4) a l’architecture matérielle d’un ordinateur telle que représentée à la . Cet ordinateur comprend notamment un processeur 15, une mémoire vive 16, une mémoire morte 17, une mémoire non volatile 18, et des moyens de communication 19 permettant notamment à chaque dispositif de collecte et d’analyse de communiquer d’une part avec les stations de base du système 1 (et notamment avec la station de base 6 en appelant en particulier l’API implémentée par cette dernière pour exposer les informations INFO_CURR de conditions de déploiement courantes des cellules qu’elle gère), et d’autre part, avec des dispositifs du réseau cœur CN. Dans le mode de réalisation décrit ici, les moyens de communication 19 sont notamment configurés pour communiquer avec les stations de base du système 1 et avec les dispositifs du réseau cœur CN en utilisant des API prévues à cet effet.

La mémoire non volatile 18 de l’ordinateur constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 15 et sur lequel est enregistré un programme d’ordinateur PROG’ conforme à l’invention, comportant des instructions définissant les principales étapes d’un procédé de collecte selon l’invention.

Le programme PROG’ définit les modules fonctionnels d’un dispositif de collecte et d’analyse selon l’invention (tel que le dispositif NWDAF 4), qui s’appuient ou commandent les éléments matériels 15 à 19 de l’ordinateur cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici, comme illustré sur la :

un module 20 de sollicitation, configuré pour solliciter (c’est-à-dire interroger) au moins une station de base du système 1, et notamment la station de base 6, via l’API mise en œuvre par cette dernière ;
un module 21 de réception configuré pour recevoir en provenance de ladite au moins une station de base sollicitée (via l’API précitée) des informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par ladite au moins une station de base ; et
un module 22 d’analyse, configuré pour utiliser tout ou partie desdites informations reçues lors d’une analyse de données du réseau.

Le fonctionnement des modules 20 à 22 du dispositif de collecte et d’analyse selon l’invention est décrit plus en détail ultérieurement en référence aux étapes du procédé de collecte selon l’invention.

Nous allons maintenant décrire, en référence à la les principales étapes des procédés de fourniture et de collecte selon l’invention lorsqu’elles sont mises en œuvre respectivement, dans le mode de réalisation décrit ici, par la station de base 6 et par le dispositif NWDAF 4 du système 1.

On suppose que l’UE 5 s’enregistre auprès du réseau cœur CN par l’intermédiaire de la station de base 6 (étape E10). De façon connue en soi, la demande d’enregistrement de l’UE 5 (« Registration Request ») est transmise à une instance AMF. Dans l’exemple de la , on suppose qu’il s’agit de l’instance AMF hébergée par le dispositif 2 (aussi désignée dans la suite indifféremment par dispositif AMF 2).

Sur réception de la requête d’enregistrement de l’UE 5, le dispositif AMF 2 demande au dispositif NWDAF 4 des prédictions/statistiques sur l’UE 5, comme par exemple des prévisions sur la mobilité de l’UE 5 (message « Nnwdaf_AnalyticsInfo Request ») (étape E20). Il utilise à cet effet, dans le mode de réalisation décrit ici, le service Nnwdaf_AnalyticsInfo décrit dans les documents 3GPP TS 23.288 intitulé « Architecture Enhancements for 5G system (5GS) to support network data analytics services (Release 17) », v17.4.0, mars 2022, et TS 28.520 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Network Data Analytics Services; Stage 3; (Release 17) », v17.6.0, mars 2022. On note que cette demande peut se faire sous la forme d’une requête simple « Nnwdaf_AnalyticsInfo Request » comme décrit ici, ou en variante sous la forme d’une souscription comme décrit dans les documents TS 23.288 et TS 29.520 précédemment cités.

Sur réception de la demande de prévisions du dispositif AMF 2, le dispositif NWDAF 4 collecte des données INPUT_DATA nécessaires au calcul des prévisions demandées, comme décrit dans le document TS 23.288 au paragraphe 6.7.2.4 (étape E30). En outre, il sollicite, via son module 20 de sollicitation, au moins une station de base gNB du système 1 pour obtenir des informations INFO_CURR représentatives des conditions de déploiement des cellules gérées par ladite au moins une station de base (étape E40).

De telles informations INFO_CURR reflètent le déploiement réel du réseau NW à un instant donné, c’est-à-dire, les zones géographiques et les infrastructures couvertes par les cellules du réseau NW, la topologie de l’architecture du réseau NW (ex. adjacence entre cellules), etc. Elles sont dynamiques dans le sens où elles peuvent évoluer dans le temps, en fonction des décisions prises par l’opérateur OP du réseau NW ou de façon autonome par les stations de base (ex. reconfiguration de certaines stations de base, etc.), du déplacement des stations de base (notamment lorsqu’elles sont mobiles), de l’extinction de certaines cellules (par exemple pour limiter la consommation énergétique du réseau), de l’apparition de nouvelles infrastructures (ex. routes, bâtiments, etc.), etc.

Ainsi, par exemple, les informations INFO_CURR représentatives des conditions de déploiement courante d’une cellule gérée par une station de base peuvent comprendre tout ou partie des informations suivantes :

informations relatives à la disposition de la cellule dans l’architecture du réseau, telles que le voisinage logique ou radio des cellules (sous forme par exemple de l’identité des cellules voisines de ladite cellule) ;
informations relatives à l’environnement géographique de la cellule telles que la zone géographique couverte par la cellule (exprimée par exemple à partir des coordonnées (latitude et longitude) du centre de la cellule et de son rayon, ou d’un motif spatial polygonal utilisant le même type de coordonnées ou via une référence à une carte de couverture, etc.) ;
informations relatives au type de déploiement de la cellule, telles qu’un déploiement indoor/outdoor, en visibilité directe (LOS) ou indirecte (NLOS), en zone blanche, dense, suburbaine ou rurale, ayant une finalité de couverture ou capacitaire, en support d’un réseau privé, d’une infrastructure ou d’une verticale critique, déploiement événementiel/temporaire, configuration du déploiement (ex. cellule macro/petite/pico, cellule gérée par une station de base embarquée sur une plateforme haute altitude, un drone ou un satellite, etc.) ;
informations relatives à une configuration d’au moins une antenne de la cellule telles que la position et l’orientation de cette antenne (latitude, longitude, altitude, hauteur au sol, azimuth, inclinaison), le déploiement d’un système d’antenne distribué (ou DAS) ;
informations relatives à au moins une infrastructure couverte par la cellule, par exemple un axe routier, une voie ferrée, une voie navigable, un ou plusieurs immeubles, une zone industrielle, etc. (exprimée par exemple sous forme de l’identité de l’infrastructure en question) ;
informations relatives à l’état de la cellule, telles que la charge ou le niveau de charge (ex. faible, moyen, élevé) de la cellule, la charge ou le niveau de charge de la cellule au niveau de chaque tranche de réseau (« network slice » en anglais), le nombre d’utilisateurs actifs dans la cellule, le débit en liaison montante (UL) ou descendante (DL), des indicateurs de congestion (ex. taux d’utilisation des ressources radio, nombre de paquets en file d’attente), un état de faute ou un niveau d’alarme, un état en termes de sécurité (ex. détection de brouillage (ou jamming en anglais), la détection d’attaques de type « attaque de l’homme du milieu » (ou « Man In The Middle Attack » en anglais), « fausse station de base », déni de service distribué (ou DDoS pour « Distributed Denial of Service » en anglais), compromission par des botnets), etc.).

Cette liste n’est bien entendu pas exhaustive et d’autres informations représentatives des conditions de déploiement courantes des cellules peuvent être envisagées dans le contexte de l’invention.

En outre, le module 20 de sollicitation peut demander à obtenir d’autres informations en plus des informations INFO_CURR sur une cellule, telle que des informations INFO_SUPP de configuration statique de la cellule comme une identité de la cellule, une bande de fréquence utilisée par la cellule, au moins une technologie d’accès radio associée à la cellule (ex. GERAN, UTRA, E-UTRA, NR), etc. Il convient de noter qu’on peut envisager que certaines de ces informations qui sont statiques aujourd’hui dans le contexte des réseaux 5G, revêtissent un caractère plus dynamique dans une version (ou « Release » en anglais) ultérieure de ces réseaux ou dans un autre contexte.

Le module 20 de sollicitation peut aussi demander à chaque station de base qu’il sollicite des informations notées ici INFO_gNB la concernant, comme son identité (sous la forme par exemple d’un identifiant « Global RAN Node ID »), la liste des TAs et/ou des tranches de réseau qu’elle supporte, des informations représentatives de son état (ex. charge ou niveau de charge, nombre d’utilisateurs utilisant la station de base), etc.

Le module 20 de sollicitation peut solliciter indifféremment toutes les stations de base du système 1, ou n’en solliciter qu’une partie sélectionnée en fonction d’un ou de plusieurs critères de sélection.

Typiquement, les stations de base du système 1 sollicitées par le module 20 de sollicitation peuvent dépendre des prédictions demandées par le dispositif AMF 2. Ainsi, dans l’exemple illustratif envisagé ici, le dispositif AMF 2 ayant demandé au dispositif NWDAF 4 des prédictions sur la mobilité de l’UE 5 rattaché à la station de base 6, le module 20 de sollicitation du dispositif NWDAF 4 peut décider de ne solliciter que la station de base 6.

De façon similaire, le module 20 de sollicitation peut cibler les informations qu’il souhaite recevoir des stations de base sollicitées. Dans l’exemple illustratif précédent, il peut notamment demander à ne recevoir que les informations relatives aux conditions de déploiement courantes de la cellule à laquelle est rattachée l’UE 5, par exemple la cellule C1 gérée par la station de base 6, ou en variante, à l’ensemble des cellules C1, C2 et C3 gérées par celle-ci. L’identifiant de la cellule utilisée par l’UE 5 (C1 dans l’exemple envisagé ici) peut être obtenu par le dispositif NWDAF 4 par exemple à partir des données INPUT_DATA qu’il a collectées.

Dans une variante de réalisation, il peut utiliser les données brutes INPUT_DATA qu’il a collectées, ou des statistiques/prévisions qu’il a établies à partir de ces données brutes de façon connue en soi, pour sélectionner les stations de base pertinentes à solliciter et/ou les informations de conditions de déploiement à demander à ces stations de base. Typiquement, dans l’exemple illustratif précédent, il peut utiliser une première prévision de mobilité établie à partir des données brutes INPUT_DATA et sélectionner les stations de base gérant les cellules qui se trouvent sur une trajectoire de l’UE 5 au regard de cette prévision, ainsi que les informations de déploiement qu’il souhaite obtenir de ces stations de base, par exemple des informations concernant la disposition des cellules gérées par ces stations de base dans l’architecture du réseau (cellules adjacentes, etc.), le type de déploiement de chacune de ces cellules et les infrastructures qu’elles couvrent.

Bien entendu ces exemples ne sont donnés qu’à titre illustratif, et d’autres critères de sélection peuvent être envisagés en variante ou en complément de ceux déjà cités pour sélectionner les stations de base à solliciter et/ou les informations à leur demander.

Dans le mode de réalisation décrit ici, lors de l’étape E40, le module 20 de sollicitation sollicite chaque station de base qu’il a sélectionnée en s’appuyant sur un service nommé ici Ngnb_CellInfo. Un tel service s’appuie ici sur les API des stations de base sollicitées et est conçu pour les besoins de l’invention : il peut notamment utiliser le même protocole (ex. protocole HTTP/2 pour « HyperText Transfer Protocol/2 » en anglais) que les services déjà définis par le standard 3GPP, tels que le service Nnwdaf_AnalyticsInfo ou tout autre service défini par le standard 3GPP pour permettre à une fonction NF du réseau cœur CN d’accéder aux fonctionnalités implémentées par une autre fonction NF et exposées par celles-ci via son API.

En variante, comme mentionné précédemment, on peut envisager d’autres types d’interface pour interagir avec les stations de base, comme par exemple une interface point à point utilisant un protocole similaire ou identique au protocole NGAP défini dans la spécification 3GPP TS 38.413 citée précédemment.

Lors de l’étape E40, le module 20 de sollicitation sollicite chaque station de base sélectionnée en lui envoyant une requête (message « Ngnb_CellInfo Request ») définie par le service Ngnb_CellInfo portant sur (c’est-à-dire indiquant implicitement ou explicitement) les informations INFO_CURR qu’il souhaite recevoir (et éventuellement d’autres informations INFO_SUPP et INFO_gNB telles qu’évoquées précédemment). Dans l’exemple envisagé à la , on suppose par exemple que le module 20 de sollicitation a sélectionné la station de base 6 à laquelle est rattachée l’UE 5, et lui envoie une requête « Ngnb_CellInfo Request » portant sur les informations INFO_CURR relatives à la cellule C1 dans laquelle se trouve l’UE 5.

Les informations INFO_CURR concernées peuvent être identifiées explicitement dans la requête « Ngnb_CellInfo Request » au moyen d’un codage prédéfini, de façon connue en soi, partagé entre le dispositif NWDAF 4 et les stations de base du système 1. Par exemple, on peut associer une valeur entière distincte à chaque information INFO_CURR pouvant être fournie par une station de base, et valoriser un champ de la requête avec les valeurs associées aux informations souhaitées par le dispositif NWDAF 4. En variante, on peut envisager une liste d’informations définie par défaut au niveau des stations de base du système 1, l’absence de mention explicite dans la requête envoyée par le dispositif NWDAF 4 signifiant que ce dernier est intéressé par l’ensemble des informations spécifiées dans cette liste.

Sur réception de la requête du dispositif NWDAF 4 par son module 13 de réception (autrement dit suite à sa sollicitation), la station de base 6 via son module 14 de transmission identifie et obtient les informations INFO_CURR (et le cas échéant les informations INFO_SUPP et INFO_gNB) demandées par le dispositif NWDAF 4 (étape E50).

Il convient de noter que les informations INFO_CURR, INFO_SUPP et/ou INFO_gNB peuvent avoir été configurées au niveau de la station de base 6 (et plus généralement de chaque station de base du système 1) par l’opérateur OP du réseau NW (via des moyens connus en soi et non décrits ici), ou être obtenues ou découvertes dynamiquement par la station de base 6 avant de les transmettre au dispositif NWDAF 4.

Par exemple, la station de base 6 peut évaluer certaines de ces informations elle-même, telles que la zone géographique couverte par chacune des cellules C1, C2 et C3 qu’elle gère. A cet effet, elle peut notamment utiliser la localisation géographique des UE qui sont rattachés à la cellule en question, cette localisation pouvant être remontée par des modules de positionnement par satellite (ou PNT pour « Positioning Navigation and Timing Service » en anglais) tels que des modules GPS ou GNSS équipant les UE ou pouvant être calculée par la station de base 6 à partir des informations de TDOA et de vitesses dont elle dispose sur les UE. Grâce à la localisation des UE et à la connaissance des cellules servant chacun de ces UE, la station de base 6 peut établir une « cartographie » des UE et en déduire les limites de couverture de chaque cellule.

Selon un autre exemple, particulièrement bien adapté dans le cas d’une station de base 6 mobile équipée d’un récepteur PNT et d’une boussole, la station de base 6 peut évaluer la position et l’orientation des antennes desservant les cellules qu’elle gère à partir des positions remontées par son récepteur PNT et des indications fournies par sa boussole.

Selon un autre exemple encore, la station de base 6 peut déterminer l’identité des cellules voisines de chaque cellule qu’elle gère en utilisant la fonctionnalité ANR (pour « Automatic Neighbor Relation » en anglais) de la technologie SON (pour « Self-Organizing Networks » en anglais) conçue de façon connue en soi pour permettre l’auto-configuration, l’auto-exploitation et l’auto-optimisation des équipements d’un réseau de communication cellulaire.

Selon un autre exemple, la station de base 6 peut déduire des informations relatives à l’état de la cellule à partir de son propre état : par exemple, si la station de base 6 rencontre un problème de surcharge causé typiquement par la limitation de ses capacités de traitement, cela va se répercuter sur l’état des cellules qu’elle gère qui seront elles-mêmes dans un état surchargé.

En outre, la station de base 6 dispose de façon connue en soi, d’informations sur l’utilisation des ressources réseaux. Elle peut à partir de ces informations détecter un état (ou un niveau) de congestion des cellules qu’elle gère. Une telle congestion est susceptible d’affecter différents types de ressources utilisées par la cellule, comme des ressources radio ou PRB (pour « Physical Ressource Block » en anglais), des buffers ou encore des canaux radio (ex. canaux de trafic, de signalisation ou de paging), et intervient lorsque 100% des ressources en question sont utilisées (ex. 100% des buffers sont pleins). Pour détecter un tel état, on peut surveiller divers indicateurs avancés de congestion tels que par exemple un pourcentage d’utilisation des ressources qui s’approche d’un seuil critique, une augmentation des délais ou des pertes de paquets observés sur la cellule, etc. Ces indicateurs peuvent être considérés parmi les informations INFO_CURR.

La station de base 6 peut par ailleurs obtenir certaines des informations d’entités tierces, par exemple d’entités du réseau NW ou d’entités externes. Notamment, on peut envisager que la station de base 6 soit configurée pour communiquer avec le système 12 de planification radio adapté au réseau NW, et obtienne certaines informations de ce système de planification radio, comme par exemple les informations relatives au type de déploiement des cellules C1, C2 et C3 qu’elle gère, l’identité des infrastructures couvertes par chacune de ces cellules, ou encore les informations relatives à la configuration de déploiement de ces cellules.

La station de base 6 peut également avoir connaissance de certaines de ces informations car elle les utilise pour implémenter les traitements dont elle est en charge (ex. identité des cellules voisines, bande de fréquences utilisée par chaque cellule ou encore de la technologie de réseau d’accès implémentée dans chaque cellule), ou parce qu’elle est configurée pour diffuser ces informations sur le réseau NW (ex. identité des cellules gérées par la station de base 6, liste des TAs et/ou des tranches de réseau qu’elle supporte).

La nature des informations INFO_CURR, et le cas échéant INFO_SUPP et INFO_gNB, configurées et/ou obtenues par la station de base 6 peut être définie par défaut au niveau de la station de base 6, par exemple par l’opérateur du réseau NW, ou par une plateforme de gestion aussi connue sous le nom de plateforme OAM (pour « Operations, Administration and Maintenance » en anglais).

Une fois les informations INFO_CURR (et le cas échéant INFO_SUPP et/ou INFO_gNB) requises par le dispositif NWDAF 4 obtenues, la station de base 6 les transmet via son module 14 de transmission au dispositif NWDAF 4 (étape E60). A cet effet, le module 14 de transmission utilise ici l’API de la station de base 6 lui permettant d’exposer au dispositif NWDAF 4 les informations INFO_CURR (et le cas échéant INFO_SUPP et/ou INFO_gNB) qu’il lui a demandées. Plus spécifiquement, il lui envoie via cette API une réponse (message « Ngnb_CellInfo Response ») à sa requête définie par le service Ngnb_CellInfo et contenant les informations INFO_CURR (et le cas échéant INFO_SUPP et/ou INFO_gNB) requises.

Il convient de noter que le dispositif NWDAF 4 peut solliciter en variante la station de base 6 (ou plus généralement tout ou partie des stations de base du système 1) via un mécanisme de souscription, connu en soi. Plus spécifiquement, le dispositif NWDAF 4 via son module 20 de sollicitation peut souscrire auprès de la station de base 6 (ou plus généralement tout ou partie des stations de base du système 1) à la notification d’événements susceptibles d’affecter les conditions de déploiement courantes de tout ou partie des cellules gérées par celle-ci. Lorsqu’un tel événement est détecté par la station de base 6, le module 14 de transmission de la station de base 6 envoie un message de notification de cet événement au dispositif NWDAF 4 contenant les informations représentatives des conditions de déploiement courantes des cellules impactées par l’événement. Dans une variante de réalisation, il peut ne transmettre dans la notification que les informations qui ont changé du fait de l’événement.

La réponse est reçue par le module 21 de réception du dispositif NWDAF 4. Le dispositif NWDAF 4, via son module 22 d’analyse, établit alors les prévisions demandées par le dispositif AMF 2 en utilisant d’une part les données INPUT_DATA collectées, mais également tout ou partie des informations reçues par son module 21 de réception de la station de base gNB 6, en particulier tout ou partie des informations INFO_CURR de conditions de déploiement courantes de la cellule C1 reçues de la station de base gNB 6 (étape E70). Par exemple, les prévisions de mobilité de l’UE 5 réalisées par le dispositif NWDAF 4 peuvent être influencées par le type de déploiement de la cellule C1 et notamment le fait qu’elle soit déployée en support d’une infrastructure donnée telle qu’une autoroute : les positions futures de l’UE 5 situées sur cette autoroute auront alors une probabilité plus importante. Bien entendu cet exemple n’est donné qu’à titre illustratif et n’est pas limitatif en soi.

Le module 22 d’analyse du dispositif NWDAF 4 transmet les prévisions ainsi établies au dispositif AMF 2 (message « Nnwdaf_AnalyticsInfo Response ») (étape E80), qui les utilise par exemple pour établir la RA de l’UE 5 de façon connue de l’homme du métier et non décrite en détail ici (étape E90). Par exemple, la RA peut contenir toutes les TA contenant les positions futures de l’UE 5 prédites par le dispositif NWDAF 4. Bien entendu cet exemple n’est donné qu’à titre illustratif et n’est pas limitatif en soi.

Les autres étapes de la procédure d’enregistrement de l’UE 5 sont identiques ou similaires aux étapes décrites dans le document 3GPP TS 23.501, et ne sont pas détaillées davantage ici.

Le dispositif AMF 2 envoie la confirmation de l’enregistrement à l’UE 5 (« Registration Accept »), en incluant dans cette confirmation la RA qu’il vient de déterminer (étape E90).

Suite à son enregistrement, on suppose ici que l’UE 5 requiert l’établissement d’une session (« PDU Session Establishment Request ») (étape E100). Le dispositif AMF 2 via lequel la requête transite, détermine de façon connue en soi l’instance SMF qui va gérer cette session (l’instance SMF 3 dans l’exemple envisagé ici), comme défini dans le standard 3GPP. Il peut éventuellement utiliser les prévisions reçues lors de l’étape E80 pour identifier le dispositif SMF 3 qui va gérer cette session.

Sur réception de la requête d’établissement de session, le dispositif SMF 3 demande ici à son tour au dispositif NWDAF 4 des prédictions/statistiques sur l’UE 5, par exemple des prévisions sur les communications de l’UE 5 (message « Nnwdaf_AnalyticsInfo Request ») (étape E110). Comme décrit précédemment pour le dispositif AMF 2 à l’étape E20, le dispositif SMF 3 utilise à cet effet, dans le mode de réalisation décrit ici, le service Nnwdaf_AnalyticsInfo décrit dans les documents 3GPP TS 23.288 et TS 28.520. Les étapes E30-E60 peuvent être réitérées si besoin par le dispositif NWDAF 4 (non représentées sur la figure 5).

Le dispositif NWDAF 4, via son module 22 d’analyse, établit alors les prévisions demandées par le dispositif SMF 3 en utilisant d’une part les données INPUT_DATA qu’elle a collectées (celles collectées lors de l’étape E30 et/ou de nouvelles données si elles ne sont pas ou plus pertinentes compte tenu des prévisions demandées), mais également tout ou partie des informations fournies par la station de base 6 sur la cellule C1 utilisée par l’UE 5 pour accéder au réseau, et en particulier tout ou partie des informations INFO_CURR de conditions de déploiement courantes de la cellule C1 (étape E120).

Il convient de noter que le dispositif NWDAF 4 peut, si nécessaire, de nouveau solliciter la station de base gNB 6, comme décrit précédemment lors de l’étape E40, si les informations INFO_CURR obtenues lors de l’étape E30 ne sont pas pertinentes pour établir les prévisions demandées par le dispositif SMF 3 (par exemple parce que ces prédictions diffèrent de celles demandées par le dispositif AMF 2), ou pour être informé d’éventuel(s) changement(s) dans les informations INFO_CURR (il peut aussi à cet effet souscrire auprès de la station de base 6 à la notification d’événements affectant les informations INFO_CURR des cellules qu’elle gère, de façon connue en soi).

De manière générale, le dispositif NWDAF 4 peut solliciter la station de base 6 directement en liaison avec une demande de prédictions/statistiques d’un dispositif du réseau ou de façon asynchrone. Il peut par ailleurs pour une même demande, interroger plusieurs fois la station de base 6. Par exemple, le dispositif NWDAF 4 peut observer le déplacement de l’UE 5 pendant une certaine période et interroger les stations de base gérant chacune des cellules visitées par l’UE 5 afin d’obtenir des prédictions plus fiables. Ceci est possible notamment lorsque le dispositif demandeur des prédictions/statistiques n’a pas besoin d’une réponse immédiate.

Le module 22 d’analyse du dispositif NWDAF 4 transmet les prévisions qu’il a établies au dispositif SMF 3 (message « Nnwdaf_AnalyticsInfo Response ») (étape E130), qui les utilise pour établir la session requise par l’UE 5 (étape E140). Par exemple, le dispositif SMF 3 utilise ces prévisions pour déterminer de façon optimale certains paramètres de la session, telle que la ou les fonctions réseau du plan utilisateur ou UPF (pour « User Plane Function » en anglais) qui achemineront les données. Par exemple, en fonction des débits des communications de l’UE 2 prévues par le dispositif NWDAF 4, le dispositif SMF 3 peut sélectionner une fonction UPF optimisée pour traiter un débit important ou au contraire des communications sporadiques. Bien entendu cet exemple n’est donné qu’à titre illustratif et n’est pas limitatif en soi.

Le dispositif SMF 3 confirme alors l’établissement de la session auprès de l’UE 5 (message « PDU Session Establishment Accept ») (étape E150).

Dans le mode de réalisation décrit ici, les dispositifs AMF 2 et SMF 3 interrogent chacun à leur tour le dispositif NWDAF 4 pour obtenir des prédictions/statistiques, et exploitent ces prédictions/statistiques pour mettre en œuvre les fonctionnalités qui leur sont confiées. Bien entendu ces hypothèses ne sont pas limitatives en soi, et on peut envisager que seul l’un des dispositifs demande et exploite de telles prédictions/statistiques.

Dans le mode de réalisation décrit ici, on s’appuie sur une API et sur un service Ngnb_CellInfo au niveau des stations de base du système 1 pour exposer les informations (et en particulier les informations INFO_CURR, INFO_SUPP et INFO_gNB) au dispositif NWDAF qui les sollicite. Comme souligné précédemment, l’avantage d’utiliser une telle API est qu’elle peut être utilisée par d’autres dispositifs du réseau NW que le dispositif NWDAF dès lors que ces dispositifs sont configurés pour appeler (i.e. utiliser) une telle API. Ainsi, dans un autre mode de réalisation de l’invention, le système selon l’invention peut comprendre au moins un dispositif hébergeant une fonction réseau du réseau cœur CN (comme par exemple un dispositif hébergeant une fonction AMF, une fonction SMF, etc.), configuré pour appeler les API de la station de base et solliciter directement via cette API la station de base pour obtenir des informations INFO_CURR (de façon similaire ou identique à ce qui a été décrit pour le dispositif NWDAF lors de l’étape E40). Le dispositif en question peut alors exploiter les informations INFO_CURR ainsi collectées pour mettre en œuvre les fonctionnalités de la fonction réseau qu’il implémente.

En variante, on peut envisager d’autres interfaces de communication entre les stations de base du système 1 et le dispositif NWDAF qu’une API, comme indiqué précédemment. Il en est de même pour les autres services activés dans ce qui précède (ex. Nnwdaf_AnalyticsInfo).

En outre, l’invention a été décrite en référence à un contexte 5G. Toutefois elle peut s’appliquer dans d’autres contextes également, par exemple à un réseau 6G ou à un réseau propriétaire.

Claims

Procédé de fourniture d’informations par une station de base (6) d’un réseau de communications cellulaire, ledit procédé comprenant, suite à une sollicitation (E40) d’un dispositif (4) de collecte et d’analyse de données du réseau, une étape (E60) de transmission audit dispositif de collecte et d’analyse, d’informations (INFO_CURR) représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par la station de base.
Procédé de fourniture selon la revendication 1 dans lequel les informations sont transmises au dispositif (4) de collecte et d’analyse en les exposant via une interface de programmation applicative de la station de base.
Procédé de fourniture selon la revendication 1 ou 2 dans lequel ladite sollicitation (E40) comprend une réception d’une requête du dispositif de collecte et d’analyse portant sur lesdites informations, lesdites informations étant envoyées dans une réponse à ladite requête.
Procédé de fourniture selon la revendication 1 ou 2 dans lequel ladite sollicitation comprend une souscription du dispositif de collecte et d’analyse auprès de la station de base à une notification d’événements susceptibles d’affecter lesdites conditions de déploiement courantes de ladite au moins une cellule, lesdites informations étant envoyées dans une notification d’au moins un dit événement.
Procédé de fourniture selon l’une quelconque des revendications 1 à 4, comprenant en outre une étape d’évaluation d’au moins une partie desdites informations avant de les transmettre audit dispositif de collecte et d’analyse.
Procédé de fourniture selon l’une quelconque des revendications 1 à 5 comprenant en outre une étape d’obtention, en provenance d’un système (12) de planification radio adapté audit réseau, d’au moins une partie desdites informations avant de les transmettre audit dispositif de collecte et d’analyse.
Procédé de fourniture selon l’une quelconque des revendications 1 à 6 dans lequel l’étape de transmission comprend également la transmission au dispositif de collecte et d’analyse :
d’une identité de ladite au moins une cellule ; et/ou

d’une bande de fréquence allouée à ladite au moins une cellule ; et/ou

d’au moins une technologie d’accès radio associée à ladite au moins une cellule.
Procédé de collecte de données par un dispositif (4) de collecte et d’analyse de données d’un réseau de communication cellulaire, ledit procédé comprenant :
une étape (E60) de réception en provenance d’au moins une station (6) de base du réseau sollicitée par ledit dispositif de collecte et d’analyse, d’informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par ladite au moins une station de base ; et

une étape (E70,E120) d’utilisation de tout ou partie desdites informations reçues lors d’une analyse de données du réseau.
Procédé de collecte selon la revendication 8 dans lequel au moins une dite station de base (6) est sollicitée par le dispositif de collecte et d’analyse en envoyant une requête portant sur lesdites informations, lesdites informations étant reçues dans une réponse de la station de base à ladite requête.
Procédé de collecte selon la revendication 8 ou 9 dans lequel au moins une dite station de base (6) est sollicitée par le dispositif de collecte et d’analyse en souscrivant auprès d’elle à une notification d’événements susceptibles d’affecter lesdites conditions de déploiement courantes d’au moins une dite cellule gérée par la station de base, lesdites informations étant reçues dans une notification de la station de base d’au moins un dit événement.
Procédé de collecte selon l’une quelconque des revendications 8 à 10 comprenant en outre une étape d’envoi (E90, E130) d’un résultat de ladite analyse à un autre dispositif (2,3) du réseau ayant sollicité cette analyse.
Procédé de collecte selon la revendication 11 dans lequel ledit résultat comprend une prévision d’une mobilité d’un équipement utilisateur géré par ledit autre dispositif.
Procédé de collecte selon l’une quelconque des revendications 8 à 12 comprenant en outre une étape préliminaire de sélection d’au moins une dite station de base sollicitée, ladite sélection étant réalisée en fonction d’au moins un critère de sélection donné et/ou d’au moins une dite information représentative de conditions de déploiement courante d’au moins une dite cellule.
Procédé selon l’une quelconque des revendications 1 à 13 dans lequel au moins une dite information (INFO_CURR) représentative de conditions de déploiement courantes d’une cellule est relative à une disposition de la cellule dans une architecture du réseau, à un environnement géographique de la cellule, à une configuration d’au moins une antenne de la cellule, à un type de déploiement de la cellule, à au moins une infrastructure couverte par la cellule, et/ou à un état de la cellule ou de la station de base gérant ladite cellule.
Station de base (6) d’un réseau de communications cellulaire comprenant un module (14) de transmission activé suite à une sollicitation d’un dispositif de collecte et d’analyse de données du réseau, ledit module étant configuré pour transmettre audit dispositif de collecte et d’analyse des informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par la station de base.
Dispositif (4) de collecte et d’analyse de données d’un réseau de communications cellulaire comprenant :
- un module (20) de sollicitation, configuré pour solliciter au moins une station de base du réseau ;
- un module (21) de réception, configuré pour recevoir en provenance de ladite au moins une station de base sollicitée des informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par ladite au moins une station de base ; et
- un module (22) d’analyse, configuré pour utiliser tout ou partie desdites informations reçues lors d’une analyse de données du réseau.
Système (1) d’un réseau de communications cellulaire comprenant :
- au moins une station (6) de base selon la revendication 15 ; et
- au moins un dispositif (4) de collecte et d’analyse de données selon la revendication 16.
Système (1) selon la revendication 17 dans lequel la station de base est configurée pour implémenter une interface de programmation applicative pour exposer lesdites informations représentatives de conditions de déploiement courantes d’au moins une cellule du réseau gérée par la station de base, et ledit système comprend au moins un autre dispositif du réseau hébergeant une fonction réseau et configuré pour appeler l’interface de programmation applicative implémentée par la station de base.