VoIP радиостанция: PTT, SQ через RTP Headers Extention

VoIP радиостанция и приемник: прототип для использования в СКРС/VCS

Существуют различные подходы к организации передачи VoIP трафика через радиотракт, такие например как RoIP: Radio over IP. Что касается систем управления воздушным движением, в частности таких как СКРС/VCS, основанных на IP, здесь всякая вольница заканчивается и работа радиостанций, с помощью которых диспетчер обменивается с бортом, жестко регламентируется документально. Европейская организация Eurocae выпустила два таких документа: ED-136 и ED-137, посвященных принципам организации СКРС/VCS и в частности — как должна быть построена радио подсистема. Документы в публичном доступе отсутствуют, но их можно приобрести. Оно того стоит: работа проделана огромная; в распечатке это увесистые тома насыщенного техникой текста, без всякой воды.

Eurocae ED-136, ED-137

Самое приятное здесь  — это сам факт наличия документа ED-137. Если ED-136 описывает целевые требования к архитектуре и параметрам и в некотором роде является аналогом нашего технического задания, то ED-137 — каким образом это лучше сделать. Соответственно, этим рекомендациям мы и будем следовать.

Поскольку парк аналоговых радиостанций, используемых для УВД в нашей стране огромен, и мне во всяком случае неизвестен ни один факт использования VoIP радиостанций в этой области, практическую ценность будет представлять ответ на вопрос: каким образом аналоговую радиостанцию можно сделать VoIP радиостанцией. Как частный случай, если мы не желаем влазить в ее внутренности — как построить радиошлюз, который обеспечит сопряжение IP среды СКРС с аналоговой радиостанцией.

И если с передачей голоса все более или менее понятно, гораздо занимательнее найти ответ на вопрос: как СКРС должна формировать сигнал нажатия тангенты PTT (Push-to-Talk) и каким образом радиошлюз должен формировать сигнал SQ наличия несущей (срабатывания шумоподавителя, Squelch).

В документах ED подразумевается использование протокола SIP для обмена между всеми устройствами сети, и радиостанции не исключение. Каждая из них должна иметь свой SIP адрес. С чем мы имеем дело — с приемником или передатчиком, или с обоими одновременно, определяется заголовками recvonly, sendrecv и sendonly SIP протокола. Если мы рассчитываем на то, что поддержку PTT, SQ предлагается реализовать на уровне SIP, как это было бы логично, нас ждет легкое разочарование. Казалось бы, эти сигналы, ответственные за процедуры установления радиосоединения, должны работать на уровне SIP сигнализации, но не тут то было. В рекомендациях этого нет, и вместо этого реализация PTT/SQ, а также других управляющих сигналов и сообщений радиолинии сделана на уровне расширенных заголовков протокола RTP: Headers Extention.

Конечно, можно сделать предположение, почему было принято именно такое решение. Eurocae жестко регламентирует задержки в СКРС и в радиотракте, как для управления, так и для голоса. Так, время между нажанием PTT и поступлением этого сигнала на передатчик не должно превышать 80 мс. Еще 20 мс отводится передатчику на то, чтобы при получении этого сигнала он начал излучение в эфире. Для приемного тракта, задержка делится поровну: за 50 мс после появления сигнала в эфире приемник должен сформировать SQ, и за 50 мс СКРС после получения SQ должна включить тракт прослушивания на рабочем месте авиадиспетчера. Всего 100 мс в ту и другую сторону. Думаю, SIP протокол вряд ли гарантировал такие задержки, и поэтому решение было принято в пользу RTP.

Здесь рассматривается обмен между рабочим местом СКРС — CWP (Controller Worker Position) и радиостанцией.

Сказанное не означает, что процедура INVITE/200OK для радиостанций не поддерживается вообще: она присутствует. Только ее функция — это активация радиостанции, возможно один раз за все время эксплуатации (что не исключает требования обязательной процедуры пересоединения REINVITE). Выход на передачу и прием сигналов с борта — все это целиком существует на уровне RTP, а точнее на уровне Extended Headers. Коль скоро это так, посмотрим, что это за расширенные заголовки.

RTP Headers Extention

Вспомним, как организован стандартный заголовок RTP пакета. Он имеет следующий вид:

Расширение заголовка RTP

В составе заголовка есть X бит, значение которого обычно равно нулю. Если же X=1, это означает, что заголовок содержит дополнительные поля RTP Header Extention, следующие за ним. Один байт отводится на тип дополнительного заголовка и еще один указывает длину оставшейся части, в которой может содержаться любая пользовательская информация. ED-137 как раз регламентирует структуру этого информационного поля.

Структура заголовка зависит от направления медиапотока VoIP. Если мы имеем дело с приемником, то есть СКРС принимает аудио и авиадиспетчер слушает, то информационное поле имеет структуру RTPRx, если с передатчиком, т.е. СКРС передает аудио и авиадиспетчер говорит, то информационное поле будет иметь структуру RTPTx. Содержание этих полей показано далее.

