FR3100681A1 - Procédé et dispositif de communication V2X pour véhicule - Google Patents
Procédé et dispositif de communication V2X pour véhicule Download PDFInfo
- Publication number
- FR3100681A1 FR3100681A1 FR1909832A FR1909832A FR3100681A1 FR 3100681 A1 FR3100681 A1 FR 3100681A1 FR 1909832 A FR1909832 A FR 1909832A FR 1909832 A FR1909832 A FR 1909832A FR 3100681 A1 FR3100681 A1 FR 3100681A1
- Authority
- FR
- France
- Prior art keywords
- data
- segment
- header
- frame
- vehicle
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/08—Upper layer protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
L’invention concerne un procédé et un dispositif de communication de données comprises dans une trame de données (2) conforme au protocole TCP obtenue par encapsulation d’une pluralité de segments de données (21 à 23) conformes au protocole « GeoNetworking ». Chaque segment de données (21) comprend un entête de segment (210), l’entête de segment comprenant une information indiquant que l’entête de segment est suivi d’un paquet de données sécurisé comprenant un entête de sécurité (211). L’entête de sécurité (211) comprend une information représentative d’une taille du paquet de données sécurisé. Figure pour l’abrégé : Figure 2
Description
L’invention concerne les procédés et dispositifs de communication entre nœuds d’un réseau ad hoc, au moins un nœud du réseau étant mobile et embarqué dans au moins un véhicule, notamment de type automobile.
Arrière-plan technologique
Les véhicules contemporains embarquent des systèmes ou fonction d’aide à la conduite qui fournissent aux conducteurs de véhicules qui en sont équipés des informations sur leur environnement et/ou une assistance active dans la conduite du véhicule. Les systèmes d’aide à la conduite les plus aboutis assurent le contrôle du véhicule qui devient un véhicule dit autonome, c’est-à-dire un véhicule apte à rouler dans l’environnement routier sans intervention du conducteur.
Pour améliorer la sécurité sur les routes, de nouvelles technologies voient le jour qui permettent l’échange d’informations entre les véhicules et/ou entre les véhicules et l’infrastructure qui les entoure. Ainsi, de nouvelles technologies de l’information et de la communication appliquées au domaine des transports sont apparues, telles que l’ITS G5 (de l’anglais « Intelligent Transportation System G5 » ou en français « Système de transport intelligent G5 ») en Europe ou DSRC (de l’anglais « Dedicated Short Range Communications » ou en français « Communications dédiées à courte portée ») aux Etats-Unis d’Amérique qui reposent tous les deux sur le standard IEEE 802.11p ou encore la technologie basée sur les réseaux cellulaires nommée C-V2X (de l’anglais « Cellular - Vehicle to Everything » ou en français « Cellulaire – Véhicule vers tout ») qui s’appuie sur la 4G basé sur LTE (de l’anglais « Long Term Evolution » ou en français « Evolution à long terme ») et bientôt la 5G.
Ces nouvelles technologies s’appuient sur des protocoles de transport tels que BTP (de l’anglais « Basic Transport Protocol » ou en français « Protocole de transport basique ») de l’anglais ou encore TCP (de l’anglais « Transmission Control Protocol » ou en français « Protocole de contrôle de transmission ») lorsque les échanges de données se font dans un réseau cellulaire de type LTE 4G ou 5G. Le protocole « GeoNetworking » ne prévoit que l’échange d’un paquet de données à la fois, ce qui impose d’ouvrir et de fermer une session TCP pour chaque envoi de paquet de données conforme au protocole « GeoNetworking » lorsque les transmissions de tels paquets de données se font via un réseau cellulaire. Un tel mode de fonctionnement entraîne des temps de latence plus important dans les communications et des besoins plus importants en bande passante du fait du surcoût (de l’anglais « overhead ») associé à ces ouvertures / fermetures répétées de sessions TCP.
Un objet de la présente invention est d’optimiser la communication de données dans un système de communication de type V2X.
Un autre objet de l’invention est d’améliorer les échanges d’informations dans un système de communication de type V2X.
Selon un premier aspect, l’invention concerne un procédé de réception de données, le procédé comprenant les étapes suivantes :
a- réception d’une trame de données conforme au protocole TCP, la trame comprenant une pluralité de segments de données conformes au protocole « GeoNetworking » ;
b- pour un segment courant de données de la pluralité, obtention, dans un entête de segment, d’une information indiquant que l’entête de segment est suivi d’un paquet de données sécurisé comprenant un entête de sécurité et obtention, dans l’entête de sécurité, d’une information représentative d’une taille du paquet de données sécurisé ;
c- détermination du début d’un segment de données suivant le segment courant de données dans la trame de données à partir de l’information représentative de la taille du paquet de données sécurisé ;
d- réitération des étapes b et c jusqu’au dernier segment de données de la pluralité, le segment de données suivant le segment courant de données devenant le segment courant de données.
Selon une variante, le procédé comprend en outre une étape d’obtention de données utiles comprises dans chaque paquet de données sécurisé de chaque segment de données de la pluralité.
Selon une autre variante, les données utiles correspondent à des données de message de type CAM ou DENM.
Selon une variante supplémentaire, le procédé comprend en outre une étape d’obtention d’une information représentative d’une taille de la trame de données, l’information représentative de la taille de la trame de données étant comprise dans un entête de la trame de données, l’information représentative de la taille de la trame de données étant utilisée pour déterminer si le dernier segment de données a été atteint.
Selon un deuxième aspect, l’invention concerne un procédé de transmission de données, le procédé comprenant les étapes suivantes :
- encapsulation d’une pluralité de segments de données conformes au protocole « GeoNetworking » dans une trame de données conforme au protocole TCP, chaque segment de données comprenant un entête de segment, l’entête de segment comprenant une information indiquant que l’entête de segment est suivi d’un paquet de données sécurisé comprenant un entête de sécurité, l’entête de sécurité comprenant une information représentative d’une taille du paquet de données sécurisé ;
- transmission de la trame de données.
Selon une variante, chaque paquet de données sécurisé de chaque segment de données de la pluralité comprend un ensemble de données utiles.
Selon une autre variante, les données utiles correspondent à des données de message de type CAM ou DENM.
Selon une variante supplémentaire, une information représentative d’une taille de la trame de données est comprise dans un entête de la trame de données.
Selon un troisième aspect, l’invention concerne un dispositif de réception et/ou de transmission de données, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé selon le premier aspect de l’invention et/ou selon le deuxième aspect de l’invention.
Selon un quatrième aspect, l’invention concerne un véhicule, par exemple de type automobile, comprenant un dispositif tel que décrit ci-dessus selon le troisième aspect de l’invention.
Selon un cinquième aspect, l’invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé selon le premier aspect de l’invention et/ou selon le deuxième aspect de l’invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur.
Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
Selon un cinquième aspect, l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect de l’invention et/ou selon le deuxième aspect de l’invention.
D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur.
D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des figures
D’autres caractéristiques et avantages de l’invention ressortiront de la description des modes de réalisation non limitatifs de l’invention ci-après, en référence aux figures 1 à 5 annexées, sur lesquelles :
Un procédé et un dispositif de réception de données ainsi qu’un procédé et un dispositif de transmission de données, notamment dans un réseau de communication de type V2X, vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 5.
Selon un exemple particulier et non limitatif de réalisation de l’invention, un procédé de réception de données, notamment dans un réseau de communication de type V2X, comprend la réception d’une trame de données conforme au protocole TCP Cette trame comprend avantageusement plusieurs segments de données conformes au protocole « GeoNetworking », chaque segment correspondant par exemple à un paquet de données de type GN-PDU (de l’anglais « GeoNetworking Protocol Data Unit » ou en français « Unité de données du protocole GeoNetworking »), par exemple défini dans le document ETSI EN 302 636-v1.4.0 de mai 2019. Chaque segment de données de la trame TCP est décodé, l’un après l’autre. Pour ce faire, la trame est parcourue avec dans un premier temps une lecture de l’entête du premier segment, cet entête comprenant une première information indiquant que l’entête suivant cet entête de segment est un entête de sécurité d’un paquet de données sécurisé. L’entête sécurisé est alors parcouru pour obtenir la taille du paquet de données sécurisé. Avec l’information sur la taille du paquet de données sécurisé, le dispositif décodant la trame TCP peut aisément déterminer où finit le segment de données courant et où commence le segment de données suivant dans la chaine d’informations binaires qui compose la trame TCP. Une fois le segment de données courant décodé, le dispositif décodant la trame passe au segment suivant (qui devient le segment courant) et détermine dans l’entête de ce nouveau segment que le paquet de données suivant cet entête est sécurisé et comprend un entête de sécurité qui contient la taille de ce nouveau paquet de données sécurisé. Le dispositif peut ainsi déterminer où se finit le nouveau segment courant dans la trame TCP et réitérer le processus de décodage d’un nouveau segment de données si la fin de la trame TCP n’a pas encore été atteinte.
Selon un autre particulier et non limitatif de réalisation de l’invention, un procédé de transmission de données comprend l’encapsulation de plusieurs segments de données dans une trame de données TCP, chaque segment étant conforme au protocole « GeoNetworking » et ayant le même destinataire. Chaque segment de données comprend un entête de segment qui comprend lui-même une information indiquant que cet entête de segment est suivi d’un paquet de données sécurisé. Le paquet de données sécurisé comprend une information indiquant la taille du paquet de données sécurisé. Une fois les segments de données encapsulés dans la trame TCP, cette dernière est transmise dans un réseau de communication de type V2X (par exemple d’un serveur vers un véhicule ou d’un véhicule vers un serveur).
L’encapsulation de plusieurs segments (paquets) de données « GeoNetworking » dans une même trame TCP évite d’ouvrir et de fermer plusieurs sessions TCP avec envoi d’un seul segment par trame TCP, comme cela est prévu dans le traitement des données au niveau de la couche « GeoNetworking ». L’utilisation de paquets de données sécurisé permet d’indiquer dans l’entête de chacun de ces paquets sécurisés quelle est la taille de ce paquet, ce qui permet au récepteur de la trame de déterminer où comment et où finit chaque segment de données dans la trame TCP, permettant ainsi de décoder les données utiles (de l’anglais « Payload ») contenues dans chacun des segments.
L’utilisation des ressources du réseau s’en trouve ainsi améliorée, notamment en réduisant le nombre de sessions TCP nécessaire à l’envoi des paquets de données GeoNetworking, diminuant ainsi la latence et les surcoûts de données de signalisation (entêtes) induits par l’ouverture et la fermeture de plusieurs sessions TCP.
La figure 1 illustre un premier véhicule 10 et un deuxième véhicule 10 circulant dans un environnement routier. Le premier véhicule 10 et le deuxième véhicule 11 embarquent chacun un dispositif de communication pour transmettre et recevoir des données à destination d’un autre véhicule et/ou d’un serveur d’une infrastructure réseau. Chaque dispositif de communication peut être assimilé à un nœud d’un réseau, par exemple un réseau sans fil ad hoc. Un tel réseau comprend avantageusement une pluralité de nœuds, par exemple 2, 3, 5, 10, 100, 1000 ou plus de nœud. Selon l’exemple particulier de la figure 1, le réseau sans fil ad hoc comprend un troisième nœud 101 et un quatrième nœud 102, correspondant chacun à une antenne d’un réseau cellulaire de type LTE 4G ou 5G selon un exemple de réalisation particulier et non limitatif.
Les véhicules 10 et 11 communiquent avantageusement en utilisant un système de communication dit V2X, par exemple basé sur les standards 3GPP LTE-V ou IEEE 802.11p de ITS G5. Dans un tel système de communication V2X, chaque véhicule embarque un nœud pour permettre une communication de véhicule à véhicule V2V (de l’anglais « vehicle-to-vehicle »), de véhicule à infrastructure V2I (de l’anglais « vehicle-to-infrastructure ») et/ou de véhicule à piéton V2P (de l’anglais « vehicle-to-pedestrian »), les piétons étant équipés de dispositifs mobiles (par exemple un téléphone intelligent (de l’anglais « Smartphone »)) configurés pour communiquer avec les véhicules.
Un réseau sans fil ad hoc (aussi appelé WANET (de l’anglais « Wireless Ad Hoc Network ») ou MANET (de l’anglais « Mobile Ad Hoc Network »)) est un réseau sans fil décentralisé. Contrairement à un réseau centralisé qui s’appuie sur une infrastructure existante comprenant par exemple des routeurs ou des points d’accès reliés entre eux par une infrastructure filaire ou sans-fil, le réseau sans fil ad hoc est constitué de nœuds qui participent chacun au routage des données en retransmettant les données d’un nœud à l’autre, de l’émetteur vers le destinataire, en fonction de la connectivité du réseau et de l’algorithme de routage mis en œuvre. Le réseau sans fil ad hoc correspond avantageusement à un réseau véhiculaire ad hoc (ou VANET, de l’anglais « Vehicular Ad hoc NETwork ») ou à un réseau véhiculaire ad hoc intelligent (ou InVANET, de l’anglais « Intelligent Vehicular Ad hoc NETwork »), aussi appelé réseau « GeoNetworking ». Dans un tel réseau, 2 véhicules ou plus embarquant chacun un nœud peuvent communiquer entre eux dans le cadre d’une communication véhicule à véhicule V2V (de l’anglais « vehicle-to-vehicle ») ; chaque véhicule peut communiquer avec l’infrastructure mise en place dans le cadre d’une communication véhicule à infrastructure V2I (de l’anglais « vehicle-to-infrastructure ») ; chaque véhicule peut communiquer avec un ou des piétons équipés de dispositifs mobiles (par exemple un téléphone intelligent (de l’anglais « Smartphone »)) dans le cadre d’une communication véhicule à piéton V2P (de l’anglais « vehicle-to-pedestrian »).
Le réseau sans fil ad hoc comprend par exemple une ou plusieurs UBR (« Unité Bord de Route »), chacune correspondant à un nœud du réseau, en plus des nœuds équipant les véhicules ou les piétons. Selon cet exemple, les nœuds 101 et 102 correspondent chacun à une UBR. Selon une variante, le réseau sans fil ad hoc comprend une ou plusieurs antennes relais d’un réseau cellulaire, par exemple un réseau cellulaire dit 4G ou 5G, en plus des nœuds équipant les véhicules ou les piétons. Selon cette variante, les nœuds 101 et 102 correspondent chacun à une antenne relais. Selon encore une variante, le réseau sans fil ad hoc comprend une ou plusieurs UBR et une ou plusieurs antennes relais d’un réseau cellulaire, en plus des nœuds équipant les véhicules ou les piétons. Selon cette variante, le nœud 101 correspond par exemple à une UBR et le nœud 102 à une antenne relais.
Les nœuds 101 et 102 sont avantageusement reliés à un ou plusieurs serveurs distants ou au « cloud » 100 (ou en français « nuage ») via une connexion filaire et/ou sans fil. Les nœuds 101 et 102 peuvent ainsi faire office de relais entre le « cloud » 100 et le premier nœud 10 et/ou le deuxième nœud 11.
Le premier nœud 10 établit avantageusement une connexion avec le troisième nœud 101 lorsque le premier nœud 10 entre dans la zone de couverture (aussi appelée zone d’interférence) du troisième nœud 101. L’association entre le premier nœud 10 et le troisième nœud 101 est par exemple réalisée lorsque la qualité d’un signal reçu du troisième nœud 101 par le premier nœud atteint un niveau suffisant, c’est-à-dire que le niveau de qualité est supérieur à un seuil. La qualité correspond par exemple à un niveau de signal sur bruit, à un taux d’erreur (par exemple le PER (de l’anglais « Packet Error Rate » ou en français « Taux d’erreur paquet ») et/ou au RSSI (de l’anglais « Received Signal Strength Indication » ou en français « Indication de force de signal reçu »). Lorsque le premier nœud 10 se situe dans les zones de couverture de plusieurs nœuds, le premier nœud s’associe par exemple au nœud pour lequel la qualité du signal reçu est la plus élevée et/ou en fonction des services de protocole internet fourni.
L’établissement d’une connexion avec le troisième nœud 101 comprend par exemple l’accès au protocole internet IP (de l’anglais « Internet Protocol »), notamment à un ou plusieurs services de protocole internet, en utilisant la couche de transport TCP.
Plusieurs services sont fournis par le protocole « GeoNetworking », tels que définis dans le document ETSI TS 102 636-4-1. Le protocole « GeoNetworking » permet le transport de paquets de données (appelée GN-PDU, de l’anglais « GeoNetworking Protocol Data Unit » ou en français « Unité de données du protocole GeoNetworking ») dans un réseau ad-hoc sans-fil de type ITS-G5. Le protocole « GeoNetworking » fournit des services aux entités de protocole plus élevées, c’est-à-dire le protocole de transport ITS, tel que le protocole de transport basique BTP (de l’anglais « Basic Transport Protocol »), et/ou un service de « GeoNetworking » à la sous-couche d’adaptation IPv6 GN6ASL (de l’anglais « GeoNetworking to IPv6 Adaptation Sub-Layer ») pour transport des paquets GN-PDU en utilisant le protocole de transport TCP.
Les paquets GN-PDU contiennent par exemple des données de messages de sécurité échangés entre les véhicules 10 et 11 et/ou entre les véhicules 10 et/ou 11 et les nœuds 101 et/ou 102 de l’infrastructure réseau, les messages de sécurité étant par exemple de type CAM (de l’anglais « Cooperative Awareness Message » ou en français « Message d’avertissement coopératif ») tel que défini dans la spécification technique ETSI TS 102 637-2 v1.2.1 de mars 2011 et/ou de type DENM (de l’anglais « Decentralized Environmental Notification Message » ou en français « Message de notification environnementale décentralisée ») tel que défini dans la spécification technique ETSI TS 102 637-3 v1.1.1 de septembre 2010.
Selon l’exemple de la figure 1, le deuxième véhicule 11 échange des données avec le premier véhicule 10 selon un mode de communication directe, c’est-à-dire sans passer par l’infrastructure réseau. Un mode de communication directe est par exemple conforme à :
- ITS G5 en Europe ou DSRC (de l’anglais « Dedicated Short Range Communications » ou en français « Communications dédiées à courte portée ») aux Etats-Unis d’Amérique, qui reposent tous les deux sur le standard IEEE 802.11p ; ou
- LTE-V Mode 4 (de l’anglais « Long-Term Evolution – Vehicle Mode 4 » ou en français « Evolution à long terme – véhicule Mode 4 ») qui permet des communications V2V, aussi appelées communications « sidelink » (ou en français « liaison latérale »)) basé sur une interface de communication directe de LTE appelée PC5 ; une telle technologie est décrite par exemple dans l’article intitulé « Analytical Models of the Performance of C-V2X Mode 4 Vehicular Communications », écrit par Manuel Gonzalez-Martin, Miguel Sepulcre, Rafael Molina-Masegosa et Javier Gozalvez, et publié en 2018.
La trame 2 est une trame de données conforme au protocole TCP, un tel protocole étant décrit dans le document RFC 793 (de l’anglais « Requests for Comments » ou en français « Requêtes pour commentaires »). La trame 2 (également appelée segment) correspond à une séquence de valeurs binaires, seuls les éléments spécifiques à l’invention étant représentés sur la figure 2.
La trame 2 comprend un entête de trame 20 suivi de 3 segments de données 21, 22 et 23, chaque segment de données 21 à 23 étant conforme au protocole « GeoNetworking », la structure d’un tel segment de données étant par exemple décrite dans le document ETSI TS 102 636-4-1. Un segment de données est aussi appelé un paquet de données, par exemple décrit sous l’acronyme GN-PDU (de l’anglais « GeoNetworking Protocol Data Unit » ou en français « Unité de données du protocole GeoNetworking »). La structure des segments de données 21 à 23 est identique pour chacun des segments, seule la structure du premier segment de données 21 étant décrite avec détail. Le nombre de segments de données n’est pas limité à 3 mais s’étend à tout nombre, par exemple 1, 2, 5, 10 ou 20 segments de données.
Les segments de données à l’intention d’un même destinataire sont encapsulés dans la trame de données 2. Par exemple, les segments de données (ou GN-PDU) à destination d’un même véhicule, par exemple le premier véhicule 10, sont encapsulés ou concaténés dans la trame 2 alors que le ou segments de données destinés à un autre véhicule, par exemple le deuxième véhicule 20, sont encapsulés ou intégrés dans une trame de données TCP différente de la trame 2.
Selon un autre exemple, les segments de données de la trame 2 correspondent à des paquets de données de message(s) émis par un même véhicule (par exemple le premier véhicule 10) à destination d’un serveur du « cloud » (par exemple des données de messages relatifs à un freinage d’urgence et d’un danger immédiat duquel le premier véhicule est en approche).
Le premier segment de données 21 comprend notamment un entête de segment 210 suivi d’un entête de sécurité 211 et de données utiles 212 (de l’anglais « Payload »), l’ensemble entête de sécurité 211 et données utiles 212 formant un paquet de données sécurisé.
L’entête de segment 210 et l’entête de sécurité 212 correspondent avantageusement à respectivement l’entête dit basique (de l’anglais « basic header ») et l’entête de sécurité (de l’anglais « secured header ») d’un GN-PDU, tels que décrit dans le document ETSI EN 302 636-4-1.
L’entête de segment 210 comprend notamment un champ NH (de l’anglais « Next Header » ou en français « Entête suivant ») dont la valeur est mise à ‘2’ pour indiquer que l’entête 211 suivant l’entête de segment 210 correspond à l’entête 211 d’un paquet de données GeoNetworking sécurisé (de l’anglais « Secured packet ») tel que défini dans le document ETSI TS 103 097, l’entête 211 d’un tel paquet de données sécurisé étant appelé entête de sécurité 211. Une valeur mise à ‘1’ pour ce champ NH indiquerait que l’entête suivant l’entête de segment 210 correspondrait à un entête « GeoNetworking » commun (de l’anglais « GeoNetworking Common Header ») alors qu’une valeur mise à ‘0’ du champ NH correspond à une absence de spécification de l’entête suivant.
L’entête de sécurité 211 comprend notamment une information représentative de la taille du paquet de données sécurisé, cette information correspondant par exemple à un paramètre indiquant la taille du paquet sécurisé en octets, ce paramètre étant par exemple dénommé « sec_packet_length » dans le document ETSI EN 302 636-4-1. Cette information est accessible au récepteur de la trame 2 lors du décodage des données contenues dans la trame 2.
Les données utiles 212 comprennent avantageusement les données relatives à des messages de sécurité de type CAM et/ou DENM. Ces données sont par exemple encodées dans les paquets de données GN-PDU en utilisant des règles d’encodage de type UPER (de l’anglais « Unaligned Packed Encoding Rules » ou en français « Règles d’encodage par paquet non alignées ») du standard ASN.1 (de l’anglais « Abstract Syntax Notation One » ou en français « Notation de syntaxe abstraite 1 »).
La décapsulation des segments de données 21 à 23 contenues dans la trame 2 est avantageusement mise en œuvre par le dispositif ayant reçu la trame 2. Cette décapsulation, correspondant au service SN-DECAP décrit dans le document ETSI TS 102 723-8 est mise en œuvre par le dispositif à la lecture du champ NH ayant pour valeur ‘2’. Une requête de décapsulation est émise depuis les couches transport et réseau à l’entité de sécurité pour exécuter le service de décapsulation. Cette requête comprend notamment l’information représentative de la taille du paquet de données sécurisé obtenu de l’entête de sécurité 211.
Connaissant la taille du paquet de données sécurisé, le dispositif décodant la trame 2 détermine où se finit le segment courant dans la trame 2, c’est-à-dire le segment 21, et où commence le segment suivant 22. Une fois les données du segment courant décodées, le dispositif en charge du décodage peut passer au décodage des données du segment 22 suivant, avec lecture de l’entête de segment du segment 22, lecture de la valeur du champ NH, lecture de l’information représentative de la taille du paquet de données sécurisé compris dans le segment 22, décapsulation et décodage des données avant de passer au segment 23 suivant le segment 22 (le fin du segment 22 et le début du segment 23 dans la trame 2 étant déduit/déterminé à partir de l’information représentative de la taille du segment 22 contenue dans l’entête de sécurité du segment 22).
Le processus de décodage décrit ci-dessus est réitéré pour chaque segment jusqu’à atteindre le dernier bit de la trame 22. Le décodeur peut déterminer que la fin de la trame 2 est atteinte à partir par exemple d’une information représentative de la taille de la trame 2 comprise dans l’entête de trame 20.
Le dispositif 3 est par exemple configuré pour la mise en œuvre des étapes du procédé décrit en regards des figures 1, 2, 4 et/ou 5. Des exemples d’un tel dispositif 3 comprennent, sans y être limités, un équipement électronique embarqué tel qu’un ordinateur de bord d’un véhicule, un calculateur électronique tel qu’une UCE (« Unité de Commande Electronique »), une unité bord de route, un téléphone intelligent, une tablette, un ordinateur portable, un serveur. Les éléments du dispositif 3, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif 3 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels. Selon différents modes de réalisation particuliers, le dispositif 3 est couplé en communication avec d’autres dispositifs ou systèmes similaires, par exemple par l’intermédiaire d’un bus de communication ou au travers de ports d’entrée / sortie dédiés.
Le dispositif 3 comprend un (ou plusieurs) processeur(s) 30 configurés pour exécuter des instructions pour la réalisation des étapes du procédé et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif 3. Le processeur 30 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif 3 comprend en outre au moins une mémoire 31 correspondant par exemple une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique.
Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur est par exemple stocké sur la première mémoire 31.
Selon un mode de réalisation particulier et non limitatif, le dispositif 3 comprend un bloc 32 d’éléments d’interface pour communiquer avec des dispositifs externes, par exemple un serveur distant ou le « cloud », d’autres nœuds du réseau ad hoc. Les éléments d’interface du bloc 32 comprennent une ou plusieurs des interfaces suivantes :
- interface radiofréquence RF, par exemple de type Bluetooth® ou Wi-Fi®, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ;
- interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ;
- interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français).
Des données sont par exemples chargées vers le dispositif 3 via l’interface du bloc 32 en utilisant un réseau Wi-Fi® tel que selon IEEE 802.11, un réseau ITS G5 basé sur IEEE 802.11p ou un réseau mobile tel qu’un réseau 4G (ou LTE Advanced selon 3GPP release 10 – version 10) ou 5G, notamment un réseau LTE-V2X.
Selon un autre mode de réalisation particulier, le dispositif 3 comprend une interface de communication 33 qui permet d’établir une communication avec d’autres dispositifs (tels que d’autres calculateurs du système embarqué lorsque le dispositif 3 correspond à un calculateur du système embarqué) via un canal de communication 330. L’interface de communication 33 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 330. L’interface de communication 33 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs ») ou CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »).
Selon un mode de réalisation particulier supplémentaire, le dispositif 3 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes, tels qu’un écran d’affichage, un ou des haut-parleurs et/ou d’autres périphériques via respectivement des interfaces de sortie non représentées.
Dans une première étape 41, une trame de données conforme au protocole TCP est reçue, par exemple via une liaison sans fil d’un réseau de type V2X. La trame comprend avantageusement une pluralité de segments de données, conformes au protocole « GeoNetworking », encapsulés dans la trame TCP.
Dans une deuxième étape 42, une information indiquant que l’entête de segment d’un segment courant de la trame est suivi d’un paquet de données sécurisé est obtenue en parcourant les données contenues dans l’entête du segment courant. Le paquet de données sécurisé comprend avantageusement un entête de sécurité. En parcourant l’entête de sécurité, une information représentative de la taille du paquet de données sécurisé est obtenue, cette information étant contenue et codée dans l’entête de sécurité.
Dans une troisième étape 43, le début du segment de données suivant le segment de données courant dans la trame 2 est déterminé à partir de l’information représentative de la taille du paquet de données sécurisé obtenue à l’étape 42. Connaissant le nombre d’octets formant le paquet de données sécurisé du segment courant traité à l’étape 42, il est possible de déterminer à quel bit de la trame TCP correspond la fin du segment courant et à quel bit de la trame TCP correspond le début du segment suivant le segment courant.
Les étapes 42 et 43 sont réitérées en prenant comme segment courant le segment dont le début de segment a été déterminé à l’étape 43. Cela permet de déterminer le début de chaque segment contenu dans la trame TCP pour en extraire et décoder les données contenues dans ces segments de données (c’est-à-dire les données utiles des paquets de données sécurisé compris dans chacun de ces segments de données).
Les données utiles correspondent par exemple à des données de sécurité de message(s) de type CAM et/ou DENM encodées dans les paquets de données sécurisé.
Dans une première étape 51, une pluralité de segments de données conformes au protocole « GeoNetworking » sont encapsulés dans une trame de données conforme au protocole TCP. Ces segments de données sont par exemple encapsulés en mettant en œuvre un service d’encapsulation conforme à l’ITS (de l’anglais « Intelligent Transport System » ou en français « Système de transport intelligent ») décrit dans le document ETSI TS 102 723-8 sous la dénomination « SN-ENCAP ». Chaque segment de données comprend avantageusement un entête de segment qui comprend une information indiquant que l’entête de segment est suivi d’un paquet de données sécurisé, ce dernier comprenant un entête de sécurité. Une information représentative de la taille du paquet de données sécurisé est comprise et encodée dans l’entête de sécurité.
Les segments de données encapsulés dans une trame ont avantageusement le même destinataire, l’adresse ou l’identifiant du destinataire étant par exemple codé dans l’entête de trame.
Dans une deuxième étape 52, la trame de données obtenue à l’étape 51 est transmise au destinataire des segments de données, par exemple via une liaison sans fil d’un réseau de type V2X.
Avant d’être encapsulés, les segments de données sont par exemple mis en mémoire tampon en fonction de leur destinataire, pour regrouper les segments à destination d’un même destinataire dans une même trame.
Bien entendu, l’invention ne se limite pas aux modes de réalisation décrits ci-avant mais s’étend à un procédé d’encapsulation (respectivement un procédé de décapsulation) de segments de données « GeoNetworking » dans une trame TCP et au dispositif configuré pour la mise en œuvre du procédé d’encapsulation (respectivement du procédé de décapsulation).
L’invention concerne également un procédé de codage (respectivement un procédé de décodage) de données de de segments de données « GeoNetworking » encapsulés dans une (respectivement décapsulés d’une) trame TCP et au dispositif configuré pour la mise en œuvre du procédé de codage (respectivement du procédé de décodage)
L’invention concerne également un véhicule, par exemple automobile ou plus généralement un véhicule à moteur terrestre, comprenant le dispositif 3 de la figure 3.
Claims (10)
- Procédé de réception de données, ledit procédé comprenant les étapes suivantes :
a- réception (41) d’une trame de données (2) conforme au protocole TCP, ladite trame comprenant une pluralité de segments de données (21 à 23) conformes au protocole « GeoNetworking » ;
b- pour un segment courant de données (21) de ladite pluralité, obtention (42), dans un entête de segment (210), d’une information indiquant que ledit entête de segment (210) est suivi d’un paquet de données sécurisé comprenant un entête de sécurité (211) et obtention, dans ledit entête de sécurité (211), d’une information représentative d’une taille dudit paquet de données sécurisé ;
c- détermination (43) du début d’un segment de données (22) suivant ledit segment courant de données (21) dans ladite trame de données (2) à partir de l’information représentative de la taille dudit paquet de données sécurisé ;
d- réitération des étapes b (42) et c (43) jusqu’au dernier segment de données (23) de ladite pluralité, ledit segment de données (22) suivant ledit segment courant de données (21) devenant le segment courant de données. - Procédé selon la revendication 1, comprenant en outre une étape d’obtention de données utiles (212) comprises dans chaque paquet de données sécurisé de chaque segment de données de ladite pluralité (21 à 23).
- Procédé selon la revendication 2, pour lequel lesdites données utiles (212) correspondent à des données de message de type CAM ou DENM.
- Procédé selon l’une des revendications 1 à 3, comprenant en outre une étape d’obtention d’une information représentative d’une taille de ladite trame de données (2), ladite information représentative de la taille de ladite trame de données étant comprise dans un entête (20) de ladite trame de données (2), ladite information représentative de la taille de ladite trame de données (2) étant utilisée pour déterminer si le dernier segment de données (23) a été atteint.
- Procédé de transmission de données, ledit procédé comprenant les étapes suivantes :
- encapsulation (51) d’une pluralité de segments de données (21 à 23) conformes au protocole « GeoNetworking » dans une trame de données (2) conforme au protocole TCP, chaque segment de données (21) comprenant un entête de segment (210), ledit entête de segment (210) comprenant une information indiquant que ledit entête de segment (210) est suivi d’un paquet de données sécurisé comprenant un entête de sécurité (211), ledit entête de sécurité (211) comprenant une information représentative d’une taille dudit paquet de données sécurisé ;
- transmission (52) de ladite trame de données (2). - Procédé selon la revendication 5, pour lequel chaque paquet de données sécurisé de chaque segment de données de ladite pluralité comprend un ensemble de données utiles (212).
- Procédé selon la revendication 6, pour lequel lesdites données utiles (212) correspondent à des données de message de type CAM ou DENM.
- Procédé selon l’une des revendications 5 à 7, pour lequel une information représentative d’une taille de ladite trame de données (2) est comprise dans un entête (20) de ladite trame de données (2).
- Dispositif (3) comprenant une mémoire (31) associée à au moins un processeur (30) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 8.
- Véhicule (10) comprenant le dispositif (3) selon la revendication 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1909832A FR3100681A1 (fr) | 2019-09-06 | 2019-09-06 | Procédé et dispositif de communication V2X pour véhicule |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1909832 | 2019-09-06 | ||
| FR1909832A FR3100681A1 (fr) | 2019-09-06 | 2019-09-06 | Procédé et dispositif de communication V2X pour véhicule |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3100681A1 true FR3100681A1 (fr) | 2021-03-12 |
Family
ID=68807109
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1909832A Withdrawn FR3100681A1 (fr) | 2019-09-06 | 2019-09-06 | Procédé et dispositif de communication V2X pour véhicule |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3100681A1 (fr) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1460818A1 (fr) * | 2003-03-20 | 2004-09-22 | Broadcom Corporation | Système et procédé pour le traitement des segments de protocole de transport |
-
2019
- 2019-09-06 FR FR1909832A patent/FR3100681A1/fr not_active Withdrawn
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1460818A1 (fr) * | 2003-03-20 | 2004-09-22 | Broadcom Corporation | Système et procédé pour le traitement des segments de protocole de transport |
Non-Patent Citations (3)
| Title |
|---|
| "Intelligent Transport Systems (ITS); GeoNetworking; Port Numbers for the Basic Transport Protocol (BTP)", vol. ITS WG3, no. V1.3.1, 12 April 2019 (2019-04-12), pages 1 - 9, XP014344452, Retrieved from the Internet <URL:http://www.etsi.org/deliver/etsi_ts/103200_103299/103248/01.03.01_60/ts_103248v010301p.pdf> [retrieved on 20190412] * |
| ERICSSON LM: "Comments to Additions to support long range access and hybrid ITS-S, revision 1", vol. WG ITS WG3 Transport and Network, 23 January 2019 (2019-01-23), pages 1 - 4, XP014335583, Retrieved from the Internet <URL:docbox.etsi.org/ITS/ITSWG3/05-CONTRIBUTIONS/2019/ITSWG3(19)045009_Comments_to_Additions_to_support_long_range_access_and_hybri.docx> [retrieved on 20190123] * |
| RENAULT SAS: "(EN 302 636-4-1 ) Additions to support long range access and hybrid ITS-S, revision 1", vol. WG ITS WG3 Transport and Network, no. .0.1, 22 January 2019 (2019-01-22), pages 1 - 100, XP014335598, Retrieved from the Internet <URL:docbox.etsi.org/ITS/ITSWG3/05-CONTRIBUTIONS/2019/ITSWG3(19)045007__EN_302_636-4-1___Additions_to_support_long_range_access_and/ITS-00358v001.docx> [retrieved on 20190122] * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2753589A1 (fr) | Relais pour systeme de radiocommunications | |
| CA2712183A1 (fr) | Architecture de communication ip entre le sol et un vehicule | |
| FR2883440A1 (fr) | Procede et equipement pour la transmission de donnees par reseau ad hoc | |
| EP2856707B1 (fr) | Trames de contrôle de courte durée en couche physique | |
| FR3100203A1 (fr) | Procédé et dispositif d’alerte d’évènement pour véhicule | |
| FR3100681A1 (fr) | Procédé et dispositif de communication V2X pour véhicule | |
| EP3957093B1 (fr) | Procédé et dispositif de communication pour véhicule dans un réseau sans fil de type ad hoc | |
| EP3675562B1 (fr) | Procédés de traitement de données, dans un réseau ad hoc de radiocommunication, stations mobiles de radiocommunication et programmes d'ordinateur associés | |
| FR3118824A1 (fr) | Procédé et dispositif de reprise en main par un conducteur d’un véhicule autonome circulant dans un tunnel | |
| FR3099679A1 (fr) | Procédé, dispositif et système de communication pour véhicule utilisant des radars | |
| EP4066519A1 (fr) | Procédé et dispositif de transmission de données pour véhicule | |
| EP2890026B1 (fr) | Procédé de communication mis en oeuvre par un noeud de relais | |
| FR3101307A1 (fr) | Procédé et dispositif de prévention de risque de collision pour véhicule | |
| FR3102965A1 (fr) | Procédé et dispositif de sélection de certificat pseudonyme pour véhicule | |
| FR3104878A1 (fr) | Procédé et dispositif de communication pour véhicule | |
| FR3099682A1 (fr) | Procédé et dispositif de communication pour véhicule | |
| FR3084985A1 (fr) | Relai pour la convergence entre un routage geographique a sauts multiples et un routage cellulaire | |
| EP1872530B1 (fr) | Procede de transfert d'un code d'information entre deux dispositifs de communication | |
| WO2021240082A1 (fr) | Procédé et système de communication dans un réseau cellulaire sans fil | |
| FR3140235A1 (fr) | Procédé et dispositif de communication de données d’identification de véhicule | |
| FR3032083A1 (fr) | Differentiation de classes de services de proximite dans des messages entre terminaux mobiles | |
| FR3104371A1 (fr) | Procédé et dispositif de communication pour véhicule | |
| FR2847405A1 (fr) | Procede de gestion de messages, systeme et entites de communication pour la mise en oeuvre du procede | |
| EP4364498A1 (fr) | Procede de traitement d'une connexion entre un equipement utilisateur et un equipement distant dans un reseau de communication, procede de controle, dispositifs, satellite, station terrestre, systeme et programmes d'ordinateur correspondants | |
| FR3084984A1 (fr) | Emission et reception pour la convergence entre un routage geographique a sauts multiples et un routage cellulaire |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20210312 |
|
| ST | Notification of lapse |
Effective date: 20220505 |