Policy and Charging Control: зачем классифицировать трафик в сотовой сети и как это сделать
Policy and Charging Control (PCC) - это архитектурный подход, с помощью которого оператор управляет политиками обслуживания и контролем тарификации в мобильной сети. Проще говоря, PCC отвечает на два практических вопроса: какое качество сервиса дать конкретному трафику и как правильно его учитывать/тарифицировать. В сетях 5G это особенно важно: нагрузка растёт, сервисы становятся разнообразнее, а ожидания пользователей к задержкам, стабильности и "честной" скорости - выше.
Откуда берётся проблема: одна PDU-сессия - много потребителей ресурса
В базовой модели есть пользовательское устройство (UE), базовая станция (gNB), транспорт и пользовательская плоскость (UPF), через которую трафик выходит в интернет. Устройство устанавливает PDU-сессию, сеть авторизует абонента и обеспечивает передачу данных.
Если представить, что у каждого UE "безлимит" по скорости и никаких правил, то при массовой нагрузке узким местом быстро станет радиодоступ: пропускная способность gNB и распределение радиоресурса не бесконечны. Итог - деградация для всех: скорость падает, задержки растут, "тяжёлые" пользователи вытесняют остальных.
Отсюда и первый практический шаг PCC: научиться ограничивать и распределять скорость и QoS на уровне сессии и отдельных сервисов.
Сессионные политики: как ограничить скорость через Session-AMBR
Для управления верхней планкой скорости на сессию используется Session-AMBR (Aggregate Maximum Bit Rate) - максимальный агрегированный битрейт для PDU-сессии. По смыслу это "потолок" по суммарной скорости трафика внутри конкретной сессии: сколько данных может проходить в единицу времени.
Типовой подход выглядит так:
- для каждого абонента (или профиля абонента) задаётся значение Session-AMBR;
- эти данные попадают в профиль, доступный управляющей функции сессии SMF;
- SMF во время установки сессии доставляет параметры в те элементы, которые реально могут обеспечить ограничение.
В 5G именно SMF управляет жизненным циклом PDU-сессии и взаимодействует сразу с несколькими сторонами: UE, gNB и UPF. Поэтому логика доставки Session-AMBR строится вокруг сигналинга установления сессии (PDU Session Establishment): SMF получает нужное значение из профиля и "раскладывает" его в соответствующие сообщения/поля для участников пользовательской плоскости.
Схема применения в процессе установки сессии типовая:
- в сторону UE отправляется *PDU Session Establishment Accept*, где присутствует поле Session AMBR;
- в сторону gNB уходит запрос настройки ресурсов, например *PDU Resource Setup Request*, где также передаётся PDU Session AMBR;
- в сторону UPF SMF формирует PFCP-сессию, например *PFCP Session Establishment Request* с правилом QER, внутри которого задаётся ограничение (MBR).
Практический итог простой: как только Session-AMBR доведён до тех узлов, которые "видят" пользовательский трафик, они начинают поддерживать заданный предел. Это позволяет экономить радиоресурс и предсказуемо делить полосу между абонентами.
Ограничение скорости - не только AMBR: QoS-характеристики
AMBR решает задачу "потолка" по скорости для сессии в целом, но не отвечает на вопрос: какой трафик важнее, а какой можно обслужить по остаточному принципу. Для этого применяются QoS-характеристики.
На практике часто оперируют такими параметрами:
- Packet Delay Budget (PDB) - допустимая задержка доставки пакета по пути между UE и выходом из UPF (или в обратном направлении);
- Guaranteed Bit Rate (GBR) - гарантированная скорость, которую сеть обязуется обеспечить;
- Maximum Bit Rate (MBR) - максимальная скорость для данного потока/класса трафика.
Эти параметры могут повторяться для одних и тех же типов сервисов (например, голос, видеозвонки, стриминг, мессенджеры). Чтобы не таскать полный набор характеристик каждый раз, в спецификациях предусмотрены стандартные "профили", закодированные числом 5QI (5G QoS Identifier). То есть вместо длинного списка параметров можно передать компактный идентификатор, за которым стоит заранее определённый набор требований по QoS.
Как профиль попадает в сеть: роль SMF в доставке QoS
Механика похожа на Session-AMBR: в профиле абонента (или политики на сессию) задаются QoS-настройки - например, 5QI как дефолт для трафика. Далее SMF при установлении PDU-сессии доставляет QoS-описание всем участникам:
- UE получает QoS Description (с 5QI или полным набором QoS-параметров) в сообщениях установления сессии;
- gNB получает описание QoS, чтобы корректно планировать радиоресурс;
- UPF получает правила и ограничения на уровне пользовательской плоскости, чтобы применить их к реальному потоку пакетов.
Таким образом, QoS становится не "бумажной" настройкой, а рабочим механизмом, который влияет на планирование, очереди, приоритезацию и ограничение потоков.
---
Зачем вообще классифицировать трафик по сервисам
Если ограничивать только PDU-сессию целиком, сеть не отличит голосовой вызов от загрузки обновлений или фонового бэкапа. В результате критичные к задержкам сервисы могут страдать наравне с "тяжёлыми" и менее важными потоками.
Классификация по сервисам нужна, чтобы:
- отделять чувствительный к задержкам трафик от "эластичного";
- задавать разные политики на видео, голос, игры, корпоративные приложения;
- включать/отключать отдельные услуги или делать их "нулевыми" по тарификации;
- точнее управлять нагрузкой на радиодоступ и ядро.
Как технически классифицируют трафик: от простого к точному
На практике применяют несколько уровней распознавания:
1. По IP/порту/протоколу - быстрый, но грубый метод: подходит для простых сервисов и статичных сценариев.
2. По 5-tuple (IP src/dst, port src/dst, protocol) - точнее, позволяет выделять конкретные потоки.
3. По сигнатурам приложений - более гибко, но сложнее в сопровождении.
4. По DPI-подходам - даёт максимум точности, но требует аккуратного обращения с ресурсами и политиками, а также внимательного отношения к требованиям приватности и регуляторике.
Выбор метода - компромисс между точностью, вычислительной стоимостью и тем, насколько часто меняются приложения/протоколы.
QoS Flow: как "прикрепить" QoS к конкретному сервису
В 5G QoS часто привязывают не ко всей сессии, а к отдельным потокам обслуживания - QoS Flow. Идея в том, что внутри одной PDU-сессии могут сосуществовать разные сервисы: например, видеозвонок и параллельная загрузка файлов. Для видеозвонка важна задержка и стабильность, для загрузки - пропускная способность, но без жёстких требований к задержке.
Тогда сеть делает следующее:
- определяет, какой трафик относится к конкретному сервису (классификация);
- назначает ему QoS Flow с нужными характеристиками (через 5QI или набор параметров);
- обеспечивает применение политики на элементах, которые реально обрабатывают пакеты.
Что делать, если QoS Flow "конкурируют" между собой
Конфликты неизбежны: радиоресурс конечен, а активных потоков может быть много. В такие моменты сеть должна решить, кому отдать приоритет.
Обычно используются комбинации механизмов:
- приоритезация по классам QoS (включая приоритетные значения/веса);
- ограничения MBR, чтобы один поток не "съедал" всё;
- гарантии GBR для критичных сервисов (если они предусмотрены политикой);
- алгоритмы планирования на стороне gNB, которые балансируют справедливость и требования к задержкам.
В результате важные сервисы продолжают работать приемлемо даже при пиковых нагрузках, а менее критичные аккуратно "поджимаются".
Policy Control Function: где рождаются правила для сессий
Чтобы политики были не статичными, а контекстными (тариф, тип абонента, роуминг, время суток, перегрузка сегмента), в 5G применяют PCF (Policy Control Function). Это компонент, который формирует и отдаёт правила для SMF: какие QoS назначить, какие ограничения включить, какие сервисы разрешить/запретить, какие условия тарификации применить.
Практически это выглядит как управляемая логика принятия решений:
- SMF сообщает контекст сессии;
- PCF подбирает подходящую политику;
- SMF реализует её, доставляя параметры в UE/gNB/UPF и формируя правила пользовательской плоскости.
Charging: как тарифицировать сервисы по отдельности
Когда сеть умеет различать трафик по сервисам, появляется следующая важная возможность: раздельная тарификация. Не "всё в одну корзину", а разные правила учёта для разных потоков. Это может быть:
- отдельное списание за конкретные услуги;
- разные лимиты или пакеты для видео/соцсетей/мессенджеров;
- нулевая тарификация для выбранных приложений (если такова продуктовая политика оператора);
- корпоративные политики, где часть трафика учитывается отдельно.
Ключевой момент: для корректного charging нужны те же кирпичики, что и для QoS - стабильная классификация, понятные правила и единая точка принятия решений в политике.
Типовые ошибки при внедрении PCC и классификации
1. Слишком грубая классификация: когда разные сервисы попадают в один класс, QoS и тарификация становятся "нечестными".
2. Слишком сложные правила: точность растёт, но сопровождаемость падает - любое изменение приложения ломает политику.
3. Нет согласованности между SMF/UPF/gNB: если параметры доставлены частично, эффект будет непредсказуемым.
4. Игнорирование конкуренции потоков: назначить QoS - мало, нужно продумать приоритеты и поведение при перегрузках.
5. Отсутствие контроля и наблюдаемости: без метрик по QoS Flow, задержкам и ограничениям легко "ослепнуть" и не понять, где деградация.
Как подойти к внедрению на практике: короткий план
Начинать обычно проще всего с поэтапной схемы:
- ввести Session-AMBR как базовый предохранитель по скорости на сессию;
- добавить дефолтный QoS через 5QI, чтобы сеть хотя бы различала классы обслуживания;
- затем перейти к QoS Flow для ключевых сервисов, где бизнесу важны качество и контроль;
- после этого подключать более тонкую классификацию и раздельный charging.
Так PCC из "теории про политики" превращается в прикладной инструмент: сеть стабильно выдерживает нагрузку, критичные сервисы получают нужный уровень качества, а тарифные модели становятся гибкими и управляемыми.
