Полудуплексный OFDM-модем: MAC, LLC и ограничения испытаний

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

Эти правила для любительского OFDM-модема описывает автор технической публикации на Habr, подписанный как bashkirtsevich. Он разбирает два канальных подуровня: MAC, который устанавливает соединение и распределяет доступ к среде, и LLC, который ведёт сессию и отвечает за доставку данных. Это отчёт о самостоятельной разработке, а не рецензированная научная статья. Точная дата публикации в доступном тексте не указана; на странице отображалось «10 часов назад».

Сначала нужно договориться, кто говорит

Обмен начинается с маяка Beacon. Он передаёт позывной станции и параметры вызова. Услышав маяк, второй узел отправляет Conn с адресами обеих станций, локатором вызывающего и случайным восьмибитным идентификатором запроса. В ответ ведущий узел посылает ConnAck: подтверждает запрос, сообщает идентификаторы соединения и задаёт параметры временных окон. Ведомый завершает обмен подтверждением Ack.

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

Затем узлы работают по расписанию. Ведущему и ведомому выделены свои интервалы, а между ними предусмотрен защитный промежуток в пять секунд. Устройство должно сразу ответить на принятый запрос, но начать новый обмен может только в отведённое ему время. Такое расписание снижает вероятность встречной передачи. Оно зависит от системных часов, поэтому расхождение времени и меняющиеся задержки могут влиять на работу схемы.

Подтверждать каждый блок или сразу пачку

На уровне LLC данные делят на небольшие фреймы. Перед отправкой узел посылает RTS, запрос на передачу. Ответ CTS сообщает, готов ли принимающий узел, и может задавать модуляцию и скорость кодирования. Полезные данные защищает контрольная сумма CRC-16, а короткие управляющие пакеты используют CRC-8.

В режиме Stop-and-Wait отправитель передаёт один фрейм и ждёт подтверждения ACK. Если пакет повреждён или не дошёл, его отправляют повторно. Это простой способ контроля доставки, но ожидание занимает время. В описанной реализации есть и пакетный режим: после серии фреймов получатель посылает SACK, битовая маска которого отмечает принятые блоки. Маска содержит сведения максимум о 16 фреймах; повторно передаются только блоки, доставку которых не подтвердили.

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

Что показали испытания и чего они не показывают

В кратком резюме автор сообщает, что в лаборатории время отклика составляло около пяти секунд, и связывает это со звуковой картой. Отдельно он называет минимальный порог в 200–300 миллисекунд. Эти значения нельзя считать двумя результатами одного измерения: публикация подробно не описывает условия, в которых получено каждое из них.

Пиковую скорость автор оценивает примерно в 1500 бит/с при 16-QAM и повышенной скорости кодирования. Модуляция 32-QAM уже была включена в реализацию, но, по словам автора, её испытали недостаточно, поэтому она остаётся экспериментальной. Заявленную скорость нельзя переносить на любой радиоканал или считать независимо подтверждённой измерениями.

В техническом разборе описаны и трудности физического уровня, от которого зависят MAC и LLC. OFDM чувствителен к временной синхронизации: автор сообщает, что сдвиг на несколько отсчётов может помешать декодированию. Он также описывает ухудшение сигнального созвездия при неудачной настройке эквалайзера Винера. Звуковой тракт добавляет задержку, а ошибки приёма вызывают повторную передачу и снижают полезную скорость обмена.

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

Для понимания, почему описание метода и воспроизводимость измерений важны при оценке результатов, полезен наш разбор проверки воспроизводимости исследования. В случае радиомодема следующий содержательный шаг для проверки заявлений был бы простым по замыслу: повторить измерения с описанными аппаратурой и условиями, отдельно сравнить Stop-and-Wait и пакетную передачу, а результаты задержки и потерь привести для каждого режима.

Источник: bashkirtsevich. «Разработка цифрового радиолюбительского протокола на базе OFDM. MAC и LLC уровни». Habr, полный текст: https://habr.com/ru/articles/1095010/. Пользовательская техническая публикация; дата в доступном тексте не указана.