MCPTT application paging через MBMS дополняет обычный paging EPC и RAN
Система MCPTT отправила application paging через MBMS, но в сети наблюдается и обычный paging. Это не обязательно дублирование неисправной процедуры. ETSI TS 123 379 V19.11.0 прямо указывает, что прикладное уведомление не заменяет стандартный paging EPC и RAN.
Задача прикладного сообщения
Описанная процедура может использоваться для начала нового вызова через unicast либо перевода текущего вызова с broadcast на unicast. Исходное условие — активный и объявленный MBMS bearer.
Application paging сообщает клиенту, что сервер начнёт передавать медиа через unicast. В формате указаны применимый групповой либо пользовательский идентификатор и причина сообщения.
Это уровень MCPTT-приложения. Его назначение нельзя автоматически расширять до всех действий мобильной сети по поиску и переводу UE в нужное состояние.
Что делает клиент в idle
Если UE находится в idle mode, он инициирует service request для перехода в connected mode. Затем применяется предусмотренная доставка unicast-медиа.
При переводе уже текущего вызова сервер прекращает отправку соответствующего медиа через MBMS. Для нового вызова такого предшествующего потока может не быть, поэтому один и тот же шаг остановки не требуется безусловно во всех сценариях.
Описание допускает перекрытие этапов. Начало unicast-медиа может вызвать обычный paging EPC и RAN, если клиент к этому моменту ещё находится в idle. Следовательно, наблюдаемая обычная сетевая процедура сама по себе не доказывает, что application paging потерялось.
Как проверить переход
В согласованном тесте фиксируют исходное состояние UE, доступность объявленного MBMS и решение о нужном unicast-сценарии. Затем сопоставляют прикладное сообщение, service request и фактическое получение медиа.
Для продолжающегося вызова отдельно наблюдают прекращение старого MBMS-потока. Для нового вызова проверяют начало нужной коммуникации без требования увидеть несуществующую прежнюю передачу.
В протоколе сохраняют события обоих уровней. Пользовательский результат оценивают по установленному разговору и слышимости, а техническую причину задержки определяют по соответствующей последовательности.
Так прикладной механизм остаётся понятным дополнением к сетевому доступу. Инженер не считает обычный paging лишним только из-за наличия MBMS-уведомления и не обещает, что одно прикладное сообщение само по себе переводит любой UE в готовое состояние без предусмотренных действий сети.
При сравнении двух испытаний также фиксируют исходное состояние UE. Разные состояния idle и connected могут объяснить различающуюся последовательность сигнализации при одинаковой пользовательской цели вызова.
Запросы отправляются на наш e-mail из вашей почтовой программы.
