Маршрутизатор acars для удаленных бортовых приложений



Маршрутизатор acars для удаленных бортовых приложений
Маршрутизатор acars для удаленных бортовых приложений
Маршрутизатор acars для удаленных бортовых приложений
Маршрутизатор acars для удаленных бортовых приложений
Маршрутизатор acars для удаленных бортовых приложений

 


Владельцы патента RU 2495537:

ЭРБЮС ОПЕРАСЬОН (FR)

Изобретение относится к области телекоммуникаций в авиации и конкретно к области передачи сообщений ACARS (Авиационная система связи «запрос-ответ»). Технический результат заключается в обеспечении установки новых приложений в системе передачи сообщений ACARS без необходимости предоставления специализированного интерфейса для каждого нового приложения. Данная коммуникационная система передачи сообщений ACARS содержит, по меньшей мере, один бортовой прибор, включающий приложение, выполненное с возможностью передачи и/или приема сообщений ACARS, и маршрутизатор, выполненный с возможностью маршрутизации через множество подсетей (ВЧ/СВЧ/SATCOM) сообщений ACARS, передаваемых в направлении или поступающих от указанного приложения. Указанный прибор и указанный маршрутизатор соединены с сетью AFDX, и указанное приложение выполнено с возможностью своей динамической регистрации в маршрутизаторе через указанную сеть, при этом маршрутизатор производит маршрутизацию указанных сообщений только если указанное приложение в нем действительно зарегистрировано. 2 н. и 8 з.п. ф-лы, 5 ил.

 

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

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

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

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

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

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

На фиг.1 схематично показана архитектура коммуникационной системы, использующей известный маршрутизатор ACARS 100. Такой маршрутизатор может включать одно или несколько приложений 110, выполненных с возможностью передачи на землю и приема данных с земли в виде сообщений ACARS. Эти приложения заранее определены при проектировании оборудования. Добавление нового приложения требует доводки маршрутизатора (и даже его замены), а также новой сертификации. Следовательно, установка нового приложения в маршрутизаторе является сложной операцией. Маршрутизатор ACARS можно также связать с удаленными бортовыми приложениями при помощи выделенных линий связи «точка-точка» типа Arinc 429. Протокол передачи сообщений ACARS по этим линиям связи определен в стандарте Arinc 619.

Удаленные бортовые приложения могут находиться в различных типах LRU (Line Replaceable Unit, легкосъемный блок), например, таких как модуль ACMS (Aircraft Condition Monitornig System, система контроля состояния летательного аппарата) для передачи в авиационную компанию сведений, связанных с состоянием самолета, модуль АТС для приема информации по управлению полетом, модуль CMS (Centralised Maintenance System, централизованная система технического обслуживания) для обмена данными по обслуживанию. Эти приложения ведут диалог с маршрутизатором при помощи выделенных интерфейсов, предусмотренных при проектировании маршрутизатора. Иначе говоря, невозможно предусмотреть, чтобы какое-либо дополнительное приложение могло воспользоваться услугой ACARS, предоставляемой маршрутизатором. Это предполагало бы, по меньшей мере, установку нового интерфейса и, следовательно, новую операцию сертификации.

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

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

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

Объектом настоящего изобретения является коммуникационная система передачи сообщений ACARS, содержащая, по меньшей мере, один бортовой прибор, включающий приложение, выполненное с возможностью передачи и/или приема сообщений ACARS, маршрутизатор, выполненный с возможностью маршрутизации указанных сообщений, передаваемых в направлении или поступающих от множества подсетей (ВЧ/СВЧ/SATCOM), в которой указанный прибор и указанный маршрутизатор соединены с сетью AFDX, и указанное приложение выполнено с возможностью своей динамической регистрации в маршрутизаторе через указанную сеть, при этом маршрутизатор производит маршрутизацию указанных сообщений, только если указанное приложение в нем действительно зарегистрировано.

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

В этом случае запрос о регистрации и возможное подтверждение регистрации предпочтительно передают при помощи стека протоколов APOTA/TFTP/UDP/IP, где АРОТА обозначает уровень адаптации протокола между уровнем TFTP и приложением со стороны прибора и уровень адаптации протокола между уровнем Arinc 618 и уровнем NFTP со стороны маршрутизатора.

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

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

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

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

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

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

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

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

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

