Одновременное PTT в LMR и MCPTT: где принимается окончательное решение о передаче
Два сотрудника нажали PTT почти одновременно: один работает в LMR, другой в MCPTT. Чтобы объяснить, кто получил передачу и почему второй увидел отказ, нужно знать место окончательного арбитража. Оно не определяется только тем, какой клиент ближе к диспетчеру.
ETSI TS 123 283 V19.5.0 связывает floor control межсистемной группы со стороной её определения. Если группа размещена в MCPTT, окончательное решение принимает соответствующий сервер. Если она относится к LMR, эта сторона представлена IWF. Дополнительно возможна локальная фильтрация запросов на партнёрской стороне.
Один или несколько запросов на границе
При локальной фильтрации несколько конкурирующих пользователей одной стороны могут сначала пройти её собственный отбор. На границу уходит выбранный запрос, после чего всё равно требуется окончательное решение владельца группы. Локальный успех поэтому не следует автоматически считать окончательным предоставлением передачи.
Без фильтрации предусмотренный вариант передаёт конкурирующие запросы дальше. Для описанного случая группы MCPTT IWF отправляет отдельные обращения LMR-пользователей с их переведёнными идентификаторами. Ожидаемое число сообщений зависит от выбранного режима и не всегда совпадает с другой конфигурацией той же сети.
На стенде задают известную сторону определения группы и политику. Затем создают контролируемую конкуренцию нескольких тестовых участников, сохраняя отправленные запросы, промежуточные решения и окончательные granted/rejected. Проверять нужно и результат у проигравшего пользователя, чтобы он понимал допустимое дальнейшее действие.
Что записать в схеме решения
В проектной карточке указывают владельца группы, место локальной фильтрации и компонент окончательного арбитража. Слова «приоритетный пользователь» без этих сведений не объясняют всю цепочку. Порядок выбора зависит от согласованной политики; статья не задаёт единственное правило по времени прихода или числовому приоритету.
Отдельно проверяют фактическую медиапередачу после granted и уведомление остальных о занятом floor. Серверный ответ и слышимый результат должны относиться к одному и тому же победившему пользователю. При неправильном сопоставлении ID журнал может выглядеть правдоподобно, скрывая неверного адресата состояния.
Практический итог — объяснимый арбитраж через межсистемную границу. Поддержка может определить, был ли запрос отфильтрован локально, дошёл ли до владельца и каким результатом завершился. Это позволяет диагностировать конкуренцию PTT без ошибочного вывода, что каждый отказ является проблемой радиопокрытия или что локальное решение автоматически обязывает другую систему предоставить передачу.
Запросы отправляются на наш e-mail из вашей почтовой программы.
