Радиосвязь: практическое применение
MCPTT off-network: равный приоритет одновременных запросов требует дополнительного способа выбора
Два пользователя MCPTT вне сети одновременно нажали PTT во время тишины. Правило «кто быстрее, тот и говорит» нельзя считать универсальным объяснением. ETSI TS 123 379 V19.11.0 рассматривает отдельный сценарий одновременных floor requests, когда текущий арбитр не определён.
Что сравнивают клиенты
В исходных условиях off-network вызов уже установлен, клиенты имеют его параметры, никто не говорит и floor arbitrator отсутствует. Два клиента направляют запросы практически одновременно.
Получая чужой запрос в ожидании ответа на собственный, клиент сравнивает свой floor priority с указанным приоритетом полученного запроса. В описанном случае более приоритетный участник объявляет floor taken при предусмотренных условиях отсутствия ответа.
Это распределённое взаимодействие клиентов. Его нельзя описывать как решение централизованного сервера, которого в данном сценарии нет.
Если приоритеты одинаковы
Примечание допускает использование другого способа определить владельца floor, когда полученный приоритет равен собственному. Конкретная дополнительная схема здесь не задана.
Также механизм обнаружения contention в описании соседнего сценария оставлен за пределами документа. Поэтому нельзя из обзорной последовательности вывести единый таймер, обязательную случайную задержку или универсальное правило выбора по ID.
Эти свойства требуют подтверждения по применимым протоколам и конкретной реализации клиента. Проверка должна оценивать согласованное поведение набора терминалов, особенно если используются разные продукты.
Как испытать без случайных выводов
В согласованном тесте сначала создают нужные исходные условия: продолжающийся off-network вызов, тишина и отсутствие определённого арбитра. Затем выполняют контролируемые почти одновременные запросы.
Отдельно проверяют разные и равные приоритеты. Сопоставляют сообщения управления, уведомления пользователям и фактическую передачу речи. Одна удачная попытка не раскрывает дополнительную схему выбора при равенстве.
В протоколе фиксируют конфигурацию приоритетов и наблюдаемый результат нескольких предусмотренных сценарием повторов. Не требуется выдавать наблюдённого победителя за постоянное правило системы.
Пользовательская памятка должна объяснять, какой признак разрешает начать речь и что делать при неуспешном запросе. Так одновременные нажатия не превращаются в предположение о сломанной кнопке, а инженер сохраняет границу между описанным сравнением приоритетов и деталями разрешения равенства, зависящими от реализации MCPTT.
Результат полезно наблюдать также отдельному слушателю. Это позволяет подтвердить, какой поток действительно принят, и отличить локальное уведомление одного клиента от согласованного состояния всей тестовой группы.