фиг.1 - схематичный вид архитектуры бортовой коммуникационной системы, использующей маршрутизатор ACARS из предшествующего уровня техники;

фиг.2 - схематичный вид архитектуры бортовой коммуникационной системы, использующей маршрутизатор ACARS согласно варианту выполнения изобретения;

фиг.3 - схема стеков протоколов, применяемых в системе, показанной на фиг.2;

фиг.4 - схема первой функциональной возможности уровня протокола АРОТА, показанного на фиг.3;

фиг.5 - схема процедуры динамической регистрации удаленного приложения в маршрутизаторе в коммуникационной системе в соответствии с настоящим изобретением.

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

В дальнейшем описании рассмотрим случай, когда летательный аппарат оборудован сетью AFDX (Avionics Full DupleX, Бортовая полнодуплексная сеть). Следует напомнить, что сеть AFDX, разработанная для нужд авиации, основана на коммутируемой сети Ethernet и была стандартизирована в стандарте Arinc 664, часть 7. В частности, подробное описание этой сети можно найти в документе под названием "AFDX protocol tutorial" по адресу URL:

http://sierrasales.com/pdfs/AFDXTutorial.pdf

Идея, лежащая в основе изобретения, состоит в том, чтобы предусмотреть протокол, позволяющий любому приложению, установленному в терминальном устройстве (End System), пройти динамическую регистрацию в маршрутизаторе с целью использования услуги связи ACARS. По сути, указанный протокол распространяет доступ к услуге связи ACARS на любое предварительно зарегистрированное удаленное приложение, как если бы оно находилось внутри маршрутизатора или как если бы бортовой прибор использовал протокол Arinc 619 на выделенной линии связи Arinc 429 с маршрутизатором.

На фиг.2 показана бортовая коммуникационная система, использующая маршрутизатор ACARS 200 согласно варианту выполнения изобретения. Маршрутизатор 200, а также один или несколько приборов 210, содержащих соответственно приложения, обозначенные client appl_1, client appl_2,…, client appl_N, соединены с сетью AFDX 220. Приборы 210 являются терминалами (End Systems) в соответствии со стандартом Arinc 664. Маршрутизатор предназначен для маршрутизации сообщений ACARS через множество подсетей, в частности, подсетей ВЧ, СВЧ, SATCOM и даже WiMAX или Wi-Fi, причем этот список не является исчерпывающем.

Каждое из приложений client appl_1, client appl_2,…, client appl_N выполнено с возможностью использования услуги ACARS. Для этого оно должно предварительно пройти регистрацию в маршрутизаторе согласно процедуре, которая подробно будет описана ниже. Добавление нового приложения не требует изменения аппаратной или программной конфигурации маршрутизатора, поэтому нет необходимости в его повторной сертификации. Следует отметить, что эта архитектура обеспечивает одновременно большие возможности модульности и гибкость изменения. В частности, можно легко индивидуализировать коммуникационную систему ACARS и интегрировать в нее самостоятельно разработанные приложения, сохраняя при этом тот же маршрутизатор.

На фиг.3 схематично показаны стеки 310 и 300 протоколов, соответственно применяемые со стороны приложения-клиента и маршрутизатора ACARS.

Нижние уровни протокола каждого стека представляют собой уровни сети AFDX, то есть уровень связи Ethernet, уровень сети IP и транспортный уровень UDP.

Со стороны приложения-клиента прикладной уровень, обозначенный в данном случае "приложение канала передачи данных ACARS", может передавать сообщения ACARS в маршрутизатор классическим образом в формате Arinc 620. Вместе с тем, в отличие от известных технических решений, где эти сообщения передаются по линиям связи Arinc 429 с использованием протокола передачи файла Arinc 619, в данном случае до передачи при помощи сеанса связи TFTP (Trivial File Transfer Protocol, Простой протокол передачи данных) они преобразуются уровнем адаптации протокола, обозначенным АРОТА (ACARS Protocol Over TFTP and AFDX, Протокол ACARS через TFTP и AFDX). Подробное описание протокола TFTP можно найти в документе RFC 1350 на сайте комиссии EETF. В нашем случае следует просто напомнить, что протокол TFTP является очень простым протоколом передачи файла, использующим UDP в качестве подчиненного транспортного уровня.

