Как оценить загрузку DMR перед расширением: считать разговорное время, а не рации
Число радиостанций помогает оценить закупку, но плохо описывает загрузку сети. Для ёмкости важнее, сколько времени пользователи занимают общий ресурс и насколько часто их обращения совпадают. ETSI описывает ограниченные разговорные ресурсы двухслотовой DMR, поэтому расширение следует обсуждать по наблюдаемой работе, а не по одному количеству выданных аппаратов.
Соберите данные за характерный период
Выберите наиболее напряжённый рабочий интервал, а не только среднее время суток. В журнале отмечайте начало и конец обмена, группу, площадку, попытки без установления связи и повторные обращения. Отдельно фиксируйте служебные передачи данных. Если система предоставляет счётчики, выясните, что именно они учитывают: фактическую речь, занятие ресурса или всю сессию между собеседниками.
Для предварительной оценки можно сложить длительности попыток занятия ресурса за час и разделить результат на 3600 секунд. Например,120 обращений средней длительностью 18 секунд дают 2160 секунд, то есть 0,6 часа суммарной предложенной нагрузки. Это наш расчётный пример учёта времени; он не определяет вероятность отказа и не доказывает достаточность одного разговорного ресурса.
Средняя загрузка скрывает очереди
Та же суммарная длительность может распределяться равномерно либо собираться в несколько коротких пиков. Во втором случае пользователи столкнутся с занятостью даже при умеренном часовом среднем. Поэтому вместе со средней нагрузкой сохраняйте максимальное число одновременных запросов, длительность ожидания и число неудачных попыток в наиболее напряжённые минуты.

Увеличить иллюстрацию

Не исключайте повторы из анализа незаметно. Частые повторные нажатия PTT могут быть следствием первоначальной занятости, неудобной индикации или непонятного регламента. В журнале их полезно связать с исходным событием. Иначе появится впечатление роста полезного трафика, хотя фактически пользователи пытаются передать одно и то же сообщение.
Сравните три способа улучшения
Первый вариант — изменить организацию переговоров: убрать ненужные общие объявления, согласовать короткие подтверждения, разделить действительно независимые задачи. Второй — изменить распределение ресурсов и служб в пределах возможностей оборудования. Третий — расширить инфраструктуру. Каждый вариант проверяйте одним и тем же сценарием пикового часа, чтобы изменение можно было оценить.
В заявке на расширение приложите исходный период наблюдения, определения счётчиков, распределение обращений и допустимое ожидание для разных видов связи. Попросите показать расчёт с явными допущениями и проверку при возросшей нагрузке. Не превращайте предварительную формулу в обещание качества: окончательный результат должен учитывать архитектуру, настройки доступа, служебный обмен и реальные рабочие пики.
Сохраняйте исходные журналы, чтобы после изменения сети сравнивать одинаковые рабочие периоды и понимать причину улучшения.
Источник: ETSI TR 102 398 V1.5.1 (2023-11), раздел4, стр.15; раздел5.1.2, стр.20; раздел5.6, стр.27; расчёт нагрузки ниже — собственный пример.