FR2975851A1 - Methode de transmission sur la liaison montante d'un aeronef. - Google Patents

Methode de transmission sur la liaison montante d'un aeronef. Download PDF

Info

Publication number
FR2975851A1
FR2975851A1 FR1154496A FR1154496A FR2975851A1 FR 2975851 A1 FR2975851 A1 FR 2975851A1 FR 1154496 A FR1154496 A FR 1154496A FR 1154496 A FR1154496 A FR 1154496A FR 2975851 A1 FR2975851 A1 FR 2975851A1
Authority
FR
France
Prior art keywords
access network
segment
aircraft
address
packet
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.)
Granted
Application number
FR1154496A
Other languages
English (en)
Other versions
FR2975851B1 (fr
Inventor
Luc Emberger
Julie Facon
Lucas Babelaere
Christian Turpaud
Sebastien Delautier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Operations SAS
Original Assignee
Airbus Operations SAS
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Airbus Operations SAS filed Critical Airbus Operations SAS
Priority to FR1154496A priority Critical patent/FR2975851B1/fr
Priority to US13/477,301 priority patent/US20120303747A1/en
Priority to CN2012101629261A priority patent/CN102801607A/zh
Publication of FR2975851A1 publication Critical patent/FR2975851A1/fr
Application granted granted Critical
Publication of FR2975851B1 publication Critical patent/FR2975851B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/005Multiple registrations, e.g. multihoming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/14Relay systems
    • H04B7/15Active relay systems
    • H04B7/185Space-based or airborne stations; Stations for satellite systems
    • H04B7/18502Airborne stations
    • H04B7/18506Communications with or from aircraft, i.e. aeronautical mobile service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/06Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne une méthode de transmission de données, sous la forme de paquets IP, entre un segment embarqué (210) à bord d'un aéronef et le sol (230), via une pluralité de réseaux d'accès (220). Le segment embarqué transmet au sol une information fournissant l'association entre les réseaux d'accès et les adresses IP correspondantes de l'aéronef via ces différents réseaux. Cette information est utilisée par le segment au sol (230) pour constituer et mettre à jour une table de correspondance (239) entre les identifiants des réseaux d'accès et les adresses IP de l'aéronef. Pour transmettre un paquet sur la voie montante, l'adresse IP destinataire est sélectionnée à partir des adresses IP figurant dans la table de correspondance.

Description

MÉTHODE DE TRANSMISSION SUR LA LIAISON MONTANTE D'UN AÉRONEF
DESCRIPTION DOMAINE TECHNIQUE La présente invention concerne de manière générale le domaine des télécommunications aéronautiques et plus particulièrement celui de la transmission de paquets IP entre un segment embarqué et le sol. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Les aéronefs communiquent avec le sol grâce à une liaison de données généralement désignée par le terme générique de « datalink ». Cette liaison permet notamment d'échanger des informations de type AOC (Aeronautical Operational Control) avec les opérateurs de compagnies aériennes ou des informations de type ATC (Air Traffic Control) avec les contrôleurs aériens, généralement sous la forme de messages ACARS (Aircraft Communications Addressing and Reporting System). Traditionnellement, les messages ACARS sont transmis selon le protocole ARINC 618. Toutefois avec l'explosion du volume des communications aéronautiques, il est envisagé de transporter les données selon le protocole TCP/IP. Par exemple, la demande FR-A-2920622 déposée au nom de la présente demanderesse décrit une méthode de transmission de messages ACARS par 2 encapsulation dans des paquets IP, selon un protocole dénommé ACARS over IP ou AoIP. La liaison de données peut utiliser plusieurs supports de transmission (encore dénommés média ou segments air-sol), c'est-à-dire plusieurs types de réseau d'accès pour transmettre les données, par exemple les réseaux HF, VDL (VHF Data Link) ou SATCOM. Il a été récemment proposé d'utiliser des supports de transmission grand public lorsque l'aéronef roule ou stationne au sol ou encore lorsqu'il est en phase d'approche. Par exemple, l'aéronef peut établir une connexion par liaison sans fil avec le centre opérationnel de la compagnie aérienne via le réseau GPRS ou UMTS, une borne Wi-Fi ou encore une station Wi- Max. Ces supports de transmission ont des conditions d'utilisation et des coûts de communication très différents. Ainsi, le réseau de télécommunication VHF permet des liaisons point à point en ligne de visée directe avec des émetteurs/récepteurs au sol mais avec une portée relativement réduite. Le réseau de télécommunication satellitaire SATCOM fournit par contre une couverture mondiale, à l'exception des zones polaires, mais avec des coûts de communication élevés.
Le réseau HF permet quant à lui de couvrir les zones polaires. Enfin, les supports de transmission grand public ont une couverture limitée à la zone d'approche de certains aéroports mais ont des coûts de communication faibles. Lorsqu'une application embarquée doit transmettre au sol, il est souhaitable de sélectionner le support de transmission le plus 3 approprié en fonction de différents critères tels que la disponibilité du réseau, le coût, la fiabilité, le débit, etc. Par exemple, la demande FR-A-2922397, déposée au nom de la présente demanderesse décrit un système de routage de messages ACARS sélectionnant un support de transmission en fonction d'un certain nombre de profils de routage. Un profil de routage indique pour une application donnée, ou un type de message à transmettre par l'application, les réseaux d'accès qui peuvent être utilisés pour la transmission et leurs degrés de préférence respectifs. La Fig. 1 représente un système de communication aéronautique mettant en oeuvre une transmission par paquets IP et un routage par sélection de support de transmission. Ce système comprend un segment embarqué 110, une pluralité de segments air-sol 120 et un segment au sol 130. Le segment embarqué à bord de l'aéronef comprend généralement une pluralité d'applications 111 hébergées par des calculateurs. Ces applications peuvent avoir à transmettre des messages au sol, par exemple au centre opérationnel de la compagnie aérienne comme représenté ici en 135, ou bien avec une tour de contrôle. Les messages en question sont transmis sous forme de paquets IP, le cas échéant par encapsulation comme mentionné plus haut. Les paquets IP sont routés par le routeur 115 vers différents segments air-sol, 120. Le routage est effectué sous le contrôle d'un contrôleur 117 à partir de profils de routage stockés dans la base de données 4 113. Pour un type de message donné et une zone géographique donnée, le contrôleur 117 récupère le profil de routage correspondant et détermine le réseau d'accès 120 sur lequel les paquets IP de ce message doivent être transmis. On comprendra que le routeur 115 réalise l'interface entre le réseau embarqué et les réseaux d'accès 120. Ainsi le routeur 115 possède autant d'adresses IP que de réseaux d'accès auxquels il est connecté : X1 pour le réseau d'accès 1, X2 pour le réseau d'accès 2,...XN pour le réseau d'accès N. Des fournisseurs d'accès 131 permettent d'accéder à un réseau IP (public ou privé), 133, par exemple le réseau Internet. Les paquets IP transmis par les applications 111, et routés sur l'un quelconque des réseaux d'accès 120, sont ensuite routés à travers le réseau IP jusqu'à leur destination finale en l'occurrence ici le centre de traitement de données (data center) 135 de la compagnie aérienne. Dans le cas illustré, les paquets IP (transportant les messages) de l'application 1 sont routés préférentiellement via le réseau d'accès 1 et à défaut sur le réseau 2 comme illustré ; les paquets IP (transportant les messages) de l'application P ne peuvent être routés que via le réseau d'accès N. Les paquets IP des applications 1 à P peuvent ensuite être routés via le réseau IP jusqu'au centre de traitement de données 135. Le fournisseur d'accès du réseau 1 attribue une adresse IP X1 à l'aéronef. Une fois la liaison établie, l'infrastructure sol met à jour ses tables de routage et l'aéronef est joignable à l'adresse IP X1 . Il en va de manière similaire pour les fournisseurs d'accès aux réseaux 2,...,N. Le centre de traitement de données de la compagnie aerienne peut par conséquent joindre l'aéronef à l'une quelconque des adresses IP mais ne 5 sait pas en revanche à quels supports de transmission correspondent ces adresses. Lors d'une transmission à l'aéronef le choix de l'adresse IP (X1r ..., XN) ne peut se faire que sur la base d'un critère classique de routage, par exemple nombre de sauts (hops) qui n'est pas nécessairement pertinent. Le réseau d'accès associé à l'adresse IP est inconnu du segment au sol. Ainsi, une application hébergée dans le centre de traitement de données pourra transmettre un fichier non prioritaire et de volume important à l'adresse XI, par conséquent via le réseau d'accès 1 (SATCOM par exemple), alors que celui-ci peut s'avérer inapproprié pour ce genre de transfert tant en termes de coûts, de débit, de fiabilité, de disponibilité etc. Il n'est actuellement pas possible de sélectionner un support de transmission donné sur la voie montante à partir des adresses IP de l'aéronef. De manière plus générale, la sélection des supports de transmission sur la base des critères précités est seulement possible sur la voie descendante puisque le contrôleur 117 prend l'initiative d'établir la communication et effectue ladite sélection de manière autonome. Le but de la présente invention est par conséquent de proposer un système de communication aéronautique permettant d'effectuer une sélection pertinente du réseau d'accès sur la voie montante.
EXPOSÉ DE L'INVENTION La présente invention est définie par une méthode de transmission de données, sous forme de paquets IP, entre un segment de système de communication embarqué à bord d'un aéronef et un segment au sol, au moyen d'une pluralité de réseaux d'accès, ledit segment embarqué étant connecté à ladite pluralité de réseaux d'accès et possédant une même pluralité d'adresses IP, chaque adresse IP correspondant à un réseau d'accès. Selon la méthode en question, une information d'association entre au moins un réseau d'accès et ladite adresse IP correspondante est transmise par le segment embarqué au segment au sol.
Selon une première variante, les paquets IP sont conformes au protocole IPv6 et le champ « Flow Label » d'au moins un paquet IP contient un identifiant du réseau d'accès sur lequel il est transmis. Selon une seconde variante, les paquets IP sont conformes au protocole IPv6 et le champ « Next Header » d'au moins un paquet IP contient un pointeur vers un entête spécifique d'un protocole encapsulé dans la charge utile dudit paquet IP, ledit entête spécifique étant suivi par un identifiant du réseau d'accès sur lequel ledit paquet IP est transmis. Avantageusement, le destinataire dudit paquet IP met à jour une table de correspondance contenant pour chaque aéronef, et pour chaque réseau d'accès, l'adresse IP du segment embarqué sur ledit aéronef pour ledit réseau d'accès. 6 7 Selon une troisième variante, le segment embarqué transmet au segment au sol un message contenant au moins un couple constitué d'un identifiant d'un réseau d'accès de ladite pluralité et de l'adresse IP correspondante du segment embarqué pour ce réseau. Dans ce cas, le destinataire dudit message met avantageusement à jour une table de correspondance contenant pour chaque aéronef, et pour chaque réseau d'accès, l'adresse IP du segment embarqué sur ledit aéronef pour ledit réseau d'accès. Quelle que soit la variante utilisée, le segment au sol sélectionne un réseau d'accès pour transmettre un paquet IP à un segment embarqué et l'adresse destinataire de ce paquet IP est obtenue à partir de ladite table de correspondance en fonction de l'identifiant du réseau d'accès ainsi sélectionné. L'adresse destinataire dudit paquet IP est avantageusement obtenue à partir de ladite table de correspondance en fonction d'un identifiant de l'aéronef à bord duquel se trouve le segment embarqué et de l'identifiant du réseau d'accès sélectionné. Lorsque le paquet IP à transmettre au segment embarqué est émis par une application hébergée dans un calculateur au sol, le réseau d'accès utilisé pour transmettre ce paquet est sélectionné en fonction du profil de routage de ladite application. Le profil de routage de ladite application peut contenir un classement des différents réseaux d'accès par degré de préférence, le réseau d'accès sélectionné correspondant alors au degré de préférence le plus 8 élevé pour lequel une adresse IP dudit réseau embarqué est présente dans la table de correspondance. BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention en référence aux figures jointes parmi lesquelles : La Fig. 1 illustre schématiquement un exemple de système de communication aéronautique connu de l'état de la technique; La Fig. 2A représente schématiquement le mode de fonctionnement sur la liaison descendante d'un système de communication aéronautique selon un mode de réalisation de l'invention; La Fig. 2B représente schématiquement le mode de fonctionnement sur la liaison montante d'un système de communication aéronautique selon un mode de réalisation de l'invention.
EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS Nous considérons à nouveau un système de communication aéronautique comprenant un segment embarqué 210, un segment au sol, 230, et une pluralité de segments air-sol, 220, constitués par différents types de support de transmission tels que SATCOM, HF, VDL, GPRS, UMTS, Wi-Fi, Wi-Max, la liste n'étant donnée ici qu'à titre indicatif et non exhaustif. 9 La Fig. 2A illustre le fonctionnement sur la voie descendante d'un système de communication aéronautique selon un mode de réalisation de l'invention. Les applications 211 hébergées par des calculateurs à bord de l'aéronef peuvent transmettre des données sous formes de paquets IP sur la voie descendante, par exemple le centre de traitement de données de la compagnie aérienne 235. Après que les communications ont été établies via les différents supports de transmission 220, le routeur d'interface 215, autrement dit le segment embarqué ou l'aéronef, possède une adresse IP par réseau d'accès comme décrit plus haut. Pour chaque réseau d'accès, une adresse IP est attribuée à l'interface du routeur connectée à ce réseau, lors de l'établissement de la connexion. On effectue ensuite une association entre chaque réseau d'accès et l'adresse IP ainsi attribuée. Chaque réseau d'accès étant caractérisé par un identifiant unique, cette association se traduit par un couple (identifiant de réseau d'accès, adresse IP du routeur d'interface sur ce réseau), noté (id(accnet),IPadd) . L'identifiant peut être une série de caractères alphanumériques et l'adresse IP correspondante peut être codée selon le format IPv6 ou le format IPv4. Les couples (id(accnet),IPadd) sont de préférence stockés dans une première table de correspondance 219, à laquelle peut accéder le contrôleur 217. On comprendra que le routeur d'interface, autrement dit le segment embarqué, dispose d'autant d'adresses IP qu'il utilise de réseaux d'accès sur la liaison descendante. Selon le principe de l'invention, 10 le segment embarqué transmet au segment au sol une information d'association entre au moins un réseau d'accès et l'adresse IP de l'aéronef pour ce réseau. Cette information peut être transmise de différentes manières : Selon une première variante utilisant le protocole IPv6, les paquets IP transmis sur la liaison descendante peuvent contenir dans le champ « Flow label » de leur entête, l'identifiant du réseau d'accès sur lequel ils sont transmis. On rappelle que le protocole IPv6 a été spécifié dans le document RFC 2460. Les entêtes des paquets IP conformes à ce protocole comprennent un champ de référence de flux, dénommé « Flow Label », dont on pourra trouver les spécifications dans le document RFC 3697. Le champ « Flow Label » est destiné à indiquer le flux auquel appartient le paquet. Plus précisément, pour un paquet donné, on peut identifier le flux auquel il appartient à partir de l'adresse source du paquet, de son adresse de destination ainsi que de la référence du flux, informations toutes trois présentes dans l'entête d'un paquet IPv6. Le champ « Flow Label » peut être renseigné par le contrôleur 217. Par exemple, si une application doit utiliser le réseau SATCOM pour transmettre un message au sol, les paquets IP transportant ce message comprendront tous dans le champ « Flow Label », l'identifiant Id(SATCOM). L'adresse IP source de ces paquets sera par exemple de la forme router address:calculator address, où « router address:0 » est l'adresse IP du routeur d'interface sur le réseau d'accès et 11 « calculator address » est le suffixe donnant l'adresse du calculateur hébergeant l'application. Le destinataire de ces paquets sera donc à même d'associer l'adresse de l'aéronef « router address:0 » au réseau SATCOM. Selon une seconde variante, les paquets IP transmis sur la liaison descendante peuvent contenir un entête spécifique. L'entête IPv6 de ces paquets comprend en effet un champ dénommé « Next-Header » pointant vers l'entête suivant, relatif à un protocole encapsulé dans la charge utile du paquet, cf. RFC 3697 précité. Il est proposé ici de définir comme entête suivant, un entête spécifique indiquant que le PDU (Protocol Data Unit) de ce protocole contient l'identifiant du réseau d'accès utilisé par le paquet. A partir du contenu du paquet, on peut alors associer le réseau d'accès à l'adresse IP du segment embarqué (c'est-à-dire de l'aéronef) et mettre à jour la table de correspondance 239.
Dans les deux variantes précédentes, l'information d'association entre le réseau d'accès et l'adresse IP du segment embarqué est typiquement transmise par chaque paquet IP. On comprendra cependant qu'elle peut être transmise par certains paquets seulement. Selon une troisième variante, pouvant être employée aussi bien pour le protocole IPv4 que le protocole IPv6, l'information d'association est transmise au moyen d'un message spécifique d'association. Ce message spécifique contient de préférence un couple constitué de l'identifiant d'un réseau d'accès De préférence, ce message est transmis lorsque le routeur d'interface se connecte à un réseau d'accès. Il peut ensuite être transmis à intervalles réguliers pour indiquer au destinataire que cette association est toujours valide. Le message peut être envoyé en mode multicast à un ensemble prédéterminé de destinataires tels que le centre opérationnel de la compagnie ou des contrôleurs aériens. A la réception du message, l'information d'association permet de mettre à jour la table de correspondance 239. Quelle que soit la variante envisagée, le segment au sol peut ainsi savoir quel réseau d'accès correspond 15 telle ou telle adresse IP de l'aéronef. Dans l'exemple représenté en Fig. 2, des paquets IP issus d'une application embarquée sont transmis au centre opérationnel de la compagnie aérienne (AOC). L'information d'association reçue de l'aéronef est 20 utilisée pour mettre à jour la table de correspondance 239. Cette table contient, pour chaque réseau d'accès, l'adresse IP correspondante de l'aéronef. En règle générale, le centre opérationnel gère simultanément un grand nombre d'aéronefs et la table comprend par 25 conséquent, pour chacun d'entre eux, une liste de réseaux d'accès avec les adresses IP correspondantes. Par exemple, chaque enregistrement de la table de correspondance 239 pourra avoir la forme suivante : 30 lid(aircraft)lid(acc _ net)IIP _ add 13 dans lequel id(aircraft) est l'identifiant d'un aéronef de la compagnie, id(accnet) est l'identifiant d'un réseau d'accès et IP add est l'adresse IP permettant d'accéder audit aéronef via ledit réseau d'accès.
Cette table de correspondance peut être mise à jour à la réception de chaque paquet IP reçu d'un aéronef, dans le cas des première et seconde variantes, la mise à jour pouvant alors être effectuée directement par une primitive de la couche réseau. En revanche, dans le cas de la troisième variante, la mise à jour est effectuée sur réception d'un message spécifique d'association par la couche applicative, une information d'association étant considérée comme valide tant qu'elle n'a pas été mise à jour par un tel message spécifique. La Fig. 2B illustre le fonctionnement sur la voie montante d'un système de communication aéronautique selon un mode de réalisation de l'invention. On suppose que la seconde table de correspondance 239 a été préalablement constituée et mise à jour, comme indiqué plus haut. On suppose également que le centre opérationnel comprend une seconde base de données 233 dans laquelle sont stockés les profils de routage. Un profil de routage, relatif à une application donnée ou à un type de message, donne les différents types de réseaux d'accès qui peuvent être empruntés par l'application (ou pour le message) ainsi que, le cas échéant, leurs degrés de préférence respectifs.
Lorsqu'une application hébergée par le centre opérationnel doit transmettre un message à une 14 application de l'aéronef, l'adresse IP destinataire est sélectionnée en fonction d'un profil de routage stocké dans une base de données 233 et de la seconde table de correspondance 239. Cette adresse IP peut être sélectionnée par le calculateur hébergeant l'application en question. Alternativement, le calculateur peut n'avoir accès qu'à une adresse générique de l'aéronef et le contrôleur 237 y substitue l'adresse IP la plus appropriée, à partir du profil de routage de l'application et des enregistrements relatifs à cet aéronef stockés dans la seconde table de correspondance. Par exemple, si une application doit transmettre un fichier important et à faible priorité à l'aéronef, le profil de routage stocké dans la base 233 pourra indiquer une préférence pour l'utilisation du réseau GPRS. Si la seconde table de correspondance comporte un enregistrement pour cet aéronef avec une adresse IP via le réseau GPRS, ce qui pourra être le cas par exemple si l'aéronef est stationné au sol, l'adresse IP choisie sera celle figurant dans cet enregistrement. A l'inverse, si le message est prioritaire, le profil de routage stocké dans la base 233 pourra indiquer une préférence pour l'utilisation du réseau SATCOM. L'adresse IP choisie sera alors celle figurant dans l'enregistrement relatif à cet aéronef et au réseau SATCOM dans la seconde table de correspondance. On comprend ainsi que, grâce à l'invention, les supports de transmission peuvent être utilisés de manière sélective sur la voie montante, en fonction de critères de coût, de débit, de fiabilité, de disponibilité, etc. de la même façon que sur la voie descendante.

Claims (10)

  1. REVENDICATIONS1. Méthode de transmission de données, sous forme de paquets IP, entre un segment de système de communication embarqué à bord d'un aéronef (210) et un segment au sol (230), au moyen d'une pluralité de réseaux d'accès (220), ledit segment embarqué étant connecté à ladite pluralité de réseaux d'accès et possédant une même pluralité d'adresses IP, chaque adresse IP correspondant à un réseau d'accès, caractérisée en ce qu'une information d'association entre au moins un réseau d'accès et ladite adresse IP correspondante est transmise par le segment embarqué au segment au sol.
  2. 2. Méthode de transmission de données selon la revendication 1, caractérisée en ce que les paquets IP sont conformes au protocole IPv6 et que le champ « Flow Label » d'au moins un paquet IP contient un identifiant du réseau d'accès sur lequel il est transmis.
  3. 3. Méthode de transmission de données selon la revendication 1, caractérisée en ce que les paquets IP sont conformes au protocole IPv6 et que le champ « Next Header » d'au moins un paquet IP contient un pointeur vers un entête spécifique d'un protocole encapsulé dans la charge utile dudit paquet IP, ledit entête spécifique étant suivi par un identifiant du réseau d'accès sur lequel ledit paquet IP est transmis. 17
  4. 4. Méthode de transmission de données selon la revendication 2 ou 3, caractérisée en ce que le destinataire dudit paquet IP met à jour une table de correspondance (239) contenant pour chaque aéronef, et pour chaque réseau d'accès, l'adresse IP du segment embarqué sur ledit aéronef pour ledit réseau d'accès.
  5. 5. Méthode de transmission de données selon la revendication 1, caractérisée en ce que le segment embarqué transmet au segment au sol un message contenant au moins un couple constitué d'un identifiant d'un réseau d'accès de ladite pluralité et de l'adresse IP correspondante du segment embarqué pour ce réseau.
  6. 6. Méthode de transmission de données selon la revendication 5, caractérisée en ce que le destinataire dudit message met à jour une table de correspondance (239) contenant pour chaque aéronef, et pour chaque réseau d'accès, l'adresse IP du segment embarqué sur ledit aéronef pour ledit réseau d'accès.
  7. 7. Méthode de transmission de données selon la revendication 4 ou 6, caractérisée en ce que le segment au sol sélectionne un réseau d'accès pour transmettre un paquet IP à un segment embarqué et que l'adresse destinataire de ce paquet IP est obtenue à partir de ladite table de correspondance en fonction de l'identifiant du réseau d'accès ainsi sélectionné.
  8. 8. Méthode de transmission de données selon la revendication 7, caractérisée en ce que l'adresse 18 destinataire dudit paquet IP est obtenue à partir de ladite table de correspondance en fonction d'un identifiant de l'aéronef à bord duquel se trouve le segment embarqué et de l'identifiant du réseau d'accès sélectionné.
  9. 9. Méthode de transmission de données selon la revendication 7 ou 8, caractérisée en ce que ledit paquet IP à transmettre au segment embarqué est émis par une application hébergée dans un calculateur au sol, et que le réseau d'accès utilisé pour transmettre ce paquet est sélectionné en fonction du profil de routage de ladite application.
  10. 10. Méthode de transmission de données selon la revendication 9, caractérisée en ce que le profil de routage de ladite application contient un classement des différents réseaux d'accès par degré de préférence, le réseau d'accès sélectionné correspondant au degré de préférence le plus élevé pour lequel une adresse IP dudit réseau embarqué est présente dans la table de correspondance.
FR1154496A 2011-05-24 2011-05-24 Methode de transmission sur la liaison montante d'un aeronef. Active FR2975851B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR1154496A FR2975851B1 (fr) 2011-05-24 2011-05-24 Methode de transmission sur la liaison montante d'un aeronef.
US13/477,301 US20120303747A1 (en) 2011-05-24 2012-05-22 Transmission method on the uplink of an aircraft
CN2012101629261A CN102801607A (zh) 2011-05-24 2012-05-23 飞行器的上行链路上的传输方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1154496A FR2975851B1 (fr) 2011-05-24 2011-05-24 Methode de transmission sur la liaison montante d'un aeronef.

Publications (2)

Publication Number Publication Date
FR2975851A1 true FR2975851A1 (fr) 2012-11-30
FR2975851B1 FR2975851B1 (fr) 2013-07-05

Family

ID=44897868

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1154496A Active FR2975851B1 (fr) 2011-05-24 2011-05-24 Methode de transmission sur la liaison montante d'un aeronef.

Country Status (3)

Country Link
US (1) US20120303747A1 (fr)
CN (1) CN102801607A (fr)
FR (1) FR2975851B1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10217111B2 (en) * 2013-01-29 2019-02-26 Genesys Telecommunications Laboratories, Inc. System and method for in-air customer service
CN104426794B (zh) * 2013-08-23 2018-06-26 华为技术有限公司 一种报文转发方法及装置
EP3417574A1 (fr) * 2016-02-18 2018-12-26 Alcatel Lucent Transmission de données
CN106789463A (zh) * 2016-12-16 2017-05-31 华中科技大学 一种基于无人机IPv6化的传感数据接入传输系统及方法
US10798033B2 (en) * 2017-03-29 2020-10-06 Honeywell International Inc. Processing messages for an application running on a computer external to a communications management unit (CMU)
US11551557B2 (en) * 2018-11-13 2023-01-10 Honeywell International Inc. Vehicle multi-communication message type communication system
CN110635837B (zh) * 2019-09-23 2022-04-26 中电科航空电子有限公司 一种支持多种网络传输地空数据的系统及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1898557A1 (fr) * 2006-09-08 2008-03-12 Research In Motion Limited Procédé et dispositif pour transmettre des messages par plusieurs modes de transmission
US20080232280A1 (en) * 2007-03-19 2008-09-25 Electronics And Telecommunications Research Institute Registration method of multiple care-of address
US20090116463A1 (en) * 2005-07-08 2009-05-07 Matsushita Electric Industrial Co., Ltd. Mobile node and communication control method
WO2010043247A1 (fr) * 2008-10-14 2010-04-22 Nokia Siemens Networks Oy Procédé et dispositif permettant de définir une description de flux de données dans un réseau

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IES20040347A2 (en) * 2004-05-18 2005-11-30 Flightman Res Ltd A method for bi-directional exchange of data based on user-defined policies for the selection of a preferred datalink
US8179784B2 (en) * 2004-07-16 2012-05-15 Hewlett-Packard Development Company, L.P. Method and apparatus for recovering a communications connection
US7512714B2 (en) * 2004-08-31 2009-03-31 Honeywell International Inc. System and method for transmitting ACARS messages over a TCP/IP data communication link
WO2007149024A1 (fr) * 2006-06-20 2007-12-27 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et arrangement pour assurer la cohérence des préfixes parmi plusieurs routeurs mobiles
US7729263B2 (en) * 2007-08-08 2010-06-01 Honeywell International Inc. Aircraft data link network routing
FR2920622B1 (fr) * 2007-09-03 2010-03-12 Airbus France Methode de transmission de messages acars sur ip.
FR2922397B1 (fr) * 2007-10-11 2010-01-08 Airbus France Systeme de routage acars par profil de routage
US8190147B2 (en) * 2008-06-20 2012-05-29 Honeywell International Inc. Internetworking air-to-air network and wireless network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090116463A1 (en) * 2005-07-08 2009-05-07 Matsushita Electric Industrial Co., Ltd. Mobile node and communication control method
EP1898557A1 (fr) * 2006-09-08 2008-03-12 Research In Motion Limited Procédé et dispositif pour transmettre des messages par plusieurs modes de transmission
US20080232280A1 (en) * 2007-03-19 2008-09-25 Electronics And Telecommunications Research Institute Registration method of multiple care-of address
WO2010043247A1 (fr) * 2008-10-14 2010-04-22 Nokia Siemens Networks Oy Procédé et dispositif permettant de définir une description de flux de données dans un réseau

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
EDDY VERIZON W IVANCIC NASA T DAVIS BOEING W: "Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks; rfc5522.txt", NETWORK MOBILITY ROUTE OPTIMIZATION REQUIREMENTS FOR OPERATIONAL USE IN AERONAUTICS AND SPACE EXPLORATION MOBILE NETWORKS; RFC5522.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWIT, 1 October 2009 (2009-10-01), XP015065691 *
LARSSON H LEVKOWETZ H MAHKONEN T KAUPPINEN ERICSSON C: "A Filter Rule Mechanism for Multi-access Mobile IPv6; draft-larsson-monami6-filter-rules-02.txt", 5. JCT-VC MEETING; 96. MPEG MEETING; 16-3-2011 - 23-3-2011; GENEVA;(JOINT COLLABORATIVE TEAM ON VIDEO CODING OF ISO/IEC JTC1/SC29/WG11AND ITU-T SG.16 ); URL: HTTP://WFTP3.ITU.INT/AV-ARCH/JC TVC-SITE/- 17/03/2011, INTERNET ENGINEERING TASK FORCE, IETF, no. 2, 5 March 2007 (2007-03-05), XP015050112, ISSN: 0000-0004 *
LARSSON M ERIKSSON ERICSSON RESEARCH K MITSUYA KEIO UNIVERSITY K TASAKA KDDI R&D LAB R KUNTZ LOUIS PASTEUR UNIVERSITY C: "Flow Distribution Rule Language for Multi-Access Nodes; draft-larsson-mext-flow-distribution-rules-01.txt", FLOW DISTRIBUTION RULE LANGUAGE FOR MULTI-ACCESS NODES; DRAFT-LARSSON-MEXT-FLOW-DISTRIBUTION-RULES-01.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, no. 1, 14 July 2008 (2008-07-14), XP015059392 *
SOLIMAN ELEVATE TECHNOLOGIES G TSIRTSIS QUALCOMM N MONTAVONT IT/TB G GIARETTA QUALCOMM K KULADINITHI UNIVERSITY OF BREMEN H: "Flow Bindings in Mobile IPv6 and Nemo Basic Support; draft-ietf-mext-flow-binding-02.txt", FLOW BINDINGS IN MOBILE IPV6 AND NEMO BASIC SUPPORT; DRAFT-IETF-MEXT-FLOW-BINDING-02.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, vol. mext, no. 2, 28 April 2009 (2009-04-28), XP015062253 *

Also Published As

Publication number Publication date
US20120303747A1 (en) 2012-11-29
CN102801607A (zh) 2012-11-28
FR2975851B1 (fr) 2013-07-05

Similar Documents

Publication Publication Date Title
FR2975851A1 (fr) Methode de transmission sur la liaison montante d'un aeronef.
EP3782337B1 (fr) Maintien et distribution d'état en raison de défaillances temporaires dans un réseau à largeur de bande partagée
CA2698870C (fr) Routeur acars pour applications avioniques distantes
EP2188954B1 (fr) Méthode de transmission de messages acars sur ip.
EP3427449B1 (fr) Sélection d'une instanciation de tranche de réseau pour la transmission de paquets montants
WO2017220892A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
WO2017220893A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3387862A1 (fr) Dispositif et procede de communication sans-fil dans un reseau ip
FR3038476A1 (fr) Procede d' optimisation de la charge d' un concentrateur de connexions reseau
WO2014184050A1 (fr) Procede et dispositif de selection d'interface de communication
EP3503499B1 (fr) Procédé d'optimisation de l'efficacité spectrale dans un contexte d'interconnexion mpls
CN100456716C (zh) 一种虚拟私有网上的数据传输方法
EP2399406B1 (fr) Procédé de commutation de noeud d'accès
KR101445047B1 (ko) 토폴로지 서버의 지원으로 통신 아키텍처에 분산된 노드의 네트워크에 대한 기밀 또는 보호 액세스
FR2794597A1 (fr) Procede de recherche automatique par un aeronef d'une adresse de communication d'une entite au sol d'un reseau atn
Ekici et al. Network layer integration of terrestrial and satellite IP networks over BGP-S
EP2890026B1 (fr) Procédé de communication mis en oeuvre par un noeud de relais
EP2206384B1 (fr) Procede de commutation de noeud d'acces
EP2232816A1 (fr) Gestion d'une communication dans un reseau heterogene
EP3160188B1 (fr) Procédé de communication avec calcul de chemin à partir de réseaux élémentaires, programme d'ordinateur, noeud d'interconnexion et poste de radiocommunication associés
WO2023275490A1 (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
CN115765836A (zh) 基于隧道封装多星座互联路由架构的星座网络融合方法

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7