Ролью уровня АРОТА в стеке 310 протоколов является предоставление услуги ACARS (в виде SAP или Service Access Point, Точка доступа к услуге) для удаленного бортового приложения, иначе говоря, доставка услуги ACARS на уровень этого приложения. Для этого уровень протокола АРОТА ведет диалог с высшим прикладным уровнем при помощи сервисных примитивов ACARS и с нижним уровнем через сервисные примитивы передачи файла. Он также производит обмен пакетами, обозначенными APOTA-PDUs (Protocol Data Units, протокольные единицы данных) со своим аналогом в пакетном протоколе 300.

Со стороны маршрутизатора уровень протокола Arinc 618 управляет связью ACARS с землей. Так же, как и в предыдущем случае, уровень протокола АРОТА стека 300 протоколов ведет диалог с высшим уровнем при помощи сервисных примитивов ACARS и с низшим уровнем через сервисные примитивы передачи файла. Однако, в отличие от стека 310 протоколов, уровень протокола АРОТА не предоставляет услуги ACARS высшему уровню. Его основной функцией является обеспечение пересылки сообщений ACARS путем передачи файла через уровень TFTP.

В целом, уровень протокола АРОТА обеспечивает, в частности, следующие функции:

- доставка услуги ACARS от маршрутизатора на удаленные приложения;

- динамическая регистрация удаленных приложений, являющихся пользователями услуги ACARS;

- управление потоком на нисходящей линии связи;

- обнаружение неисправных приложений-клиентов;

- обнаружение потери услуги ACARS;

- контроль ошибок.

На фиг.4 схематично показан механизм доставки услуги ACARS для нисходящей линии связи, то есть связи воздух-земля (A/G).

Уровень протокола АРОТА кодирует в 410 сервисные примитивы ACARS, а также их возможные параметры, генерируя примитивы передачи файла. Предназначенный для передачи файл может содержать один или несколько пакетов APOTA-PDU. Название файла, в данном случае обозначенное "#Filename", как правило, содержит код, идентифицирующий приложение-отправитель, код идентификации получателя (то есть, маршрутизатора) и код, указывающий на тип сообщения, содержащегося в файле.

Уровень протокола АРОТА в 420 подает команду на уровень TFTP для передачи файла, содержащего пакеты APOTA-PDU, при помощи примитива передачи файла, обозначенного FT-Write. После этого уровень TFTP передает файл #Filename в виде пакетов TFTP PDU в соответствии со стандартом RFC 1350. Эти стандартные пакеты поступают на маршрутизатор через сеть AFDX при помощи протокола передачи файла TFTP. Уровень протокола АРОТА стека 300 протоколов получает извещение о получении файла #Filename при помощи примитива FT-Data-Ind. Если уровень протокола АРОТА согласен принять файл, он принимает содержащиеся в нем пакеты APOTA-PDU. На этапе 440 сообщения ACARS извлекаются из пакетов APOTA-PDUs и передаются на уровень протокола Arinc 618. Для восходящей линии связи уровни протокола АРОТА пакетных протоколов 300 и 310 работают симметрично.

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

Процедура начинается с отправки приложением запроса на регистрацию в виде сервисного примитива ACARS, обозначенного в данном случае A-Reg-req, передаваемого на уровень протокола АРОТА. Этот примитив позволяет удаленному приложению заявить себя в качестве нового клиента на уровне маршрутизатора и указать метки или подметки сообщений ACARS, которые приложение хочет передавать на землю или принимать с земли.

После этого уровень протокола АРОТА генерирует сервисный примитив передачи файла (FT-Write), параметрами которого являются название файла #Filename (RegReq), пакет APOTA-PDU, обозначенный в данном случае RefReq PDU, и номер порта TFTP (не показан). Название файла содержит тип передаваемого файла, в данном случае запрос на регистрацию, а также код идентификации приложения-отправителя.

При получении маршрутизатором уровень TFTP передает название принятого файла #Filename (RegReq) и пакет RegReq PDU. Пакет RegReq содержит, кроме всего прочего, список меток и подметок ACARS, которые приложение хочет зарезервировать.