Поле RTPTx: направление от CWP к радиостанции

Поле RTPTx

В этом двухбайтовом блоке существенными для нас являются следующие поля:

• PTT-type: CWP передает на радиостанцию признак выхода на передачу PTT ON, впрочем как и признак отсутствия передачи PTT OFF;
• PTT-ID: четырехбитный идентификатор передатчика. Откуда CWP берет этот код, сказано ниже.

Здесь возникает пара вопросов.

Несколько неожиданно наличие признака PTT OFF: зачем передавать поток RTP, если голоса нет? На самом деле при остутвии аудио-передачи RTP поток не прекращается: в нем идут Keep-Alieve пакеты без голоса с этим признаком PTT OFF. Четкое различение состояний PTT ON/OFF совершенно необходимо, и в СКРС предпринимаются специальные меры для исключения «залипания» признака передачи в том или ином состоянии. Существуют дополнительные состояния PTT ON, которые я для краткости опускаю, они касаются приоритета выхода на связь.

Присутствует интересное поле: идентификатор передатчика PTT-ID. Эти данные СКРС получает по SIP адресу радиостанции во время SIP сессии INVITE/200OK от радиостанции: так она сообщает свой ID.

Поле RTPRx: направление от радиостанции к CWP

Поле RTPRx

Как видно, структура этого блока соответствует блоку RTPTx, только смысл интересующих нас полей меняется, а именно:

• PTT-type: содержимое этого поля говорит CWP о выходе радиостанцию на передачу, причем инициатива выхода на передачу может быть с других CWP;
• SQU: признак наличия сигнала в эфире;
• PTT-ID: четырехбитный идентификатор передатчика, который вышел на передачу;
• SCT: признак одновременного приема.

Поскольку как отмечалось выше пакеты RTPRx идут не только во время радиоприема, а также и во время молчания на данном канале как Keep-Alive пакеты, то CWP получает информацию о том, кто выходит на передачу на тех радиостанциях к которым он подсоединен.

В поле RTPTx, точнее в его расширении передается еще одна важная информация об уровне и качестве принимаемого сигнала. Эта информация используется подсистемой BSS (Best Signal Selection).

С точки зрения диспетчера, механизм PTT-ID позволяет ему наблюдать за событиями связанными со «своими» радиостанциями:

• факт выхода на передачу с другого рабочего места;
• с какой радиостанции идет выход на передачу.

Таким образом, на уровне протокола расширенных заголовков RTP  поддерживается важная сетевая функция — распределенный доступ к радиостанциям.

VoIP радиостанция: прототип

Теперь, когда мы знаем как работать с Header Extensions, сделаем VoIP радиостанцию. Как я отмечал выше, эта задача решается добавлением к обычной аналоговой радиостанции VoIP радиошлюза. Конечно, на уровне прототипа радиошлюз не будет конструктивно встраиваться в радиостанцию: наша цель это проверка концепции, а не разработка VoIP радиостанции. Однако, базируясь на аппаратно-программных решениях прототипа, ничего не мешает сделать встраиваемый в радиостанцию шлюз.

В качестве платформы для прототипирования был выбран SBC (Single Board Computer) на основе процессора CM-T3730. Этот процессор имеет OMAP архитектуру и включает в себя ARM и DSP ядра. Его размеры чуть более размеров спичечного коробка: на фото видно как SBC закреплен на несущей плате. На несущей плате располагается соответствующее обрамление: электропитание, Ethernet, аудио-интерфейсы.

CM-T3730 на несущей плате

Для прототипирования были использованы стандартные серийные приемник и радиостанция. Аудио и PTT/SQ подключение осуществлялось через интерфейс E&M. Для того, чтобы перейти к встраиваемому варианту шлюза, необходимо всего лишь поменять E&M на внутренний цифровой аудио-интерфейс радиостанции и разработать несущую плату, конструктивно и интерфейсно совместимую с радиостанцией — контроллер VoIP.

Для прототипа было разработано следующее ПО:

• SIP модуль с поддержкой процедур обмена с радиостанциями в соответствии с Eurocae ED-136, ED-137;
• модуль RTP с поддержкой Headers Extension;
• голосовые кодеки и система эхоподавления.

В ходе экспериментов имитировались сигналы PTT/SQ и тестировалась совместная работа подсистем SIP и RTP. Для радиостанции использовался эквивалент нагрузки. Источником сигнала был микрофон и плеер, речь выводилась на гарнитуру и на внешние громкоговорители. Также оценивалась задержки, вносимые как радиотрактом, так и прототипом.

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

Эксперименты и тесты полностью подтвердили работоспособность принятой концепции с реальными радиоустройствами.