Два MC gateway UE для одного устройства: как разделять службы без выдуманного объединения каналов
Одно рабочее устройство должно использовать голос через первый MC gateway UE, а данные — через второй. Такая схема отличается от попытки сложить пропускную способность двух шлюзов для одной службы. При подготовке проекта эти ожидания нужно разделить до настройки маршрутов.
Раздел 11.2.0 ETSI TS 123 280 V19.10.1 допускает использование одного или нескольких MC gateway UE при одновременной работе нескольких MC-служб. При этом каждая отдельная служба в описанном варианте ограничена одним шлюзом. Приведённый пример разделяет MCPTT и MCData по двум направлениям.
Карта служб вместо общего маршрута
В проектной карточке для каждой службы указывают клиент, выбранный шлюз, серверную сторону и требуемую операцию. Тогда успешная голосовая проверка не выглядит подтверждением пути передачи данных. Общая сет eвая доступность устройства также не заменяет проверку каждой службы.
Прокручивайте увеличенную схему по горизонтали. С клавиатуры: перейдите к схеме и используйте стрелки.
На стенде сначала подтверждают каждый путь отдельно. Затем выполняют согласованную одновременную работу: голосовой сценарий через первый шлюз и передачу данных через второй. Сохраняют фактическую конфигурацию и результаты, чтобы показать именно разделение служб, а не случайный выбор одного общего выхода.
Если оператору нужен единый интерфейс состояния, интегратор должен объяснить, как он показывает частичный отказ. Например, доступность голоса при недоступных данных — отдельное состояние, которое нельзя скрыть одной зелёной отметкой «устройство подключено». Конкретный вид интерфейса стандарт не задаёт.
Резервирование не возникает автоматически
Наличие двух шлюзов в составе не доказывает автоматическое переключение одной службы при отказе. Рассматриваемый пример описывает распределение служб, а не готовый универсальный механизм резервирования или агрегации. Требования к восстановлению нужно получить и испытать отдельно по документации поставки.
Для согласованного отрицательного сценария прекращают доступность одного тестового пути и наблюдают обе службы. Важно выяснить, какой результат ожидается на затронутой стороне и сохраняется ли другая рабочая операция. Дальнейшее восстановление проверяют предусмотренным способом, не предполагая самопроизвольную смену шлюза.
Практический итог — прозрачное разделение ответственности и диагностики. Заказчик знает, какой шлюз обеспечивает каждую MC-службу, какие проверки выполнены одновременно и что означает частичная недоступность. Два устройства в схеме перестают служить необоснованным обещанием удвоенной скорости либо полного резервирования одной службы. Если нужны именно эти свойства, их оформляют отдельными требованиями и подтверждают отдельным техническим решением.