Уровень АРОТА маршрутизатора проверяет, является ли запрос на регистрацию правильным, на основании информации, содержащейся в названии файла и/или в передаваемом пакете RegReq PDU. В случае положительного результата маршрутизатор локально регистрирует код рассматриваемого приложения, после чего отправляет сообщение о подтверждении регистрации. В противном случае, если запрос на регистрацию не проходит, маршрутизатор отправляет сообщение об отказе в регистрации. Отправка сообщения подтверждения или отказа в регистрации происходит, как и в предыдущем случае, при помощи сервисного примитива передачи файла (FT-Write). В рассматриваемом случае регистрация подтверждена, и уровень АРОТА генерирует указанный примитив с параметрами, такими как название файла #Filename (RegConf) и пакет RegConf PDU.

По получении терминалом сообщение подтверждения обрабатывается уровнем АРОТА, и подтверждение передается на приложение-клиент при помощи сервисного примитива ACARS, обозначенного A-Reg-conf.

Функцией протокола АРОТА является также контроль потока на нисходящей линии связи. Предпочтительно этот контроль потока предусматривают по причине неодинаковости скорости передачи между сетью AFDX (100 Мбит/с) и подсетями СВЧ/ВЧ/SATCOM (менее 31 кбит/с), что может привести к перегрузке на уровне маршрутизатора. При этом следует отметить, что на восходящей линии связи нет необходимости в каком-либо механизме контроля потока.

Произведя свою регистрацию в маршрутизаторе, удаленное приложение может передавать сообщения ACARS. Для этого уровень АРОТА удаленного приложения передает сервисный примитив передачи файла (FT-Write) на уровень АРОТА маршрутизатора. Параметрами этого примитива являются название файла, содержащее, в частности, код удаленного приложения, тип сообщения (восходящая или нисходящая линия связи) и размер сообщения.

Когда уровень АРОТА маршрутизатора принимает этот запрос, он прежде всего проверяет, чтобы удаленное приложение было действительно известным и зарегистрированным. В противном случае запрос отклоняется, и передача файла прекращается. После этого он проверяет тип сообщения, чтобы определить, должен ли он осуществить контроль потока. В случае подтверждения (нисходящая линия связи) он проверяет, чтобы размер сообщения был меньше, чем свободное место в его буфере приема. Если это так, маршрутизатор дает согласие на передачу TFTP. Если нет, эта передача отменяется, и уровень АРОТА маршрутизатора сообщает об этом уровню АРОТА удаленного приложения при помощи сервисного примитива с указанием об отказе. После этого уровень АРОТА удаленного приложения перестает передавать новые запросы.

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

Предпочтительно название файла в параметре сервисного примитива передачи файла (FT-Write) может также содержать указание о приоритете и/или указание о стратегии маршрутизации. Эти указания позволяют маршрутизатору, с одной стороны, установить иерархию поступающих потоков и, с другой стороны, выбрать для каждого поступающего потока наиболее подходящую среду передачи ВЧ/СВЧ/SATCOM в зависимости от соответствующей степени их незанятости.

Уровень протокола АРОТА позволяет также обнаруживать неисправные удаленные приложения-клиенты. Удаленное приложение является неисправным, если оно больше не может обрабатывать сообщения, которые ему направляются по восходящей линии связи.

Чтобы обнаружить такую неисправность, уровень протокола АРОТА маршрутизатора периодически передает тестовое сообщение (в данном случае обозначенное "Testlink") в каждое из зарегистрированных приложений. При каждой отправке таймер устанавливают на значение (Ttest) и, когда таймер доходит до конца этого времени, передают новое тестовое сообщение. Если для одного из этих приложений передача сообщения не состоялась, то есть если маршрутизатор не получил от этого приложения подтверждение приема до момента срабатывания указанного таймера, это приложение считается неисправным. Этот механизма обнаружения позволяет маршрутизатору определить максимально быстро, что удаленное приложение не работает, и, следовательно, не принимать сообщения, поступающие с земли и предназначенные для этого приложения.

