INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Selon un mode de réalisation, l'étape (a) est précédée par une étape (c) dans laquelle le module de communication en champ proche détecte que les premières données comprennent des données sensibles.
Selon un deuxième mode de réalisation, un mode de réalisation prévoit un procédé de réalisation d'une transaction NFC entre un terminal mobile et un module distant, ledit terminal comprenant un processeur hébergeant une application établissant la transaction NFC, un module de communication en champ proche, et un élément sécurisé distinct du processeur, le procédé comprenant au moins les étapes successives suivantes : (a) ledit module de communication en champ proche envoie, à ladite première application, des premières données envoyées par le module distant et chiffrées par ledit élément sécurisé ; et (b) ladite première application demande audit élément sécurisé de déchiffrer lesdites premières données.
Un autre mode de réalisation prévoit un terminal mobile adapté à mettre en oeuvre une transaction NFC avec un module distant, ledit terminal comprenant un processeur hébergeant une application établissant la transaction NFC, un module de communication en champ proche, et un élément sécurisé distinct du processeur, le procédé de réalisation de la transaction NFC comprenant au moins les étapes successives suivantes : (a) ledit module de communication en champ proche envoie, à ladite première application, des premières données envoyées par le module distant et chiffrées par ledit élément sécurisé ; et (b) ladite première application demande audit élément sécurisé de déchiffrer lesdites premières données.
Selon un mode de réalisation, l'application est autorisée à mettre en oeuvre une transaction NFC par des logiciels d'interface, les logiciels d'interface étant des logiciels hébergés par le processeur et exécutant des commandes envoyées par ladite application.
Selon un mode de réalisation, l'application est une application système.
Selon un mode de réalisation, l'application est une application fiable ayant reçu une autorisation permanente à mettre en oeuvre une transaction NFC.
Selon un mode de réalisation, l'application a reçu une autorisation temporaire pour mettre en oeuvre une transaction NFC.
A une étape 410 (Transaction continue), successive à l'étape 408, l'application 2014 peut continuer à envoyer des commandes et à recevoir des réponses de la part du module distant 203 en utilisant le même mécanisme décrit précédemment, c'est-à-dire en faisant chiffrer chaque réponse reçue de la part du module distant 203 par l'élément sécurisé 2012. Selon une variante, un seul chiffrement peut être réalisée pour la ou les premières réponses reçues du module distant 203 pour accélérer la transaction.
A l'étape 409, l'application 2014 a été reconnue comme non autorisée. L'application 2014 ne peut donc pas faire déchiffrer la réponse e(ans2). En étant reconnue comme non autorisée l'application 2014 n'aura pas accès aux données sensibles de la transaction NFC.
A une étape 411 (Transaction stop), successive à l'étape 409, l'application 2014 n'ayant pas accès aux données sensibles et/ou secrètes, l'application 2014 ne peut pas mener la transaction NFC, et la transaction NFC s'arrête d'elle-même.
Un autre avantage de ce mode de réalisation est que la gestion de la clé de déchiffrement est l'unique responsabilité de l'élément sécurisé 2012. L'élément sécurisé peut ainsi choisir de la clé de déchiffrement à utiliser, n'utiliser que la même clé, ou bien la changer aussi souvent qu'il le souhaite.
On notera que lorsque l’émetteur-récepteur secondaire 21 est un émetteur-récepteur BLE, La diffusion se fait via une communication BLE. Le fait de faire une diffusion via une communication BLE permet de peu consommer en termes de consommation électrique. On notera que la portée d’émission-réception BLE correspond à une distance d0 comprise entre 10 et 50 mètres.
Comme le Smartphone 3 est en écoute permanente, il reçoit toujours les trames de diffusion Adv, quelque soit leur fréquence de diffusion f1.
On notera que si le Smartphone 3 se trouve hors de la portée d’émission-réception p0 du véhicule automobile 2, à savoir à une distance d1 supérieure à d0, bien entendu, il ne reçoit aucune trame de diffusion Adv émise par l’émetteur-récepteur secondaire 21 du véhicule automobile 2.
Les trames de diffusion Adv étant émises par le véhicule automobile 2, elles comprennent le code d’identification unique Id.2 associé au véhicule automobile 2.
On notera que de manière classique tous les Smarphones possèdent un émetteur-récepteur BLE. On utilise donc un émetteur-récepteur BLE, ici l’émetteur-récepteur quaternaire 31 pour établir une connexion BLE avec le véhicule automobile 2, ici avec l’émetteur-récepteur secondaire 21 dudit véhicule automobile 2.
Sur réception d’une trame de diffusion Adv par le Smartphone 3, une connexion BLE dans le mode de réalisation non limitatif pris est ainsi établie entre le Smartphone 3 et le véhicule automobile 2 pour l’échange d’informations pour l’authentification du Smartphone 3 notamment. En particulier, l’émetteur-récepteur BLE 31 du Smartphone 3 et l’émetteur-récepteur BLE 21 du véhicule automobile 2 sont configurés pour établir une connexion BLE entre eux (fonctions illustrées f26(31, 21, BLE) et f27(21, 31, BLE)).
Lorsque la connexion BLE est établie, l’unité de contrôle électronique 22 du véhicule automobile 2 est configurée pour authentifier le Smartphone 3 à partir du code d’identification unique Id.2. Une telle authentification étant connue de l’homme du métier, elle n’est pas décrite ici. L’authentification s’effectue ainsi via un échange de trames de communication BLE, autrement appelées trames BLE et référencée Fy sur la .
On notera que la connexion BLE permet par ailleurs de donner un rendez-vous entre l’émetteur-récepteur UWB 30 du Smartphone 3 et l’émetteur-récepteur UWB 20 du véhicule automobile 2 pour établir une connexion UWB pour localiser le Smartphone 3. Ainsi, lors de la connexion BLE, dans certaines trames BLE échangées est encapsulé un instant trdv de rendez-vous. Ce rendez-vous permet aux deux émetteurs-récepteurs UWB de savoir quand ils doivent communiquer en UWB. L’instant de rendez-vous trdv est envoyé soit par le Smartphone 3, soit par le véhicule automobile 2.
Le Smartphone 3, après avoir été authentifié, peut établir une connexion UWB avec le véhicule automobile 2 et ainsi communiquer via une communication UWB avec le véhicule automobile 2 pour échanger des informations relatives à la localisation. Plus particulièrement, l’émetteur-récepteur tertiaire UWB 30 du Smartphone 3 et l’émetteur-récepteur primaire 20 du véhicule automobile 2 sont configurés pour établir une connexion UWB entre eux (fonctions illustrées f28(30, 20, UWB) et f29(20, 30, UWB)). Ainsi, ils peuvent échanger via une communication UWB des trames de localisation Fx pour mesurer une distance d entre ledit Smartphone 3 et ledit véhicule automobile 2. On notera que l’échange de trames de localisation Fx et de mesure de distance d entre un identifiant et un véhicule automobile étant connu de l’homme du métier, ils ne sont pas décrits ici.
On notera que si l’identifiant 3 est une clef, il n’est pas possible qu’elle soit en scrutation permanente comme dans le cas du Smarphone 3 car la consommation électrique est dans ce cas trop importante pour la pile bouton 33 qui l’alimente. Cette dernière se déchargerait en 1 journée.
Aussi, le deuxième mode de réalisation non limitatif illustré à la est proposé.
le deuxième mode de réalisation non limitatif est décrit ci-après.
Dans ce deuxième mode de réalisation non limitatif, l’identifiant 3 est donc une clef. Il est ainsi autrement appelé clef 3. La clef 3 est configurée pour être alimentée par une pile bouton 33.
Dans ce deuxième mode de réalisation non limitatif, on fait l’inverse de ce qui a été fait dans le premier mode de réalisation non limitatif, à savoir c’est la clef 3 qui va faire la diffusion des trames de diffusion Adv, tandis que le véhicule automobile 2 va lui scruter et recevoir ces trames de diffusion Adv. Ainsi, dans ce cas, l’échange des trames de diffusion s’effectue de l’identifiant 3 vers le véhicule automobile 2.
Ainsi, dans ce cas, ledit émetteur-récepteur quaternaire 31 dudit identifiant 3 est configuré pour diffuser des trames de diffusion Adv (fonction f23(31, Adv(Id)), tandis que ledit émetteur-récepteur secondaire 21 dudit véhicule 2 est configuré scruter (fonction f24(21, m2, Adv(Id)) et recevoir (fonction f25(21, m2, 31, Adv(Id)) lesdites trames de diffusion Adv. Il est dans ce cas dans un mode de scrutation m2. La scrutation correspond à un mode actif par opposition à un mode veille. Ainsi, l’échange des trames de diffusion Adv se fait de la clef 3 vers le véhicule automobile 2.
Dans un premier mode de réalisation non limitatif illustré sur la , la scrutation est périodique. Dans un mode de réalisation non limitatif, la scrutation comprend une période de scrutation p1. Dans un mode de réalisation non limitatif, la scrutation possède une fenêtre d’écoute w1 qui est de 20% du temps de la période de scrutation p1 contre 80% du temps de la période de scrutation p1 pour la non-scrutation où l’émetteur-récepteur secondaire 21 est en mode veille ce qui permet de réduire sa consommation électrique.
A une étape 613 (Transaction stop), successive à l'étape 611, l'application 2014 n'ayant pas accès aux données sensibles et/ou secrètes, l'application 2014 ne peut pas mener la transaction NFC, et la transaction NFC s'arrête d'elle-même.
Le mode de mise en oeuvre de la est similaire à la mise en oeuvre décrite en relation avec la . La différence entre ces deux mises en oeuvre est que dans celle de la , ce n'est pas la couche d'interface primaire 2017 qui vérifie si l'application est autorisée à mettre en oeuvre la transaction NFC mais la couche de commande 2019 des circuits et composants du terminal 201 qui effectue cette vérification. Dans ce cas, le procédé est donc le suivant.
A une étape initiale 701 (App -> DRIVERS Req Trans), l'application 2014 du terminal 201 décide de mettre en oeuvre une transaction NFC avec le module distant 203. Pour cela, l'application 2014 envoie une requête à la couche de commande 2019. Cette requête peut être, par exemple, une requête d'authentification auprès de l'élément sécurisé 2012. Cette requête peut, par exemple, comprendre des informations sur le type de transaction NFC autorisé à être mis en oeuvre par l'application.
A une étape 702 (NFC -> CARD cmd5), successive à l'étape 701, la couche de commande 2019 envoie la requête à l'élément sécurisé 2012. Si l'application 2014 est autorisée (sortie Y) l'étape suivante est une étape 703 (SE -> DRIVERS evt5), sinon (sortie N) l'étape suivante est une étape 704 (App error). Selon une variante de réalisation, la vérification de l'autorisation de l'application 2014 n'est pas réalisé à l'étape 702, et l'étape suivante est directement l'étape 703.
la communication dite « V2V » pour Véhicule-à-Véhicule (ou « Vehicle-to-Vehicle » en anglais) : les véhicules qui prennent en charge ce type de communication peuvent échanger des messages (par exemple sur leur emplacement, leur vitesse, leur état, etc.). Cet échange de messages a lieu directement entre les véhicules ou via une infrastructure du réseau de téléphonie mobile (par exemple une station de base, au sein d’une cellule). La communication V2V permet a un véhicule d’alerter d’autres véhicules d’un danger, d’un problème ou simplement d’échanger des informations (vitesse, emplacement, sens de direction, freinage ou perte de stabilité etc.) afin que la circulation soit la plus fluide possible. Les véhicules peuvent alors agir et prendre des mesures afin d’éviter un problème lors d’un changement soudain de trajectoire ou d’un freinage d’urgence par exemple ; la communication dite « V2I » pour Véhicule-à-Infrastructure (ou « Vehicle-to-Infrastructure » en anglais) : les véhicules qui prennent en charge ce type de communication peuvent échanger des messages avec les infrastructures routières qui les entourent. Ces infrastructures peuvent être des feux de signalisation, des marqueurs de voie, des lampadaires, des parcmètres, des caméras de surveillance… La communication V2I permet ainsi de récolter et d’échanger des données avec des infrastructures routières afin de fournir aux voyageurs et aux véhicules des informations en temps réel sur des éléments tels que les conditions de circulation, la fluidité du trafic, les accidents, les zones de travaux et les disponibilités de places dans les parkings. Il est alors possible d’anticiper certaines situations et d’agir en conséquence ; la communication dite « V2N » pour Véhicule-à-Réseau (en anglais, « Vehicle-to-Network ») permet, via les infrastructures du réseau mobile, d’échanger des données et établir des communications entre les véhicules et un serveur de gestion des applications V2X par exemple. Les véhicules peuvent recevoir des alertes diffusées concernant des accidents plus loin sur la route ou des avertissements de congestion ou de files d'attente sur l'itinéraire prévu par exemple ; la communication dite « V2P » pour Véhicule-à-Piéton (en anglais « Vehicle-to-Pedestrian ») implique des communications entre un véhicule et un piéton ou plusieurs piétons à proximité immédiate. En outre, la communication peut s'adresser à d'autres usagers de la route vulnérables, tels que les cyclistes. Le V2P est réalisé directement ou par l'intermédiaire de l'infrastructure du réseau mobile. Différents types de support aident à la communication V2P : téléphone intelligent, canne pour malvoyant, éclairages, navigateur vélo etc. Ce type de communication permet d'avertir le piéton de l'approche d'un véhicule, d'avertir le véhicule de la présence d'usagers vulnérables, grâce à leur localisation, et ainsi de garantir leur protection. Elle permet donc d’alerter le piéton et les conducteurs de véhicules connectés des potentiels dangers dans la rue.
Ainsi, la communication V2X permet d’assurer et améliorer la sécurité routière, de réduire la consommation de carburant ou encore d’améliorer l’expérience entre les conducteurs et les autres usagers de la route, tels que les cyclistes et les piétons. En particulier, la communication V2X peut être utilisée de différentes manières, par exemple pour la conduite coopérative, l’avertissement de bouchons, l’évitement des collisions, l’avertissement de dangers, la conduite autonome, l’assistance à la conduite, l’info-divertissement…
Les exigences de qualité de service liées à chacune de ces utilisations peuvent être très différentes et avoir un impact important sur les normes de télécommunication à utiliser pour fournir le service adéquat. En effet, la conduite sûre et efficace, notamment des véhicules automatisés, peut être affectée par des changements soudains de la qualité de service fournie.
Les solutions actuelles proposées pour faire face à des changements de QoS, ne peuvent être appliquées à la communication V2X. En effet, ces solutions sont principalement basées sur des modifications manuelles de la configuration des équipements utilisateurs basées sur l’observation dans le temps des variations de QoS (par exemple : augmentation manuelle de la capacité de certaines stations de base pendant des périodes où l’on sait que la densité de population va augmenter). Ces solutions ne sont pas suffisamment dynamiques. En particulier, elles ne permettent pas de laisser suffisamment de temps à l'application V2X embarquée dans les équipements utilisateurs (par exemple véhicules connectés, téléphones intelligents etc.) pour s'adapter en douceur et en toute sécurité aux variations de QoS.
Il existe donc un besoin d’améliorer les techniques d’adaptation à un changement de QoS dans un contexte de réseau de communication de type V2X afin d’assurer la sécurité des utilisateurs ou améliorer leur expérience. En particulier, il est primordial dans le cadre de la communication V2X de permettre à l’application V2X des équipements utilisateurs d’être informée en amont d’une variation de QoS et de réagir avec suffisamment de temps à cette dernière en toute sécurité pour l’utilisateur.
L’invention répond à ce besoin en proposant un procédé de prédiction d’une variation d’une qualité de service dans un réseau de communication V2X comprenant au moins une station de base, à laquelle est connecté au moins un équipement utilisateur. Le procédé comprend : - une identification d’au moins un indicateur clé de performance (KPI) représentatif de la qualité de service pour ledit au moins un équipement utilisateur, appelé indicateur clé de performance d’intérêt, - une prédiction par apprentissage profond à partir de valeurs passées d’au moins un indicateur clé de performance secondaire, collectées pour ladite au moins une station de base, d’une valeur future dudit au moins un indicateur clé de performance d’intérêt, - une émission, le cas échéant, d’une notification d’information de la variation de qualité de service à destination dudit au moins un équipement utilisateur, en fonction de la valeur prédite.
Ainsi, l’invention repose sur une approche tout à fait nouvelle et inventive de la prédiction de variation de QoS dans un réseau de communication de type V2X. Plus particulièrement, afin de satisfaire aux conditions de sécurité et de qualité d’expérience utilisateur d’un réseau basé sur la communication de type V2X, le procédé selon l’invention met en œuvre une prédiction d’une variation de qualité de service (QoS). Cette prédiction de QoS permet notamment d’anticiper les variations de QoS et d’avertir, via l’envoi d’une notification d’information, l’équipement utilisateur de cette variation. L’équipement peut alors, sur réception de la notification, anticiper et adapter son comportement au changement à venir.
En effet, en raison des conditions variables du réseau mobile, il n’est pas toujours possible de satisfaire les exigences de qualité de service requises par les applications V2X. La prédiction de QoS est alors utile pour que les équipements utilisateurs du réseau V2X soient informés à l’avance de tout changement à venir dans la qualité de service disponible, afin de permettre aux applications V2X de prendre les mesures appropriées. Ces mesures sont par exemple l’adaptation ou l’arrêt complet des applications qui ne peuvent pas être exploitées en toute sécurité dans les conditions de qualité de service prévues (par exemple : conduite autonome).
L’étape d’apprentissage profond (en anglais « deep learning ») permet de prédire avec précision les variations de QoS.
Selon une caractéristique de l’invention, la prédiction par apprentissage profond tient également compte d’une mesure de distance dudit au moins un équipement utilisateur à ladite au moins une station de base.
De manière avantageuse, il est possible d’affiner la prédiction de variation de qualité de service au niveau de l’équipement utilisateur en prenant en compte la distance de l’équipement utilisateur au sein de la couverture réseau d’une station de base de ce réseau de communication V2X à laquelle l’équipement est connecté. En effet, il a été constaté que la qualité de service est différente en fonction de la position d’un équipement utilisateur dans la couverture réseau de la station de base.
Ainsi, il est possible de prédire une variation de QoS pour l’équipement utilisateur tout au long d’un itinéraire.
Selon une autre caractéristique de l’invention, le procédé comprend en outre une sélection, parmi un ensemble d’indicateurs clés de performance secondaires, dudit au moins un indicateur clé de performance secondaire pris en compte pour la prédiction, une valeur dudit au moins un indicateur clé de performance secondaire sélectionné influençant une valeur de l’indicateur clé de performance d’intérêt.
De manière avantageuse, la prédiction de QoS met en œuvre en particulier une étape de sélection d’un ensemble de facteurs (aussi appelés KPIs secondaires) pour au moins un indicateur clé de performance (KPI) d’intérêt à surveiller pour un cas d’usage du réseau de communication V2X (par exemple télé-opération). En effet, différents KPIs d’intérêts sont à surveiller en fonction des différents cas d’usage de communication V2X. Le ou les KPIs d’intérêts dépendent d’autres KPIs secondaires qui vont l’influencer. Cette sélection d’un ensemble pertinent de KPIs secondaires, pour un KPI d’intérêt, permet de réduire le temps de prédiction et d’en augmenter la précision. En effet, dans un environnement aussi dynamique qu’un réseau de communication V2X, cette sélection permet d’éliminer des KPIs secondaires qui biaiseraient la prédiction de QoS.
Ainsi, la combinaison de ces étapes spécifiques de prédiction de QoS permet d’obtenir une prédiction précise et donc d’avertir ensuite l’équipement utilisateur suffisamment en avance du changement de QoS.
Selon un aspect particulier de l’invention, la prédiction par apprentissage profond met en œuvre un algorithme de type LSTM.
Selon un mode de réalisation, l'élément sécurisé fournit l'autorisation temporaire concernant l'application auxdits logiciels d'interface.
Selon un mode de réalisation, si les logiciels d'interface ne comprennent pas d'autorisation concernant ladite application alors pendant l'étape les logiciels d'interface interdisent à l'application de demander la clé à l’élément sécurisé.
Selon un mode de réalisation, si l'application n'est pas autorisée à mettre en oeuvre une transaction NFC alors pendant l'étape (b) l'élément sécurisé refuse de déchiffrer les premières données et de les envoyer à ladite application.
Selon un troisième aspect, un mode de réalisation prévoit un procédé de réalisation d'une transaction NFC entre un terminal mobile et un module distant, ledit terminal comprenant un processeur hébergeant une application établissant la transaction NFC, un module de communication en champ proche, et un élément sécurisé distinct du processeur, le procédé comprenant au moins les étapes successives suivantes : (a) ledit module de communication en champ proche stocke, dans ledit élément sécurisé, des premières données envoyées par ledit module distant ; (b) ledit module de communication en champ proche envoie des deuxièmes données à ladite première application pour l'avertir que lesdites premières données ont été stockées dans ledit élément sécurisé ; et (c) ladite première application demande audit élément sécurisé de lui fournir lesdites premières données.
Un autre mode de réalisation prévoit un terminal mobile adapté à mettre en oeuvre une transaction NFC avec un module distant, le terminal comprenant un processeur hébergeant une application établissant la transaction NFC, un module de communication en champ proche, et un élément sécurisé distinct du processeur, le procédé de réalisation de la transaction NFC comprenant au moins les étapes successives suivantes : (a) ledit module de communication en champ proche stocke, dans ledit élément sécurisé, des premières données envoyées par ledit module distant ; (b) ledit module de communication en champ proche envoie des deuxièmes données à ladite première application pour l'avertir que lesdites premières données ont été stockées dans ledit élément sécurisé ; et (c) ladite première application demande audit élément sécurisé de lui fournir lesdites premières données.
Selon un mode de réalisation, l'application est une application système, ou dans lequel l'application est une application fiable ayant reçu une autorisation permanente à mettre en oeuvre une transaction NFC, ou l'application a reçu une autorisation temporaire pour mettre en oeuvre une transaction NFC, dans lequel l'élément sécurisé fournit l'autorisation temporaire concernant l'application auxdits logiciels d'interface, l'élément sécurisé ayant obtenu cette autorisation temporaire auprès d'un serveur extérieur.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter les étapes ou pour être utilisé dans l'exécution du procédé de prédiction d’une variation de qualité de service dans un réseau de communication V2X précité.