INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Le module 2A peut en outre exploiter des informations dont la gNB 2 dispose pour construire la matrice FMAT(3) et obtenir tout ou partie des caractéristiques du trafic sortant associé à l’UE 3. En effet, la gNB 2 connaît, pour chaque slice du réseau NW, l’identifiant (S-NSSAI) de cette slice, le ou les services qu’elle propose, ainsi que les UE connectés à la slice. La gNB 2 est également en mesure de déterminer en interrogeant la fonction d’accès et de mobilité du réseau NW (aussi connue sous le nom de fonction réseau AMF pour « Access and Mobility Function » en anglais), les slices autorisées pour un UE particulier suite à son enregistrement auprès du réseau NW. La gNB 2 dispose par ailleurs des SLA associés à chaque service fourni par le réseau NW. , qui lui permet d’identifier les flux QoS relatifs à ce service ainsi que les valeurs 5QI associées à ces flux QoS (et incidemment, la priorité associée à chaque flux QoS et la latence maximale supportée par celui-ci et par chaque flux de données de service lié à ce flux QoS).
Le module 2A peut donc exploiter ces informations, combinées à celles fournies le cas échéant par l’UE 3, pour compléter la matrice FMAT(3).
Il peut également, en variante, exploiter ces informations sur les services auxquels est connecté l’UE 3 et les priorités associés à ces services, et estimer les flux sortants et la volumétrie de ces flux en utilisant un modèle de prédiction MOD(3) du trafic associé à l’UE 3, établi pour chaque service offert par le réseau NW auquel l’UE 3 est autorisé à se connecter (ou de façon équivalente ici pour chaque slice du réseau NW autorisée pour l’UE 3). Aucune limitation n’est attachée à la nature du modèle de prédiction qui peut s’appuyer sur un algorithme d’apprentissage par renforcement ou par renforcement profond, un modèle mathématique ou une heuristique, etc.
Dans l’exemple illustratif considéré ici, où les deux slices SL(S1) et SL(2) sont autorisées pour l’UE 3, et seul le trafic sortant associé à l’UE 3 est pris en compte, un tel modèle MOD(3) comprend deux composantes, une première composante MOD(3,S1) correspondant à un modèle de prédiction de trafic UL établi pour l’UE 3 pour le service S1 (ou de façon équivalente pour la slice SL(S1)) et une deuxième composante MOD(3,S2) correspondant à un modèle de prédiction de trafic UL établi pour l’UE 3 pour le service S2 (ou de façon équivalente pour la slice SL(S2)), soit MOD(3)=[MOD(3,S1) ; MOD(3,S2)]. Un tel modèle de prédiction MOD(3) peut être appris (c’est-à-dire construit et mis à jour jusqu’à converger vers un modèle stable) de façon connue en soi, à partir de données d’apprentissage collectées lors d’une phase préliminaire d’apprentissage, ces données d’apprentissage correspondant aux caractéristiques précitées (nombre de flux, niveau de priorité associé, volumétrie) déterminées pour les flux sortants associés à l’UE 3 durant la phase d’apprentissage, à chaque fois que l’UE 3 est connecté à un service offert par une slice du réseau NW. Un tel apprentissage peut être supervisé ou non.
Le module 2A d’estimation peut en variante utiliser, pour chaque service auquel l’UE 3 est connecté ou autorisé à se connecter, un modèle de prédiction du trafic sortant associé à une pluralité d’UE attachés à la gNB 2 et connectés ou autorisés à se connecter à ce service (la pluralité d’UE est par exemple un groupe d’UE connectés ou autorisés à se connecter aux mêmes slices, ou l’ensemble des UE attachés à la gNB 2).
Par ailleurs, comme mentionné précédemment, dans l’exemple illustratif envisagé ici, on ne considère par souci de simplification pour l’UE 3 que des flux de données sortants, c’est-à-dire émis par l’UE 3. Dans l’hypothèse de l’existence de flux de données entrants destinés à l’UE 3, le module 2A peut obtenir les caractéristiques de ces flux entrants, et compléter la matrice FMAT(3) établie pour les flux entrants, à partir d’informations fournies par l’entité distante à l’origine des flux entrants et/ou à partir d’informations dont la gNB 2 dispose, ou en utilisant un modèle de prédiction pour le trafic DL, de façon similaire ou identique à ce qui vient d’être décrit pour les flux sortants.
En variante, des informations permettant de déterminer la matrice FMAT(3) des flux sortants associés à l’UE 3 peuvent être obtenues par le module 2A d’autres entités du réseau NW ayant une visibilité sur ces flux, comme par exemple une fonction réseau NWDAF telle qu’évoquée précédemment.
A partir des caractéristiques des flux QoS sortants contenues dans la matrice FMAT(3), le module 2B d’ordonnancement (ou ordonnanceur ou encore « scheduler » en anglais) de la gNB 2 décide de l’ordonnancement des paquets de données véhiculés par ces flux (étape E20). Différents types d’ordonnanceurs peuvent être envisagés dans le contexte de l’invention, comme par exemple un ordonnanceur configuré pour ordonnancer les paquets de flux de données appartenant à différentes slices tel que décrit dans le document de M. Raftopoulou et al. intitulé « Optimisation of Numerology and Packet Scheduling in 5G Networks : To Slice or not to Slice », IEEE 93 rd Vehicular Technology Conference, 2021, ou dans le document de X. Zhang et al. intitulé « RB Allocation Scheme for eMBB and uRLLC coexistence in 5G and Beyond », Wireless Communications and Mobile Computing, vol. 2021, 11 octobre 2021. Ces exemples ne sont donnés qu’à titre illustratif et ne sont pas limitatifs en soi, d’autres ordonnanceurs pouvant être utilisés dans le contexte de l’invention, comme par exemple un ordonnanceur basé sur un algorithme similaire à celui décrit dans le document de Boutiba et al. cité précédemment, mais dans lequel la contrainte visant à utiliser une même BWP et une même numérologie pour les services S1 et S2 est relâchée.
Ainsi, le module 2B d’ordonnancement affecte une BWP associée à une numérologie µ (notée BWP(µ)) à chaque flux QoS se rapportant aux services auxquels l’UE 3 est connecté(S1 et S2 dans l’exemple envisagé ici), à partir de la connaissance de ces services et des flux QoS, de leurs priorités respectives ou de leurs exigences respectives en termes de latence. Le choix effectué par le module 2B d’ordonnancement de la partie de bande passante BWP(µ) à activer pour la transmission des flux QoS relatifs à un service tient compte du SLA associé au service et des profils QoS associés aux flux QoS : la BWP et la numérologie µ choisies permettent en effet de respecter le SLA du service et le profil QoS des flux QoS.
Dans le mode de réalisation décrit ici, le module 2B d’ordonnancement est configuré pour choisir une même BWP pour tous les flux QoS se rapportant à un même service. Par exemple, une partie de bande passante BWP2 (extraite de la bande passante BW(CF) allouée à la cellule CELL) associée à une numérologie µ2 élevée (ex. µ2=3 ou 4 dans la table 1), notée dans la suite BWP2/µ2, est choisie pour les flux QoS relatifs au service S2 prioritaire (flux DF3), tandis qu’une partie de bande BWP1 (extraite de la bande BW(CF) allouée à la cellule CELL) associée à une numérologie µ1 moins élevée (ex. µ1=0 ou 1 dans la table 1), notée dans la suite BWP1/µ1, est choisie pour les flux DF1 et DF2 relatifs au service S1 non prioritaire.
Selon certains modes de réalisation, l’opérateur d’infrastructure enregistre les fonctions de sécurité singularisées associées à l’identifiant du terminal client et au service. Il peut enregistrer les fonctions en tant que telles, par exemple sous la forme de code logiciel, ou des informations permettant d’obtenir ces fonctions, de la même manière que les informations transmises au dispositif client et au fournisseur de service décrites précédemment.
Une fois la ou les fonctions singularisées de sécurité transmises au dispositif client et au fournisseur de services, des étapes additionnelles d’activation du service peuvent être envisagées. A ce titre, l’activation peut utiliser des mécanismes de challenge/réponse ( en anglais « challenge /response ») pour activer le service. Le fournisseur de services peut créer un défi donné dont il connait la réponse attendue. Il transmet ce défi, la fonction singularisée est appliquée sur ce message de défi et renvoie une réponse que le fournisseur de services vérifie. Si la vérification montre que la réponse est bien la réponse attendue, alors le service est activé.
Une fois activé, le service peut être utilisé par le dispositif client car celui-ci respecte le niveau de sécurité attendu pour la mise en œuvre du service par le fournisseur de service.
Sur les figures 3, 4 et 5, on utilise les abréviations suivantes : - FS : fournisseur de service - OI : opérateur d’infrastructure - SG : service de singularisation - Infra : infrastructure réseau - Client : dispositif client
La représente un premier mode de réalisation d’une mise en œuvre d’un service de déploiement d’une fonction de sécurité. Elle représente les échanges entre les dispositifs du système.
Une première étape optionnelle peut comprendre une requête REQ_1 de la part du dispositif client. Cette requête peut comprendre une demande du dispositif client d’une fonction de sécurité singularisée. Ce dispositif peut souhaiter mettre en œuvre un service fourni par un des fournisseurs de service, mais ne dispose pas du niveau de sécurité requis par le fournisseur de service pour la mise en œuvre du service.
Plus généralement, l’opérateur d’infrastructure peut ne pas générer une seule fonction de sécurité pour un terminal client suite à une requête telle la requête REQ_1 mais peut générer une ou plusieurs fonctions de sécurité pour chaque ou plusieurs des terminaux clients présents dans le réseau de l’opérateur, sans attendre de requête. En effet, l’opérateur d’infrastructure peut avantageusement disposer de la connaissance de l’ensemble des terminaux clients, et générer les fonctions de sécurité pour ces terminaux connectés au réseau. L’opérateur peut générer ces fonctions de sécurité en utilisant un service de singularisation, en charge de générer les fonctions de sécurité. Le service de singularisation, illustré comme étant un dispositif ou module différent de l’opérateur d’infrastructure, pour des raisons de clarté, peut être intégré à celui-ci, comme mentionné en référence à la . L’opérateur d’infrastructure peut proposer un service de singularisation à tous les fournisseurs de service et à tous les dispositifs clients. Ce service peut être mis en œuvre à la demande, ou suite à l’établissement d’un contrat entre le fournisseur de service qui souhaite utiliser le service de singularisation. Ainsi, avantageusement, des terminaux clients qui ne pouvaient pas bénéficier du service car n’ayant pas le niveau de sécurité requis par le service, peuvent élever leur niveau de sécurité et ainsi mettre en œuvre le service. Ce service peut également être mis en œuvre lors de l’achat du dispositif client ou lors de la fabrication du dispositif client.
L’opérateur d’infrastructure demande donc au service de singularisation une ou plusieurs fonctions de sécurité G pour chacun des dispositifs clients, requête REQ_2. Ceci peut être fait, comme mentionné précédemment, suite à une demande du dispositif client mais plus généralement automatiquement par l’opérateur d’infrastructure, par exemple lors de la connexion dudit dispositif client au réseau. Le service de singularisation peut générer une fonction de sécurité comme décrit en référence à la . La ou les fonctions de sécurité G ou les paramètres permettant de créer ou déterminer ou obtenir cette fonction de sécurité ou cette pluralité de fonctions de sécurité G, sont transmis par le dispositif de singularisation à l’opérateur lors dans un message REP_2. L’opérateur d’infrastructure transmet aux dispositifs clients les informations relatives à cette ou ces premières fonctions de sécurité, dans un message TR_SG1. Le service de singularisation enregistre la ou les fonctions G.
Outre la au moins une fonction de sécurité déterminée pour chaque dispositif client, le service de singularisation peut déterminer une ou plusieurs fonction de sécurité singularisées V aptes à collaborer avec la ou les fonctions de sécurité transmises au dispositif client. Par collaborer on peut entendre, décoder des données générées par la au moins une première fonction de sécurité ou coder des données destinées à la au moins une première fonction de sécurité. Le service de singularisation enregistre la ou les fonctions V. Autrement dit, la première fonction de sécurité et la seconde fonction de sécurité collaborent ensemble pour coder, décoder ou vérifier le service de sécurité à sécuriser entre le dispositif client et le fournisseur de services lors de la mise en œuvre du service.
L’opérateur d’infrastructure transmet au fournisseur de services la ou les fonctions de sécurité singularisées V lui permettant de collaborer avec les fonctions G dans le message TR_SG2. Outre les informations relatives aux fonctions de sécurité singularisées V, l’opérateur d’infrastructure peut transmettre un identifiant du dispositif client à qui la fonction G est transmise. Cet identifiant peut être un identifiant, différent de ou identique à, l’identifiant que l’opérateur d’infrastructure utilise pour communiquer ou identifier le terminal client dans le réseau. Cet identifiant peut être un identifiant généré pour les communications mises en œuvre entre le fournisseur de service et le terminal client lors de la mise en œuvre du service. Cet identifiant peut également être un ensemble de données permettant d’identifier le dispositif utilisateur et le composant, par exemple une adresse IP, un identifiant d’application tel l’AID, identifiant normalisé des applications pouvant être installées sur une carte à puce (AID, acronyme anglais de « application identifier »).
Comme mentionné précédemment, les informations relatives à ces fonctions de sécurité peuvent être transmises - sous la forme de code logiciel de la fonction, - sous la forme d’un ensemble d’informations permettant au dispositif client et au fournisseur de service de construire la fonction, l’ensemble d’informations pouvant comprendre : - un identifiant de la fonction de sécurité transmise, - une liste LBA, - un accès sécurisé à un serveur comprenant le code de la fonction de sécurité transmise.
On peut noter que la forme sous laquelle les informations transmises au dispositif client relatives à cette ou ces premières fonctions de sécurité dans le message TR_SG1 peut être différente de la forme sous laquelle les informations transmises au fournisseur de service client relatives à cette ou ces secondes fonctions de sécurité, dans le message TR_SG2.
Optionnellement, l’opérateur d’infrastructure peut transmettre au dispositif client un message lui donnant des droits d’utilisation du service de singularisation, dans le message OPEN. Ce message peut par exemple être transmis suite à une requête d’utilisation, par exemple la requête REQ_1, ou suite à une souscription au service de singularisation faisant elle-même suite à une demande de service au fournisseur de services. L’opérateur d’infrastructure peut par exemple distribuer au fournisseur de service un jeton pouvant être vérifié par l’équipement utilisateur et manifestant le droit de consommer la fonction singularisée Il est effectivement envisagé que les étapes de la comprennent, préalablement aux étapes indiquées sur la , une ou plusieurs étapes comprenant : - une demande du dispositif client au fournisseur de service d’une mise en œuvre (ou utilisation) d’un service, - une réponse dudit fournisseur de service indiquant audit terminal qu’il ne possède pas le niveau de sécurité requis pour la mise en œuvre du service demandé ou - une réponse dudit fournisseur de service indiquant audit terminal qu’il doit demander à l’opérateur d’infrastructure une activation du service de singularisation pour mettre en œuvre l’application demandée.
Des étapes d’activation ECH_1 et ECH_2 peuvent être mises en œuvre permettant l’utilisation de la fonction singularisée G et de la fonction inverse V. Les étapes d’activation ECH_1 et ECH_2 peuvent consister en la réalisation d’un premier échange réussi entre le fournisseur de services et le dispositif client. Elles peuvent être faites dans un ordre différent de ce qui est illustré sur la (ECH_2 avant ECH_1). Cette activation peut utiliser un mécanisme de type « challenge-response ». Le fournisseur de services peut créer un défi donné dont il connait la réponse attendue. Il transmet ce défi, la fonction singularisée est appliquée sur ce message de défi et renvoie une réponse que le fournisseur de services vérifie. Si la vérification montre que la réponse est bien la réponse attendue, alors le service est activé.
Dans certains modes de réalisation, le service de singularisation détermine deux fonctions singularisées G1 et V2 pour le dispositif client et G2 et V1 pour le fournisseur de service. Avantageusement, ceci permet de renforcer la sécurité en brouillant différemment les messages allant du terminal client vers le fournisseur de services et les messages allant du fournisseur de services vers le terminal client.
Avantageusement, les fonctions G et V sont des bijections et peuvent être utilisées en miroir, c’est-à-dire que V peut être utilisé pour chiffrer ou crypter ou brouiller et G pour déchiffrer, décrypter ou débrouiller.
Les moyens d’ajustement 42 comprennent des arrêts de cordon 44 et un cordon 46. Le cordon est un cordon raide ou élastique . Le cordon 46 est reçu à l’intérieur d’un ourlet 48 formé sur le bord transversal avant de la toile 2 et engagé à travers les arrêts de cordon 44 . Les extrémités du cordon 46 comprennent des boucles. Ainsi, le tirage du cordon 46 est facilité.
Les arrêts de cordon 44 sont agencés aux extrémités du cordon 46 de sorte que lorsque les arrêts de cordon 44 sont coulissés le long du cordon 46 vers le centre du cordon 46 le bord transversal avant de la toile 2 est plissée et lorsque les arrêts de cordon 48 sont coulissé le long du cordon 46 vers les extrémités du cordon 46 la toile 2 est déplissée. Ainsi, la forme du bord transversal avant de la toile 2 peut être ajustée afin d’épouser la forme du véhicule.
Les moyens d’ajustement 42 comprennent des boucles 49 connectées aux extrémités du bord transversal avant de la toile 2 à travers lesquelles des sardines peuvent être engagées et plantées dans le sol près du véhicule. Additionnellement ou alternativement, les moyens d’ajustement 42 comprennent des crochets 47 connectés aux extrémités du bord transversal avant de la toile 2 agencés pour crocheter le véhicule. Ainsi, le bord transversal avant de la toile 2 peut épouser la forme du véhicule plus encore.
La un auvent de véhicule 101 dans une configuration arrière selon un deuxième mode de réalisation. L’auvent de véhicule 101 diffère de l’auvent de véhicule 1 en ce que les moyens d’ajustement 42 sont remplacés par des moyens d’ajustement 142.
Les moyens d’ajustement 142 comportent une bande velcro mâle 144 s’étendant le long du bord transversal avant de la toile 2 sur une face intérieure et une bande velcro femelle 146 s’étendant le long du bord transversal avant de la toile 2 sur une face extérieure (ou inversement). La bande velcro mâle 144 et la bande velcro femelle 146 sont agencées de sorte que lorsque le bord transversal avant de la toile 2 est enroulée sur lui-même la bande velcro mâle 144 coopère avec la bande velcro femelle 146 pour maintenir la toile enroulée sur elle-même. Ainsi, la forme du bord transversal avant de la toile 2 peut être ajustée afin d’épouser la forme du véhicule.
Les Figures 5 et 6 illustrent un auvent de véhicule 201 dans une configuration arrière selon un troisième mode de réalisation. L’auvent de véhicule 201 diffère de l’auvent de véhicule 1 en ce que les moyens d’ajustement 42 sont remplacés par des moyens d’ajustement 242.
Les moyens d’ajustement 242 comportent des boucle mâles 244 connectées au bord transversal avant de la toile 2 et des boucles femelles 246 connectées au bord transversal avant de la toile 2. Les boucle mâles 244 et les boucles femelles 246 opèrent par paire et sont distantes l’une de l’autre. Les boucles mâles 244 et les boucles femelles 246 sont agencées de sorte lorsque les boucles mâles 244 sont reçues dans les boucles femelles 246 le bord transversal avant de la toile 2 est plié et lorsque les boucle mâles 244 ne sont pas reçues dans les boucle femelles 246 le bord transversal avant de la toile 2 est déplié. Ainsi, la forme du bord transversal avant de la toile 2 peut être ajustée afin d’épouser la forme du véhicule.
Les boucles mâles 244 sont connectées au bord transversal avant de la toile 2 par des sangles. Les boucles femelles 246 sont connectées au bord transversal avant de la toile 2 par des sangles. La longueur des sangles connectant les boucles mâles 244 au bord de la toile 2 et/ou la longueur des sangles connectant les boucles femelles 246 à la toile 2 peut être ajustée afin d’ajuster la forme du bord transversal avant de la toile 2 plus finement (non représenté).
Comme il va de soi, la présente demande ne se limite pas à la seule forme d’exécution décrite ci-dessus à titre d’exemple, elle en embrasse au contraire toutes les variantes de réalisation.
Châssis télescopique PITERAC pour résidences mobiles en zones inondables. Cette innovation s’applique à certaines habitations situées en zones inondables. Il existe 4 types de construction pour faire face aux inondations : Construction traditionnelle fixe au-dessus de l’eau Construction traditionnelle flottante dans une double coque Construction légère flottante avec fondations Construction légère flottante sans fondations
En France, la loi Climat et Résilience interdit les constructions fixes dans les zones exposées aux inondations, mais les résidences mobiles sont acceptées. Ce qui limite le champ des habitations autorisées dans les zones inondables selon liste ci-dessus aux seules constructions légères sans fondations.
Nous limiterons donc notre recherche à ce que propose la technique actuelle pour satisfaire les 2 critères ci-dessous : Assurer la mobilité du lieu de résidence Sécuriser l’habitat en zone inondable
Contexte environnemental, sociétal et réglementaire : Le réchauffement climatique est à l’origine d’une élévation globale du niveau des mers. L’urbanisation intensive, source d’imperméabilisation des sols, amplifie ces effets avec la brusque montée des cours d’eau lors d’épisodes pluvieux. De ce fait, nombre d’habitation sont situées dans des zones submersibles ou condamnées à l’être ces prochaines années. Les pays européens concernés durcissent leur législation pour protéger les biens et les personnes, notamment la France, où il est interdit de construire ou d’aménager de nouveaux lieux d’habitation sur des terrains classés inondables. Les propriétaires dont les terrains sont menacés, doivent déménager ou entreprendre des travaux de sécurisation des lieux existants qui ne font que repousser l’échéance car la montée des eaux est inexorable ! Les résidences mobiles sont cependant acceptées en qualité d’habitat temporaire grâce à leur mobilité qui autorise un déplacement rapide. Dans le reste du monde cette situation pousse au déplacement des personnes dont l’habitat traditionnel est menacé ce qui restreint les zones de peuplement et accroit l’immigration climatique des populations.
On peut également citer 6 autres publications plus anciennes relatives à des constructions flottantes telles que : « Construction flottante » n° WO2007030013 – 2007.03.15 « La maison flottante enclavée » n° WO9513212 – 1995.05.18 « L’agencement d’une construction mobile entre 2 positions, l’une en appui au sol et l’autre flottante » n° WO03031732 – 2003.04.17 « Construction en bois dans les zones inondables avec système de protection contre les inondations » n° CZ2012330 – 2012.05.20 « Dispositif de survie dans le cadre de catastrophes naturelles constitué d’un module d’habitation et de ses accessoires » n° WO2007110489 – 2006.03.03 « Maison flottante à terre » n° WO9513212 - 1995.05.18