В то же время, удаленное приложение может обнаружить потерю услуги ACARS, например, в случае проблемы в сети AFDX. Для этого удаленное приложение устанавливает таймер на значение Тmon>Ttest во время своей регистрации в маршрутизаторе. После этого таймер переустанавливают на значение Тmon при каждом получении тестового сообщения (Testlink). Если реле времени доходит до конца установленного времени, приложение делает вывод об отсутствии тестового сообщения и о потере услуги ACARS.

Наконец, уровень протокола АРОТА позволяет контролировать ошибки, которые могут появиться в услуге ACARS. В частности, если обнаружена ошибка, например, если передача файла не состоялась, принятое сообщение неправильно сформатировано, название файла в параметре запроса на передачу является ошибочным, или если передача сообщения не разрешена при текущем состоянии уровня протокола, реакция на ошибку является следующей:

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

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

1. Коммуникационная система передачи сообщений ACARS, содержащая, по меньшей мере, один бортовой прибор, включающий в себя приложение, выполненное с возможностью передачи и/или приема сообщений ACARS, маршрутизатор, выполненный с возможностью маршрутизации указанных сообщений, передаваемых в направлении или поступающих от множества подсетей (ВЧ/СВЧ/SATCOM), отличающаяся тем, что указанный прибор и указанный маршрутизатор соединены с сетью AFDX и что указанное приложение выполнено с возможностью своей динамической регистрации в маршрутизаторе через указанную сеть, при этом маршрутизатор выполняет маршрутизацию указанных сообщений, только если указанное приложение в нем действительно зарегистрировано.

2. Коммуникационная система по п.1, отличающаяся тем, что указанное приложение регистрируется в маршрутизаторе, передавая в него запрос о регистрации и получая от него в ответ подтверждение регистрации, при этом указанное подтверждение отправляется маршрутизатором, только если сведения, содержащиеся в запросе, определены им как действительные.

3. Коммуникационная система по п.3, отличающаяся тем, что запрос о регистрации и возможное подтверждение регистрации передают при помощи стека протоколов АРОТА/TFTP/UDP/IP, где АРОТА обозначает уровень адаптации протокола между уровнем TFTP и приложением со стороны прибора и уровень адаптации протокола между уровнем Arinc 618 и уровнем TFTP со стороны маршрутизатора.

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

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

6. Коммуникационная система по п.1, отличающаяся тем, что маршрутизатор периодически направляет в указанное приложение тестовое сообщение, при этом первый таймер переустанавливают на первое определенное значение времени (Ttest) при каждой отправке, и тестовое сообщение отправляют каждый раз, когда он доходит до конца установленного времени, при этом неисправность указанного приложения обнаруживают, если маршрутизатор не получает подтверждения приема тестового сообщения до окончания установленного времени указанного первого таймера.

7. Коммуникационная система по п.6, отличающаяся тем, что указанное приложение устанавливает второй таймер на второе значение времени (Tmon), превышающее первое значение, во время своей регистрации в маршрутизаторе и при каждом приеме тестового сообщения, при этом неисправность маршрутизатора обнаруживают, если указанный второй таймер доходит до конца установленного времени до приема тестового сообщения.

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

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

10. Летательный аппарат, содержащий коммуникационную систему по одному из предыдущих пунктов.



 

Похожие патенты:

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

Изобретение относится к защищенному шлюзу, обеспечивающему двустороннюю связь между двумя сетями связи, при этом первая сеть имеет высокий уровень защиты, а вторая сеть имеет более низкий уровень защиты.

Обеспечены способ функционирования шлюза управления устройствами (DM) в системе связи, включающей в себя шлюз DM, сервер DM и конечное устройство, которым сервер DM не может непосредственно управлять, чтобы обеспечить возможность управления устройством посредством сервера DM, через шлюз DM, способ для шлюза DM в системе связи для обновления информации начальной загрузки для некоторого класса устройств, способ для шлюза DM в системе связи для обрабатывания команд DM, способ для шлюза DM в системе связи для обрабатывания сообщений о прерывании, способ для шлюза DM в системе связи для обрабатывания периодического информационного сообщения об услугах/возможностях и способ для шлюза DM в системе связи для обрабатывания окончания интервала контроля времени.

Изобретение относится к системам связи. .

Изобретение относится к беспроводным сетям, а именно к системам безопасности для иерархических сетей. .

