INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Selon un autre exemple, la station de base 3 peut déduire des informations relatives à l’état de la cellule à partir de son propre état : par exemple, si la station de base 3 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 3 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 mémoires tampons (ou buffers en anglais) 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 3 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 3 soit configurée pour communiquer avec le système 15 de planification radio adapté au réseau NW, et obtiennent 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 3 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 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 qu’elle gère, 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, contenues dans le profil gNBPROF(3) de la station de base 3 peuvent être définies par défaut au niveau de la station de base 3 (et plus précisément de l’entité 7), 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).
Pour enregistrer le profil gNBPROF de la station de base 3 auprès du dispositif NRF 8, dans le premier mode de réalisation décrit ici, le module d’enregistrement 7A utilise le service Nnrf_NFManagement_NFRegister défini dans les documents 3GPP TS 23.502 et TS 29.510 cités précédemment, adapté pour les besoins de l’invention. Plus spécifiquement, la requête d’enregistrement du service Nnrf_NFManagement_NFRegister (message « Nnrf_NFManagement_NFRegister Request »), habituellement utilisée par les fonctions NF du réseau cœur CN pour enregistrer leurs profils NFPROF respectifs auprès du dispositif NRF 8, est adaptée pour être utilisée par la station de base 3 (et plus particulièrement par le module 7A d’enregistrement de l’entité 7 hébergée par la station de base 3) pour enregistrer son profil gNBPROF(3). Cette adaptation consiste à modifier la requête pour qu’elle contienne dans le profil gNBPROF(3), pour chaque cellule C1, C2 et C3 gérée par la station de base 3, les informations INFO_CURR, et le cas échéant les informations INFO_SUPP et INFO_gNB. Une telle adaptation est évidente pour l’homme du métier et n’est pas décrite davantage ici.
Sur réception de la requête d’enregistrement de la station de base 3, le dispositif NRF 8, via son module 8A d’enregistrement, mémorise le profil gNBPROF(3) par exemple dans sa mémoire non volatile 13 (étape E20).
Puis il envoie par l’intermédiaire de son module 8A d’enregistrement un message de confirmation (message « Nnrf_NFManagement_NFRegister Response ») de l’enregistrement du profil gNBPROF(3) à la station de base 3 en utilisant le service Nnrf_NFManagement_NFRegister, de façon similaire ou identique à ce qu’il fait lors de l’enregistrement du profil d’une fonction NF (étape E30).
On suppose maintenant que lorsqu’il détecte l’activation d’une nouvelle station de base (à savoir ici de la station de base 3), l’instance AMF 4 interroge le dispositif NRF 8 pour obtenir des informations sur les cellules du réseau NW gérées par cette nouvelle station de base 3 se trouvant sa zone de service (autrement dit, dans les TA que l’instance AMF4 dessert) (étape E40). A cet effet, dans le premier mode de réalisation décrit ici, le module 16A d’envoi de l’instance AMF 4 utilise le service Nnrf_NFManagement_NFDiscovery défini dans les documents 3GPP TS 23.502 et TS 29.510 cités précédemment, adapté pour les besoins de l’invention. Plus spécifiquement, le module 16A d’envoi de l’instance AMF 4 envoie au dispositif NRF 8 une requête de découverte (message « Nnrf_NFManagement_NFDiscovery Request ») telle que définie par le service Nnrf_NFManagement_NFDiscovery indiquant comme critères de recherche l’identité de la station de base 3 nouvellement détectée et les TA desservies par l’instance AMF 4.
On note qu’en variante, cette interrogation du dispositif NRF 8 par l’instance AMF 4 peut intervenir à d’autres moments qu’en réaction à l’activation de la station de base 3. Ainsi par exemple, cette interrogation peut être déclenchée lorsque l’instance AMF 4 détecte qu’elle a besoin d’informations concernant un UE qu’elle gère.
Suite à son enregistrement, l’UE 2 requiert l’établissement d’une session (« PDU Session Establishment Request ») (étape F120). L’instance AMF 4 via laquelle la requête transite peut sélectionner l’instance SMF 5 qui va gérer cette session de façon classique, telle que prévue par le standard 3GPP, en utilisant éventuellement les prévisions reçues lors de l’étape F90 pour sélectionner l’instance SMF 5.
Sur réception de la requête d’établissement de session, l’instance SMF 5 demande à l’instance NWDAF 6 des prédictions/statistiques sur l’UE 2, comme par exemple des prévisions sur les communications de l’UE 2 (message « Nnwdaf_AnalyticsInfo Request ») (étape F130). Comme décrit précédemment pour l’instance AMF 4 à l’étape F50, l’instance SMF 5 utilise à cet effet, dans le premier 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 F60 et F70 peuvent être réitérées si besoin par l’instance NWDAF 6 (non représentées sur la ). Ce peut être le cas notamment lorsque l’instance NWDAF 6 est sollicitée pour réaliser des prédictions/statistiques de différentes natures, comme par exemple ici, par l’instance AMF 4 pour établir des prévisions sur la mobilité de l’UE 2 et par l’instance SMF 5 pour établir des prévisions sur les communications de l’UE 2, les requêtes de découverte adressées auprès du dispositif NRF 8 pouvant alors porter sur des critères de recherche différents.
L’instance NWDAF 6, via son module 16C d’utilisation, établit alors les prévisions demandées par l’instance SMF 5 (fonctionnalité implémentée par l’instance NWDAF 6 au sens de l’invention) en utilisant d’une part les données INPUT_DATA qu’elle a collectées, mais également tout ou partie des informations fournies par le dispositif NRF 8 sur la cellule C1 utilisée par l’UE 2 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 F140).
Le module 16C d’utilisation de l’instance NWDAF 6 transmet les prévisions ainsi établies à l’instance SMF 5 (message « Nnwdaf_AnalyticsInfo Response ») (étape F150), qui les utilise pour établir la session requise par l’UE 2 (étape F160). Par exemple, le module 16C d’utilisation de l’instance SMF 5 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 l’instance NWDAF 6, l’instance SMF 5 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.
L’instance SMF 5 confirme alors l’établissement de la session auprès de l’UE 2 (« PDU Session Establishment Accept ») (étape F170).
Il convient de noter que les remarques faites précédemment quant à la possibilité d’utiliser d’autres messages que ceux définis par les services Nnrf_NFManagement_NFRegister et Nnrf_NFManagement_NFDiscovery du standard 3GPP, de mettre à jour certaines informations du profil de la station de base 3 ou des cellules du réseau NW, d’interroger et d’exploiter les informations de conditions de déploiement courantes des cellules uniquement durant certaines étapes, et d’envisager un autre dispositif de contrôle que le dispositif NRF 8 (par exemple un dispositif de contrôle gérant des entités applicatives du réseau d’accès AN telles que les stations de base) s’appliquent également dans le contexte de ce deuxième exemple illustratif.
Par ailleurs, les deux exemples illustratifs qui viennent d’être présentés ne sont pas limitatifs en soi, et l’invention peut s’appliquer dans d’autres contextes, et impliquer d’autres entités applicatives du réseau cœur CN (par exemple d’autres fonctions réseau) et/ou du réseau d’accès AN (par exemple d’autres stations de base). Notamment on peut envisager comme autre dispositif demandeur, une station de base du réseau AN qui utilise les informations de conditions de déploiement courantes des cellules du réseau NW pour décider d’un transfert ou « handover » entre deux cellules pour un UE rattaché à cette station de base, et déterminer les modalités de ce handover (notamment la cellule cible). Par exemple, s’il est déterminé qu’un UE se déplace sur une voie ferrée (ex. par l’intermédiaire des prédictions réalisées par une fonction réseau NWDAF), la station de base pourrait, grâce aux informations INFO_CURR obtenues du dispositif NRF 8, ne sélectionner parmi les cellules voisines candidates (qui sont configurées au niveau de la station de base), que celles qui couvrent la voie ferrée en question sur laquelle l’UE se déplace, comme cibles potentielles pour le handover de l’UE. Il convient de noter que les API actuellement définies par le standard 3GPP ne permettent pas à une station de base gNB d’interroger un dispositif NRF ; par conséquent, il conviendrait d’adapter cette API (ce qui ne poserait pas de difficulté à l’homme du métier) ou de prévoir une interface permettant à la station de base d’interroger le dispositif NRF pour obtenir les informations INFO_CURR qui l’intéressent.
Dans le premier mode de réalisation qui vient d’être décrit, la station de base 3 héberge l’entité 7, et enregistre elle-même auprès du dispositif NRF 8 son profil gNBPROF(3) ou le profil CellPROF des cellules C1, C2 et C3 qu’elle gère. Ce qui vient d’être décrit en référence à la station de base 3 est mis en œuvre par tout ou partie des stations de base du réseau NW.
Nous allons maintenant envisager en référence à la un deuxième mode de réalisation de l’invention dans lequel l’entité 7 est hébergée dans une entité applicative du réseau cœur CN et plus précisément dans un dispositif hébergeant une fonction réseau, à savoir une instance AMF (dispositif de gestion d’accès au réseau au sens de l’invention). Les mêmes références que celles utilisées sur les figures 1 à 3 sont utilisées pour les éléments qui sont identiques au premier mode de réalisation et pour lesquelles les caractéristiques détaillées dans le premier mode de réalisation s’appliquent dans le deuxième mode de réalisation.
Ainsi, la représente un système 1’ dans un réseau NW de communication cellulaire, conforme au deuxième mode de réalisation de l’invention. Le réseau NW est comme décrit précédemment en référence au premier mode de réalisation, un réseau 5G tel que défini par le standard 3GPP, géré par un opérateur OP, et comprenant au moins un réseau d’accès AN et un réseau cœur CN.
Pour accéder aux services offerts par le réseau NW, l’UE 2 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 3’ de ce réseau d’accès. La station de base gNB 3’ est configurée pour gérer une ou plusieurs cellules du réseau NW ; dans l’exemple envisagé ici, la station de base 3’ est une gNB tri-sectorielle gérant trois cellules du réseau C1, C2 et C3.
Le réseau cœur CN s’appuie sur plusieurs fonctions réseau comme décrit précédemment pour le premier mode de réalisation, et notamment sur des instances 4’ de fonction réseau AMF, 5 de fonction réseau SMF et 6 de fonction réseau NWDAF.
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, conforme à l’invention, à savoir la station de base 3’ gérant les cellules C1, C2 et C3 du réseau NW ; au moins un dispositif demandeur, conforme à l’invention, à savoir dans l’exemple illustré sur la , l’instance NWDAF 6. Bien entendu, cet exemple n’est donné qu’à titre illustratif, et d’autres entités du réseau NW, en particulier d’autres fonctions réseau ou instances de fonctions réseau du réseau cœur CN peuvent être des dispositifs demandeurs au sens de l’invention ; au moins une entité 7 du réseau NW conforme à l’invention. Dans le deuxième mode de réalisation, l’entité 7 est hébergée par l’instance AMF 4’ (dispositif de gestion d’accès au sens de l’invention) ; et un dispositif 8 de contrôle du réseau NW, conforme à l’invention, tel que décrit dans le premier mode de réalisation de l’invention.
La représente la répartition dans les différents éléments du système 1’ des modules fonctionnels 8A-8B, 7A, et 16A à 165C définis respectivement par les programmes PROG1, PROG2 et PROG3, décrits précédemment pour le premier mode de réalisation. Les caractéristiques de ces modules restent les mêmes pour le deuxième mode de réalisation à la différence près que l’entité 7 (et donc le module d’enregistrement 7A) est maintenant hébergée dans une instance de fonction réseau du réseau cœur CN, à savoir dans l’instance AMF 4’. Il convient de noter que l’instance AMF 4’ peut également être un dispositif demandeur au sens de l’invention dans le deuxième mode de réalisation et héberger des modules 16A-16C (non représentés toutefois sur la ).
Nous allons maintenant décrire, en référence à la qui illustre un exemple d’application de l’invention dans le deuxième mode de réalisation, les principales étapes des procédés de communication, de gestion et de découverte mises en œuvre respectivement par l’instance AMF 4’ hébergeant l’entité 7, par le dispositif NRF 8, et par l’instance NWDAF 6. Il convient de noter que le deuxième mode de réalisation est particulièrement bien adapté lorsque la station de base 3’ ne supporte pas le ou les protocoles permettant de consommer les services de l’instance AMF 4’ ou du dispositif NRF 8 (protocole HTTP2 notamment dans l’exemple d’un réseau 5G défini par le standard 3GPP).
Suite à son activation par l’opérateur OP du réseau cellulaire NW, la station de base 3’ déclenche une procédure d’association avec l’instance 4’ AMF désignée pour gérer la station de base 3’ (étape G10). A cet effet, dans le deuxième mode de réalisation décrit ici, la station de base 3’ exécute la procédure « NG Setup » décrite 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, au paragraphe 8.7.1. Toutefois conformément à l’invention, lors de cette procédure, la station de base 3’ enrichit le message d’association (message « NG SETUP Request ») envoyé à l’instance AMF 4’ avec son profil gNBPROF(3’). Comme décrit dans le premier mode de réalisation de l’invention, le profil gNBPROF(3’) contient pour chaque cellule C1, C2, C3 gérée par la station de base 3’, des informations INFO_CURR représentatives des conditions de déploiement courantes de ces cellules, et éventuellement des informations supplémentaires INFO_SUPP et INFO_gNB relatives à la station de base 3’. Les informations INFO_CURR, INFO_SUPP et INFO_gNB considérées dans le deuxième mode de réalisation sont identiques à celles considérées dans le premier mode de réalisation et ne sont pas décrites de nouveau en détail ici. Il en est de même pour la façon dont la station de base 3’ obtient ces informations (configuration opérateur, évaluation par elle, ou obtention en provenance d’entités tierces comme d’un système de planification radio adapté au réseau NW).
: présente un exemple d’agencement d’une pluralité de caméras formant un système d’acquisition d’une vidéo multi-vues d’une scène, selon l’art antérieur ;
: illustre de façon schématique une pluralité d’images de la scène, capturées par la pluralité de caméras à un instant donné, selon l’art antérieur;
: illustre de façon schématique une séquence de la pluralité d’images, capturées par la pluralité de caméras à plusieurs instants successifs et formant la vidéo multi-vues originale, selon l’art antérieur;
: illustre de façon schématique un premier exemple d’architecture d’un système selon un mode de réalisation de l’invention comprenant un dispositif de segmentation d’une pluralité de données d’entrée, un dispositif de codage d’informations de segmentation et d’un sous-ensemble de données à traiter issues de la segmentation, un dispositif de décodage de données codées représentatives du sous-ensemble de données à traiter et des informations de segmentation associées et un dispositif de traitement des données décodées, lorsque la pluralité de données est une vidéo multi-vues de la scène acquise par une pluralité de caméras;
: illustre de façon schématique un deuxième exemple d’architecture d’un système selon un mode de réalisation de l’invention comprenant un dispositif de segmentation d’une pluralité de données d’entrée, un dispositif de codage d’informations de segmentation et d’un sous-ensemble de données à traiter issues de la segmentation, un dispositif de décodage de données codées représentatives du sous-ensemble de données à traiter et des informations de segmentation associées et un dispositif de traitement des données décodées, lorsque la pluralité de données comprend des mesures physiologiques d’un patient acquises par une pluralité de capteurs;
: décrit sous forme d’un logigramme les étapes d’un procédé de segmentation d’une pluralité de données d’entrée, selon un exemple de réalisation de l’invention ;
: décrit sous forme d’un logigramme les étapes d’un procédé de codage des données issues de la segmentation de la pluralité de données codées selon un mode de réalisation de l’invention ;
: décrit sous forme d’un logigramme les étapes d’un procédé de décodage des données issues de la segmentation de la pluralité de données selon un mode de réalisation de l’invention ;
: détaille un premier exemple de mise en œuvre des procédés de segmentation et de codage précités lorsque la pluralité de données comprend une vidéo multi-vues ;
: détaille un premier exemple de mise en œuvre du procédé de décodage précités lorsque la pluralité de données d’entrée comprend une vidéo multi-vues ;
: détaille un deuxième exemple de mise en œuvre des procédés de segmentation et de codage précités lorsque la pluralité de données d’entrée comprend une pluralité de séquences de mesures physiologiques d’un patient ;
: détaille un deuxième exemple de mise en œuvre du procédé de décodage précité lorsque la pluralité de données d’entrée comprend une pluralité de séquences de mesures physiologiques d’un patient ;
: décrit un exemple de structure matérielle d’un dispositif de segmentation d’une pluralité de données selon l’invention ;
: décrit un exemple de structure matérielle d’un dispositif de codage d’une pluralité de données selon l’invention ; et
: décrit un exemple de structure matérielle d’un dispositif de décodage de données issues de la segmentation et du codage selon l’invention.
Description de l’invention Le principe de l’invention repose sur la segmentation d’une pluralité de données d’entrée, acquises par des capteurs disposés autour d’une scène, d’un objet ou d’un sujet, en vue de leur traitement par un dispositif de traitement donné. On désigne ici par segmentation le fait d’identifier parmi la pluralité de données d’entrée celles à conserver pour un traitement ultérieur donné et de les rassembler en un sous-ensemble de données à traiter.
Dans les fonctions DetAct() et PostProc(), de nombreux retraitements sont conditionnés par une baisse du ratio r. Dans certaines variantes, cette condition pourrait être omise.
Une fois la fonction DetAct() terminée, le tableau AS[] comprend donc l'ensemble des segments d'activation détectés, ainsi que les instants de référence correspondants qui définissent les intervalles.
La représente un exemple de mise en œuvre de la fonction ALCL() mise en œuvre par le calculateur 12 pour estimer la valeur LCL et éventuellement une valeur LCL agglomérée.
La fonction ALCL() comprend deux parties. Dans une première partie, cette fonction calcule la valeur LCL pour la piste qui vient d'être traitée, puis elle cherche à déterminer si une valeur LCL agglomérée peut également être calculée.
La première partie commence par une opération 500 dans laquelle une fonction Per() est exécutée. La fonction Per() a pour but de déterminer si les intervalles définis par les segments d'activations définissent une activation périodique. Pour cela, dans l'exemple décrit ici, la fonction Per() teste trois conditions : - la durée de chaque intervalle est calculée afin de vérifier qu'aucun d'entre eux n'excède un quart de la piste, - la durée totale des segments d'activation est mesurée pour vérifier qu'elle occupe plus de la moitié de la piste, et - le ratio r est recalculé pour vérifier qu'il est inférieur à 0,6.
Si l'une de ces trois conditions n'est pas remplie, alors la piste est considérée comme inexploitable et la valeur LCL est mise à 0 dans une opération 502.
Dans le cas contraire, la piste est considérée comme périodique, et une opération 505 optionnelle vérifie si le rythme de la piste est lent ou non. Si c'est le cas, alors dans une opération 510 également optionnelle, le tableau AS[] est complété avec des données de tableau AS[] antérieures en mémoire tampon afin d'avoir suffisamment de segments d'activation pour pouvoir calculer la valeur LCL.
Ensuite, dans une opération 515, une fonction Calc() détermine à partir du tableau AS[] une valeur LCL ainsi qu'une valeur CV qui représente la variance des durées d'intervalle au sein du tableau AS[]. Dans l'exemple décrit ici, la valeur LCL est obtenue en déterminant la médiane des durées des intervalles dans le tableau AS[]. En variante, la moyenne ou une valeur tirée de la médiane, de la moyenne ou autrement barycentrique pourrait être utilisée. Dans l'exemple décrit ici, la valeur CV est obtenue en divisant l'écart-type des durées d'intervalle par la moyenne de celles-ci.
La valeur CV est alors testée dans une opération 520 afin de déterminer si les intervalles sont suffisamment homogènes entre eux. Si cette valeur excède 0,5, alors il est considéré que ce n'est pas le cas, et la valeur LCL est mise à 0 dans l'opération 502.
Enfin, la première partie de la fonction ALCL() se termine dans une opération 530 dans laquelle la valeur LCL est introduite dans un tableau LCL[]. La valeur "0" indique que la valeur LCL est soit associée à une piste non périodique, soit insuffisamment homogène.