RU2479141C2

RU2479141C2 - Способ передачи сообшений acars по протоколу ip

Info

Publication number: RU2479141C2
Application number: RU2010112708/08A
Authority: RU
Inventors: Пьер ГРЮЙЕР; Фредерик ДЮРАН; Паскаль ШОМЕТТ; Ив РЮТШЛЬ
Original assignee: Эрбюс Операсьон
Priority date: 2007-09-03
Filing date: 2008-09-02
Publication date: 2013-04-10
Also published as: RU2010112708A; EP2188954A1; CN101796771A; CN101796771B; JP2010538508A; FR2920622B1; DE602008005612D1; WO2009030681A1; BRPI0815833A2; ATE502462T1; EP2188954B1; US20110047281A1; CA2698325C; US8285865B2; CA2698325A1; FR2920622A1; JP4951766B2

Abstract

Заявленное изобретение относится к способу передачи сообщений адресно-отчетной системы авиационной связи (ACARS) по протоколу IP между передатчиком и приемником. Технический результат состоит в предложении протокола передачи, который не подвержен ограничениям скорости и не сказывается на надежности передачи. Для этого сообщение ACARS (M), передаваемое приложением, разбивают на множество блоков (B₁, B₂, …, B_n). Для каждого блока указанного сообщения, за исключением последнего, локально на уровне передатчика на указанное приложение направляют имитацию подтверждения приема