Изобретение относится к способу передачи дейтаграммы между автоматизированными приборами автоматизированных установок. .

Изобретение относится к области управления безопасностью в беспроводной сети. .

Изобретение относится к системам мультимедиа. .

Изобретение относится к системе и способу обеспечения устойчивости к сбоям и балансировки нагрузки для объекта функции управления сеансом связи. Технический результат заключается в повышении надежности и снижении нагрузки сети IMS. Система включает в себя объекты прокси-функции управления сеансом связи, объекты запрашивающей функции управления сеансом связи и объекты обслуживающей функции управления сеансом связи, а также сервер системы доменных имен. Объекты системы сконфигурированы для регулярной передачи серверу системы доменных имен отчета об их эквивалентном весовом коэффициенте нагрузки посредством сообщения DNS UPDATE для использования сервером переданных данных при реализации стратегии балансировки нагрузки. 2 н. и 9 з. п. ф-лы, 6 ил.

Заявленное изобретение относится к механизмам, предоставляющим мультимедийный контент и, в частности, к способу и устройству для переноса мультимедийного сеанса с устройства на устройство. Технический результат состоит в эффективности воспроизведения пользователями мультимедийного контента в пути или вне дома или офиса. Для этого один из примеров способа включает инициирование переноса мультимедийного сеанса с устройства приема мультимедийных данных и предоставление сетевому устройству сообщения о переносе сеанса. Устройство приема мультимедийных данных и сетевое устройство имеют соединения связи с сетью. 6 н. и 15 з.п. ф-лы, 10 ил.

Изобретение относится к технике связи и может использоваться как система связи между сетью компьютеров в летательном аппарате и сетью компьютеров на земле. Технический результат состоит в повышении эффективности использования каналов связи. Для этого система содержит средства, выполненные с возможностью установления сетевого соединения между сетью компьютеров на земле и сетью компьютеров в летательном аппарате через, по меньшей мере, один носитель связи в режиме синхронной связи. 3 н. и 5 з.п. ф-лы, 7 ил.

Изобретение относится к системам связи. Технический результат заключается в расширении межсетевого взаимодействия. Предоставляются архитектуры IIF (функции межсетевого взаимодействия и совместимости) и соответствующие последовательности действий вызова для сценариев роуминга CDMA2000/GPRS, например, чужой режим GPRS с Mobile IPv4, чужой режим GPRS с Simple IPv4 или IPv6, чужой режим пакетных данных CDMA2000 с Mobile IPv4 и чужой режим пакетных данных CDMA2000 с Simple IPv4 или Mobile IPv6. 6 н. и 26 з.п. ф-лы, 9 ил.

Изобретение относится к хранению мультимедийных презентаций. Техническим результатом является обеспечение возможности хранения мультимедийных презентаций, имеющих несколько источников. Способ хранения мультимедийных презентаций, имеющих несколько источников, включающий сохранение файла, содержащего множество дорожек; обеспечение в упомянутом файле первого указания, касающегося того, принадлежит ли упомянутое множество дорожек презентации, имеющей несколько источников, которая включает, по меньшей мере, одну из следующих: презентация видеотелефонии, презентация многосторонней видеоконференции и презентация видеонаблюдения, и отображает более одного потока мультимедийных данных, обеспечение в упомянутом файле второго указания, указывающего на то, что упомянутое множество дорожек, принадлежащее упомянутой презентации, имеющей несколько источников, должно быть отображено на многооконном экране, и обеспечение в упомянутом файле дополнительного указания, указывающего для одного типа мультимедийных данных на то, что дорожки упомянутого типа мультимедийных данных получены от различных источников и должны быть воспроизведены одновременно. 6 н. и 12 з.п. ф-лы, 6 ил.

