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.

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)
• Computer Security & Cryptography (AREA)
• Telephonic Communication Services (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=8859132

Family Applications (1)

Country Status (4)

Families Citing this family (24)

Family Cites Families (7)

• 2001
  • 2001-01-23 FR FR0100877A patent/FR2819964B1/fr not_active Expired - Fee Related
• 2002
  • 2002-01-22 EP EP02700365A patent/EP1266509A1/de not_active Withdrawn
  • 2002-01-22 WO PCT/FR2002/000256 patent/WO2002060155A1/fr not_active Application Discontinuation
  • 2002-01-22 US US10/221,181 patent/US6965771B2/en not_active Expired - Fee Related

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events