INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Cependant, toutes ces publications font référence à des constructions flottantes qui ne pourront être érigées en zones inondables car non mobiles. On peut donc le constater, les techniques actuelles, bien qu’intéressantes par certains aspects, ne permettent pas de satisfaire à la fois aux 2 critères de mobilité et de sécurité. Voilà pourquoi nous présentons le châssis télescopique PITERAC destiné aux résidences mobiles situées en zones inondables.
La gNB 2, via son module 2E d’envoi, informe alors l’UE 3 des ressources qui lui sont allouées pour l’émission de son trafic sortant, comme décrit précédemment à l’étape E40.
Si la valeur limite Llim n’est pas atteinte pour aucun des services auxquels l’UE 3 est connecté (réponse non à l’étape test E52), le module d’ajustement 2C diminue la fréquence de surveillance courante, par exemple en augmentant d’un nombre de déterminé de slots la période T PDCCH avec laquelle l’UE 3 surveille de façon périodique le canal PDCCH (étape E54). Ceci permet avantageusement d’économiser les ressources du réseau et la consommation de puissance de l’UE 3.
Pour dimensionner de quel ordre la fréquence de surveillance doit être diminuée, c’est-à-dire « dimensionner » la diminution à apporter à la fréquence de surveillance (dans l’exemple envisagé ci-avant, évaluer le nombre de slots à ajouter à la période T PDCCH ), le module 2C peut procéder par tâtonnement, de manière itérative, par exemple en ajoutant lors de chaque itération un slot (ou plus) à la période T PDCCH tant que la latence de bout-en-bout du réseau en résultant pour chaque service est inférieure respectivement à la valeur limite Llim définie pour ce service. On note T PDCCH-adj , la période maximale permettant de respecter la contrainte de latence de bout-en-bout. Cette période T PDCCH-adj , ajustée par rapport à la valeur T PDCCH , est représentative de la fréquence de surveillance ajustée.
Il convient de noter que les étapes E52 à E54 sont optionnelles et visent à optimiser les ressources du réseau NW et de l’UE 3. Ainsi, dans une variante de réalisation, si les services relatifs aux flux sortants associés à l’UE 3 n’ont pas de priorités différentes ni d’exigences en termes de qualité de service différentes, la fréquence de surveillance du canal PDCCH par l’UE 3 est maintenue en l’état (pas d’ajustement). Par ailleurs, le module 2C d’ajustement peut également être configuré pour mettre en œuvre les étapes E52 à E54 qui viennent d’être décrites lorsqu’à l’étape E30, le module 2C détermine qu’aucun changement de BWP n’est requis par l’ordonnancement proposé par le module 2B.
Si la condition examinée à l’étape E51 est vérifiée (réponse oui à l’étape test E51), le module 2C d’ajustement examine si une augmentation de la fréquence de surveillance courante est possible, afin de réduire la latence due au changement de BWP, et améliorer la qualité de service des services et/ou des flux les plus prioritaires ou les plus exigeants en matière de latence. De tels services sont par exemple identifiés comme prioritaires du fait de leurs exigences en matière de latence (ex. services uRLLC ou V2X), ou parce qu’ils sont associés à des flux QoS ayant des valeurs 5QI élevées, supérieures à un seuil donné (par exemple supérieures à 82). Des considérations similaires s’appuient aux flux QoS et aux flux de données de service.
A cet effet, le module 2C d’ajustement détermine si la puissance consommée par l’UE 3 a atteint ou dépassé une valeur limite Plim (étape test E55). La puissance consommée par l’UE 3 est une mesure effectuée par l’UE 3 classiquement remontée à la gNB 2 et disponible au niveau de la gNB 2. La valeur limite Plim représente la valeur de la puissance maximale que l’UE 3 est autorisée à consommer ; elle est connue de la gNB 2 et définie par l’opérateur du réseau NW au regard des limites imposées par la Réglementation.
Si la puissance consommée par l’UE 3 a atteint ou dépassé sa valeur limite Plim (réponse oui à l’étape test E55), la fréquence de surveillance courante est maintenue en l’état (pas d’ajustement) (étape E56). En effet, une augmentation de la fréquence de surveillance aurait pour conséquence une augmentation de la puissance consommée par l’UE 3, ce qui pourrait s’avérer préjudiciable pour l’utilisateur de l’UE 3.
Sinon (réponse non à l’étape test E55), le module 2C d’ajustement augmente la fréquence de surveillance courante du canal de contrôle PDCCH par l’UE 3, par exemple en réduisant la période T PDCCH d’un nombre déterminé de slots (étape E57). Pour évaluer l’augmentation à apporter à la fréquence de surveillance courante (autrement dit dans l’exemple envisagé ici, le nombre de slots à soustraire à la période T PDCCH ), le module 2C peut procéder par tâtonnement, de manière itérative, par exemple en réduisant d’un slot lors chaque itération la période T PDCCH tant que la puissance consommée par l’UE 3 reste inférieure à sa valeur Plim. On note T PDCCH-adj , la période minimale permettant de respecter la contrainte de puissance consommée par l’UE 3. Cette période T PDCCH-adj , ajustée par rapport à la valeur T PDCCH , est représentative de la fréquence de surveillance ajustée.
D’autres façons de déterminer si un ajustement de la fréquence de surveillance courante est pertinent et le cas échéant, d’évaluer cet ajustement, peuvent être mises en œuvre par le module 2C d’ajustement au cours de l’étape E50, en prenant en compte les caractéristiques des flux associés à l’UE 3 collectées dans la matrice FMAT(3), et le cas échéant, d’autres facteurs comme des indicateurs de performance de l’UE 3 et/ou du réseau NW. Par exemple, le module 2C d’ajustement peut utiliser une intelligence artificelle (AI pour « Artificial Intelligence » en anglais) ou un algorithme d’apprentissage automatique (ou ML pour « Machine Learning » en anglais), ou encore un algorithme heuristique ou basé sur la théorie des jeux auxquels les caractéristiques des flux et le cas échéant les indicateurs de performances sont fournis en tant que paramètres d’entrée.
Par ailleurs, d’autres quantités représentatives de la fréquence de surveillance peuvent être envisagées que la période avec laquelle l’UE 3 surveille le canal PDCCH, telle que par exemple l’inverse de cette période (fréquence).
Si au cours de l’étape E50, un ajustement de la fréquence de surveillance du canal PDCCH par l’UE 3 a été décidé (étapes E54 et E57), alors la fréquence de surveillance ajustée est notifiée à l’UE 3 par la gNB 2 via son module 2D de notification (étape E60). A cet effet, le module 2D de notification utilise par exemple un message RRC permettant de reconfigurer l’UE 3 avec la fréquence de surveillance ajustée, pour qu’il la mette en œuvre pour surveiller le canal PDCCH (i.e. pour qu’elle devienne la fréquence de surveillance courante appliquée par l’UE 3). Plus particulièrement, ce message RRC est utilisé par la gNB 2 pour modifier la valeur du champ monitoringSlotPeriodicityAndOffset qui définit la périodicité avec laquelle l’UE 3 doit scanner une bande de fréquences déterminée (définie par le CORESET) pour détecter le canal PDCCH qui véhicule les informations (dont les informations de contrôle DCI) qui lui sont destinées. En d’autres mots, le champ monitoringSlotPeriodicityAndOffset définit la valeur de la période T PDCCH . La modification de champ avec la valeur T PDCCH-adj permet d’informer l’UE 3 de la nouvelle fréquence de surveillance à appliquer.
Il convient de noter que réduire (diminuer) la fréquence de surveillance de l’UE 3 a une incidence sur la fréquence à laquelle la gNB 2 peut envoyer des informations à l’UE 3 dans le canal de contrôle PDCCH, et en particulier des informations de contrôle DCI transportant un indicateur de BWP. En effet, la gNB 2 doit tenir compte de cette réduction lorsqu’elle envoie des informations DCI sur le canal de contrôle PDCCH à l’UE 3, pour que l’UE 3 puisse être en mesure de détecter et de décoder ces informations. En fonction de l’ajustement réalisé par le module 2C, l’UE 3 ne sera en mesure de détecter et de décoder ces informations que de façon plus espacée dans le temps par rapport à sa configuration initiale (si une réduction de la fréquence de surveillance a été opérée) ou à l’inverse de façon plus rapprochée dans le temps (si une augmentation de la fréquence de surveillance a été opérée). Ainsi, suite à l’étape E60 de reconfiguration RRC de l’UE 3 avec la fréquence de surveillance ajustée, la gNB 2 est configurée pour envoyer des informations DCI dans le canal PDCCH en fonction de cette fréquence de surveillance ajustée (étape E70).
Il en résulte avantageusement que si un changement de BWP est requis (par exemple pour la transmission des paquets de données des flux DF1 et DF2) et que la fréquence de surveillance a été augmentée, la gNB 2 peut informer plus rapidement l’UE 3 de la nouvelle BWP à activer par l’UE 3, via l’envoi d’informations de contrôle DCI au format 0_1 sur le canal de contrôle PDCCH. Les informations DCI contiennent également les ressources allouées à l’UE 3 par le module 2B d’ordonnancement pour la transmission du trafic sortant de l’UE 3. Tout autre changement de BWP ultérieur (par exemple pour la transmission des paquets de données du flux DF3) est signalé de façon identique à l’UE 3 (dans l’exemple envisagé, avec les ressources allouées à l’UE 3 sur cette nouvelle BWP pour la transmission des paquets de données du flux DF3).
Les étapes E10 à E70 du procédé de contrôle qui viennent d’être décrites sont réitérées par la gNB 2 plusieurs fois (étape E80), périodiquement dans le mode de réalisation décrit ici, par exemple à chaque nouvelle trame (i.e. toutes les 10ms ici) et ce, tant que l’UE 3 est connecté à la gNB 2. Bien entendu, une période différente peut être envisagée. En outre, dans un autre mode de réalisation, les étapes E10 à E60 peuvent être déclenchées sur détection d’un événement particulier, par exemple la connexion de l’UE 3 à une nouvelle slice ou un nouveau service, ou tout autre événement susceptible de modifier les caractéristiques de la matrice des flux FMAT(3) de l’UE 3.
La décrit les étapes du procédé de communication mises en œuvre par l’UE 3 dans un mode particulier de réalisation, lorsque la fréquence de surveillance du canal de contrôle PDCCH de l’UE 3 a été adaptée par la gNB 2 (étapes E54 et E57 de la ). Il convient de noter que dans le cas où la fréquence de surveillance n’a pas été adaptée, l’UE 3 fonctionne de façon conventionnelle, comme décrit dans l’état de la technique et prévu par le standard 3GPP.
Toutefois, comme mentionné précédemment, on peut envisager de choisir des BWP différentes pour transmettre les flux QoS se rapportant à un même service si cela est pertinent au regard des profils QoS associés à ces flux QoS.
Il convient de noter que lors du choix de la BWP et de la numérologie adaptée à chaque service auquel est connecté l’UE 3 (respectivement à chaque flux QoS se rapportant à un service auquel l’UE 3 est connecté), le module 2B d’ordonnancement peut être configuré pour examiner en premier lieu si la BWP active courante au niveau de l’UE 3, et la numérologie associée à cette BWP active courante, peuvent être utilisées pour transmettre les flux QoS associés à ce service (respectivement ce flux QoS), autrement dit examiner si elles respectent le SLA du service (respectivement le profil QoS associé au flux QoS). Le cas échéant, cette BWP et la numérologie µ associée peuvent être privilégiées pour le service (respectivement pour le flux QoS) en question afin d’éviter un changement de partie de bande.
Par ailleurs, le module 2B d’ordonnancement affecte pour chaque flux QoS de la matrice de flux FMAT(3) correspondant à un trafic non nul : un ensemble de PRB pour la transmission des paquets de données des flux de données de service liés à ce flux QoS sur la BWP affectée au service auquel se rapporte ce flux QoS ; et des instants de transmission (TTI) de ces PRB.
A titre illustratif, on suppose que l’ordonnancement effectué par le module 2B résulte en l’allocation des ressources suivantes : les nb1 paquets de données du flux QoS DF1 sont répartis sur les TTI T0(1), T1(1),…, TX(1) sur BWP1(µ1), puis les nb2 paquets de données du flux QoS DF2 sont répartis sur les TTI T0(2), T1(2),…, TX(2) sur BWP1(µ1), puis les nb3 paquets de données du flux DF3 sont répartis sur les TTI T0(3), T1(3),…, TX(3) sur BWP2(µ2). Les ressources ainsi allouées par le module 2B sont reportées ici dans la matrice des flux sortants FMAT(3). Cette matrice de flux sortants FMAT(3) représente donc l’activité UL à venir de l’UE 3 sur la période de temps considérée (une trame ici). Il convient de noter qu’en cas d’absence de trafic UL sur cette période de temps pour l’UE 3, la matrice de flux sortants FMAT(3) peut être nulle.
On suppose par ailleurs qu’avant d’envoyer le flux DF1, la BWP active courante utilisée pour les transmissions en UL de l’UE 3 est la BWP UL définie par défaut notée BWP0(µ0=0).
Le module 2C d’ajustement de la gNB 2 examine ensuite si un ou des changements de BWP sont requis au regard de l’ordonnancement réalisé par le module 2B d’ordonnancement pour transmettre le trafic sortant de l’UE 3 (étape test E30).
Dans le mode de réalisation décrit ici, si le module 2C détermine qu’aucun changement de BWP n’est requis (réponse non à l’étape test E30), alors la gNB 2, via son module 2E d’envoi, informe l’UE 3 des ressources qui lui sont allouées pour l’émission de son trafic sortant (étape E40). A cet effet, le module 2E d’envoi envoie des informations de contrôle DCI destinées à l’UE 3 (par exemple selon le format 0_1 ou 0_0 décrit dans le document 3GPP TS 38.212 cité précédemment) et identifiant ces ressources dans le canal PDCCH. Cet envoi est calé sur la période T PDCCH courante avec laquelle l’UE 3 surveille de façon périodique le canal PDCCH pour que l’UE 3 soit en mesure de détecter et de décoder ces informations DCI.
Dans l’exemple illustratif envisagé ici, il résulte de l’étape test E30 : qu’un changement de BWP est requis, de la BWP0(µ0) courante vers BWP1(µ1), pour transmettre les paquets de données du flux DF1 ; qu’aucun changement de BWP n’est requis depuis la BWP1(µ1) pour transmettre les paquets de données du flux DF2 ; et qu’un changement de BWP est de nouveau requis, de la BWP1(µ1) vers BWP2(µ2), pour transmettre les paquets de données du flux DF3.
Autrement dit, lors de l’étape test E30, le module 2C d’ajustement détecte que deux changements de BWP sont requis (réponse oui à l’étape test E30).
Conformément au standard 3GPP, chaque changement de BWP est notifié par la gNB 2 au niveau de l’UE 3 en envoyant des informations de contrôle DCI selon le format 0_1 (pour les transmissions UL) à l’UE 3 sur le canal de contrôle PDCCH. Ces informations de contrôle DCI comprennent l’indicateur de BWP désignant la nouvelle partie de bande à activer par l’UE 3 et la numérologie associée pour la transmission des données, en remplacement de la partie de bande active et de la numérologie courantes.
Conformément à l’invention, avant d’envoyer les indicateurs de BWP, le module 2C d’ajustement examine si un ajustement de la fréquence de surveillance du canal PDCCH par l’UE 3 est pertinent et le cas échéant, évalue l’ampleur (i.e. dimensionne) de cet ajustement (étape E50). On note qu’un tel examen peut être mené y compris lorsqu’aucun changement de BWP n’est requis auprès de l’UE 3 et donc qu’aucun indicateur de BWP n’est envoyé par la gNB 2 pour la trame sur laquelle le trafic sortant associé à l’UE 3 a été considéré.
Dans le mode de réalisation décrit ici, lors de l’étape E50, le module 2C d’ajustement examine plusieurs conditions liées d’une part, aux caractéristiques des flux sortants associés à l’UE 3 à transmettre, mais également ici à un ou plusieurs indicateurs de performance de l’UE 3 et/ou du réseau NW.
Plus précisément, le module 2C d’ajustement détermine d’abord si au moins deux parties de bande distinctes sont affectées à l’UE 3 pour la transmission des flux QoS sortants identifiés (et correspondant à un trafic non nul) dans la matrice des flux sortants FMAT(3) (et donc pour les flux de données de service liés à ces flux QoS) et si au moins un service auquel l’UE 3 est connecté et/ou au moins un flux QoS sortant de la matrice FMAT(3) (et donc incidemment au moins un flux de données de service liés à ce flux QoS) est identifié comme prioritaire ou associé à une latence maximale inférieure à un seuil donné (étape E51). Ce seuil est choisi de sorte à refléter une exigence forte en matière de latence ; il est pris par exemple ici égal à 1ms.
Si cette condition n’est pas vérifiée (réponse non à l’étape E51), par exemple tous les services auxquels l’UE 3 est connecté sont identifiés comme non prioritaires ou tolèrent une latence maximale supérieure à un seuil donné (latence considérée comme peu élevée) ou tous les flux QoS identifiés dans la matrice de flux sortants FMAT(3) (et donc incidemment tous les flux de données de service liés à ces flux QoS) sont identifiés comme non prioritaires par la gNB 2 (ou comme non exigeants en termes de latence), ou encore une même BWP est affectée à tous les services auxquels l’UE 3 est connecté et à tous les flux sortants de la matrice de flux FMAT(3) (et donc incidemment à tous les flux de données de service liés à ces flux QoS), le module 2C d’ajustement examine si la fréquence de surveillance courante du canal PDCCH par l’UE 3 peut être réduite afin de diminuer la puissance consommée par l’UE 3. Une telle réduction se traduit par une diminution des traitements de surveillance et de décodage du canal PDCCH implémentés par l’UE 3, et donc de la puissance consommée par ce dernier.
A cet effet, le module 2C d’ajustement détermine si la latence de bout-en-bout du réseau pour chaque service auxquels l’UE 3 est connecté (S1 et S2 dans l’exemple envisagé ici) atteint ou dépasse une valeur limite Llim définie pour ce service, qui correspond à la latence maximale tolérée par ce service (étape test E52). Cette valeur limite est extraite par la gNB 2 pour chaque service de son SLA. La latence de bout-en-bout du réseau pour chaque service auxquels l’UE 3 est connecté peut être mesurée par l’UE 3 et fournie par ce dernier à la gNB 2 ou en variante être estimée par la gNB 2.
Si la valeur limite Llim est atteinte ou dépassée pour l’un des services (réponse oui à l’étape test E52), la fréquence de surveillance courante est maintenue en l’état (i.e. pas d’ajustement) (étape E53). En effet, une réduction de la fréquence de surveillance permettrait certes de réduire la puissance consommée par l’UE 3 mais elle aurait pour conséquence d’augmenter la latence de bout-en-bout du réseau pour ce service, ce qui serait préjudiciable à la qualité du service.
La requête d’authentification A_REQ1 est reçue par le premier microservice 20 à l’étape E8.
Le premier microservice 20 (configuré ici comme client comme déjà indiqué) émet alors à l’étape E10 une requête REQ à destination du second microservice 22 (configuré ici comme serveur comme déjà indiqué).
Cette requête REQ inclut l’identifiant ID précité, le nom SN précité et le localisateur uniforme de ressource (ou URL) UU désignant la fonction UDM (implémentée ici par le module de gestion de données d’abonné 16).
Le premier microservice 20 peut en effet obtenir ce localisateur uniforme de ressource UU par consultation du module d’enregistrement 18.
Le second microservice 22 reçoit la requête REQ à l’étape E12.
En utilisant le localisateur uniforme de ressource UU désignant la fonction UDM contenu dans la requête REQ, le second microservice 22 émet à l’étape E14 une requête d’obtention GET_REQ à destination du module de gestion de données d’abonné 16.
La requête d’obtention GET_REQ est accompagnée de l’identifiant ID susmentionné et du nom SN susmentionné.
Les données échangées entre le second microservice 22 et le module de gestion de données d’abonné 16 sont par exemple transmises à travers un canal de communication sécurisé 30 établi entre le second microservice 22 et le module de gestion de données d’abonné 16. Un tel canal de communication sécurisé 30 est par exemple réalisé au moyen d’une session TLS, d’un tunnel IPsec ou d’un tunnel SSH.
Le module de gestion d’abonné 16 reçoit la requête d’obtention GET_REQ avec l’identifiant ID et le nom SN à l’étape E16.
Lorsque l’identifiant ID est un identifiant masqué de l’abonné, le module de gestion d’abonné 16 déchiffre l’identifiant ID pour obtenir l’identifiant permanent de l’abonné.
Le module de gestion d’abonné 16 génère alors un vecteur d’authentification AV comprenant un nombre aléatoire RAND, un jeton d’authentification AUTN, un résultat attendu XRES et une clé cryptographique K AUSF .
Pour ce faire, on prévoit par exemple que le module de gestion d’abonné 16 récupère (dans une mémoire du module de gestion d’abonné 16 ou au sein du dépôt de données utilisateur) la clé secrète K associée à l’abonné identifié par l’identifiant permanent de l’abonné, obtienne le nombre aléatoire RAND par tirage aléatoire, et détermine le résultat attendu XRES par application au nombre aléatoire RAND d’un algorithme cryptographique utilisant la clé secrète K.
Le module de gestion d’abonné 16 transmet alors à l’étape E20 le vecteur d’authentification AV au second microservice 22 dans un message GET_RSP de réponse à la requête d’obtention GET_REQ. S’agissant d’un message de réponse à une requête préalable (requête d’obtention GET_REQ), son émission par le module de gestion d’abonné 16 ne nécessite pas de retrouver par ailleurs (par exemple auprès du module d’enregistrement 18) l’adresse ou le localisateur uniforme de ressource du second microservice 22. On remarque à cet égard que le second microservice 22 n’est pas répertorié au sein de du module d’enregistrement 18, ce qui limite les risques d’attaque contre le second microservice 22.
Le message GET_RSP peut éventuellement comprendre en outre un indicateur de la méthode d’authentification utilisée (en particulier pour la détermination du résultat attendu XRES en fonction du nombre aléatoire RAND).
Le second microservice 22 reçoit à l’étape E22 le message GET_RSP contenant le vecteur d’authentification AV (et éventuellement l’indicateur de la méthode d’authentification utilisée).
Le second microservice 22 mémorise alors à l’étape E24 le résultat attendu XRES contenu dans le vecteur d’authentification AV. Le résultat attendu XRES peut ainsi être mémorisé par exemple dans une mémoire du système d’authentification 14 ou dans une enclave sécurisée comprise dans le système d’authentification 14. Une telle enclave sécurisée peut être par exemple du type Intel SGX, ou ARM TrustZone, ou encore AMD SEV.
Avantageusement, l’ouverture débouchant 6 est aménagée aux abords de la première extrémité 20.
Au moins une autre ouverture débouchant 6 peut être ménagée dans la paroi extérieure 7 du corps creux 4. Cette autre ouverture 6 est débouchant radialement et elle est aménagée aux abords de la première extrémité 20.
D’autres ouvertures débouchant es 6 peuvent être aménagées aux abords de la seconde extrémité 21.
Dans le mode de réalisation de l’invention illustré sur la , deux ouvertures débouchant es 6 sont aménagées dans la paroi extérieure 7 du corps creux 4 aux abords de la première extrémité 20 et deux autres ouvertures débouchant es 6 sont aménagées dans la paroi extérieure 7 du corps creux 4 aux abords de la seconde extrémité 21.
Dans l’arbre de rotor 2 selon l’invention, une pluralité d’ouvertures débouchant es 6, en particulier plus de deux, par exemple trois ou quatre, peuvent être aménagées dans la paroi extérieure 7 du corps creux 4 aux abords de la première extrémité 20 et il en va de même aux abords de la seconde extrémité 21.
Un nombre différent d’ouvertures débouchant es 6 peut être aménagé dans la paroi extérieure 7 du corps creux 4 aux abords de la première extrémité 20 par rapport au nombre d’ouvertures débouchant es 6 ménagées dans la paroi extérieure 7 du corps creux 4 aux abords de la seconde extrémité 21.
L’arbre 2 comporte au moins une pale 8. La pale 8 s’étend dans la chambre 5, depuis la surface intérieure 9 de la paroi extérieure 7, vers l’intérieure de la chambre 5.
La pale 8 est configurée pour créer, lorsque le rotor 1 est en rotation, un flux de fluide orienté des orifices d’injection 22 vers l’intérieur de la chambre 5.