указанного блока и, когда передатчик принимает от приемника сообщение (D(ack_C), S(ack_C),

,

указывающее на нормальный прием указанного множества переданных блоков, он генерирует подтверждение приема (ack_n) последнего блока, после чего пересылает его указанному приложению. 9 з.п. ф-лы, 6 ил.

Description

Область техники

Настоящее изобретение в целом относится к области телекоммуникаций в авиации и конкретно к области передачи сообщений ACARS (Aircraft Communication and Reporting System) (Адресно-отчетная система авиационной связи).

Предшествующий уровень техники

В области авиации система ACARS позволяет передавать данные между летательным аппаратом и наземной станцией, в частности обмениваться информацией типа АОС (Aeronautical Operational Control) (Оперативное управление полетами) с операторами авиационных компаний или информацией типа АТС (Air Traffic Control) (Управление воздушным движением) с авиадиспетчерами. Линию передачи данных между бортом самолета и землей обычно называют термином "datalink".

Система ACARS может использовать несколько сред передачи (называемых также media в данной области техники) или, точнее, несколько типов подсетей ВЧ, СВЧ или SATCOM. Телекоммуникационная подсеть СВЧ обеспечивает связь типа «точка-точка» на линии прямого визирования с передатчиками/приемниками на земле, но эта связь характеризуется малой дальностью. Спутниковая телекоммуникационная подсеть SATCOM покрывает практически весь мир, за исключением полярных областей, но такая связь является дорогой. Подсеть ВЧ позволяет покрывать полярные области.

Как правило, передачу данных на землю осуществляют при помощи модуля управления связью, или CMU (Communications Management Unit), который автоматически выбирает наиболее подходящую среду передачи (СВЧ, ВЧ, SATCOM) в зависимости от определенного числа параметров.

Вместе с тем, вышеуказанные среды передачи уже начинают достигать своих пределов с точки зрения возможности свободного доступа, тогда как даже связь с землей требует все большей пропускной способности. Кроме того, стоимость связи с учетом все более значительных объемов передаваемых данных резко увеличивает статьи расходов авиационных компаний.

Чтобы исправить эту ситуацию, в области авиации было предложено использовать общедоступные среды передачи для обмена сообщениями ACARS. Так, когда летательный аппарат находится перед посадочным терминалом, на земле или даже в фазе захода на посадку, он может установить связь с центром управления полетами или с оперативным центром авиационной компании через сеть GPRS, точку доступа Wi-Fi или станцию Wi-Max. В этом случае передачу сообщений ACARS осуществляют путем их упаковки в датаграммы IP, что описано, например, в международной заявке WO 006/026632. В этом случае говорят о передаче сообщений ACARS по протоколу IP или AoIP (ACARS no IP).

Обмен сообщениями ACARS между летательным аппаратом и оперативным центром авиационной компании должен соблюдать стандарт ARINC 618 независимо от того, упакованы эти сообщения или нет в датаграммы IP. Протокол ARINC 618 предполагает разбиение сообщений ACARS на элементарные блоки из 220 полезных символов и передачу нового блока только после получения подтверждения приема предыдущего блока. Этот механизм подтверждения "stop and wait" (остановись и жди) отличается высокой надежностью, но мало подходит для передачи по IP, что будет показано ниже.

На фиг.1 схематично показана передача сообщений ACARS по протоколу IP между передатчиком (например, летательным аппаратом) и приемником (например, базой авиационной компании).

На этом чертеже, как со стороны передатчика, так и со стороны приемника, показаны прикладные уровни Arinc 618, адаптационные уровни, обозначенные AoIP и обеспечивающие адаптацию к уровню IP, уровни IP. На чертеже показано также беспроводное сопряжение между летательным аппаратом и наземной станцией, по которому проходят сообщения к центру авиационной компании.

Сообщение ACARS М разбивают максимум на n блоков В₁, В₂, …, B_n, где n≤16, при этом каждый блок максимально содержит 220 полезных символов. Это разбиение производит уровень Arinc 618 передатчика. Сначала уровень AoIP упаковывает первый блок В₁ в датаграмму IP, обозначенную I(В₁), до его передачи по беспроводному сопряжению. Наземная станция принимает датаграмму и переправляет ее через сеть Интернет на адрес IP получателя. Уровень AoIP извлекает блок B₁ из датаграммы I(B₁) и передает его на уровень Arinc 618. После проверки его целостности уровень Arinc 618 передает сообщение квитирования ack₁ (или подтверждения приема - оба выражения используют равнозначно), которое в свою очередь упаковывается в датаграмму IP уровнем AoIP. Сообщение квитирования принимается летательным аппаратом, извлекается уровнем AoIP и затем передается на уровень Arinc 618. Затем этот уровень может передавать второй блок B₁. Процесс повторяют для каждого блока сообщения.

Понятно, что механизм квитирования, используемый уровнем Arinc 618, отрицательно сказывается на скорости передачи сообщений ACARS.

В связи с этим настоящее изобретение призвано предложить протокол передачи сообщений ACARS no IP, который не подвержен этим ограничениям скорости, но, вместе с тем, не сказывается на надежности передачи.

Сущность изобретения

Объектом настоящего изобретения является способ передачи сообщений ACARS по протоколу IP между передатчиком и приемником, при этом сообщение ACARS, передаваемое приложением, разбивают на множество блоков, причем в способе для каждого блока указанного сообщения, за исключением последнего, локально на уровне передатчика направляют указанному приложению имитацию подтверждения приема указанного блока и, когда передатчик принимает от приемника сообщение, указывающее на нормальный прием указанного множества переданных блоков, передатчик генерирует подтверждение приема последнего блока, после чего пересылает его указанному приложению.

Как правило, указанное приложение содержит уровень протокола Arinc 618, при этом указанное сообщение ACARS соответствует стандарту Arinc 618, и подтверждение приема направляют на указанный уровень.

Согласно первому варианту выполнения, передатчик содержит между уровнем протокола Arinc 618 и уровнем IP уровень адаптации протокола, называемый первым адаптационным уровнем, при этом указанный первый адаптационный уровень отправляет для каждого блока сообщения ACARS, за исключением последнего, имитацию квитирования на уровень протокола Arinc 618 и после получения от уровня протокола Arinc 618 всех блоков указанного сообщения собирает их и упаковывает собранные таким образом блоки в первую датаграмму IP.

Аналогично, приемник содержит между уровнем протокола Arinc 618 второго приложения и уровнем IP уровень адаптации протокола, называемый вторым адаптационным уровнем, при этом указанный второй адаптационный уровень выполнен с возможностью извлечения и разбиения полезного содержимого указанной датаграммы IP для восстановления указанных блоков с последующим направлением блоков по одному на уровень протокола Arinc 618 указанного второго приложения, при этом блок направляют на уровень протокола Arinc 618 только после подтверждения получения им предыдущего блока.

Предпочтительно, когда второй адаптационный уровень принял все подтверждения приема указанных блоков, он направляет передатчику во второй датаграмме IP подтверждение приема множества указанных блоков.

Согласно второму варианту выполнения, передатчик содержит между уровнем протокола Arinc 618 и уровнем TCP на IP уровень адаптации протокола, называемый третьим адаптационным уровнем, при этом указанный третий адаптационный уровень отправляет для каждого блока сообщения ACARS, за исключением последнего, имитацию квитирования на уровень протокола Arinc 618, и после получения от уровня протокола Arinc 618 всех блоков указанного сообщения собирает их и упаковывает собранные таким образом блоки в первый сегмент TCP.

Приемник предпочтительно содержит между уровнем протокола Arinc 618 второго приложения и уровнем TCP уровень адаптации протокола, называемый четвертым адаптационным уровнем, при этом указанный четвертый адаптационный уровень выполнен с возможностью извлечения и разбиения полезного содержимого из указанного первого сегмента TCP для восстановления указанных блоков с последующим направлением блоков по одному на уровень протокола Arinc 618 второго приложения, при этом блок на уровень протокола Arinc 618 направляют только после подтверждения получения им предыдущего блока.

Предпочтительно, когда четвертый адаптационный уровень принял все подтверждения приема указанных блоков, он направляет в передатчик второй сегмент TCP, содержащий подтверждение приема множества указанных блоков, а также подтверждение приема первого сегмента TCP.

Согласно третьему варианту выполнения, передатчик содержит между уровнем протокола Arinc 618 и уровнем UDP на IP уровень адаптации протокола, называемый пятым адаптационным уровнем, при этом указанный пятый адаптационный уровень отправляет для каждого блока сообщения ACARS, за исключением последнего, имитацию квитирования на уровень протокола Arinc 618, и после получения от уровня протокола Arinc 618 всех блоков указанного сообщения собирает их и упаковывает собранные таким образом блоки в первую датаграмму UDP.

Приемник предпочтительно содержит между уровнем протокола Arinc 618 второго приложения и уровнем UDP уровень адаптации протокола, называемый шестым адаптационным уровнем, при этом указанный шестой адаптационный уровень выполнен с возможностью извлечения и разбиения полезного содержимого из указанной первой датаграммы UDP для восстановления указанных блоков с последующим направлением блоков по одному на уровень протокола Arinc 618 второго приложения, при этом блок на уровень протокола Arinc 618 направляют только после подтверждения получения им предыдущего блока, и, когда шестой адаптационный уровень получил все подтверждения приема указанных блоков, он ожидает отправки второго сообщения ACARS в направлении передатчика, при этом подтверждение приема множества указанных блоков соединяют с блоками второго сообщения до помещения их во вторую датаграмму UDP.

Краткое описание чертежей

Другие отличительные признаки и преимущества настоящего изобретения будут более очевидны из нижеследующего описания предпочтительного варианта выполнения изобретения со ссылками на прилагаемые чертежи, на которых:

фиг.1 - схема протокола передачи сообщений ACARS no IP согласно предшествующему уровню техники;

фиг.2 - система передачи сообщений ACARS по IP, в которой может применяться способ передачи в соответствии с настоящим изобретением;

фиг.3 - схема способа передачи сообщений ACARS по IP согласно варианту выполнения изобретения;

фиг.4А и 4В - способ передачи сообщений ACARS по IP соответственно согласно первой и второй версиям варианта выполнения изобретения;

фиг.5 - способ передачи сообщений ACARS по IP согласно третьей версии варианта выполнения изобретения.

Подробное описание частных вариантов выполнения

Рассмотрим снова систему передачи/приема сообщений ACARS по протоколу IP. Для лучшего понимания изобретения пример такой системы показан на фиг.2. Вместе с тем, для специалиста понятно, что этот пример выполнения не является ограничительным, и изобретение можно применять для системы передачи сообщений AoIP любой архитектуры.

Система ACARS на IP разбита на три сегмента: бортовой сегмент 210, сегмент 220 наземной сети и собственный сегмент 230 центра авиационной компании.

Бортовой сегмент содержит бортовой электронный модуль CMU (Communications Management Unit) (Модуль управления связью) 211, структура которого по уровням протокола схематично показана на чертеже.

Модуль CMU содержит приложения АОС и АТС, предназначенные соответственно для обмена данными с центром авиационной компании и с центром управления полетами. Данные типа АОС передают при помощи сообщений ACARS через уровень протокола Arinc 618. Эти сообщения могут быть отправлены либо в обычную среду передачи 212, например, передатчику СВЧ, ВЧ или SATCOM, либо в первый конверсионный модуль 213, включенный или не включенный в CMU. Этот конверсионный модуль использует уровень адаптации протокола, обозначенный AoIP, между уровнем протокола Arinc 618 приложения и уровнем IP, что будет подробно описано ниже.

Если выбрана обычная среда передачи, сообщения передаются на наземную станцию сети ACARS. Эта станция 221 оборудована шлюзом 223, осуществляющим преобразование протокола Arinc 618 в протокол Arinc 620. Напомним, что стандарт Arinc 620 связан с протоколом передачи на земле сообщений ACARS, например, между провайдером услуг (DSP) и оперативным центром авиационной компании.

Если выбрана передача по протоколу IP, сообщения ACARS направляются на шлюз 213. Датаграммы IP, содержащие сообщения ACARS, направляются через сеть Интернет на адрес IP получателя. Связь между летательным аппаратом и землей осуществляют через инфраструктуру общедоступной телекоммуникационной связи, например, через сеть GPRS, терминал Wi-Fi, станцию Wi Max.

Сегмент авиационной компании содержит терминал 231, при этом терминал содержит с одной стороны уровень протокола Arinc 620, выполненный с возможностью приема сообщений ACARS, прошедших через обычную среду передачи, и с другой стороны уровень протокола, выполненный с возможностью приема сообщений ACARS, прошедших через сеть IP. В частности, терминал 231 содержит второй конверсионный модуль 233, принадлежащий адаптационному уровню AoIP, который предназначен для извлечения упакованных блоков и для их передачи на уровень ACARS 618 и уровень адаптации протокола ACARS 618/620, обозначенный позицией 234. Мультиплексор 235 переправляет сообщения ACARS согласно стандарту Arinc 620 на порты управляющих приложений AOC₁, …, AOC_N, находящиеся в терминале 231.

Изобретение касается первого и второго конверсионных модулей уровня AoIP. Основной принцип состоит во включении всех блоков одного сообщения в одну датаграмму IP, в локальном моделировании имитации подтверждений приема блоков сообщения ACARS, за исключением последнего блока, который в этом случае приравнивается к квитированию для всех блоков сообщения.

В частности, на фиг.3 представлен способ передачи сообщений ACARS по IP согласно первому варианту выполнения изобретения.

Здесь вновь присутствуют прикладные уровни Arinc 618, адаптационные уровни AoIP, уровни IP для бортового сегмента 310 и наземного сегмента 320. Связь между бортовым сегментом и наземным сегментом осуществляют через беспроводное сопряжение и предпочтительно через инфраструктуру общедоступной телекоммуникационной связи.

Если сообщение ACARS М должно быть передано приложением, находящимся в передатчике, например, в CMU, уровень Arinc 618 разбивает это сообщение на n блоков В₁, …, B_n. Следует отметить, что изобретение не ограничивается каким-либо определенным числом блоков, хотя на сегодняшний день, согласно стандарту, n≤16.

Первый блок B₁ передается на уровень AoIP, который отправляет имитацию подтверждения приема

, что позволяет уровню Arinc передать второй блок В₂. Процесс повторяется вплоть до передачи предпоследнего блока B_n-1. Когда уровень Arinc 618 получает имитированное подтверждение приема

, он передает последний блок B_n. Однако при этом для последнего блока имитацию подтверждения приема не передают. При этом n блоков сообщения собирают для образования составного блока, который упаковывают в одну датаграмму IP, обозначенную D(B₁, …, B_n). Затем эту датаграмму переправляют на адрес IP назначения. Понятно, что уровень IP сегмента 320 соответствует классической маршрутизации в Интернете.

По адресу IP назначения, то есть на практике, на уровне центра авиационной компании уровень AoIP извлекает составной блок из датаграммы IP, после чего разбивает его, чтобы получить блоки B₁, …, B_n. После этого первый блок B₁ передают в прикладной уровень Arinc 618, который проверяет его целостность и, в случае нормального приема, отправляет подтверждение приема ack₁ на уровень AoIP. Процесс повторяют последовательно для каждого блока. Сообщение ACARS M воссоздается уровнем Arinc 618 приложения назначения (например, приложения типа АОС) из блоков B₁, …, B_n.

Когда уровень AoIP получает последнее подтверждение приема ack_n, при условии, однако, получения до этого n-1 подтверждений приема предыдущих блоков, он передает составное сообщение подтверждения приема ack_C, свидетельствующее о нормальном приеме n блоков. Сообщение ack_C может быть просто результатом сборки элементарных сообщений подтверждения приема ack₁, …, ack_n. Затем это сообщение помещают в датаграмму IP D(ack_C), после чего переправляют его на адрес IP модуля CMU летательного аппарата.

Уровень AoIP модуля CMU получает сообщение подтверждения приема ack_C и преобразует его в сообщение подтверждения приема последнего блока ack_n, после чего передает его на уровень Arinc 618. Преобразование ack_C в ack_n может быть результатом простого усечения составного сообщения. Когда уровень Arinc 618 получает последнее подтверждение приема ack_n, он считает, что сообщение М нормально принято получателем.

Если один из блоков B₁, …, B_n нарушен или не принят получателем, сообщение подтверждения приема ack_C не отправляют, и, следовательно, сообщение ack_n не передается на уровень Arinc 618. В таком случае этот уровень после заранее определенного времени ожидания может принять решение об отправке сообщения М, то есть всей совокупности блоков B₁, …, B_n.

В вышеизложенном варианте предполагалось, что передатчиком сообщения ACARS был модуль CMU летательного аппарата, а приемником - центр авиационной компании, иначе говоря, что связь была нисходящей (downlink). Однако понятно, что способ можно аналогично применять для восходящей связи (uplink), оставаясь в рамках настоящего изобретения.

Понятно, что способ передачи сообщений ACARS согласно этому предпочтительному варианту выполнения обладает преимуществом, заключающимся в том, что позволяет не дожидаться фактического подтверждения приема одного блока, прежде чем передать следующий. Кроме того, следует отметить, что передают только одну датаграмму IP вместо n для передачи сообщения, что позволяет сократить трафик на беспроводном сопряжении и, в случае необходимости, стоимость передачи.

Описанный выше вариант выполнения изобретения не зависит от используемого подчиненного транспортного протокола, в частности, от того, является ли он ориентированным на соединение, как TCP, или не ориентированным на соединение, как UDP.

Далее последовательно рассмотрим эти две ситуации.

На фиг.4А показана первая версия, в которой способ передачи сообщений ACARS использует классический транспортный протокол TCP. Мы уже рассмотрели детально пакетный протокол TCP/IP со стороны передатчика и со стороны приемника. Известно, что уровень TCP устанавливает и поддерживает соединение между передатчиком и получателем и что он использует свой собственный механизм квитирования для обеспечения хорошего приема датаграмм TCP.

Эта версия не требует изменения транспортного уровня TCP, и, следовательно, уровень AoIP по сути дела реализует адаптацию прикладного уровня Arinc 618 к транспортному протоколу TCP. В частности, блоки B₁, …, B_n, отправляемые уровнем Arinc 618 согласно уже описанному механизму имитации квитирования, собираются и упаковываются в сегмент TCP. После установления соединения TCP сегмент TCP, обозначаемый S(B₁, …, B_n), передается на сокет TCP получателя. Разумеется, передача сегмента TCP происходит путем включения в датаграмму TCP способом, известным специалистам.

Когда сегмент TCP поступает на сокет TCP получателя, на передатчик отправляют подтверждение приема

, как предусмотрено протоколом TCP. Пересылка блоков от уровня AoIP на уровень Arinc 618 уже была описана со ссылками на фиг.2, и ее повторное описание опускается.

Когда уровень AoIP принимает подтверждения приема ack₁-ack_n от уровня Arinc 618, он передает составное подтверждение приема ack_C на уровень TCP, который в свою очередь передает его в виде сегмента TCP, обозначаемого S(ack_C), на сокет ТСП передатчика. По получении сегмента S(ack_C) уровнем TCP модуля CMU на землю направляется подтверждение приема, обозначаемое

, в соответствии с протоколом TCP. После этого подтверждение приема преобразуют в сообщение подтверждения приема последнего блока ack_n, что уже было описано выше.

Эта версия обеспечивает непосредственное применение варианта выполнения, показанного на фиг.3, на существующем пакетном протоколе ТСРЛР.

Вместе с тем, следует отметить, что она требует передачи четырех сегментов TCP через беспроводное сопряжение, то есть S(B₁, …, B_n),

, S(ack_C) и

.

На фиг.4В показана вторая версия описанного выше варианта выполнения. Эта вторая версия позволяет сократить количество сегментов, проходящих через беспроводное сопряжение.

В частности, вторая версия отличается от первой тем, что подтверждение приема

не передается отдельно. Эту вторую версию можно осуществлять, задерживая передачу подтверждения приема S(B₁, …, B_n), пока уровень TCP не получит составное подтверждение приема ack_C от уровня AoIP, или обеспечивая, чтобы время обработки Δτ блоков B₁, …, B_n уровнем Arinc 618 в худшем случае n=16 было меньше времени генерирования подтверждения приема. Время обработки Δτ можно сократить за счет соответствующего выбора процессора, более эффективного алгоритма сжатия (то есть уменьшая число и размер блоков) или более быстрого алгоритма контроля ошибки.

Во всех случаях составное подтверждение приема ack_C передают вместе с подтверждением приема S(B₁, …, B_n) в единственном сегменте ТСП, обозначаемом S(ack_C,

). По поступлении этого сегмента на соответствующий порт TCP модуля CMU на землю отправляют подтверждение приема

. Остальная часть процесса подтверждения приема идентична первой версии. В конечном счете через интерфейс проходят только три сегмента TCP для переданного сообщения ACARS, то есть S(B₁, …, B_n), S(ack_C,

) и

.

На фиг.5 показана третья версия, в которой способ передачи сообщений ACARS использует транспортный протокол, не имеющий своего собственного механизма квитирования, например, протокол UDP. Известно, что протокол UDP является протоколом, не ориентированным на соединение, который не гарантирует хорошего прохождения датаграмм.

В основе этой версии лежит идея ожидания передачи сообщения ACARS по восходящей связи для отправки подтверждения приема сообщения, которое только что было принято по нисходящей связи. Аналогично, ожидают передачу сообщения по нисходящей связи, чтобы отправить подтверждение приема сообщения, которое было принято по восходящей связи. Случай передачи сообщения ACARS M по нисходящей связи показан на фиг.5.

Передачу сообщения М осуществляют, как уже было описано и показано на фиг.4, где транспортный уровень был просто детализирован. Иначе говоря, блоки B₁, …, B_n передаются на уровень AoIP, который их собирает и упаковывает в датаграмму UDP. После этого датаграмму UDP, обозначаемую U(B₁, …, B_n), классическим образом включают в датаграмму IP. После получения адресатом датаграмму U(B₁, …, B_n) извлекают из датаграммы IP, и блоки B₁, …, B_n последовательно пересылаются уровнем UDP на уровень Arinc 618. Подтверждения приема ack₁, …, ack_n, полученные уровнем AoIP, преобразуются этим уровнем в составное подтверждение приема ack_C, которое переводят в состояние ожидания.

Когда наземный центр авиационной компании передает сообщение ACARS М' по восходящей связи, например, в ответ на сообщение М, подтверждение приема ack_C включают вместе с блоками сообщения М' в датаграмму UDP. В частности, уровень Arinc 618 разбивает сообщение М' на блоки B'₁, …, B'_n; при n'≤16. Блок B'₁ передается на уровень AoIP, который пересылает ему имитацию подтверждения приема

. Процесс повторяют для следующих блоков, кроме последнего, для которого имитация подтверждения приема не передается, что уже было рассмотрено для нисходящей связи. Когда уровень AoIP получает блоки В'₁,…, B'_n', он проверяет, находится ли в состоянии выжидания подтверждение приема. Если это так, подтверждение приема включают вместе с блоками B'₁, …, B'_n' в одну датаграмму UDP, причем включение подтверждения приема, в случае необходимости, отмечают в датаграмме при помощи специального заголовка.

Предпочтительно таймер времени устанавливают на время задержки τ_max, когда уровень AoIP получает n блоков B₁, …, B_n. Если сообщение М' должно быть передано уровнем AoIP в течение времени задержки τ_max, вместе с блоками сообщения М' включают подтверждение приема ack_C, как было описано выше. Если же в течение срока задержки по восходящей связи не предусмотрено никакого сообщения М' для передачи, подтверждение приема передают при помощи отдельной датаграммы UDP. Продолжительность задержки можно регулировать и, в частности, она может зависеть от степени заполнения буфера передачи сообщений ACARS по нисходящей связи. Так, при высоком коэффициенте заполнения продолжительность τ_max выбирают относительно небольшой, чтобы не задерживать отправки нового сообщения уровнем Arinc 618.

В случае, показанном на фиг.5, единое составное подтверждение приема ack_C соединяют с блоками В'₁, …, B'_n' для передачи в виде датаграммы, обозначаемой U(e, B'₁, …, B'_n', ack_C), где е является вышеупомянутым заголовком. Разумеется, эту датаграмму UDP затем включают в датаграмму IP, которую пересылают на модуль CMU летательного аппарата. По получении датаграмму U(e, B'₁, …, B'_n', ack_C) извлекают из датаграммы IP. После этого уровень AoIP определяет наличие подтверждения приема благодаря присутствию заголовка е. Он извлекает и разбивает блоки B'₁, …, B'_n', а также подтверждение приема ack_C, после чего передает их на уровень Arinc 618. Заголовок е может также содержать указание на степень заполнения буфера сообщений ACARS на линии восходящей связи. Аналогично случаю нисходящей связи, сразу по получении блоков В'₁, …, B'_nтаймер устанавливают на время задержки τ'_max. Это время будет зависеть от коэффициента заполнения, указанного в заголовке. Как и в предыдущем случае, он определяет максимальное время выжидания для подтверждения приема сообщения М', при этом подтверждение приема ack'_C может быть передано при помощи датаграммы UDP U(e', B₁, …, B_n, ack'_C), содержащей новое сообщение на линии нисходящей связи, или, по умолчанию, при помощи отдельной датаграммы UDP по окончании задержки. Предпочтительно датаграмма U(e', B'₁, …, B'_n', ack'_C) содержит заголовок, указывающий на состояние буфера передачи на линии нисходящей связи.

