INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
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).
En référence aux FIGURES, deux exemples de réalisation de l’invention sont illustrés. L’invention concerne un outil de cueillette 1 permettant de récolter des fruits situés en hauteur dans un arbre. L’outil de cueillette 1 comporte :
- une perche 11 qui s’étend de manière rectiligne selon un axe d’élongation propre O1. Dans l’exemple de réalisation illustré de manière schématique sur les FIGURES 1 et 2, la perche 11 comporte un unique tronçon. Alternativement, la perche 11 peut être télescopique et comporter plusieurs tronçons aboutables les uns aux autres ;
- un dispositif de cueillette 12 d’un fruit dans l’arbre, le dispositif de cueillette 12 configuré pour permettre de détacher un fruit d’une branche de l’arbre. Le détachement du fruit de la branche est préférentiellement réalisé par coupage d’un pédoncule du fruit. Le dispositif de cueillette 12 est situé au niveau d’une extrémité supérieure 111 de la perche 11, c’est-à-dire celle qui est destinée à être portée en hauteur par un utilisateur de l’outil de cueillette 1 ;
- un dispositif de recueil 13 d’un fruit coupé par le dispositif de cueillette 12, le dispositif de recueil 13 étant configuré pour réceptionner un fruit venant d’être prélevé de l’arbre par le dispositif de cueillette 12. Ainsi, le fruit prélevé sur la branche de l’arbre tombe par simple effet gravitaire dans le dispositif de recueil 13. Le dispositif de recueil 13 forme ainsi un logement temporaire pour les fruits successivement prélevés sur l’arbre, de sorte à ce qu’ils soient temporairement stockés en hauteur et à une faible distance par rapport à la branche sur laquelle ils ont été prélevés.
Dans le premier exemple de réalisation illustré sur les FIGURES 1 et 5, le dispositif de recueil 13 est solidaire de la perche 11 et situé à l’aplomb du dispositif de cueillette 12, à distance de l’extrémité supérieure 111 de la perche 11. Comme visible sur la , le dispositif de recueil 13 est situé à l’aplomb du dispositif de cueillette 12, de sorte qu’un axe d’alignement O2 – ou axe central – du dispositif de recueil 13 soit sécant avec l’outil de cueillette 1. Une distance entre le dispositif de recueil 13 et le dispositif de cueillette 12 est inférieure à 40 cm.
Dans le deuxième exemple de réalisation illustré sur les FIGURES 2 et 6, le dispositif de recueil 13 est fixé solidairement à un organe d’orientation 123 décrit plus bas. Cette configuration avantageuse permet de faire coïncider une orientation du dispositif de cueillette 12 et celle du dispositif de recueil 13, afin que les fruits coupés tombent toujours dans ledit dispositif de recueil 13.
De manière avantageuse, le dispositif de recueil 13 comporte un filet de récupération d’un fruit coupé par l’outil de coupe 121, le filet de récupération est situé à l’aplomb de l’outil de coupe 121.
Le filet de récupération comporte :
- un filet périphérique 134 formant un cylindre ou un cône au travers duquel le fruit coupé est destiné à tomber. Au niveau d’une partie supérieure 131, le filet périphérique 134 est délimité par un arceau 137 formant l’ouverture du filet de récupération ;
– un espace de stockage 136 de plusieurs fruits coupés, étant situé au niveau d’une partie inférieure 132 du filet périphérique 134. L’espace de stockage 136 forme un logement en communication avec la partie supérieure 131 du filet périphérique 134 et destiné à recevoir plusieurs fruits coupés ; et
– un dispositif d’amortissement 133 de la chute d’un fruit coupé dans ledit filet de récupération.
Selon une première variante de réalisation illustrée sur les FIGURES 1 et 2, le dispositif d’amortissement 133 est logé dans le filet périphérique 134 et situé au-dessus de l’espace de stockage 136. Le dispositif d’amortissement 133 est situé dans une position intermédiaire entre la partie supérieure 131 et la partie inférieure 132 du filet périphérique 134.
Selon une deuxième variante de réalisation illustrée sur les FIGURES 5 et 6, le dispositif d’amortissement 133 est logé dans le filet périphérique 134 et délimite, latéralement par rapport à la perche 11, un espace de stockage 136 et un espace de réception 138 des fruits coupés. L’espace de réception 138 est situé d’un premier côté de la perche 11, et l’espace de stockage 136 est situé d’un deuxième côté de la perche 11. Le dispositif d’amortissement 133 est situé au niveau de la partie inférieure 132 du filet périphérique 134.
De manière avantageuse, le dispositif d’amortissement 133 est incliné de sorte que l’espace de réception 138 soit situé au-dessus de l’espace de stockage 136. Par exemple, une inclinaison du dispositif d’amortissement 133 est égale à 5° ou 6°. Eventuellement, le dispositif d’amortissement 133 comporte, au niveau d’une limite entre l’espace de réception 138 et l’espace de stockage 136 marquée par un arceau transversal 139 :
- une variation en pente douce ; ou
- une marche formant une discontinuité de forme et d’inclinaison, de sorte qu’une hauteur de la marche soit comprise entre 1 cm et 2 cm.
Selon une autre caractéristique optionnelle de l’invention, le rail de liaison comprend au moins une platine rendue solidaire du rail de guidage par le boulon, la platine comprenant au moins un revêtement en matériau diminuant les forces de frottement entre la platine et le rail de guidage.
Selon une autre caractéristique optionnelle de l’invention, le panneau comprend un pan principal s’étendant dans un plan parallèle à une direction d’allongement principal de la cuve de stockage et à une direction verticale et au moins un pan d’extrémité s’étendant dans le plan parallèle à une direction d’allongement principal de la cuve de stockage et à une direction transversale, le pan d’extrémité étant solidaire du rail de liaison.
Selon une autre caractéristique optionnelle de l’invention, le panneau comprend de pans latéraux s’étendant chacun dans des plans parallèles à la direction verticale et à la direction transversale.
Selon une autre caractéristique optionnelle de l’invention, le panneau comprend des moyens de rigidification comportant au moins une paroi de rigidification s’étendant perpendiculairement au pan principal et au pan d’extrémité, en étant solidaire du pan principal et du pan d’extrémité.
Selon une autre caractéristique optionnelle de l’invention, le panneau présente une extrémité supérieure au regard de la paroi supérieure de la cuve de stockage et une extrémité inférieure au regard de la paroi inférieure de la cuve de stockage, le premier dispositif de fixation étant disposé entre l’extrémité supérieure du panneau et la paroi supérieure de la cuve de stockage, le deuxième dispositif de fixation étant disposé entre l’extrémité inférieure du panneau et la paroi inférieure de la cuve de stockage, formant ainsi une paroi anti-ballotement.
Selon une autre caractéristique optionnelle de l’invention, le premier dispositif de fixation est disposé entre l’extrémité inférieure du panneau et la paroi inférieure de la cuve de stockage, le deuxième dispositif de fixation étant disposé entre l’extrémité supérieure du panneau et la paroi supérieure de la cuve de stockage de sorte à former une paroi anti-ballotement.
Selon une autre caractéristique optionnelle de l’invention, le système anti-ballotement comprend une pluralité de panneaux alignés dans un même plan.
Selon une autre caractéristique optionnelle de l’invention, les pans principaux des panneaux s’inscrivent dans un même plan.
Selon une autre caractéristique optionnelle de l’invention, le moyen de blocage longitudinal du déplacement du rail de liaison le long de l’un des degrés de liberté axiaux est constitutif du premier dispositif de fixation.
La présente invention concerne également un navire destiné à transporter du gaz à l’état liquide comprenant au moins une cuve de stockage telle qu’exposée ci-dessus et une coque à l’intérieur de laquelle est disposée l’au moins une cuve de stockage, au moins l’un des dispositifs de fixation étant solidaire de ladite coque.
est une coupe transversale d’une cuve de stockage selon l’invention comprenant un système anti-ballotement ;
est une vue en perspective du système anti-ballotement illustré sur la ;
est une vue de détails en perspective d’un dispositif de fixation du système anti-ballotement illustré sur la ;
est une autre vue de détails en perspective du dispositif de fixation du système anti-ballotement illustré sur la ;
est une vue de détails en perspective d’un premier dispositif de fixation du système anti-ballotement illustré sur la ;
Selon un autre exemple encore, une station de base 6, 7 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,7 peut déduire des informations relatives à l’état de la cellule à partir de son propre état : par exemple, si la station de base 6,7 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,7 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.
Chaque station de base 6, 7 peut par ailleurs obtenir certaines des informations INFO_CURR d’entités tierces, par exemple d’entités du réseau NW ou d’entités externes. Notamment, on peut envisager que chaque station de base 6, 7 soit configurée pour communiquer avec le système 14 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 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, 7 peut également avoir connaissance de certaines des informations INFO_CURR et/ou INFO_gNB, car elle les utilise pour implémenter les traitements dont elle est en charge ou parce qu’elle est configurée pour diffuser ces informations sur le réseau NW (par exemple, l’identité des cellules qu’elle gère, ou la liste des TAs et/ou des slices qu’elle supporte).
La nature des informations INFO_CURR (et le cas échéant INFO_gNB) utilisées par chaque module 15 d’envoi d’une station de base 6, 7 pour enrichir les informations système SI peut être définie par défaut au niveau de la station de base, par exemple par l’opérateur OP 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). De façon alternative ou complémentaire, on peut envisager que le module 15 d’envoi d’une station de base soit configuré pour opérer une sélection de tout ou partie des informations de conditions de déploiement courantes des cellules qu’il envoie dans les SIB en fonction d’un ou des plusieurs facteurs donnés, tels que par exemple de la localisation de la station de base à laquelle il appartient (ex. environnement rural ou urbain), ou de la mobilité des UE rattachés aux cellules que la station de base gère, etc.
Une fois obtenues les informations INFO_CURR (et le cas échéant INFO_gNB) qu’elle souhaite/doit diffuser sur les cellules qu’elle gère, la station de base 6, 7 les transmet via son module 15 d’envoi dans des blocs SIB d’information système selon la procédure décrite dans le document 3GPP TS 38.331, paragraphe 5.2.2 (étapes E10 et E20). Ainsi, la station de base 6 diffuse via son module 15 d’envoi dans les SIB les informations INFO_CURR (et le cas échéant INFO_gNB) qu’elle a obtenues sur les cellules C1, C2 et C3, et la station de base 7 diffuse via son module 15 d’envoi dans les SIB les informations INFO_CURR (et le cas échéant INFO_gNB) qu’elle a obtenues sur les cellules C4, C5 et C6.
Il convient de noter que les informations INFO_CURR (et le cas échéant INFO_gNB) diffusées par la station de base 6, 7 peuvent être transmises par son module 15 d’envoi dans les SIB sous forme brute ou sous forme condensée, par exemple, sous la forme de valeurs de hachage (ou « hash » en anglais), de clés ou de liens permettant d’accéder aux informations brutes dans une base de données sécurisée ou auprès de toute autre entité de confiance interne ou externe ou réseau NW (non représentée sur la ). Le recours à des fonctions de hachage permet notamment de sécuriser les informations INFO_CURR transmises : en effet, de telles fonctions de hachage ont des propriétés variées et peuvent notamment être utilisées de façon connue pour authentifier et protéger l’intégrité des données auxquelles elles sont appliquées, gérer la confidentialité de ces données ou les masquer.
On note en outre que conformément au standard 3GPP, les SIB (et a fortiori dans le mode de réalisation décrit ici les informations INFO_CURR, et le cas échéant INFO_gNB) peuvent être diffusés périodiquement par les stations de base du réseau NW (dont les stations de base 6 et 7 du système 1) ou être transmis par les stations de base sur requête des UEs.
Dans l’exemple envisagé ici, on suppose que l’UE 8, par l’intermédiaire de son module 21 de réception et de ses moyens de communication 20, reçoit les SIB diffusés par la station de base 6 contenant les informations INFO_CURR (et le cas échéant INFO_gNB) relatives aux cellules C1, C2 et C3, et les SIB diffusés par la station de base 7 contenant les informations INFO_CURR (et le cas échéant INFO_gNB) relatives aux cellules C4, C5 et C6.
Dans le mode de réalisation décrit ici, l’UE 8 via son module 22 de traitement utilise les informations INFO_CURR relatives aux conditions de déploiement courantes des cellules C1 à C6 pour sélectionner une cellule pour s’enregistrer auprès du réseau cœur CN du réseau cellulaire NW (étape E30). Par exemple, le module 22 de traitement peut tenir compte à cet effet du contexte d’usage dans lequel se trouve l’UE 8 et sélectionner en fonction de ce contexte la cellule la plus appropriée parmi les cellules C1 à C6 au regard des informations INFO_CURR dont il dispose. Ce contexte peut être défini au niveau de l’UE 8 de façon statique (par exemple configuré lors de la fabrication de l’UE ou par l’utilisateur) et refléter un usage particulier de l’UE 8 : par exemple, l’UE 8 est un appareil destiné à équiper un bateau, une voiture, un train, etc. Le contexte d’usage de l’UE 8 peut en variante être déterminé de façon dynamique par le module 22 de traitement, par exemple en interrogeant l’utilisateur de l’UE 8 via une interface utilisateur prévu à cet effet, ou de façon autonome en s’appuyant par exemple sur l’historique des cellules qu’il a utilisées et le type de déploiement associé à ces cellules (par exemple les N dernières cellules étaient de type routier), et/ou sur des informations remontées le cas échéant par son accéléromètre (qui permet notamment de distinguer un usage piéton d’un usage voiture, les mouvements de l’UE n’étant pas les mêmes), etc.
Ainsi, à titre illustratif, si le module 22 de traitement détermine que l’UE 8 équipe un bateau et qu’il dispose parmi les informations INFO_CURR, d’informations sur les conditions de déploiement des cellules C1 à C6 et/ou sur les infrastructures qu’elles couvrent, le module 22 de traitement peut sélectionner une cellule parmi les cellules C1 à C6 pour lesquelles ces informations indiquent un déploiement de type port ou voie navigable ou couvrant un port ou une voie navigable.
Selon un autre exemple, si le module 22 de traitement détermine que l’UE se trouve à bord d’un train (respectivement d’une voiture ou d’un camion) et qu’il dispose parmi les informations INFO_CURR, d’informations sur les conditions de déploiement des cellules C1 à C6 et/ou sur les infrastructures qu’elles couvrent, le module 22 de traitement peut sélectionner une cellule parmi les cellules C1 à C6 pour lesquelles ces informations indiquent un déploiement de type voie ferrée ou couvrant une voie ferrée (respectivement de type routier).
Bien entendu, ces exemples ne sont donnés qu’à titre illustratif et ne sont pas limitatifs de l’invention.