EP1266509A1 - Procede de selection des applications activables au travers d'un reseau de communication aeronautique civil - Google Patents

Procede de selection des applications activables au travers d'un reseau de communication aeronautique civil

Info

Publication number
EP1266509A1
EP1266509A1 EP02700365A EP02700365A EP1266509A1 EP 1266509 A1 EP1266509 A1 EP 1266509A1 EP 02700365 A EP02700365 A EP 02700365A EP 02700365 A EP02700365 A EP 02700365A EP 1266509 A1 EP1266509 A1 EP 1266509A1
Authority
EP
European Patent Office
Prior art keywords
remote
availability
local
applications
atc
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
Application number
EP02700365A
Other languages
German (de)
English (en)
Inventor
Nicolas Thales Intellectual Property ROSSI
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.)
Thales SA
Original Assignee
Thales SA
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 Thales SA filed Critical Thales SA
Publication of EP1266509A1 publication Critical patent/EP1266509A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/18502—Airborne stations
    • H04B7/18506—Communications with or from aircraft, i.e. aeronautical mobile service
    • H04B7/18508—Communications with or from aircraft, i.e. aeronautical mobile service with satellite system used as relay, i.e. aeronautical mobile satellite service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4535—Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers
    • 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/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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]

Definitions

  • the present invention relates to the management of communications other than those dedicated to air traffic control, exchanged between an aircraft and the ground.
  • ATN civil aeronautical communication network
  • the aeronautical telecommunication network ATN which is being gradually implemented on the surface of the globe, is a general purpose digital data transmission network, dedicated to the routing of all the information that aircraft are likely to to exchange with the ground in the near future.
  • ATC air traffic control
  • non-ATC such as, for example, those called AAC (acronym taken from the Anglo-Saxon:” Aeronautical Administrative Communications ")
  • AOC acronym taken from the Anglo-Saxon: “Airline Operation Control” coming from technical operation of the aircraft such as aircraft consumption and various maintenance information and that known as APC (acronym taken from the
  • the ICAO recommendations set out in detail, in a binding manner, the method of managing communications through the aeronautical telecommunication network ATN, essentially, addressing, establishing, maintaining and completing a communication , and so-called "ATC" applications fulfilling tasks involving the exchange of ATC type information through the ATN aeronautical network.
  • ATC automatic time division multiple access
  • non-ATC non-ATC applications fulfilling tasks not involving the exchange of ATC-type information through the aeronautical ATN telecommunications network.
  • These non-ATC applications are left to the initiative of each participant, the only constraint being compliance with the communication management method imposed for the establishment, maintenance and completion of a communication through the aeronautical network of ATN telecommunications.
  • non-ATC applications are therefore developed by the participants, in practice the airlines, according to their own needs, without concern for standardization, other than that of respecting the imposed method of management of communications within the aeronautical telecommunication network ATN. .
  • reliability being less critical than in the case of ATC applications, non-ATC applications are not developed with the same rigor, in particular methodological, as ATC applications, which still works against their standardization.
  • vain call attempts unnecessarily occupy the air / ground communication resources of the ATN aeronautical telecommunications network and can prove to be costly for the parties involved, the aeronautical telecommunications network being billed not only for the number of data actually transmitted but also for each request. of connection.
  • the present invention aims to limit the costs associated with the use of the aeronautical telecommunication network and the load of this network, the capacities of which will never be unlimited, by preventing non-ATC applications from attempting connections through the network.
  • aeronautical telecommunications doomed from the outset to failure, due to the temporary or permanent inability of the recipient to perform the requested task because they do not have, temporarily or permanently, the appropriate application.
  • the local availability table is reset when the connection terminal in question is started up.
  • the updating of the local availability table is done as a function of the malfunction alarms and of the notices of end of non-availability generated by the local non-ATC applications.
  • the updating of the local availability table is done systematically and periodically.
  • the remote availability table is reset when the connection terminal in question is started up, with content obtained by remote copying of the contents of the local availability tables of remote terminals for connection to the aeronautical telecommunications network listed beforehand.
  • the remote availability table is reset when the terminal in question is started up, with a default content which reflects the theoretical availability of non-ATC remote applications of remote terminals listed beforehand and which is updated by interrogating the remote terminals taken into account on the differences between the real and theoretical content of their local availability tables.
  • the means for consulting the local availability table are sensitive to at least two types of requests from a remote terminal, a general request on the overall content of their local availability table and a specific request on the differences. between the actual contents of their local availability table and those theoretical or previously notified.
  • the remote availability table is reset when the terminal in question is started up, by remote copying of the contents of the local availability tables from a pre-established list of remote terminals and updated by periodically interrogating the remote terminals for content. from their local availability tables.
  • a connection terminal to the aeronautical telecommunication network in the presence of a change of availability state of one of its non-ATC applications, warns of this change of availability state all the remote connection terminals referenced in its remote availability table to match their remote availability tables.
  • the terminal for connection to the aeronautical telecommunications network contains an automatic microprocessor ensuring communication management under the control of various specialized software modules called depending on the nature of the task to be performed: CMA software module for initialization, maintenance and completion of application communication, SN-SME software module for maintenance and completion of a connection within the aeronautical telecommunications network, IRDP software module for routing a communication, ATC Apps software module for executing ATC preloaded applications and non-ATC Apps software modules for l execution of preloaded non-ATC applications, the means of consulting the remote availability table and updating the local and remote availability tables consist of said microprocessor-based controller operating under the control of a specific validation software module call, which manages the means of consultation and updating of the local availability tables and remote, intercepts connection requests from local non-ATC applications and checks the availability of their correspondent before authorizing further processing.
  • CMA software module for initialization, maintenance and completion of application communication
  • SN-SME software module for maintenance and completion of a connection within the aeronautical telecommunications
  • the call validation software module monitors the freshness of the information contained in the local and remote availability tables and updates them as soon as they reach an arbitrarily fixed expiration date.
  • FIG. 1 shows the aeronautical telecommunication network ATN
  • FIG. 2 shows diagrammatically a first example of an on-board router of an aeronautical telecommunication network ATN implementing the invention
  • FIG. 3 shows, in the form of a flowchart, an example of a method for validating a call address.
  • the ATN aeronautical telecommunications network aims to provide reliable, high-speed digital ground-to-shore links for exchanges of information between aircraft on the ground or in flight and centers on the ground, whether these centers are assigned to an air traffic control activity, the information exchanged with the air traffic control authorities being called ATC, or to a flight operation activity the aircraft or flight, the information exchanged with the company or companies operating the aircraft which can be very diverse being said to be non-ATC, the distinction between the two types of information being justified by different transmission constraints at the level of security and reliability.
  • the ATN aeronautical telecommunications network allows exchanges of information or dialogues between two tasks or applications carried out by remote processors, generally a processor placed on board an aircraft and a processor placed on the ground.
  • the applications that can communicate with each other by the aeronautical telecommunication network ATN are said to be ATC or non-ATC depending on the ATC or non-ATC nature of the information they exchange.
  • the aeronautical telecommunication network ATN is designed to use the various possible media for air-ground links (HF, VHF, radar mode S, UHF by satellite) and to use on the ground specialized or non-switched or switched data transmission networks. no, by cable or radio waves, relayed or not by satellite, in order to send the information transmitted to the destination.
  • the aeronautical telecommunication network ATN comprises an aerial part 1 on board each connected aircraft 2 and a land part 3.
  • the aerial part 1 is made up of various transceiver equipment on board an aircraft 2 and adapted to the different media usable for air-ground communications. These transceiver equipment and their ground correspondents constitute transmission subnetworks.
  • an aircraft 2 is shown with an aerial part 1 of the aeronautical ATN transmission network comprising several transceivers including a transceiver 10 constituting a head of VDL mode transmission subnetwork 2 operating in VHF according to a protocol specific standard, a transceiver 11 constituting a head of HF DL mode transmission subnetwork operating in HF according to another specific standardized protocol, a transceiver 12 constituting a head of mode S transmission subnetwork operating in UHF in collaboration with a secondary radar according to another protocol also standardized and a transceiver 13 constituting a sub head -AMSS communication network (abbreviation of the Anglo-Saxon "Aeronautical Mobile Satellite System”) Satcom data 3 mode operating in UHF with a satellite relay 4, according to yet another standardized protocol.
  • ATN is made up of ground routing stations 5, 6. These ground routing stations 5, 6 are equipped with ground-air communication means, HF-VHF transceivers 7, mode S radar 8, satellite communication ground station 9 , allowing them to communicate with aircraft passing in their vicinity according to one or more of the planned communication modes: Satcom Data 3 subnetwork, VDL mode 2 subnetwork, Mode S subnetwork or HF DL mode subnetwork and connected between them and at various ground centers 15, 16 interested in exchanging information with aircraft, by digital data transmission networks, specialized or not, switched or not, using cable or radio waves relayed or not by satellite.
  • non-ATC applications are not regulated and are developed by the various parties involved, in practice airlines, according to their own needs, without concern for standardization, other than that of compliance with the imposed method of communications management within the ATN aeronautical telecommunications network. Their connection requests are issued on the ATN aeronautical network without prior coordination between the edge of an aircraft and the ground.
  • a non-ATC on-board application that is to say managed from the edge of an aircraft, can send messages via the aeronautical telecommunication network, to the ground, either spontaneously or upon interrogation. from the ground. Whatever the operating mode chosen, there is no coordination and messages are sent blindly without knowing whether the recipient of the message is available, good reception being noted by the request for an acknowledgment of receipt or by execution of the requested task. As a non-ATC application relies on the availability of its correspondent, this lack of coordination can lead an application to multiply the unsuccessful transmission attempts, at least as many times as the number admitted to decree the presence of a problem in the transmission.
  • an aeronautical telecommunication network router ATN with a mechanism for validating connection requests operating by means of a database specific to the router, listing the non-ATC applications available locally and non-ATC applications available remotely, at the connection terminals of one or more privileged correspondents selected either because they are pre-selected, or because the intervener considered has already tried beforehand to enter into contact with them through the aeronautical telecommunication network, and means of keeping this database up to date.
  • FIG. 2 illustrates, schematically, an example of hardware and software architecture for an on-board router of the aeronautical telecommunication network ATN making it possible to improve the rate of connection requests which result in the use of such a validation mechanism .
  • This router consists, as usual, of a specialized computer with a central processing unit 20, a memory, and various input-output interfaces.
  • the memory has different parts, mainly:
  • a part 21 known as an ATN stack with registers the manipulation of which by the central unit 20 makes it possible to apply the transmission protocols of the ATN network as well to generate the data flow transmitted from the edge to the ground from the information to transmit and service information used for the establishment, maintenance and conclusion of a connection within the ATN network, only for the extraction of information contained in the data stream received from the ground during a connection and their redirects to the on-board equipment concerned,
  • a part 22 used for the storage of different program modules and - a part 23 used for the storage of a database on the ATN network.
  • the input-output interfaces connect the on-board router with various pieces of equipment on the aircraft, which are essentially: - the transceiver systems 25, 26, 27, 28 of the aircraft which can act as heads of sub-networks of air-ground communication for the ATN network,
  • the equipment 29 of the aircraft which can be brought to use the ATN network to exchange information with the ground, and at least one HMI man-machine interface 30 such as, for example, the MCDU ("Multipurpose Control Display Unit") ), allowing a dialogue of the on-board router with the crew of the aircraft so that the latter can give its instructions to the router and extract therefrom various information on the state of the links established through the ATN network.
  • the MCDU Multipurpose Control Display Unit
  • a management and task distribution software module 31 managing the activities of the various on-board transceivers 25, 26, 27, 28 which can serve as head of the communication sub-network,
  • CMA 32 software module responsible for initializing, maintaining and cutting a link
  • IDRP 33 software module responsible more specifically for routing
  • an “ATC apps” software module 34 responsible for carrying out tasks relating to air traffic control
  • Non-ATC Apps software modules 35 responsible for the execution of tasks relating to flight and aircraft management.
  • one of the “non-ATC apps” software modules 35 has determined the need for a connection to the ground via the ATN network, it directly calls on the ATN communication stack. for establishing the connection. The message is then relayed step by step within the network to the requested remote terminal. The success of the connection attempt depends on the availability on the remote terminal of the application with which a contact is sought. If the application is available, the message is delivered to it, if it is not, the connection attempt is a failure. In both cases, the resources of the ATN network are used, which implies a systematic use of the transmission capacities of the ATN network and a billing of a connection package regardless of the success or subsequent failure of the attempt. of connection.
  • a call validation procedure is introduced which is executed on each attempt to send a message from one of the "Non-ATC apps" modules to eliminate calls. doomed to failure.
  • This call validation procedure can be carried out by a call validation software module 36 added to the other software modules of the router.
  • the call validation software module 36 relies on two application availability tables specific to the router in question and stored in its ATN database 23, a local availability table listing the applications available locally and a remote availability table listing the applications available at the level of ATN network connection terminals, one or more privileged correspondents selected, either because they have been preselected, or because there has already been a recent attempt to connect with them through the ATN network.
  • the local availability table which lists the addresses of the applications available locally, is not used directly for the call validation software module of the router in question but allows the routers of the terminals of connection to the ATN network of the remote correspondents to supply their availability tables remote in information concerning the applications actually accessible at the level of the router considered.
  • the addresses it contains are advantageously accompanied by an update date providing information on the freshness of the information.
  • the remote availability table lists the addresses of applications considered to be effectively accessible at the level of remote terminals for connection to the ATN network with either a date of entry into the table, or the date of update which accompanied them during their extraction of a local availability table. It is consulted by the call validation software module 36 on each connection request from a “non-ATC” application.
  • the call validation software module 36 consults the remote availability table to search the latter for the actual presence of the called remote application address. If it finds this address in the remote availability table and it is accompanied by a sufficiently recent update or recognition date, it validates it and the call continues. Otherwise, it discards it and blocks the call before any attempt to connect to the ATN network.
  • the call validation software module 36 executes a waiting loop in the absence of a connection request from a non-ATC app on board. As soon as it has detected a connection request, the validation software module leaves its waiting loop and tests in 41 the presence in the remote availability table of the remote application address contained in the connection request. If the search is unsuccessful, the module invalidates the connection request. If this search is successful, it goes to a second test 42 on the update date associated with this address in the remote availability table. If the update date is too old, the module invalidates the connection request. Otherwise, it validates it. In all cases of connection request rejection, the call validation software module 36 can emit an incorrect address alarm.
  • Updating the availability tables is also a task performed by the call validation software module 36, with the aim of ensuring the validity of the information contained in its local and remote availability tables.
  • This call validation module 36 includes an updating application capable of interrogating the local availability tables of remote terminals and of responding to requests for consultation of the local availability table by remote terminals.
  • the local availability table is updated by receiving non-availability alarms as well as end of non-availability notifications from local applications, and by transferring them to the local availability table.
  • the update application can also, on its own initiative, periodically check the availability of local applications and report their results in the local availability table.
  • the application for updating the availability tables communicates these changes in information appearing in the local availability table that it manages to the remote terminals of the correspondents listed in the remote availability table of the router considered.
  • the task of updating the remote availability table is performed by periodically checking the validity dates of the information contained in the remote availability table.
  • the application for updating the availability tables comes into contact with its peer application in the remote terminals concerned to obtain from them, in return, the information contained in their local availability tables.
  • the local application for updating the availability tables can send two kinds of requests to its counterpart:
  • An application for updating the availability tables which receives one of these requests via the ATN network introduced into its remote availability table, with an update or introduction date, the information contained in the notification of the applicant. In return, it responds by providing the same information as that received from the applicant.
  • the exchange of these requests between these two entities allows them to synchronize and update their respective remote availability tables, according to the information contained in the local availability tables of their counterpart.
  • a certain number of update requests remain unsatisfied by the local application for updating the availability tables by the fact that no connection has been successfully established through the ATN network, with the peer application of the remote terminal considered. These unsatisfied update requests are recorded in a register by the local application for updating the availability tables. Once several specific connection requests have failed, the remote terminal concerned is considered to be out of service and all calls intended for it are rejected for a certain period of time.
  • the local availability table can be kept between two start-ups of the connection terminal to which it belongs or be reset each time this start-up terminal is started.
  • the remote availability table can be reset when the terminal in question is started up, with a default content which reflects the theoretical availability of non-ATC remote applications of remote terminals listed beforehand and which is updated by interrogating the terminals. taken into account on the differences between the real and theoretical contents of their local availability tables.
  • the remote availability table can be deleted when the terminal in question is started up and updated progressively, taking advantage of connection requests from local or remote non-ATC applications to interrogate the terminals that host them on the contents of their local availability tables.
  • the remote availability table can be reset when the terminal in question is started up, by remote copying of the contents of the local availability tables from a pre-established list of remote terminals and updated by periodically polling the remote terminals for content from their local availability tables.

Abstract

On propose, pour une meilleure rentabilité du réseau aéronautique de télécommunications ATN, de soumettre les demandes de connexions au travers du réseau ATN provenant d"applications non-ATC, à une validation des adresses demandées au moyen de deux tables de disponibilités maintenues à jour et placées dans le terminal hébergeant les applications sollicitant les connexions. L"une des tables concerne la disponibilité des applications locales et sert à renseigner les terminaux distants. L"autre table concerne la disponibilité des applications distantes et sert pour la validation des demandes de connexion émanant des applications locales.

Description

PROCEDE DE SELECTION DES APPLICATIONS ACTIVABLES AU TRAVERS D'UN RESEAU DE COMMUNICATION AERONAUTIQUE CIVIL
La présente invention concerne la gestion des communications autres que celles dédiées au contrôle du trafic aérien, échangées entre un aéronef et le sol.
La densification du trafic aérien, le souci permanent de maintenir et même d'accroître la sécurité ainsi que celui d'améliorer la gestion d'un vol conduisent à une demande toujours plus importante d'échanges d'informations entre un aéronef, qu'il soit en vol ou au sol, et des centres au sol. Cette demande qui est encore renforcée par une augmentation rapide des capacités de traitement d'informations des équipements embarqués à bord d'un aéronef se trouve freinée par la capacité limitée d'acheminement d'informations du réseau de radiocommunication utilisé actuellement entre les aéronefs civils et le sol. Pour supprimer ce goulot d'étranglement, l'Organisation de l'Aviation Civile Internationale a prévu le déploiement d'un nouveau réseau de communication aéronautique civil beaucoup plus performant dit "ATN" (sigle tiré de l'anglo-saxon : "Aeronautical Télécommunication Network") dont elle a défini les grandes lignes par des documents contraignants dits "recommandations".
Le réseau aéronautique de télécommunication ATN, qui est en train d'être mis progressivement en place à la surface du globe, est un réseau de transmission de données numériques à vocation généraliste, dédié à l'acheminement de toutes les informations que des aéronefs sont susceptibles d'échanger avec le sol dans un futur proche. Parmi ces informations, il est habituel de faire la distinction entre celles ressortant de l'activité du contrôle aérien dite "ATC" (sigle tiré de l'anglo-saxon :"Air Traffic Control") pour lesquels la transmission est soumise à une exigence de très grande fiabilité, et les autres dites "non-ATC comme par exemple, celles dites AAC (sigle tiré de l'anglo-saxon : "Aeronautical Administrative Communications") ressortant de l'exploitation commerciale du vol telles que la liste des passagers du vol, la liste du ravitaillement des passagers et de l'équipage, la liste des ventes hors-taxes proposées à bord, etc., celles dites AOC (sigle tiré de l'anglo-saxon : "Airline Opération Control") ressortant de l'exploitation technique de l'aéronef telles que la consommation de l'aéronef et diverses informations de maintenance et celles dites APC (sigle tiré de l'anglo-saxon : "Aeronautical Public Correspondence") ressortant du confort des passagers telles que le téléphone, les informations passagers, etc. pour lesquelles la fiabilité de la transmission est moins critique. Les recommandations de l'OACI fixent dans le détail, de manière contraignante, la méthode de gestion des communications au travers du réseau aéronautique de télécommunication ATN, essentiellement, l'adressage, l'établissement, le maintien et l'achèvement d'une communication, et les applications dites "ATC" remplissant des tâches impliquant des échanges d'informations de type ATC au travers du réseau aéronautique ATN. Par contre, elles ne s'intéressent pas aux autres applications dites "non-ATC" remplissant des tâches n'impliquant pas d'échanges d'informations de type ATC au travers du réseau aéronautique de télécommunication ATN. Ces applications non-ATC sont laissées à l'initiative de chaque intervenant, la seule contrainte étant le respect de la méthode de gestion des communications imposée pour l'établissement, le maintien et l'achèvement d'une communication au travers du réseau aéronautique de télécommunication ATN.
Les applications non-ATC sont donc développées par les intervenants, en pratique les compagnies aériennes, selon leurs besoins propres, sans souci d'uniformisation, autre que celui du respect de la méthode imposée de gestion des communications au sein du réseau aéronautique de télécommunication ATN. De plus, la fiabilité étant moins critique que dans le cas des applications ATC, les applications non-ATC ne sont pas développées avec la même rigueur, notamment méthodologique, que les applications ATC, ce qui joue encore à rencontre de leur uniformisation.
A l'heure actuelle, les messages des applications non-ATC sont émis sur le réseau aéronautique ATN sans coordination préalable entre le bord d'un aéronef et le sol. Une application "bord", c'est-à-dire gérée depuis le bord d'un aéronef, peut émettre des messages par l'intermédiaire du réseau aéronautique de télécommunication, à destination du sol, soit spontanément, soit sur interrogation depuis le sol. Quel que soit le mode de fonctionnement choisi, il n'y a pas de coordination et les messages sont émis en aveugle sans savoir si le destinataire du message est disponible, la bonne réception étant constatée par la demande d'un accusé de réception ou par l'exécution de la tâche demandée. Comme une application table sur la disponibilité de son correspondant, ce manque de coordination peut amener une application à multiplier les essais infructueux de transmission, au moins autant de fois que le nombre admis pour décréter la présence d'un problème dans la transmission, alors que toute tentative de transmission était vouée dès l'origine, à un échec du fait d'une absence du destinataire recherché, par exemple, par le fait que l'aéronef ou le centre au sol interrogé n'a jamais disposé ou ne dispose plus momentanément de l'application voulue. En effet, les degrés d'équipement des aéronefs sont très divers et les centres au sol interrogés peuvent être victimes d'indisponibilités passagères prévues ou non, de certaines de leurs applications. Ces vaines tentatives d'appel occupent inutilement les ressources de communication air/sol du réseau aéronautique de télécommunication ATN et peuvent se révéler coûteuses pour les intervenants, le réseau aéronautique de télécommunication étant facturé non seulement au nombre de données effectivement transmises mais également à chaque demande de connexion.
La présente invention a pour but de limiter les coûts liés à l'utilisation du réseau aéronautique de télécommunication et la charge de ce réseau dont les capacités ne seront jamais illimitées, en évitant que les applications non-ATC ne tentent des connexions au travers du réseau aéronautique de télécommunication vouées dès l'origine à un échec, du fait de l'incapacité temporaire ou définitive du destinataire à exécuter la tâche demandée car ne disposant pas, de manière temporaire ou définitive de l'application adéquate.
Elle a pour objet un procédé de sélection des applications activables au travers d'un réseau aéronautique de télécommunication, remarquable en ce qu'il consiste, à pourvoir le terminal de raccordement au réseau aéronautique de télécommunication d'un intervenant à des applications non-ATC, :
• de deux tables de disponibilité d'applications, l'une locale répertoriant les applications disponibles localement, au niveau du terminal de raccordement de l'intervenant et l'autre distante répertoriant les applications disponibles au niveau des terminaux de raccordement d'un ou plusieurs correspondants privilégiés retenus soit parce qu'ils sont présélectionnés, soit parce que l'intervenant a déjà tenté au préalable, d'entrer en relation avec eux au travers du réseau aéronautique de télécommunication, • des moyens de consultation de la table de disponibilité locale activés par demande d'un terminal de raccordement distant,
• des moyens de consultation de la table de disponibilité distante qui sont activés, à chaque tentative faite par une application pour se connecter au travers du réseau aéronautique de télécommunication et qui, soit autorise la connexion si le correspondant demandé est répertorié dans la table de disponibilité distante pour l'application considérée, soit la refuse si le correspondant demandé ne figure pas dans la table de disponibilité distante pour l'application considérée, • des moyens d'interrogation à distance des tables de disponibilité locale des correspondants joignables au travers du réseau aéronautique de télécommunication,
• des moyens de mise à jour de la table de disponibilité locale de l'intervenant opérant par surveillance de la disponibilité des applications possédées par l'intervenant, et
• des moyens de mise à jour de la table de disponibilité distante opérant par recopie au moins partielle des tables de disponibilité locale des correspondants en activant les moyens d'interrogation à distance.
Avantageusement, la table de disponibilité locale est réinitialisée à la mise en route du terminal de raccordement considéré.
Avantageusement, la mise à jour de la table de disponibilité locale se fait en fonction des alarmes de dysfonctionnement et des avis de fin de non-disponibilité engendrés par les applications locales non-ATC.
Avantageusement, la mise à jour de la table de disponibilité locale se fait de manière systématique et périodique. Avantageusement, la table de disponibilité distante est réinitialisée à la mise en route du terminal de raccordement considéré, avec un contenu obtenu par recopie à distance des contenus des tables de disponibilité locale de terminaux distants de raccordement au réseau aéronautique de télécommunication listés au préalable.
Avantageusement, la table de disponibilité distante est réinitialisée à la mise en route du terminal considéré, avec un contenu par défaut qui reflète les disponibilités théoriques d'applications distantes non-ATC de terminaux distants listés au préalable et qui est mis à jour en interrogeant les terminaux distants pris en compte sur les différences entre les contenus réel et théorique de leurs tables de disponibilité locale.
Avantageusement, les moyens de consultation de la table de disponibilité locale sont sensibles à au moins deux types de requêtes de la part d'un terminal distant, une requête générale sur le contenu global de leur table de disponibilité locale et une requête particulière sur les différences entre les contenus réel de leur table de disponibilité locale et ceux théoriques ou précédemment notifiés.
Avantageusement, la table de disponibilité distante est réinitialisée à la mise en route du terminal considéré, par recopie à distance des contenus des tables de disponibilité locale d'une liste préétablie de terminaux distants et mise à jour en interrogeant périodiquement les terminaux distants sur des contenus de leurs tables de disponibilité locale.
Avantageusement, un terminal de raccordement au réseau aéronautique de télécommunication, en présence d'un changement d'état de disponibilité de l'une de ses applications non-ATC, avertit de ce changement d'état de disponibilité tous les terminaux de raccordement distants référencés dans sa table distante de disponibilité pour mettre en concordance leurs tables de disponibilité distante.
Avantageusement, lorsque le terminal de raccordement au réseau aéronautique de télécommunications renferme un automate à microprocesseur assurant la gestion des communications sous le contrôle de différents modules logiciels spécialisés appelés en fonction de la nature de la tâche à effectuer : module logiciel CMA pour l'initialisation, maintien et achèvement d'une communication applicative, module logiciel SN-SME pour le maintien et l'achèvement d'une connexion au sein du réseau aéronautique de télécommunication, module logiciel IRDP pour le routage d'une communication, module logiciel Applis ATC pour l'exécution d'applications préchargées ATC et modules logiciels Applis non-ATC pour l'exécution d'applications préchargées non-ATC, les moyens de consultation de la table de disponibilité distante et de mise à jour des tables locale et distante de disponibilité sont constitués dudit automate à microprocesseur opérant sous le contrôle d'un module logiciel spécifique de validation d'appel, qui gère les moyens de consultation et de mise à jour des tables de disponibilités locale et distante, intercepte les demandes de connexion des applications locales non-ATC et vérifie la disponibilité de leur correspondant avant d'autoriser une poursuite de leur traitement.
Avantageusement, le module logiciel de validation des appels surveille la fraîcheur des informations contenues dans les tables de disponibilités locale et distante et procède à leurs mises à jour dès qu'elles atteignent une date de péremption fixée arbitrairement.
D'autres caractéristiques et avantages de l'invention ressortiront de la description ci-après d'un mode de réalisation donné à titre d'exemple. Cette description sera faite en regard du dessin dans lequel :
- une figure 1 schématise le réseau aéronautique de télécommunication ATN,
- une figure 2 schématise un premier exemple de routeur embarqué de réseau aéronautique de télécommunication ATN mettant en œuvre l'invention, et
- une figure 3 représente, sous forme d'organigramme, un exemple de méthode de validation d'une adresse d'appel.
Le réseau aéronautique de télécommunication ATN vise à assurer des liaisons numériques sol-bord, fiables et à haut débit pour des échanges d'informations entre des aéronefs au sol ou en vol et des centres au sol, que ces centres soient affectés à une activité de contrôle aérien, les informations échangées avec les autorités du contrôle aérien étant dites ATC, ou à une activité d'exploitation de l'aéronef ou du vol, les informations échangées avec la ou les compagnies exploitant l'aéronef qui peuvent être très diverses étant dites non-ATC, la distinction entre les deux types d'informations se justifiant par des contraintes de transmission différentes au niveau de la sécurité et de la fiabilité.
Comme toute liaison numérique, le réseau aéronautique de télécommunication ATN permet des échanges d'informations ou dialogues, entre deux tâches ou applications déroulées par des processeurs distants, en général un processeur placé à bord d'un aéronef et un processeur placé au sol. Les applications pouvant dialoguer entre elles par le réseau aéronautique de télécommunication ATN sont dites ATC ou non-ATC selon la nature ATC ou non-ATC des informations qu'elles échangent.
Le réseau aéronautique de télécommunication ATN est conçu pour utiliser les différents médias envisageables pour des liaisons air-sol (HF, VHF, radar mode S, UHF par satellite) et pour utiliser au sol des réseaux de transmission de données spécialisés ou non, commutés ou non, par câble ou ondes hertziennes, relayées ou non par satellite, afin de faire parvenir les informations transmises à destination.
Comme représenté à la figure 1 , le réseau aéronautique de télécommunication ATN comporte une partie aérienne 1 à bord de chaque aéronef 2 raccordé et une partie terrestre 3.
La partie aérienne 1 se compose de divers équipements émetteurs-récepteurs embarqués sur un aéronef 2 et adaptés aux différents médias utilisables pour les communications air-sol. Ces équipements émetteurs-récepteurs et leurs correspondants au sol constituent des sous- réseaux de transmission. Sur la figure 1 , est représenté un aéronef 2 avec une partie aérienne 1 de réseau aéronautique de transmission ATN comportant plusieurs émetteurs-récepteurs dont un émetteur-récepteur 10 constituant une tête de sous-réseau de transmission mode VDL 2 opérant en VHF selon un protocole spécifique normalisé, un émetteur-récepteur 11 constituant une tête de sous-réseau de transmission mode HF DL opérant en HF selon un autre protocole spécifique normalisé, un émetteur-récepteur 12 constituant une tête de sous-réseau de transmission mode S opérant en UHF en collaboration avec un radar secondaire selon un autre protocole également normalisé et un émetteur-récepteur 13 constituant une tête de sous-réseau de communication AMSS (abréviation de l'anglo-saxon " Aeronautical Mobile Satellite System ") mode Satcom data 3 opérant en UHF avec un relais satellitaire 4, selon encore un autre protocole normalisé. Ces divers émetteurs-récepteurs 10, 11 , 12, 13 peuvent présenter des parties communes de sorte que les différents sous-réseaux peuvent ne pas être tous disponibles simultanément. Ils peuvent même ne pas être présents au complet sur un aéronef, cela dépendant du degré d'équipement de l'aéronef considéré. Ils sont gérés à bord d'un aéronef par un automate 14 dit routeur qui, en plus de leur gestion, assure, par manipulation d'une pile mémoire dans laquelle transitent les données à échanger avec le sol, l'initialisation, le maintien et l'achèvement d'une communication sous le contrôle d'un module logiciel dit CMA (abréviation de l'expression anglo- saxonne " Context Management Agent "), le routage d'une communication sous le contrôle d'un module logiciel dit IDRP (abréviation de l'anglo-saxon " Inter Domain Routing Policy "), l'exécution d'applications préchargées de contrôle aérien comme la communication périodique de la position de l'aéronef au contrôle au sol sous le contrôle d'un module logiciel dit " Applis ATC " et l'exécution d'applications préchargées de gestion de flotte comme le suivi de la consommation de l'aéronef sous le contrôle d'un module logiciel dit " Applis non-ATC ". La partie terrestre du réseau aéronautique de télécommunication
ATN se compose de stations sol de routage 5, 6. Ces stations sol de routage 5, 6 sont équipées de moyens de communication sol-air, émetteurs- récepteurs HF-VHF 7, radar mode S 8, station terrestre de communication par satellite 9, leur permettant de communiquer avec les aéronefs passant dans leurs voisinages selon un ou plusieurs des modes de communication prévus : sous-réseau Satcom Data 3, sous-réseau VDL mode 2, sous-réseau Mode S ou sous-réseau mode HF DL et reliées entre elles et à divers centres au sol 15, 16 intéressés par des échanges d'informations avec les aéronefs, par des réseaux de transmission numérique de données spécialisés ou non, commutés ou non, utilisant le câble ou les ondes hertziennes relayées ou non par satellite.
A l'heure actuelle, les applications non-ATC ne sont pas réglementées et sont développées par les différents intervenants, en pratique les compagnies aériennes, selon leurs besoins propres, sans souci d'uniformisation, autre que celui du respect de la méthode imposée de gestion des communications au sein du réseau aéronautique de télécommunication ATN. Leurs demandes de connexion sont émises sur le réseau aéronautique ATN sans coordination préalable entre le bord d'un aéronef et le sol.
Une application "bord" non-ATC, c'est-à-dire gérée depuis le bord d'un aéronef, peut émettre des messages par l'intermédiaire du réseau aéronautique de télécommunication, à destination du sol, soit spontanément, soit sur interrogation depuis le sol. Quel que soit le mode de fonctionnement choisi, il n'y a pas de coordination et les messages sont émis en aveugle sans savoir si le destinataire du message est disponible, la bonne réception étant constatée par la demande d'un accusé de réception ou par l'exécution de la tâche demandée. Comme une application non-ATC table sur la disponibilité de son correspondant, ce manque de coordination peut amener une application à multiplier les essais infructueux de transmission, au moins autant de fois que le nombre admis pour décréter la présence d'un problème dans la transmission, alors que toute tentative de transmission était vouée dès l'origine, à un échec du fait d'une absence du destinataire recherché, par exemple, par le fait que l'aéronef ou le centre au sol interrogé n'a jamais disposé ou ne dispose plus momentanément de l'application voulue. En effet, les degrés d'équipement des aéronefs sont très divers et les centres au sol interrogés peuvent être victimes d'indisponibilités passagères prévues ou non, de certaines de leurs applications.
Pour une meilleure efficacité du réseau aéronautique de télécommunication ATN, il importe de limiter le plus possible les demandes de connexion infructueuses. L'utilisateur y est encouragé par le mode de facturation qui est basé non seulement sur la quantité d'informations transmises mais également sur un forfait de prise en charge à chaque demande de connexion. Il importe donc pour un utilisateur de limiter le plus possible les demandes de connexion infructueuses.
Dans ce but, on propose d'équiper un routeur de réseau aéronautique de télécommunication ATN, d'un mécanisme de validation des demandes de connexion opérant au moyen d'une base de données propre au routeur, répertoriant les applications non-ATC disponibles localement et les applications non-ATC disponibles à distance, au niveau des terminaux de raccordement d'un ou plusieurs correspondants privilégiés retenus soit parce qu'ils sont présélectionnés, soit parce que l'intervenant considéré a déjà tenté au préalable, d'entrer en relation avec eux au travers du réseau aéronautique de télécommunication, et de moyens de maintien à jour de cette base de données.
La figure 2 illustre, de manière schématique, un exemple d'architecture matérielle et logicielle pour un routeur embarqué de réseau aéronautique de télécommunication ATN permettant d'améliorer le taux des demandes de connexion qui aboutissent par l'utilisation d'un tel mécanisme de validation. Ce routeur est constitué, comme à l'habitude, d'un calculateur spécialisé avec une unité centrale 20, une mémoire, et différentes interfaces d'entrée-sortie.
La mémoire comporte différentes parties dont, principalement, :
- une partie 21 dite pile ATN avec des registres dont la manipulation par l'unité centrale 20 permet la mise en application des protocoles de transmission du réseau ATN aussi bien pour engendrer le flux de données émis du bord vers le sol à partir des informations à transmettre et des informations de service utilisées pour l'établissement, le maintien et la conclusion d'une liaison au sein du réseau ATN, que pour l'extraction des informations contenues dans le flux de données reçues du sol au cours d'une liaison et leurs redirections vers les équipements embarqués concernés,
- une partie 22 utilisée pour le stockage de différents modules de programmes, et - une partie 23 utilisée pour le stockage d'une base de données sur le réseau ATN.
Les interfaces d'entrée-sortie relient le routeur embarqué avec différents équipements de l'aéronef qui sont essentiellement : - les systèmes émetteurs-récepteurs 25, 26, 27, 28 de l'aéronef pouvant jouer le rôle de têtes de sous-réseaux de communication air-sol pour le réseau ATN,
- les équipements 29 de l'aéronef pouvant être amenés à utiliser le réseau ATN pour échanger des informations avec le sol, et - au moins une interface homme-machine IHM 30 telle que, par exemple, le MCDU ("Multipurpose Control Display Unit"), permettant un dialogue du routeur embarqué avec l'équipage de l'aéronef pour que celui-ci puisse donner ses consignes au routeur et en retirer diverses informations sur l'état des liaisons établies au travers du réseau ATN.
Parmi les modules de programmes stockés dans la partie 22 de la mémoire du routeur et exécutés en temps partagés par son unité centrale 20, on trouve classiquement :
- un module logiciel de gestion 31 et de répartition de tâches gérant les activités des différents émetteurs-récepteurs embarqués 25, 26, 27, 28 pouvant servir de tête de sous- réseau de communication,
- un module logiciel CMA 32 chargé de l'initialisation, du maintien et de la coupure d'une liaison, - un module logiciel IDRP 33 chargé plus spécifiquement du routage,
- un module logiciel "Applis ATC" 34 chargé de l'exécution de tâches relevant du contrôle aérien, et
- des modules logiciels "Applis non-ATC" 35 chargés de l'exécution de tâches relevant de la gestion du vol et de l'aéronef.
Ces différents modules logiciels ne seront pas détaillés car ils ne font pas partie de l'invention. Ils sont conçus par des spécialistes du génie logicielle en tenant compte à la fois des spécificités des équipements embarqués à bord de l'aéronef, des protocoles normalisés du réseau ATN et des desiderata des autorités de contrôle du trafic aérien et de la compagnie exploitant l'aéronef.
A l'heure actuelle, une fois qu'un des modules logiciels "Applis non-ATC" 35 a déterminé la nécessité d'une liaison avec le sol par l'intermédiaire du réseau ATN, il fait directement appel à la pile de communication ATN pour l'établissement de la liaison. Le message est alors relayé de proche en proche au sein du réseau jusqu'au terminal distant demandé. Le succès de la tentative de connexion dépend de la disponibilité sur le terminal distant de l'application avec laquelle un contact est recherché. Si l'application est disponible, le message lui est délivré, si elle ne l'est pas, la tentative de connexion est un échec. Dans les deux cas, les ressources du réseau ATN sont mises à contribution, ce qui implique une utilisation systématique des capacités de transmission du réseau ATN et une facturation d'un forfait de connexion indépendamment de la réussite ou de l'échec ultérieur de la tentative de connexion.
Lorsqu'une tentative de connexion échoue, l'application qui en est à l'origine la renouvelle généralement un certain nombre de fois, avant de renoncer. Cela peut conduire, surtout lorsque qu'une application fait appel périodiquement au même correspondant par l'intermédiaire du réseau ATN, à une occupation indue des capacités du réseau ATN et à un surcoût non négligeable pour le propriétaire de l'application, lié à cette utilisation infructueuse du réseau ATN.
Pour limiter les demandes de connexion infructueuses par l'entremise du réseau ATN, on introduit une procédure de validation des appels exécutée à chaque tentative d'émission de message de la part d'un des modules « Applis non-ATC » pour éliminer les appels voués à un échec certain. Cette procédure de validation d'appel peut être conduite par un module logiciel de validation d'appel 36 ajouté aux autres modules logiciels du routeur. Pour cette validation, le module logiciel de validation d'appel 36 s'appuie sur deux tables de disponibilité d'applications propres au routeur considéré et stockées dans sa base de données ATN 23, une table de disponibilité locale répertoriant les applications disponibles localement et une table de disponibilité distante répertoriant les applications disponibles au niveau des terminaux de raccordement au réseau ATN, d'un ou plusieurs correspondants privilégiés retenus, soit parce qu'ils ont été présélectionnés, soit parce qu'il y a déjà eu une tentative récente de connexion avec eux au travers du réseau ATN.
La table de disponibilité locale qui répertorie les adresses des applications disponibles localement, ne sert pas directement au module logiciel de validation d'appel du routeur considéré mais permet aux routeurs des terminaux de raccordement au réseau ATN des correspondants distants d'alimenter leurs tables de disponibilité distante en informations concernant les applications effectivement accessibles au niveau du routeur considéré. Les adresses qu'elle renferme sont avantageusement accompagnées d'une date de mise à jour renseignant sur la fraîcheur des informations.
La table de disponibilité distante répertorie des adresses d'applications considérées comme effectivement accessibles au niveau de terminaux distants de raccordement au réseau ATN avec, soit une date d'entrée dans la table, soit la date de mise à jour qui les accompagnait lors de leur extraction d'une table de disponibilité locale. Elle est consultée par le module logiciel de validation d'appel 36 à chaque demande de connexion de la part d'une application « non-ATC ».
Le module logiciel de validation d'appel 36 consulte la table de disponibilité distante pour rechercher dans cette dernière la présence effective de l'adresse d'application distante appelée. S'il trouve cette adresse dans la table de disponibilité distante et qu'elle est accompagnée d'une date de mise à jour ou de prise en compte suffisamment récente, il la valide et l'appel poursuit son cours. Dans le cas contraire, il l'écarté et bloque l'appel avant toute tentative de connexion avec le réseau ATN.
L'organigramme de la figure 3 illustre les principales étapes de ce processus de validation.
En 40, le module logiciel de validation d'appel 36 exécute une boucle d'attente en l'absence de demande de connexion de la part d'une appli non-ATC à bord. Dès qu'il a détecté une demande de connexion, le module logiciel de validation sort de sa boucle d'attente et teste en 41 la présence dans la table de disponibilité distante de l'adresse d'application distante contenue dans la demande de connexion. Si la recherche est vaine, le module invalide la demande de connexion. Si cette recherche est fructueuse, il passe à un deuxième test 42 sur la date de mise à jour associée à cette adresse dans la table de disponibilité distante. Si la date de mise à jour est trop ancienne, le module invalide la demande de connexion. Dans le cas contraire, il la valide. Dans tous les cas de rejet de demande de connexion, le module logiciel de validation d'appel 36 peut émettre une alarme d'adresse erronée.
La mise à jour des tables de disponibilité est également une tâche réalisée par le module logiciel de validation d'appel 36, dans le but de s'assurer de la validité des informations contenues dans ses tables de disponibilité locale et distante. Ce module de validation d'appel 36 comporte une application de mise à jour capable d'interroger les tables de disponibilité locales de terminaux distants et de répondre aux demandes de consultation de la table de disponibilité locale par des terminaux distants.
La mise à jour de la table de disponibilité locale est réalisée par réception des alarmes de non disponibilité ainsi que des avis de fin de non disponibilité des applications locales, et par leur report dans la table de disponibilité locale. L'application de mise à jour peut également, procéder, de sa propre initiative à des contrôles périodiques de disponibilité des applications locales et reporter leurs résultats dans la table de disponibilité locale. En cas d'évolution de ces disponibilités, l'application de mise à jour des tables de disponibilité communique ces changements d'informations apparus dans la table de disponibilité locale qu'elle gère aux terminaux distants des correspondants répertoriés dans la table de disponibilité distante du routeur considéré. D'autre part, la tâche de mise à jour de la table de disponibilité distante est réalisée par contrôle périodique des dates de validité des informations contenues dans la table de disponibilité distante. Dès que l'une d'entre elles arrive à une date de péremption fixée arbitrairement, l'application de mise à jour des tables de disponibilité entre en contact avec son application homologue dans les terminaux distants concernés pour obtenir de leur part, en retour, les informations contenues dans leurs tables de disponibilité locale. Une fois en communication avec son homologue du terminal distant, l'application locale de mise à jour des tables de disponibilité peut envoyer deux sortes de requêtes à son homologue :
• une requête générale contenant la recopie de sa table de disponibilité locale, si l'identifiant du terminal distant considéré n'apparaît pas dans la table de disponibilité distante ou
• une requête particulière contenant la mise à jour des seuls changements récents de sa table de disponibilité locale.
Une application de mise à jour des tables de disponibilité qui reçoit l'une de ces requêtes par l'intermédiaire du réseau ATN introduit dans sa table de disponibilité distante, avec une date de mise à jour ou d'introduction, les renseignements contenus dans la notification du demandeur. En retour, elle y répond en fournissant les mêmes renseignements que ceux reçus du demandeur. Ainsi, l'échange de ces requêtes entre ces deux entités leur permet de se synchroniser et de mettre à jour leurs tables de disponibilité distante respectives, en fonction des informations contenues dans les tables de disponibilité locales de leur homologue.
Un certain nombre de demandes de mise à jour restent insatisfaites par l'application locale de mise à jour des tables de disponibilité par le fait qu'aucune liaison n'a été établie avec succès au travers du réseau ATN, avec l'application homologue du terminal distant considéré. Ces demandes de mise à jour non satisfaites sont consignées dans un registre par l'application locale de mise à jour des tables de disponibilité . Une fois que plusieurs demandes spécifiques de connexion ont échoué, le terminal distant concerné est considéré comme hors service et tous les appels qui lui sont destinés sont rejetés pour une certaine période de temps.
Les adresses d'appel sont plus strictement contrôlées puisqu'elles sont systématiquement refusées lorsqu'elles ne figurent pas dans la table de disponibilité distante. Par contre le maintien à jour de la table de disponibilité distante pour la mise à jour des informations périmées nécessite davantage de demandes de connexion au travers du réseau ATN puisqu'il s'effectue indépendamment des liaisons établies. On peut envisager différentes variantes sans sortir du cadre de l'invention.
Ainsi, la table de disponibilité locale peut être conservée entre deux mises en route du terminal de raccordement auquel elle appartient ou être réinitialisée à chaque mise en route de ce terminal de raccordement.
La table de disponibilité distante peut être réinitialisée à la mise en route du terminal considéré, avec un contenu par défaut qui reflète les disponibilités théoriques d'applications distantes non-ATC de terminaux distants listés au préalable et qui est mis à jour en interrogeant les terminaux distants pris en compte sur les différences entre les contenus réels et théoriques de leur tables locales de disponibilité.
La table de disponibilité distante peut être effacée à la mise en route du terminal considéré et mise à jour progressivement, en profitant des demandes de connexion provenant d'applications non-ATC locales ou distantes pour interroger les terminaux qui les accueillent sur les contenus de leurs tables locales de disponibilité.
La table de disponibilité distante peut être réinitialisée à la mise en route du terminal considéré, par recopie à distance des contenus des tables de disponibilité locale d'une liste préétablie de terminaux distants et mise à jour en interrogeant périodiquement les terminaux distants sur des contenus de leurs tables locales de disponibilité.

Claims

REVENDICATIONS
1. Procédé de sélection des applications activables au travers d'un 5 réseau aéronautique de télécommunication, caractérisé en ce qu'il consiste, à pourvoir le terminal de raccordement au réseau aéronautique de télécommunication d'un intervenant à des applications non-ATC, :
• de deux tables de disponibilité d'applications, l'une locale répertoriant les applications disponibles localement, au niveau o du terminal de raccordement de l'intervenant et l'autre distante répertoriant les applications disponibles au niveau des terminaux de raccordement d'un ou plusieurs correspondants privilégiés retenus soit parce qu'ils sont présélectionnés, soit parce que l'intervenant a déjà tenté au préalable, d'entrer en 5 relation avec eux au travers du réseau aéronautique de télécommunication,
• des moyens de consultation de la table de disponibilité locale activés par demande d'un terminal de raccordement distant,
• des moyens de consultation de la table de disponibilité distante 0 qui sont activés, à chaque tentative faite par une application pour se connecter au travers du réseau aéronautique de télécommunication et qui, soit autorise la connexion si le correspondant distant demandé est répertorié dans la table de disponibilité distante pour l'application considérée, soit la 5 refuse si le correspondant distant demandé ne figure pas dans la table de disponibilité distante pour l'application considérée,
• des moyens d'interrogation à distance des tables de disponibilité locale des correspondants joignables au travers du réseau aéronautique de télécommunication, • des moyens de mise à jour de la table de disponibilité locale de l'intervenant opérant par surveillance de la disponibilité des applications possédées par l'intervenant, et
• des moyens de mise à jour de la table de disponibilité distante opérant par recopie au moins partielle des tables de disponibilité locale des correspondants en activant les moyens d'interrogation à distance.
2. Procédé selon la revendication 1 , caractérisé en ce que la table de disponibilité locale est réinitialisée à la mise en route du terminal de raccordement considéré.
3. Procédé selon la revendication 1 , caractérisé en ce que la mise à jour de la table de disponibilité locale se fait en fonction des alarmes de non disponibilité et des avis de fin de non-disponibilité engendrés par les applications locales non-ATC.
4. Procédé selon la revendication 1 , caractérisé en ce que la mise à jour de la table de disponibilité locale se fait de manière systématique et périodique.
5. Procédé selon la revendication 1 , caractérisé en ce que la table de disponibilité distante est réinialisée à la mise en route du terminal de raccordement considéré, avec un contenu obtenu par recopie à distance des contenus des tables de disponibilité locale de terminaux distants de raccordement au réseau aéronautique de télécommunication listés au préalable.
6. Procédé selon la revendication 1 , caractérisé en ce que la table de disponibilité distante est réinitialisée à la mise en route du terminal considéré, avec un contenu par défaut qui reflète les disponibilités théoriques d'applications distantes non-ATC de terminaux distants listés au préalable et qui est mis à jour en interrogeant les terminaux distants pris en compte sur les différences entre les contenus réels et théoriques de leur tables locales de disponibilité.
7. Procédé selon la revendication 1, caractérisé en ce que les moyens de consultation de la table de disponibilité locale sont sensibles à au moins deux types de requêtes de la part d'un terminal distant, une requête générale sur le contenu global de leur table de disponibilité locale et une requête particulière sur les différences entre les contenus réel et théorique de leur table de disponibilité locale.
8. Procédé selon la revendication 1 , caractérisé en ce que la table de disponibilité distante est réinitialisée à la mise en route du terminal considéré, par recopie à distance des contenus des tables de disponibilité locale d'une liste préétablie de terminaux distants et mise à jour en interrogeant périodiquement les terminaux distants sur des contenus de leurs tables locales de disponibilité.
9. Procédé selon la revendication 1, caractérisé en ce qu'un terminal de raccordement au réseau aéronautique de télécommunication, en présence d'un changement d'état de disponibilité de l'une de ses applications non-ATC, avertit de ce changement d'état de disponibilité tous les terminaux distants référencés dans sa table de disponibilité distante pour mettre en concordance leurs tables de disponibilité distantes.
10. Procédé selon la revendication 1, caractérisé en ce que, lorsque le terminal de raccordement au réseau aéronautique de télécommunications renferme un automate à microprocesseur assurant la gestion des communications sous le contrôle de différents modules logiciels spécialisés appelés en fonction de la nature de la tâche à effectuer : module logiciel CMA pour l'initialisation, le maintien et l'achèvement d'une communication applicative, module logiciel SN-SME pour le maintien et l'achèvement d'une connexion au sein du réseau aéronautique de télécommunication, module logiciel IRDP pour le routage d'une communication, module logiciel Applis ATC pour l'exécution d'applications ATC préchargées et modules logiciels Applis non-ATC pour l'exécution d'applications non-ATC, les moyens de consultation de la table distante de disponibilité et de mises à jour des tables locale et distante de disponibilité sont constitués dudit automate à microprocesseur opérant sous le contrôle d'un module logiciel spécifique de validation des appels, qui gère les moyens de consultation et de mise à jour des tables locales et distantes de disponibilité, intercepte les demandes de connexion des applications locales non-ATC et vérifie la disponibilité de leur correspondant avant d'autoriser une poursuite de leur traitement.
11. Procédé selon la revendication 1, caractérisé en ce que le module logiciel de validation des appels surveille la fraîcheur des informations contenues dans les tables locale et distante et procède à leurs mises à jour dès qu'elles atteignent une date de péremption fixée arbitrairement.
EP02700365A 2001-01-23 2002-01-22 Procede de selection des applications activables au travers d'un reseau de communication aeronautique civil Withdrawn EP1266509A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0100877A FR2819964B1 (fr) 2001-01-23 2001-01-23 Procede de selection des applications activables au travers d'un reseau de communication aeronautique civil
FR0100877 2001-01-23
PCT/FR2002/000256 WO2002060155A1 (fr) 2001-01-23 2002-01-22 Procede de selection des applications activables au travers d"un reseau de communication aeronautique civil

Publications (1)

Publication Number Publication Date
EP1266509A1 true EP1266509A1 (fr) 2002-12-18

Family

ID=8859132

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02700365A Withdrawn EP1266509A1 (fr) 2001-01-23 2002-01-22 Procede de selection des applications activables au travers d'un reseau de communication aeronautique civil

Country Status (4)

Country Link
US (1) US6965771B2 (fr)
EP (1) EP1266509A1 (fr)
FR (1) FR2819964B1 (fr)
WO (1) WO2002060155A1 (fr)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0761340A (ja) * 1993-08-25 1995-03-07 Nippon Denshi Kogyo Kk Ａｂｓ装置に於ける制御点検出法
US7489927B2 (en) * 2002-05-24 2009-02-10 Alcatel-Lucent Usa Inc. Method and system for object tracking and communication
US7797744B2 (en) 2002-06-17 2010-09-14 At&T Intellectual Property Ii, L.P. Method and device for detecting computer intrusion
US7823203B2 (en) * 2002-06-17 2010-10-26 At&T Intellectual Property Ii, L.P. Method and device for detecting computer network intrusions
US7284727B2 (en) * 2003-10-01 2007-10-23 L-3 Integrated Systems Company Systems and methods for aerial dispersion of materials
FR2879052B1 (fr) * 2004-12-07 2007-02-02 Thales Sa Architecture pour simulation d'abonnes sur un reseau atn
FR2884666B1 (fr) * 2005-04-19 2007-06-22 Thales Sa Procede et dispositif de determination d'une adresse au sein d'un reseau aeronautique de telecommunication
FR2898445B1 (fr) * 2006-03-08 2008-11-14 Airbus France Sas Procede et dispositif de detection de tentatives d'intrusion sur une liaison de communication entre un aeronef et une station sol.
FR2900008B1 (fr) * 2006-04-18 2008-05-30 Airbus France Sas Procede et dispositif de communication sur une liaison de communication entre un aeronef et une station sol
US7979200B2 (en) * 2006-11-20 2011-07-12 Lockheed Martin Corporation Managing an air-ground communications network with air traffic control information
US20080154444A1 (en) * 2006-12-22 2008-06-26 Boeing Company A Corporation Of Delaware Apparatus and method for cooperative employment with installed airborne application control system
FR2920062B1 (fr) 2007-08-17 2015-01-30 Thales Sa Architecture distribuee pour l'ensemble des aides a la radionavigation
FR2926692B1 (fr) * 2008-01-23 2010-02-19 Airbus France Procedes et dispositifs pour ameliorer la fiabilite de communication entre un aeronef et un systeme distant
US7835316B2 (en) * 2008-03-26 2010-11-16 Honeywell International Inc. Method for mobile network operational state indication
US20090258643A1 (en) * 2008-04-09 2009-10-15 Honeywell International Inc. Method for accessing air traffic control communications
FR2952771B1 (fr) * 2009-11-13 2011-12-02 Thales Sa Systeme de telecommunications comprenant un noeud de communication aeroporte, noeud de communication aeroporte et noeud radio tactique
US9092611B1 (en) * 2012-06-11 2015-07-28 Rockwell Collins, Inc. Adaptive, multi-level security for flight deck applications hosted on mobile platforms
JP6095362B2 (ja) * 2012-12-27 2017-03-15 古野電気株式会社 衛星通信装置及び衛星通信システム
US9380465B2 (en) * 2013-03-14 2016-06-28 Smartsky Networks LLC Network design in wireless communications
CN104780621B (zh) * 2014-01-13 2019-04-26 联想(北京)有限公司 通信方法和电子设备
US9832269B2 (en) * 2014-10-16 2017-11-28 Netapp, Inc. Methods for migrating data between heterogeneous storage platforms and devices thereof
CN104683151B (zh) * 2015-03-02 2019-02-26 中国联合网络通信集团有限公司 宽带故障的处理方法和装置
US10243646B2 (en) 2015-08-17 2019-03-26 The Mitre Corporation Performance-based link management communications
FR3089375B1 (fr) 2018-12-04 2020-11-20 Airbus Operations Sas Procédé et système de protection d’un aéronef contre une instruction de commande incohérente

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5221635A (en) * 1991-12-17 1993-06-22 Texas Instruments Incorporated Method of making a field-effect transistor
US6185430B1 (en) * 1997-11-26 2001-02-06 Motorola, Inc. Voice call group function for a satellite based air traffic control system
FR2778046B1 (fr) * 1998-04-23 2000-05-19 Thomson Multimedia Sa Procede de gestion d'objets dans un reseau de communication et dispositif de mise en oeuvre
FR2787658B1 (fr) * 1998-12-18 2001-03-16 Sextant Avionique Procede de gestion de modes de communication pour un aeronef
DE69930918T2 (de) * 1999-01-25 2006-11-30 International Business Machines Corp. Dienstankündigungen in drahtlosen lokalen Netzen
US20020007234A1 (en) * 2000-05-05 2002-01-17 Heppe Stephen B. Apparatus and method for transitioning from a dual air/ground and ground/ground aeronautical data network architecture to an end-to-end aeronautical data network architecture
FR2814874B1 (fr) * 2000-10-03 2002-12-06 Thomson Csf Procede de selection d'une station sol au sein d'un reseau de telecommunication aeronautique

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO02060155A1 *

Also Published As

Publication number Publication date
US20030139135A1 (en) 2003-07-24
US6965771B2 (en) 2005-11-15
FR2819964B1 (fr) 2003-04-11
FR2819964A1 (fr) 2002-07-26
WO2002060155A1 (fr) 2002-08-01

Similar Documents

Publication Publication Date Title
EP1266509A1 (fr) Procede de selection des applications activables au travers d'un reseau de communication aeronautique civil
CA2234306C (fr) Systeme de liaisons de donnees entre un aeronef et le sol et procede de survie a une panne
EP1228584B1 (fr) Procede de selection d'une station sol au sein d'un reseau de telecommunication aeronautique
US8578037B2 (en) Aircraft data services
CA2698870C (fr) Routeur acars pour applications avioniques distantes
RU2474050C2 (ru) Способ и устройство управления каналами связи для обменов данными с борта летательного аппарата
EP2008376B1 (fr) Procédé et dispositif de communication sur une liaison de communication entre un aéronef et une station sol
CA2320870A1 (fr) Procede de gestion de modes de communication pour un aeronef
US20050037787A1 (en) Wireless intelligent portable-server system (WIPSS)
CN109525574B (zh) 一种跨网跨层级业务协同服务平台系统
WO2008139060A2 (fr) Systeme de communication entre un reseau d'ordinateurs dans un aeronef et un reseau d'ordinateurs au sol
WO2009047297A2 (fr) Système de routage acars par profil de routage
WO2007101945A1 (fr) Procedes et dispositifs d'emission et de reception d'un message a echanger entre un aeronef et une base au sol, et aeronef equipe de tels dispositifs
FR2884666A1 (fr) Procede et dispositif de determination d'une adresse au sein d'un reseau aeronautique de telecommunication
EP1738521A1 (fr) Systeme de controle dynamique de reseau ip
WO2023237725A1 (fr) Dispositif de communication d'un satellite permettant de communiquer avec des véhicules

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20021014

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20060801