В конечном счете, для переданного сообщения ACARS, как правило, через беспроводное сопряжение проходит только одна датаграмма, то есть U(e', B₁, …, B_n, ack'_C) для сообщения по линии нисходящей связи и U(e', B'₁, …, B'_n', ack_C) для сообщения по линии восходящей связи.

Claims

1. Способ передачи сообщений адресно-отчетной системы авиационной связи (ACARS) по протоколу IP между передатчиком и приемником, при этом сообщение ACARS (М), передаваемое приложением, разбивают на множество блоков (B₁, В₂, …, B_n), отличающийся тем, что для каждого блока указанного сообщения, за исключением последнего, локально на уровне передатчика направляют указанному приложению имитацию подтверждения приема

указанного блока, а когда передатчик принимает от приемника сообщение (D(ack_C), S(ack_C),

, U(e, B'₁, …, B'_n', ack_C)), указывающее на нормальный прием указанного множества переданных блоков, передатчик генерирует подтверждение приема (ack_n) последнего блока, после чего пересылает его указанному приложению.

2. Способ передачи по п.1, отличающийся тем, что указанное приложение содержит уровень протокола Arinc 618, при этом указанное сообщение ACARS соответствует стандарту Arinc 618, а подтверждение приема направляют на указанный уровень.

3. Способ передачи по п.2, отличающийся тем, что передатчик содержит между уровнем протокола Arinc 618 и уровнем IP уровень адаптации протокола, называемый первым адаптационным уровнем, при этом указанный первый адаптационный уровень отправляет для каждого блока сообщения ACARS, за исключением последнего, имитацию квитирования на уровень протокола Arinc 618, а после получения от уровня протокола Arinc 618 всех блоков указанного сообщения собирает их и упаковывает собранные таким образом блоки в первую датаграмму IP.

4. Способ передачи по п.3, отличающийся тем, что приемник содержит между уровнем протокола Arinc 618 второго приложения и уровнем IP уровень адаптации протокола, называемый вторым адаптационным уровнем, при этом указанный второй адаптационный уровень выполнен с возможностью извлечения и разбиения полезного содержимого указанной датаграммы IP для восстановления указанных блоков с последующим направлением блоков по одному на уровень протокола Arinc 618 указанного второго приложения, при этом блок направляют на уровень протокола только после подтверждения получения им предыдущего блока.

5. Способ передачи по п.4, отличающийся тем, что, когда второй адаптационный уровень принял все подтверждения (ack₁, ack₂, …, ack_n) приема указанных блоков, он направляет передатчику во второй датаграмме IP (D(ack_C)) подтверждение приема множества указанных блоков.

6. Способ передачи по п.2, отличающийся тем, что передатчик содержит между уровнем протокола Arinc 618 и уровнем TCP на IP уровень адаптации протокола, называемый третьим адаптационным уровнем, при этом указанный третий адаптационный уровень отправляет для каждого блока сообщения ACARS, за исключением последнего, имитацию квитирования на уровень протокола Arinc 618, а после получения от уровня протокола Arinc 618 всех блоков указанного сообщения собирает их и упаковывает собранные таким образом блоки в первый сегмент TCP.

7. Способ передачи по п.6, отличающийся тем, что приемник содержит между уровнем протокола Arinc 618 второго приложения и уровнем TCP уровень адаптации протокола, называемый четвертым адаптационным уровнем, при этом указанный четвертый адаптационный уровень выполнен с возможностью извлечения и разбиения полезного содержимого из указанного первого сегмента TCP для восстановления указанных блоков с последующим направлением блоков по одному на уровень протокола Arinc 618 второго приложения, при этом блок направляют на уровень протокола Arinc 618 только после подтверждения получения им предыдущего блока.

8. Способ передачи по п.7, отличающийся тем, что, когда четвертый адаптационный уровень принял все подтверждения (ack₁, ack₂, …, ack_n) приема указанных блоков, он направляет в передатчик второй сегмент TCP (S(ack_C),

) содержащий подтверждение (ack_C) приема множества указанных блоков, а также подтверждение приема первого сегмента TCP

.

9. Способ передачи по п.2, отличающийся тем, что передатчик содержит между уровнем протокола Arinc 618 и уровнем протокола UDP на IP уровень адаптации протокола, называемый пятым адаптационным уровнем, при этом указанный пятый адаптационный уровень отправляет для каждого блока сообщения ACARS, за исключением последнего, имитацию квитирования на уровень протокола Arinc 618, а после получения от уровня протокола Arinc 618 всех блоков указанного сообщения собирает их и упаковывает собранные таким образом блоки в первую датаграмму протокола UDP.

10. Способ передачи по п.9, отличающийся тем, что приемник содержит между уровнем протокола Arinc 618 второго приложения и уровнем протокола UDP уровень адаптации протокола, называемый шестым адаптационным уровнем, при этом указанный шестой адаптационный уровень выполнен с возможностью извлечения и разбиения полезного содержимого из указанной первой датаграммы протокола UDP для восстановления указанных блоков с последующим направлением блоков по одному на уровень протокола Arinc 618 второго приложения, при этом блок направляют на уровень протокола Arinc 618 только после подтверждения получения им предыдущего блока, причем когда шестой адаптационный уровень получил все подтверждения (ack₁, ack₂, …, ack_n) приема указанных блоков, он ожидает отправки второго сообщения ACARS (M') в направлении передатчика, при этом подтверждение приема (ack_C) множества указанных блоков соединяют с блоками второго сообщения, после чего помещают их во вторую датаграмму протокола UDP.