A method for transmitting acars messages over IP, between a transmitter and a receiver, includes dividing an acars message of a first application into a plurality of blocks. For each block of the message, except for the last, a dummy acknowledgment of receipt of the block is locally sent back at the transmitter to the application. When the transmitter receives from the receiver a message indicating proper reception of the plurality of transmitted blocks, the method further includes generating an acknowledgment of receipt of the last block before sending the acknowledgement of receipt back to the application.
|
1. A method for transmitting acars messages over IP, between a transmitter and a receiver, the method comprising:
dividing an acars message transmitted by an application into a plurality of blocks;
for each block of said message, except for the last block, locally, at the transmitter, sending a dummy acknowledgment of receipt of said block back to said application; and
when the transmitter receives from the receiver a message indicating proper reception of said plurality of transmitted blocks, generating, at the transmitter, an acknowledgment of receipt of the last block before sending the acknowledgement of receipt back to said application.
2. The transmission method according to
3. The transmission method according to
4. The transmission method according to
5. The transmission method according to
6. The transmission method according to
7. The transmission method according to
8. The transmission method according to
9. The transmission method according to
10. The transmission method according to
|
The present invention generally relates to the field of aeronautical telecommunications and more particularly to that of transmitting ACARS (Aircraft Communication and Reporting System) messages.
In the aeronautical field, with the ACARS system, data may be transmitted between an aircraft and an earth-borne station, notably with exchange of information of the AOC (Aeronautical Operational Control) type with airline operators or information of the ATC (Air Traffic Control) type with air controllers. The data link between onboard and the ground is generally designated by the generic term of <<datalink>>.
The ACARS system may use several transmission media (also called media in the state of the art), or more exactly several subnetwork types for transmitting data, i.e. HF, VHF or SATCOM subnetworks. The telecommunications VHF subnetwork allows point-to-point links in direct line of site with transmitters/receivers on the ground but with a relatively reduced range. The satellite telecommunications subnetwork on the other hand provides worldwide coverage, except for the polar regions, but with high communications costs. The HF subnetwork as for it, provides coverage of the polar regions.
Generally, transmission of data to the ground is accomplished by means of an on-board telecommunications module or CMU (Communications Management Unit) which automatically selects the most suitable transmission medium (VHF, HF, SATCOM) according to a certain number of parameters.
The aforementioned communications media however begin to reach their limits in terms of access availability, even though communications with the ground require increasingly high throughputs. Further, communications costs caused by increasingly large volumes of data to be transmitted are a burden on airline budgets.
To find a remedy to this situation, certain actors in the aeronautical field have proposed the use of general public transmission media for transmitting ACARS messages. Thus, when the aircraft is parked at the boarding gate, is on the ground or in an approach phase, it may establish a connection with the air control centre or the operational centre of the airline, via a GPRS network, a Wi-Fi terminal or a Wi-Max station. Transmission of the ACARS messages is then accomplished by encapsulating them in IP datagrams as described for examples in international application WO2006/026632. This is then designated by ACARS over IP or over AoIP.
ACARS message exchange between an aircraft and the operational centre of the airline should be compliant with the ARINC 618 standard, regardless of whether these messages are encapsulated in IP datagrams or not. The ARINC 618 protocol imposes segmentation of the ACARS messages into elementary blocks of 220 useful characters and no transmission of a new block until it has received acknowledgment of the previous block. This <<stop and wait>> acknowledgment mechanism has the merit of providing great robustness but poorly lends itself to IP transmission, as this will be seen hereafter.
In the figure, the Arinc 618 application layers, the adaptation layers denoted AoIP for adaptation to the IP layer, the IP layers are illustrated both on the transmitter side and on the receiver side. The air interface between the aircraft and the ground station relaying the messages towards the centre of the airline is also illustrated.
The ACARS message M is at most segmented in n blocks B1, B2, . . . , Bn, with n≦16, each block containing at most 220 useful characters. This segmentation is carried out by the Arinc 618 layer of the transmitter. The first block B1 is first of all encapsulated by the AoIP layer in an IP datagram, noted as I(B1) before being transmitted over the air interface. The datagram is received by a ground station and routed through the Internet network as far as the IP address of the addressee. The block B1 is decapsulated from the datagram I(B1) by the AoIP layer and transmitted to the Arinc 618 layer. After checking its integrity, the Arinc 618 layer transmits an acknowledgment message ack1 (or acknowledgment of receipt, both expressions being used indifferently) which is itself encapsulated in an IP datagram by the AoIP layer. The acknowledgment message is received by the aircraft, decapsulated by the AoIP layer and then transmitted to the Arinc 618 layer. This layer may then transmit the second block B2. The process is repeated for each message block.
It is understood that the acknowledgment mechanism induced by the Arinc 618 layer is a severe penalty for the transmission rate of ACARS messages.
The object of the present invention accordingly is to propose a protocol for transmitting ACARS messages over IP which does not suffer from these throughput limitations, without however giving up the security of the transmission.
The present invention is defined by a method for transmitting ACARS messages over IP, between a transmitter and a receiver, an ACARS message transmitted by an application being divided into a plurality of blocks, in which for each block of said message, except for the last, a dummy acknowledgment of receipt of said block is sent back locally at the transmitter, to said application and, when the transmitter receives from the receiver a message indicating proper reception of said plurality of transmitted blocks, it generates an acknowledgment of receipt of the last block before sending it back to said application.
Typically, said application comprises an Arinc 618 protocol layer, said ACARS message complies with this standard and the acknowledgment of receipt is transmitted to this layer.
According to a first embodiment, the transmitter comprises a protocol adaptation layer, referred to as first adaptation layer, between the Arinc 618 protocol layer and the IP layer, said first adaptation layer sending back for each block of an ACARS message, except for the last, a dummy acknowledgment to the Arinc 618 protocol layer, and when it has received from this layer the totality of the blocks of said message, it concatenates them and encapsulates the thereby concatenated blocks in a first IP datagram.
In a symmetric way, the receiver comprises a protocol adaptation layer, referred to as second adaptation layer between the Arinc 618 protocol layer of a second application and the IP layer, said second adaptation layer being adapted for decapsulating and segmenting the useful load of said IP datagram for recovering said blocks and then providing the blocks, one by one, to the Arinc 618 protocol layer of said second application, a block being provided to it only when it has acknowledged receipt of the previous block.
Preferably, when the second adaptation layer has received the totality of the acknowledgments of receipt of said blocks, it sends back to the transmitter in a second IP datagram, an acknowledgment of receipt of the plurality of said blocks.
According to a second embodiment, the transmitter comprises a protocol adaptation layer, referred to as third adaptation layer, between the Arinc 618 protocol layer and a TCP layer on IP, said third adaptation layer sending back for each block of an ACARS message, except for the last, a dummy acknowledgment to the Arinc 618 protocol layer, and when it has received from this layer the totality of the blocks of said message, it concatenates them and encapsulates the thereby concatenated blocks in a first TCP segment.
Advantageously, the receiver comprises a protocol adaptation layer, referred to as fourth adaptation layer, between the Arinc 618 protocol layer of a second application, and the TCP layer on IP, said fourth adaptation layer being adapted for decapsulating and segmenting the useful load of said first TCP segment for recovering said blocks, and then providing the blocks one by one, to the Arinc 618 protocol layer of the second application, a block being provided to it only when it has acknowledged receipt of the previous block.
Preferably, when the fourth adaptation layer has received the totality of the acknowledgments of receipt of said blocks, it sends back to the transmitter a second TCP segment containing an acknowledgment of receipt of the plurality of said blocks as well as an acknowledgment of the first TCP segment.
According to a third embodiment, the transmitter comprises a protocol adaptation layer, referred to as fifth adaptation layer, between the Arinc 618 protocol layer and a UDP layer on IP, said fifth adaptation layer sending back for each block of an ACARS message, except for the last, a dummy acknowledgment to the Arinc 618 protocol layer, and when it has received from this layer the totality of the blocks of said message, it concatenates them and encapsulates the thereby concatenated blocks in a first UDP datagram.
Advantageously, the receiver comprises a protocol adaptation layer, referred to as sixth adaptation layer, between the Arinc 618 protocol layer of a second application, and the UDP layer, said sixth adaptation layer being adapted for decapsulating and segmenting the useful load of said first UDP datagram for recovering said blocks, and then providing the blocks one by one, to the Arinc 618 protocol layer of the second application, a block being provided to it only when it has acknowledged receipt of the previous block and in that, when the sixth adaptation layer has received the totality of the acknowledgments of receipt of said blocks, it awaits the sending of a second ACARS message to the transmitter, the acknowledgment of receipt of the plurality of said blocks being then concatenated to the blocks of the second message before being placed in a second UDP datagram.
Other features and advantages of the invention will become apparent upon reading a preferential embodiment of the invention with reference to the appended figures wherein:
We shall again consider a system for transmitting/receiving ACARS messages over IP. In order to allow better understanding of the invention, an exemplary embodiment of such a system has been illustrated in
The ACARS system over IP is divided into three segments: an on-board segment 210, a ground network segment 220, and a segment specific to the centre of the airline, 230.
The on-board segment comprises a CMU (Communications Management Unit) avionics module, 211, the structure of which is schematically illustrated in terms of protocol layers.
The CMU module harbours AOC and ATC applications respectively dedicated to exchanging data with the airline centre and with the air control centre. The data of AOC types are transmitted by means of ACARS messages via the Arinc 618 protocol layer. These messages may be sent either to a conventional transmission medium 212, for example a VHF, HF or SATCOM transmitter, or to a first conversion module 213, either included in the CMU or not. This conversion module uses a protocol adaptation layer noted as AoIP, between the Arinc 618 protocol layer of the application and the IP layer, as detailed later on.
When a conventional transmission medium is selected, the messages are transmitted to a ground station of the ACARS network. This station, 221, is equipped with a gateway 223, performing a conversion of the Arinc 618 protocol into an Arinc 620 protocol. It is recalled that the Arinc 620 standard is relative to a protocol for transmitting ACARS messages to the ground, for example between a service provider (DSP) and an operational airline centre
If the transmission over IP is selected, the ACARS messages are sent to the gateway 213, the IP datagrams containing the ACARS messages are routed via the Internet network as far as the IP address of the addressee. The link between the aircraft and the ground is accomplished via a general public telecommunications infrastructure for example the GPRS network, a Wi-Fi terminal, a WiMax station.
The segment of the airline comprises a terminal 231, a terminal comprising an Arinc 620 protocol layer adapted for receiving ACARS messages passing in transit through the conversion gateway, i.e. via the conventional transmission medium on the one hand, and a protocol layer adapted for receiving ACARS messages having been in transit via the IP network on the other hand. More specifically, the terminal 231 comprises a second conversion module 233, belonging to the adaptation layer AoIP, responsible for decapsulating the blocks and transmitting them to the ACARS layer 618 and a ACARS 618/620 protocol adaptation layer, referenced at 234. A multiplexer, 235, directs the ACARS messages according to the Arinc 620 standard towards the ports of the control applications AOC1, . . . , AOCN harboured by the terminal 231.
The invention relates to the first and second conversion modules of the AoIP layer. The general principle is to load the whole of the blocks of a message in a single IP datagram to locally simulate artificially the acknowledgments of the blocks of an ACARS message except for the one of the last block which then applies as an acknowledgment of the whole of the blocks of the message.
More specifically,
The Arinc 618 application layers, the AoIP adaptation layers, the IP layers for the on-board segment 310, and the ground segment 320 are again illustrated. The link between the on-board segment and the ground segment is achieved through an air interface and is advantageously based on a general public telecommunications infrastructure.
When an ACARS message M is to be transmitted by an application harboured by the transmitter, for example the CMU, this message is segmented into n blocks B1, . . . , Bn by the Arinc 618 layer. It will be noted that the invention is not restricted to a given number of blocks, although n≦16 in the present state of the standard.
The first block B1 is transmitted to the AoIP layer which then sends back a dummy acknowledgment , which allows the Arinc layer to transmit the second block B2. The process is iterated until transmission of the last but one block Bn-1. When the Arinc 618 layer receives the dummy acknowledgment
, it transmits the last block Bn. However, for the last block, no dummy acknowledgment is sent back. The n blocks of the message are then concatenated in order to form a composite block which is encapsulated in a single IP datagram, noted as D(B1, . . . , Bn). This datagram is then routed as far as its IP destination address. It will be understood that the IP layer of the segment 320 corresponds to standard routing on the Internet.
At the IP destination address, i.e. in practice at the centre of the airline, the AoIP decapsulates the composite block of the IP diagram, before segmenting it, for recovering the blocks B1, . . . , Bn. The first block B1 is then transmitted to the Arinc 618 application layer which then checks its integrity, and in the case of proper reception, sends an acknowledgment ack1 back to the AoIP layer. The process is successively repeated for each block. The ACARS message M is reconstructed by the Arinc 618 layer of the addressee application (for example an application of the AOC type) from blocks B1, . . . , Bn.
When the AoIP layer receives the last acknowledgment ackn, provided that it has nevertheless received beforehand the n−1 acknowledgments of the previous blocks, it transmits a composite acknowledgment message ackC meaning proper reception of the n blocks. The ackC message may simply result from the concatenation of the elementary acknowledgment messages ack1, . . . , ackn. This message is then loaded in an IP datagram, D(ackC), before being routed towards the IP address of the CMU module of the aircraft.
The AoIP layer of the CMU recovers the acknowledgment message ackC and converts it into an acknowledgment message of the last block ackn, before transmitting it to the Arinc 618 layer. The conversion of ackC into ackn may simply result from truncation of the composite message. When the Arinc 618 layer receives the last acknowledgment ackn, it considers that the message M has actually been received by the addressee.
If one of the blocks B1, . . . , Bn is corrupted or is not received by the addressee, the acknowledgment message ackC is not sent, and subsequently, the message ackn is not transmitted to the Arinc 618 layer. This layer may then decide after a predetermined waiting time, to send back the message M, i.e. the whole of the blocks B1, . . . , Bn.
In the foregoing, it was envisioned that the transmitter of the ACARS message was the CMU of the aircraft and the receiver the centre of the airline, in other words, the communication was a downward communication (downlink). It is however clear that the method applies equivalently to the upward communication (uplink) without however departing from the scope of the invention.
It will be understood that the ACARS message transmission method according to this embodiment is advantageous in that it is possible not to wait for actual acknowledgment of a block before sending the next one. Further, it will be noted that only one IP datagram is transmitted instead of n datagrams in order to transmit the message, which all the more reduces the traffic on the air interface and, possibly, the transmission costs.
The embodiment of the invention described earlier disregards the underlying transport protocol used, notably because it is connection-oriented, like TCP, or not connection-oriented, such as UDP.
We shall consider both situations successively hereafter.
This alternative does not require any modification of the TCP transport layer and therefore the layer noted as AoIP actually achieves an adaptation of the Arinc 618 application layer to the TCP transport layer. More specifically, the blocks B1, . . . , Bn delivered by the Arinc 618 layer, according to the already described dummy acknowledgment mechanism, are concatenated and encapsulated in a TCP segment. Once the TCP connection is established, the TCP segment noted as S(B1, . . . , Bn) is transmitted to the TCP socket of the addressee. Of course, transmission of the TCP segment involves incorporation into an IP datagram in a way known to the man skilled in the art.
When the TCP segment is received by the TCP socket of the addressee, an acknowledgment of receipt ack1tcp is sent back to the transmitter as provided by the TCP protocol. Delivery of the blocks of the AoIP layer to the Arinc 618 layer has already been described in connection with
When the AoIP layer has received the acknowledgments of receipt, ack1 to ackn from the Arinc 618 layer, it transmits a composite acknowledgment of receipt ackC to the TCP layer, which itself transmits it as a TCP segment noted as S(ackC), to the TCP socket of the transmitter. Upon receiving the segment S(ackC) by the TCP layer of the CMU, an acknowledgment of receipt noted as ack2tcp is then sent back to the ground, according to the TCP protocol. The acknowledgment of receipt is then converted into a message for acknowledging the last block, ackn, as already described.
This alternative allows direct implementation of the embodiment of
However, it will be noted that it requires the transmission of four other TCP segments on the air interface, i.e. S(B1, . . . , Bn), ack1tcp, S(ackC) and ack2tcp.
More specifically, the second alternative differs from the first in that the acknowledgment ack1tcp is not transmitted independently. This second alternative may be achieved by delaying the transmission of the acknowledgment of receipt of S(B1, . . . , Bn) until the TCP layer has itself received the composite acknowledgment ackC from the AoIP layer, or else, by making sure that the time Δr for processing the blocks B1, . . . , Bn by the Arinc 618 layer, in the worst case when n=16, is shorter than the time required for generating the acknowledgment of receipt. The processing time Δr may be reduced by suitable selection of the processor, by a more efficient compression algorithm (therefore reducing the number and size of the blocks), or further a faster error checking algorithm.
In any case, the composite acknowledgment ackC is transmitted with the acknowledgment of receipt of S(B1, . . . , Bn) in a single TCP segment, noted as S(ackC, ack1tcp). Upon receiving this segment by the corresponding TCP port of the CMU, an acknowledgment ack2tcp is sent back to the ground. The remainder of the acknowledgment process is identical with that of the first alternative. Eventually, only three TCP segments are in transit on the interface for a transmitted ACARS message, i.e. S(B1, . . . , Bn), S(ackC, ack1tcp) and ack2tcp.
The idea at the basis of this alternative is to await transmission of an ACARS message over the upward route in order to send back the acknowledgment of receipt of the message which has just been received over the downward route. In a symmetrical way, transmission of a message over the downward route will be awaited in order to send back the acknowledgment of receipt of the message which has just been received over the upward route. The case of a transmission of an ACARS message M on the downward route has been illustrated in
The transmission of the message M is performed as already described in
When the earth-borne airline centre transmits an ACARS message M′ over the upward route, for example as a reply to the message M, the acknowledgment of receipt ackC is loaded with the blocks of the message M′ into the UDP datagram. More specifically, the message M′ is divided into blocks B′1, . . . , B′n′ with n′≦16 by the Arinc 618 layer. The block B′1 is transmitted to the AoIP layer which sends back to it a dummy acknowledgment . The process is repeated for the following blocks except for the last for which the dummy acknowledgment is not transmitted, as this has already been seen for the downlink. When the AoIP layer is in possession of blocks B′1, . . . , B′n′, it checks whether an acknowledgment of receipt is pending. If this is the case, the acknowledgment of receipt is loaded with the blocks B′1, . . . , B′n′ in the same UDP datagram, the loading of an acknowledgment of receipt being possibly signalled in the datagram by a characteristic header.
Advantageously, a timer is loaded with a time-out period τmax when the n blocks B1, . . . , Bn have been received by the AoIP layer. If a message M′ is to be transmitted by the AoIP layer during the time-out period τmax, the acknowledgment of receipt ackC is loaded with the blocks of the message M′ as described earlier. On the other hand, if at the end of the time-out period, there is still no message M′ to be transmitted over the upward route, the acknowledgment of receipt is then sent by means of a separate UDP datagram. The time-out period may be adaptive and notably depend on the filling rate of the ACARS message transmission buffer on the downward route. Thus, for a high filling rate, the duration τmax will be selected to be relatively short so as not to delay the sending of a new message by Arinc 618 layer.
In the case illustrated in
Eventually, for a transmitted ACARS message, a single datagram passes in transit, as a general rule, over the air interface, i.e. U(e′, B1, . . . , Bn, ack′C) for the message on the downward route and U(e, B′1, . . . , B′n, ackC) for the message on the upward route.
Durand, Frederic, Gruyer, Pierre, Chaumette, Pascal, Rutschle, Yves
Patent | Priority | Assignee | Title |
10200110, | Jun 30 2016 | GE Aviation Systems LLC | Aviation protocol conversion |
10318451, | Jun 30 2016 | GE Aviation Systems LLC | Management of data transfers |
10425149, | Aug 22 2018 | Honeywell International Inc. | ACARS over IP system for non-safety messages |
10444748, | Jun 30 2016 | GE Aviation Systems LLC | In-situ measurement logging by wireless communication unit for communicating engine data |
10467016, | Jun 30 2016 | GE Aviation Systems LLC | Managing an image boot |
10470114, | Jun 30 2016 | General Electric Company; GE Aviation Systems LLC | Wireless network selection |
10529150, | Jun 30 2016 | Aviation Systems LLC | Remote data loading for configuring wireless communication unit for communicating engine data |
10681132, | Jun 30 2016 | GE Aviation Systems LLC | Protocol for communicating engine data to wireless communication unit |
10712377, | Jun 30 2016 | GE Aviation Systems LLC | Antenna diagnostics for wireless communication unit for communicating engine data |
10764747, | Jun 30 2016 | GE Aviation Systems LLC | Key management for wireless communication system for communicating engine data |
10819601, | Jun 30 2016 | GE Aviation Systems LLC | Wireless control unit server for conducting connectivity test |
10986028, | Feb 22 2017 | GE Aviation Systems LLC | Aircraft message routing system |
11003603, | Jun 30 2016 | GE Aviation Systems LLC | Management of data transfers |
11061394, | Jun 30 2016 | GE Aviation Systems LLC | In-situ measurement logging by wireless communication unit for communicating engine data |
11551557, | Nov 13 2018 | Honeywell International Inc.; Honeywell International Inc | Vehicle multi-communication message type communication system |
Patent | Priority | Assignee | Title |
6785301, | Jun 29 2000 | Cisco Technology, Inc | Method and apparatus for conducting call waiting-caller identification in a packet switched network |
20010055312, | |||
GB2433006, | |||
WO2006026632, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Sep 02 2008 | Airbus Operations | (assignment on the face of the patent) | / | |||
Apr 01 2010 | GRUYER, PIERRE | AIRBUS OPERATIONS INCORPORATED AS A SOCIETE PAR ACTIONS SIMPLIFIEE | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 024773 | /0965 | |
Apr 01 2010 | DURAND, FREDERIC | AIRBUS OPERATIONS INCORPORATED AS A SOCIETE PAR ACTIONS SIMPLIFIEE | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 024773 | /0965 | |
Apr 01 2010 | CHAUMETTE, PASCAL | AIRBUS OPERATIONS INCORPORATED AS A SOCIETE PAR ACTIONS SIMPLIFIEE | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 024773 | /0965 | |
Apr 01 2010 | RUTSCHLE, YVES | AIRBUS OPERATIONS INCORPORATED AS A SOCIETE PAR ACTIONS SIMPLIFIEE | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 024773 | /0965 |
Date | Maintenance Fee Events |
Jan 10 2013 | ASPN: Payor Number Assigned. |
Mar 31 2016 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Apr 01 2020 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Apr 03 2024 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Oct 09 2015 | 4 years fee payment window open |
Apr 09 2016 | 6 months grace period start (w surcharge) |
Oct 09 2016 | patent expiry (for year 4) |
Oct 09 2018 | 2 years to revive unintentionally abandoned end. (for year 4) |
Oct 09 2019 | 8 years fee payment window open |
Apr 09 2020 | 6 months grace period start (w surcharge) |
Oct 09 2020 | patent expiry (for year 8) |
Oct 09 2022 | 2 years to revive unintentionally abandoned end. (for year 8) |
Oct 09 2023 | 12 years fee payment window open |
Apr 09 2024 | 6 months grace period start (w surcharge) |
Oct 09 2024 | patent expiry (for year 12) |
Oct 09 2026 | 2 years to revive unintentionally abandoned end. (for year 12) |