INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Typiquement, ces informations destinées à l’équipement utilisateur peuvent comprendre au moins un indicateur de BWP affectée par l’entité du réseau à l’équipement utilisateur (en vue par exemple d’optimiser la transmission du trafic associé à l’équipement utilisateur) à activer pour la transmission du trafic associé à l’équipement utilisateur (flux de données entrant(s) ou sortant(s)).
Ainsi l’invention permet de bénéficier de la fréquence de surveillance et de la fréquence d’envoi ajustées pour notifier à l’équipement utilisateur un changement de BWP. L’entité du réseau peut, grâce à l’invention, contrôler et adapter le moment où l’équipement utilisateur est notifié de la BWP qu’il doit activer en fonction de l’urgence et des contraintes du trafic associé à cet équipement utilisateur.
Par exemple, dans un mode particulier de réalisation, l’étape d’ajustement comprend une augmentation de la fréquence de surveillance lorsqu’au moins deux parties de bande distinctes sont affectées audit équipement utilisateur pour une transmission dudit au moins un flux de données et lorsqu’au moins un dit service et/ou au moins un dit flux de données est identifié comme prioritaire ou associé à une latence maximale inférieure à un seuil donné.
A l’inverse, dans un mode de réalisation, l’étape d’ajustement comprend une diminution de la fréquence de surveillance lorsqu’une condition est vérifiée parmi : une même partie de bande est affectée audit équipement utilisateur pour une transmission dudit au moins un flux de données ; ledit au moins un service comprend uniquement un ou des services identifiés comme non prioritaires ou associés à une latence maximale supérieure à un seuil donné ; ledit au moins un flux comprend uniquement un ou des flux identifiés comme non prioritaires ou associés à une latence maximale supérieure à un seuil donné.
Typiquement, un service, respectivement un flux de données, identifié comme prioritaire est un service, respectivement un flux de données, qui a souvent de fortes exigences en termes de latence (par exemple supportant une latence maximale inférieure à 1ms), comme par exemple un service uRLLC ou V2X, ou un flux QoS de type Delay Critical GBR (pour « Guaranteed Bit Rate » en anglais).
En effet, lorsque tout ou partie du trafic associé à un équipement utilisateur est relatif à un service identifié comme prioritaire ou tolérant une faible latence, il est souhaitable que le basculement vers une BWP adaptée à ce type de service (ex. associée à une numérologie élevée) puisse se faire dans les meilleurs délais afin de réduire la latence et de limiter les risques d’interruption de ce service. Ce constat est également valable pour un flux de données prioritaire ou tolérant une faible latence, y compris lorsque celui-ci se rapporte à un service non prioritaire. A cet effet, l’entité du réseau peut alors avantageusement, lors de l’étape d’ajustement, augmenter la fréquence de surveillance du canal de contrôle pour que l’équipement utilisateur puisse être informé dès que possible de la BWP qui lui est affectée pour ce service ou ce flux prioritaire et l’activer sans délai indu.
A l’inverse, si le trafic associé à l’équipement utilisateur ne concerne pas de service ou de flux prioritaire ou ayant des exigences élevées en termes de latence (par exemple un service eMBB), ou encore s’il ne requiert pas de changement de BWP, l’entité du réseau peut, lors de l’étape d’ajustement, diminuer la fréquence de surveillance afin de limiter la puissance consommée par l’équipement utilisateur et préserver les ressources du réseau.
L’invention permet donc une gestion optimisée et efficace de la fonctionnalité BWP, notamment dans un contexte où un changement de BWP est envisagé. Elle a une application privilégiée mais non limitative lorsque l’équipement utilisateur est connecté à plusieurs services ayant des contraintes hétérogènes ou des priorités différentes, car elle offre la possibilité à l’opérateur du réseau d’activer sans latence une BWP adaptée à chaque service en vue d’optimiser la transmission du trafic associé à l’équipement utilisateur.
Par ailleurs, l’invention apporte un gain substantiel par rapport à l’état de la technique, selon lequel le canal de contrôle véhiculant les indicateurs de BWP est surveillé de façon périodique par l’équipement utilisateur avec une période fixe, configurée par l’opérateur du réseau au niveau de l’équipement utilisateur, via un message RRC (pour « Radio Resource Control » en anglais) envoyé par la station de base lors de l’établissement de la connexion de l’équipement utilisateur avec le réseau. Une telle période est appliquée à l’ensemble des équipements utilisateurs rattachés à la station de base, et est typiquement fixée par l’opérateur égale à plusieurs slots (ex. 5 ou 8 slots) ou TTI, ce qui pour la numérologie µ=0 représente plusieurs millisecondes. On comprend bien dès lors que si un changement de BWP est décidé par la station de base pour transmettre des flux de données associés à un équipement utilisateur relatifs à un service uRLLC, imposant une latence inférieure à une milliseconde, la station de base doit attendre l’envoi du prochain canal de contrôle comportant des informations destinées à l’équipement utilisateur pour lui transmettre cette instruction, donc potentiellement plusieurs millisecondes selon la valeur de la période configurée par l’opérateur, ce qui peut s’avérer préjudiciable pour la qualité du service uRLLC.
Au contraire dans l’invention, la fréquence de surveillance du canal de contrôle et la fréquence d’envoi des informations destinées à l’équipement utilisateur sur ce canal de contrôle (incluant le cas échéant les indicateurs de BWP) sont paramétrables et sont adaptées à chaque équipement utilisateur, en fonction de son trafic et des services auxquels il est connecté. L’invention offre la possibilité de réaliser aisément un compromis entre latence et puissance consommée par l’équipement utilisateur et de satisfaire les contraintes diverses et variées des services auxquels un utilisateur est susceptible d’accéder.
En outre, elle est relativement simple à mettre en œuvre puisqu’elle s’appuie sur la modification de la fréquence de surveillance du canal de contrôle par l’équipement utilisateur, qui peut être aisément configurée par l’opérateur du réseau, par exemple via un message RRC. Elle est également compatible avec la contrainte imposée par le standard 3GPP selon laquelle un équipement utilisateur ne peut avoir qu’une unique BWP active à un instant donné (il convient toutefois de noter que l’invention s’applique également en l’absence de cette contrainte), et permet, sous cette contrainte, d’optimiser la transmission du trafic associé à un équipement utilisateur connecté à de multiples services.
Dans un mode de réalisation, le système, en particulier un module de gestion de configuration, est conçu pour générer et stocker des bases de données et/ou des vues cibles (par exemple, des vues appelées vues SQL) pour différents utilisateurs et/ou rôles en fonction d’autorisations prédéterminées et/ou attribuées. Dans un mode de réalisation, il existe plusieurs bases de données et/ou vues cibles pour un ensemble de données initiales, les bases de données et/ou vues cibles individuelles étant différentes en ce qu’elles sont anonymisées à des degrés différents. Par exemple, une première vue peut délivrer les données initialement enregistrées par le module de gestion de configuration, tandis qu’une seconde vue ne montre qu’une partie des données initialement enregistrées, des ensembles de données ayant été supprimés et/ou des entrées ayant été anonymisées, par exemple.
L’anonymisation hors ligne est donc réalisée dans ce mode de réalisation, les données étant éventuellement dupliquées ou délivrées différemment sur la base de différentes vues. Cette approche a comme avantage de pouvoir répondre très efficacement aux requêtes. Il est également possible d’enregistrer et donc de documenter les états et donc les différents degrés d’anonymisation des tables/vues/champs individuels.
Comme expliqué précédemment, le système peut être conçu pour sélectionner une base de données cible parmi une pluralité de bases de données cibles pour les requêtes sur l’interface, laquelle base de données contient les données permettant de répondre à la requête.
Dans un mode de réalisation, le module d’authentification est conçu pour a) attribuer un rôle et/ou un utilisateur à la requête ; b) déterminer si la base de données cible est une base de données relationnelle ; et c) si la base de données cible est une base de données relationnelle, utiliser le rôle ou les informations relatives à l’utilisateur pour sélectionner une vue parmi une pluralité de vues ; d) utiliser la vue sélectionnée pour répondre à la requête.
L’utilisation de vues a comme avantage, du moins en ce qui concerne les bases de données SQL, de ne pas dupliquer les données ad libitum, tandis qu’un concept d’accès efficace peut être implémenté en même temps.
Dans un mode de réalisation, le système, en particulier le module de gestion de configuration, est conçu pour générer et stocker des copies pour différents utilisateurs et/ou rôles pour une base de données de hachage cible (distribuée), qui est utilisée comme base de données cible, en fonction d’autorisations prédéterminées et/ou attribuées. Les bases de données de hachage de copies créées de cette façon peuvent avoir différents degrés d’anonymisation, comparables aux vues ou aux tables SQL déjà expliquées.
Dans un mode de réalisation, il existe une corrélation entre les différentes autorisations et les différentes bases de données de hachage cibles. Dans un mode de réalisation, il existe des corrélations entre les différents rôles et les bases de données de hachage de copies. Il s’agit donc de copies spécifiques aux rôles.
Une base de données non basée sur SQL est appelée base de données de hachage au sens de la présente invention. Il peut s’agir d’une base de données qui stocke des paires clé-valeur. La base de données de hachage peut être une base de données distribuée telle que DynamoDB ® d’Amazon. Les bases de données de hachage correspondantes sont très performantes en termes de réponse aux requêtes. Ces performances ne sont pas affectées par la création des copies. Les performances du système peuvent encore être améliorées en répartissant habilement les copies individuelles sur différents serveurs.
Dans un mode de réalisation, le système est conçu pour sélectionner une base de données cible parmi une pluralité de bases de données cibles pour des requêtes sur l’interface, laquelle base de données contient les données permettant de répondre à la requête. Dans ce contexte, le module d’authentification peut également être conçu pour a) attribuer un rôle et/ou un utilisateur à la requête ; b) déterminer si la base de données cible est une base de données de hachage ; et c) si la base de données cible est une base de données de hachage, utiliser le rôle ou les informations relatives à l’utilisateur pour sélectionner une base de données de hachage de copies parmi une pluralité de bases de données de hachage de copies à utiliser pour répondre à la requête.
Dans un mode de réalisation (préféré), les bases de données SQL et les bases de données non SQL, en particulier les bases de données de hachage, coexistent en parallèle. Dans ce contexte, l’anonymisation des bases de données SQL s’effectue selon différentes approches. Par exemple, les bases de données SQL peuvent être anonymisées en fournissant des vues différentes et les bases de données non SQL en dupliquant des données individuelles (cf. bases de données de hachage de copies). Le système connaît au moins ces deux approches d’anonymisation et, lorsqu’il répond à une requête, détermine l’entité (vue ou copie) qui doit être utilisée avec l’autorisation donnée. Ainsi, malgré l’anonymisation nécessaire, différentes implémentations de bases de données peuvent être utilisées. En particulier, les différentes implémentations de bases de données peuvent être adaptées à la manière dont les données peuvent être stockées et interrogées le plus efficacement possible. La protection nécessaire des données peut donc être implémentée indépendamment de l’implémentation spécifique de la base de données respective. La technologie spécifique utilisée pour implémenter les bases de données respectives n’est pas transparente pour un accès externe (par l’intermédiaire des interfaces) afin de permettre un accès uniforme.
Dans un mode de réalisation, le système comprend un module de contexte de collecte de données qui est conçu pour stocker un contexte de collecte de données pour au moins une sélection d’ensembles de données sur l’au moins une base de données cible. Le contexte de collecte de données peut être, par exemple, un moment où les données ont été collectées, un objectif de la collecte de données, une période de conservation des données, une base juridique pour la collecte de données, des informations sur les politiques de conservation associées, etc. En déterminant le contexte de collecte de données, il est possible d’initier différentes formes d’anonymisation sur la base de ces données. Des politiques de conservation partiellement ou totalement automatisées peuvent également être implémentées pour des données individuelles. À cette fin, le système, en particulier le module de gestion de configuration, peut être conçu pour sélectionner des données en fonction du contexte de collecte de données et pour stocker les données sélectionnées sous une forme anonymisée.
Dans un mode de réalisation, au moins une partie des données d’au moins une base de données cible est cryptée, le système étant conçu pour recevoir un jeton de sécurité et, sur la base du jeton de sécurité, pour déterminer si l’ordinateur client émettant l’interrogation est autorisé à communiquer avec le système et/ou à recevoir les données interrogées. Une base de données de clés peut être fournie à cette fin, le système étant conçu pour utiliser la base de données de clés afin de sélectionner une clé qui est utilisée pour décrypter les données cryptées, en particulier de l’au moins une base de données cible.
Le système selon l’invention peut donc également assurer une fonction de gestion de clés, un ordinateur client/utilisateur réalisant l’interrogation étant authentifié et le système sélectionnant les clés pour un accès à des données de chiffrement individuelles dans les bases de données cibles en fonction de son propre concept d’authentification. Au moyen du pilote décrit ci-dessus et du système selon l’invention, il est donc également possible d’implémenter un système d’authentification pour des applications plus anciennes s’exécutant sur les ordinateurs clients, qui est implémenté de manière uniforme sur l’ensemble des requêtes d’accès.
L’objet mentionné au début est également atteint grâce à un procédé permettant de répondre à au moins une requête au moyen d’un ensemble de données de réponse, le procédé comprenant les étapes suivantes : a) réception d’au moins une requête par l’intermédiaire d’une interface, en particulier d’une API REST ; b) interrogation des données d’au moins une base de données cible en réponse à la requête reçue ; c) détermination si l’ordinateur client et/ou l’utilisateur a l’autorisation de réaliser l’interrogation ; et d) transmission d’au moins un ensemble de données de réponse pour répondre à la requête, au moins une partie des données de l’ensemble de données de réponse étant anonymisées si une autorisation restreinte est déterminée.
Ce procédé présente des avantages, comme cela a déjà été expliqué en rapport avec le système. Le procédé peut être mis en œuvre sur le système qui a déjà été expliqué. La description du système se traduit par des étapes de procédé implicites pour le procédé selon l’invention, qui le définissent plus en détail dans différents modes de réalisation.
L’objet mentionné au début est également atteint grâce à une mémoire lisible par ordinateur contenant des instructions pour l’implémentation du procédé mentionné ci-dessus, en particulier lorsque les instructions sont exécutées sur au moins une unité de traitement. Les avantages sont ici aussi similaires à ceux déjà décrits en rapport avec le système selon l’invention.
D’autres modes de réalisation avantageux sont obtenus à partir des revendications dépendantes.
L’invention est décrite ci-dessous au moyen de plusieurs exemples de modes de réalisation, qui sont expliqués plus en détail en référence aux illustrations. Dans les figures : la montre une représentation schématique du système selon l’invention, qui est connecté en communication à un ordinateur client par l’intermédiaire d’Internet ; la montre une illustration schématique détaillée du système selon l’invention selon la ; et la montre une représentation schématique de données différemment anonymisées.
Dans la description ci-dessous, les mêmes numéros de référence sont utilisés pour les parties identiques et agissant de la même manière.
La montre un ordinateur client 10 qui est connecté en communication à un exemple de mode de réalisation du système 100 selon l’invention par l’intermédiaire de l’Internet 1. Au niveau d’abstraction indiqué, le système 100 comprend une base de données relationnelle 30 et une base de données de hachage, par exemple une base de données DynamoDB ® d’Amazon.
Différentes applications peuvent être installées sur l’ordinateur client 10, qui communique généralement avec une base de données par l’intermédiaire d’une interface ODBC. Dans l'exemple de mode de réalisation présenté, un pilote de base de données 12 est fourni, qui permet aux applications de communiquer avec une API REST 105 (cf. ) du système 100 par l’intermédiaire d’un pilote JDBC.
Selon un aspect de l’invention, l’ordinateur client 10 communique avec le module d’accès aux données 110 par l’intermédiaire de l’API REST 105. Le module d’accès aux données représente un composant central du système 100 et organise essentiellement la réponse aux requêtes qui sont émises par l’ordinateur client 10. Dans l’exemple de mode de réalisation décrit, il existe des modules de connexion aux bases de données ou des proxys de bases de données entre l’API REST 105 et le module d’accès aux données 110. Ils peuvent être utilisés pour transférer les interrogations au module d’accès aux données 110 d’une manière spécifique à la base de données cible (cf. la base de données relationnelle 30 ou la base de données SQL ou la base de données de hachage 40). Dans l’exemple de mode de réalisation illustré, le module de gauche est un module de connexion à une base de données SQL 140 spécifique et le composant de droite est un module de connexion à une base de données pour les bases de données cibles non SQL.
La montre à titre d’exemple que les interrogations de données ne proviennent initialement pas de l’ordinateur client 10, mais des applications exécutées sur celui-ci.
Dans un mode de réalisation, l’application est une application qui habituellement communiquerait avec une base de données cible appropriée par l’intermédiaire d’une interface ODBC. Selon l’invention, comme expliqué précédemment, l’ordinateur client 10 possède un pilote de base de données 12 qui traduit une requête SQL soumise en une requête REST. Pour ce faire, le nom de table adressée est analysé à partir de la requête et les informations de champs spécifiques sont résolues. Des informations de champs non spécifiques, telles qu’un symbole de remplacement (« * »), peuvent également être traduites en noms de champs individuels, tant que la base de données cible est connue. Ainsi, les conditions typiques de SQL qui sont définies pour une requête spécifique (mot-clé : « WHERE ») peuvent également être traduites. Essentiellement, le pilote de base de données 12 génère une requête REST à partir de l’interrogation SQL et envoie cette requête REST au système 100 par l’intermédiaire de l’interface 105. L’interrogation y est traitée, entre autres, par le module d’accès aux données 110.
Le module d’accès aux données 110 sélectionne une base de données cible, dans l’exemple la base de données relationnelle 30, par exemple sur la base des données fournies par le module de connexion à une base de données 140.
Dans un mode de réalisation, le module d’accès aux données 110 détermine également dans quelle mesure les données initiales ou les données partiellement anonymisées peuvent être fournies en réponse à la requête. Par exemple, un rôle spécifique au sein du système 100 peut être attribué à l’application effectuant la requête sur l’ordinateur client 10 sur la base des informations d’identification. Ce rôle peut être associé à une vue de base de données relationnelle 30 particulière.
La montre deux vues différentes, à savoir une vue de base de données complète 31 et une vue de base de données au moins partiellement anonymisée 32. À titre d’exemple, les tables ou les vues montrées peuvent être des données de patients. Alors que dans la vue de base de données complète 31, le nom, la date de naissance exacte et le groupe sanguin sont indiqués, la vue de base de données anonymisée 32 ne contient que l’année de naissance et aucune information sur le groupe sanguin en plus du nom. Le groupe sanguin a simplement été fixé à une valeur nulle (« NULL ») pour générer la vue de base de données anonymisée 32.
Après sélection de l’une de ces vues, les données appropriées peuvent être renvoyées du module d’accès aux données 110 à l’application sur l’ordinateur client 10 par l’intermédiaire de l’API REST 105. À cet égard, il est facilement possible de fournir des données sous une forme clairement structurée et anonymisée.
L’approche montrée sur la au moyen de différentes vues a comme avantage que les ensembles de données ne doivent exister qu’une seule fois dans la base de données relationnelle 30 et que les fonctions d’anonymisation nécessaires sont exécutées en ligne lors de l’interrogation des ensembles de données.
Une approche nettement différente peut être utilisée pour les bases de données non basées sur SQL. En utilisant la base de données de hachage 40 comme exemple, il est possible de créer des copies d’une base de données de hachage initiale et d’y écraser définitivement certaines valeurs. À ce titre, en fonction du rôle attribué, pour une interrogation adressée à la base de données de hachage 40, le module d’accès aux données 110 sélectionnera la base de données de hachage associée au rôle utilisateur de l’application effectuant l’interrogation. Cette approche présente l’avantage d’obtenir des performances élevées.
Dans l’exemple de mode de réalisation décrit, les deux approches sont poursuivies en parallèle en fonction de l’implémentation technique de la base de données cible respective. Toutefois, selon l’invention, il est également concevable de n’implémenter qu’une seule de ces approches dans un système 100.
Ainsi, par exemple, comme l’illustre la table 1, une numérologie élevée (par exemple correspondant à un espacement de 120kHz entre les sous-porteuses) permet de réduire la durée d’un intervalle de transmission ou TTI, et incidemment la latence : elle est donc particulièrement bien adaptée aux services uRLLC. A l’inverse, une numérologie moins élevée permet d’atteindre un débit plus élevé et est particulièrement bien adaptée aux services eMBB.
Comme évoqué précédemment, la technologie d’accès radio 5G NR permet à un UE, via la fonctionnalité BWP, d’utiliser une bande passante plus étroite que la bande passante totale allouée par une réseau 5G à la cellule dans laquelle se trouve l’UE. Cette bande passante plus étroite correspond à une partie (désignée par BWP dans la suite) de la bande passante totale allouée par le réseau à la cellule. Compte-tenu des largeurs de bande envisagées en 5G (jusqu’à 400 MHz pour une seule porteuse), le recours à cette fonctionnalité permet avantageusement d’une part, de s’adapter à des UE disposant de capacités réduites en termes de largeur de bande supportée et/ou qu’ils peuvent surveiller, et d’autre part, de réduire la complexité des traitements réalisés par les UE (ex. surveillance et décodage des canaux de contrôle) et ainsi la puissance qu’ils consomment.