Группа изобретений относится к синхронизации времени сетевой игры между множеством игроков. Технический результат заключается в повышении надежности передачи данных в игровой среде при наличии временных задержек. В способе определяют разницу во времени между сервером и клиентом сетевой игры с учетом момента передачи сервером сетевой игры первого пакета данных клиенту сетевой игры, момента передачи клиентом сетевой игры второго пакета данных серверу сетевой игры и момента получения сервером сетевой игры второго пакета данных от клиента сетевой игры. Далее определяют фактический момент передачи клиентом сетевой игры второго пакета данных серверу сетевой игры в ходе игры с учетом указанной разницы во времени и синхронизируют время клиента сетевой игры с временем сервера сетевой игры. Благодаря настоящему изобретению обеспечивается возможность точного определения момента передачи клиентом сетевой игры второго пакета данных серверу сетевой игры, что позволяет снизить нагрузку на память и процессорные ресурсы, а также улучшить восприятие игры игроками. 2 н. и 10 з.п. ф-лы, 6 ил.

Изобретение относится к системам связи, в частности к телекоммуникационным системам клиент-сервер, основанным на IP (например, VoIP - голос по Интернет-протоколу). Техническим результатом является обеспечение способности создания правил маршрутизации вызова на клиенте на основании использования сообщений протокола сеанса (например, SIP-протокол инициации сеанса) посредством существующего протокола сеанса. Предложен механизм сигнализации стороны клиента, который позволяет клиенту управлять тем, как вызов телефона обрабатывается на сервере вызова. Пользователь клиента может создать правила маршрутизации вызова на устройстве клиента, используя компонент управления клиента, который управляет сообщениями протокола сеанса. После создания правило(а) маршрутизации вызова, созданные на клиенте, передают серверу вызова, где компонент маршрутизации вызова сервера вызова обрабатывает правила для вызова, относящегося к клиенту. Когда сервер принимает правило(а) и определяет, что правило(а) относится к существующему вызову (входящий или находящийся в процессе исполнения в настоящее время), сервер останавливает текущую обработку нормальных правил сервера для того вызова и выполняет правило(а), созданное клиентом. Сообщения сеанса SIP используют для управления клиентом перенаправлением вызовов стороны сервера. 3 н. и 17 з.п. ф-лы, 18 ил.

Заявленное изобретение относится к области технологий связи. Технический результат заключается в регулировке полосы пропускания канала ODUflex без потерь. Для этого способ регулировки без потерь включает в себя этапы, на которых соответственно регулируют, в соответствии с информацией запроса индикации регулировки полосы пропускания, временной интервал, занятый кадром ODUflex, в блоке данных оптического канала высшего порядка на выходной стороне каждого сетевого узла по каналу ODUflex; и регулируют, в соответствии с информацией индикации регулировки скорости передачи, скорость передачи кадра ODUflex каждого сетевого узла в канале ODUflex для унификации скорости передачи каждого сетевого узла в канале ODUflex. 2 н. и 10 з.п. ф-лы, 8 ил.

Изобретение относится к системам связи. Технический результат заключается в повышении эффективности использования ресурсов. Ретрансляторы могут использоваться для того, чтобы способствовать передаче пакета, например, с базовой станции на мобильное устройство. Пакет может включать в себя заголовок, который обозначает намеченный пункт назначения для пакета. Заголовок может пересылать, так что обозначение намеченного пункта назначения может посылаться с восстановлением после сжатия или без него на ретрансляторе. Если имеется более одного ретранслятора, участвующего в передаче, тогда заголовок может конфигурировать так, что заголовок является доступным без выполнения восстановления после сжатия. Однако если имеется один останов ретрансляции, тогда заголовок может сжимать указатель таким образом, что должно происходить восстановление после сжатия. 5 н. и 12 з.п. ф-лы, 19 ил.

Изобретение относится к беспроводной связи. Технический результат - определение приоритетности экстренных вызовов. Предлагаются способы и устройства для передачи полезных данных, связанных с высокоприоритетным вызовом, например экстренным вызовом. В одном варианте осуществления указанные данные содержат данные (например, блок MSD или блок FSD), внедренные в один или большее количество пакетов протокола передачи в реальном времени, например пакетов протокола управления передачей в реальном времени (RTCP), которые проходят перемежение с потоком голосовых данных или данных пользователя (передаваемых, например, в пакетах протокола RTP) экстренного вызова. Описанные устройства и способы предназначены для надежной передачи части данных из инициирующего терминала (например, системы, установленной в транспортном средстве) в пункт обеспечения общественной безопасности (PSAP) путем использования того же транспортного соединения, что и для данных пользователя. 4 н. и 35 з.п.ф-лы, 12 ил.
Наверх