Scheduled access TEDS: как резервирование по расписанию обслуживает периодические данные
Для регулярного потока повторный запрос ресурса перед каждым пакетом создаёт дополнительную работу. Scheduled access в TEDS позволяет согласовать периодическое предоставление восходящей ёмкости. Но это не безусловная постоянная аренда канала. Руководство ETSI связывает механизм с согласованием QoS, началом потока и возможностью приостановки или изменения расписания при определённых условиях.
Опишите настоящую периодичность
Укажите, как часто приложение формирует данные, какой размер нужен в каждом событии и насколько допустимо отклонение времени. Периодическая отправка не означает, что приложение всегда создаёт одинаковый объём. Если размеры существенно меняются, это должно быть видно при согласовании требований, а не обнаруживаться после ввода.
Отдельно определите начало после включения и возобновление после длинной паузы. В руководстве initial scheduled data рассматриваются как ещё не полностью обслуживаемые действующим расписанием. Поэтому нельзя ожидать, что самый первый пакет всегда пройдёт по тем же условиям, что устойчивый регулярный поток.
Проверьте поддержку согласования
Scheduled access в рассматриваемой схеме требует поддержки переговоров QoS при активации PDP-контекста. Наличие периодического таймера в приложении не доказывает наличие сетевого расписания. Уточните по документации и фактическим данным, какой механизм используется в выбранном составе.
Согласуются период повторения, допустимая временная ошибка и объём данных. Базовая станция оценивает требуемые интервалы, а адаптация линии может влиять на фактическую потребность. Поэтому расписание приложения и распределение радиоресурса нужно сопоставлять по результату, не предполагая точное совпадение лишь по числу миллисекунд в настройке.
Испытайте паузу и возврат
Сначала измерьте устойчивый поток, затем предусмотренную остановку приложения и последующее продолжение. Зафиксируйте, когда выдача ресурса приостановилась и как восстановилась. Если сеть временно не может поддержать согласованные условия, приложение должно корректно обработать относящееся к нему изменение.
При совместной работе с другими потоками проверьте, не появились ли задержки или неиспользованные предоставления. Важен полезный результат всей конфигурации, а не только существование записи о расписании. Не пытайтесь компенсировать ошибочную постановку задачи заведомо избыточным резервированием для каждого терминала.
В техническое задание включите частоту, размеры, допустимое отклонение и действия после паузы. Испытания должны подтверждать именно эти условия на реальном составе. Тогда Scheduled access будет средством эффективного обслуживания подходящих периодических данных, а не общим обещанием, что любой пакет любого приложения всегда получает заранее зарезервированный ресурс без конкуренции и ограничений.
Источник: ETSI TR 102 300-7 V1.3.1 (2026-05), раздел7.8.1–7.8.3, стр.116–118; initial scheduled data ипауза расписания.
Запросы отправляются на наш e-mail из вашей почтовой программы.
