Primary и Secondary PDP context в TEDS: зачем одному IP-адресу несколько режимов обслуживания
Увеличить схему
Один IP-адрес не обязательно означает один одинаковый режим для всех данных приложения. В TEDS первичный PDP-контекст связывает адрес с абонентом и согласованными параметрами, а вторичный может использовать тот же адрес с другими требованиями QoS. Это позволяет различать потоки, но требует правильного сопоставления. Создание дополнительной записи само по себе ещё не направляет через неё нужные пакеты.
Разделите адресацию и обслуживание
Первичный контекст относится к конкретному PDP-адресу. Вторичный получает адрес первичного, но может иметь другие параметры качества обслуживания. Поэтому подсчёт IP-адресов не показывает число независимых контекстов, а число контекстов не равно числу одновременно доступных физических радиоканалов.
Руководство указывает протокольную возможность нескольких активных контекстов, вплоть до четырнадцати. Для закупки это не гарантия любого терминала: фактическую поддержку, ограничения и программный доступ подтверждают отдельно. Приложению нужны только те контексты, для которых есть понятная рабочая задача.
Проверьте, как распознаётся поток
Для входящих данных вторичные контексты могут связываться с фильтрами по портам. Если пакет не попадает в предусмотренный вторичный фильтр, он может обслуживаться через первичный контекст согласно описанному порядку. Внешне приложение продолжит получать данные, но ожидаемый режим обслуживания может не применяться.
В проекте запишите назначения потоков, используемые порты и нужные параметры. Если применяется автоматическое формирование фильтра, уточните его реальные условия в выбранной реализации. Не оставляйте это неявным предположением разработчика и инженера сети, которые могут понимать один и тот же обмен по-разному.
Испытайте каждый поток отдельно и вместе
Сначала передайте известный учебный поток и подтвердите, какой контекст используется по доступным данным. Затем включите второй поток и сравните поведение при совместной работе. При необходимости измените нагрузку в пределах согласованного испытания. Важно увидеть не только доставку, но и ожидаемое различие обслуживания.
После обновления приложения проверьте, не изменились ли порты или другие условия распознавания. Изменение интерфейса программы может не затрагивать радиочасть физически, но нарушить прежнюю связь потока с нужным контекстом. Поэтому история конфигурации должна охватывать обе стороны интеграции.
Практический результат — таблица «поток — адрес — фильтр — контекст — параметры — подтверждённый результат». Она позволяет использовать возможности TEDS предметно и диагностировать случаи, когда данные приходят, но получают неподходящее обслуживание. Без такой таблицы несколько контекстов могут оставаться лишь красивым списком настроек, не связанным с реальной работой приложения.
Источник: ETSI TR 102 300-7 V1.3.1 (2026-05), раздел7.3.1, стр.76–78; раздел7.3.4, стр.81–82; контексты иQoS-фильтры.
Запросы отправляются на наш e-mail из вашей почтовой программы.
