Привет всем! Меня зовут Саша Иргер, я эксперт по разработке ПО в департаменте проектирования и разработки пакетного ядра сети в YADRO. Вчера мой коллега опубликовал на Хабре статью про Policy Control: как и зачем классифицировать трафик в сотовой сети. Сегодня продолжу тему и разберу, как конкретно работает User Plane: по сути, он организован так, чтобы удовлетворить требования от Policy Control. Посмотрим, что здесь есть интересного.
Во время PDU-сессии на мобильное устройство (UE) поступают IP Flows, и их нужно разложить по QoS. Между устройством и базовой станцией (gNB) есть некий набор радиоканалов — DRB (Data Radio Bearer): они обеспечивают требуемое качество обслуживания для разных типов трафика. Со стороны gNB, DRB мапятся в отдельные QoS Flow:
Если вы посмотрите на эту схему справа налево, то увидите, что UPF разбивает трафик разных сервисов по разным QoS Flow. Дальше на базовой станции они разбиваются по DRB и поступают на устройство. Получается, в uplink трафик по QoS разбивает базовая станция, а в downlink — UPF.
Разбивка трафика по QoS — это основная задача User Plane в сотовой сети. Радиоресурс очень сложный, поэтому сотовая сеть старается использовать его как можно плотнее. Чтобы сервисы корректно работали, нужно «помочь» базовой станции, разделив сервисы по классам обслуживания. Так gNB понимает, как приоритизировать их на радио.
Трафик разбивается на QoS при помощи фильтров на UPF и UE:
-
адрес (или подсеть) отправителя;
-
адрес (или подсеть) и получателя;
-
порт (или диапазон портов) отправителя;
-
порт (или диапазон портов) получателя;
-
IP-протокол;
-
IPv4 ToS / IPv6 Traffic class.
То есть у нас есть некий набор фильтров, они выстроены по приоритету. Каждый пакет трафика, который нужно классифицировать, мы прогоняем поочередно по всем этим фильтрам. Первый фильтр, с которым пакет сметчился, и определяет для него QoS. Это вторая центральная концепция всего User Plane в 4G и 5G.
Присоединяйтесь к команде! Сейчас у нас открыты вакансии:
PCC rule как основная концепция при управлении QoS
PCC rule (Policy and Charging Control Rule) — это набор инструкций, которые используются в сетях мобильной связи для управления трафиком конкретного абонента. PCC rule определяет, как детектировать, приоритизировать и тарифицировать сервисы.
К PCC rule относятся:
-
Набор Service Data Flow Templates — фильтры для трафика.
-
5QI — набор QoS-характеристик, которые должны соблюдаться.
-
MBR/GBR — максимальные Guaranteed Bit Rate.
-
Charging — Charging ID (Rating Group): номер, с которым сопоставляются все отчеты по трафику для PCC rule.
-
Gate status — показывает, пропускать трафик или нет.
От PCC rule к UE QoS Filters
Из списка, который я дал выше, UE QoS Filters обеспечивает две первые характеристики: набор Service Data Flow Templates и 5Q.
Процесс выглядит так: информация из PCC rule поступает на SMF, после чего он ставит на мобильное устройство какое-то количество фильтров. Фильтры нужны, чтобы классифицировать трафик в uplink:
Как я уже писал выше, каждый пакет «пробегает» по фильтрам и сопоставляется с QoS. Трафик, который не соответствует ни одному фильтру, дропается. Но обычно все операторы ставят открытый фильтр с самым низким precedence, который ловит все. Ведь ситуаций, когда какой-либо трафик вообще не нужно передавать, в современной жизни практически не бывает.
От PCC rule к QoS Flows
QoS Flows отвечают за 5QI и GBR.
Фильтры на UE, QoS на gNB и правила на UPF согласовываются одновременно во время установки PDU-сессии.
Задача базовой станции обеспечить заданный QoS, и это очень непростая алгоритмическая задача: по каждому пакету базовая станция должна считать, сколько времени он проводит в буфере, сколько будет передаваться, сколько радиоресурса это требует, и сколько раз этот пакете может передаваться повторно (ретрансмититься).
Поскольку базовой станции и так есть чем заняться, задачу классификации пакетов по QoS flow выполняет опорная сеть. Работает это так: SMF через AMF «договаривается» с базовой станцией о QoS Flow и характеристиках (5QI и Guaranteed Bit Rate по этому QoS Flow) и инструктирует UPF, как «размечать» пакеты. Буквально в каждом пакете UPF в специальном заголовке выставляет номер QoS Flow. Базовой станции остается только посмотреть в этот заголовок.
От PCC rule к UPF PFCP Rules
UPF PFCP Rules отвечают за набор Service Data Flow Templates, 5QI (DL), MBR, Charging ID, Gate status.
Как и в остальных элементах сети, SMF на входе устанавливает PFCP Rules на UPF. UPF — это «железка», которая знает больше всего о QoS User Plane в сети. По сути, она делает все: обеспечивает 5QA, фильтрацию трафика, выдерживает максимум Bit Rate, в том числе по каждой сессии отдельно, а еще чарджит и занимается гейтингом.
Давайте еще раз посмотрим на схему выше и разберемся, что у нас за названия из трех букв. Конкретно имплементируются четыре типа правил:
-
PDR (Packet Detection Rule) — именно он определяет правила классификации трафика, в которых есть фильтр.
-
FAR (Forwarding action rule) определяет правила обработки сопоставленного трафика. Например, куда его форвордить.
-
QER (QoS Enforcement Rule) определяет правила качества обслуживания классифицированного трафика. Например, как трафик попадает на QoS Flow и какой там может быть Bit Rate.
-
URR (Usage Reporting Rule) определяет правила подсчета трафика и предоставления отчетов. Например, как считать трафик до Charging и как репортить по нему события.
С этим разобрались — идем дальше.
Как работает UPF
Кратко алгоритм обработки пакетов выглядит так:
-
находим сессию;
-
IP-адреса и TEID берутся из PDR;
-
все складывается в глобальные таблицы поиска.
Теперь посмотрим на примере:
Пакет трафика влетает в N3 (интерфейс в сторону базовой станции) или N6 (выходной интерфейс в сторону сети IP). Правила всех сессий на UPF уже настроены.
На интерфейсе N3 используется протокол GTP (GPRS Tunneling Protocol). В его заголовке есть TEID (Tunnel Endpoint Identifier) — это 32-битное число, которое идентифицирует туннель конкретного пользователя и позволяет различать трафик разных абонентов между собой. Соответственно на входе в N3 первая задача UPF — найти конкретную пользовательскую сессии по таблице TEID.
На стороне N6 у нас глобальная таблица IP. Каждый пакет, который приходит со стороны какой-либо сети (не важно, приватная она или нет), есть destination. По нему мы пытаемся найти мобильное устройство и сессию.
Когда сессия найдена, мы начинаем перебирать все PDR, пока не найдем подходящий: SMF уже произвел свою магию и установил нам в PDU-сессии все PDR с фильтрами и расставил им приоритет (precedence) так, чтобы он соответствовал PCC rules, которые были ему выданы.
Потом UPF по очереди начинает прикладывать пакет к фильтру каждого PDR и проверять, есть ли совпадение. Если есть — мы работаем только с этим PDR. Если совпадений нет, пакет дропается. Так мы обеспечиваем фильтрацию трафика.
Когда мы сравниваем пакет с PDR в uplink, у него уже есть QoS Flow ID, и его тоже важно учитывать. Если пакет пришел по соответствующему PDR, но QoS Flow у него другой, мы этот PDR не берем. Почему? Маппинг пакетов на QoS Flow в uplink производится мобильным устройством, но никто не говорит, что оно всегда будет действовать правильно и по стандарту. Особенно учитывая, что Charging у нас идет по QFI, и мобильное устройство может послать высокоприоритетный трафик по бесплатному QoS Flow. Поэтому в UPF для uplink введена процедура под названием QoS Flow Bindinging Verification: ее задача — следить, что пакет пришел по QoS Flow, проставленному в правилах.
Итак, мы с вами нашли PDR:
У нас прямо сказано, что пакет, который совпадает с этим PDR, работает по конкретному QER, URR и FAR.
В QER (а он есть у PDR всегда) указывается QoS Flow, по которому пакет пойдет в gNB, и Maximum Bit Rate. То есть буквально QER в себе содержит ограничение трафика. Через него может пройти определенное количество килобит, мегабит или гигабит трафика в секунду. Если пакет в QER не вписывается, он дропается. Тем же образом обеспечивается Gate Status. Прямо в QER есть флажок «Пропускать трафик» или «Не пропускать трафик».
Если все в порядке и мы проходим QER, трафик попадает в URR:
В URR содержится вся информация, которая есть в Charging. Он считает проходящий через него трафик в байтах, а еще в нем есть квоты (Quotas). Квоты выставляются с Charging и через SMF попадают прямо в URR. Соответственно, есть правило, что когда определенная квота трафика исчерпается, должен создаваться отчет (report). Он улетит в SMF, потом попадет в Charging, а там сгенерируется промежуточный Charging-report, который сообщит, сколько потрачено трафика.
Последнее правило, которое применяется в UPF, — это FAR (Forwarding Action Rule). FAR говорит, что делать с этим трафиком дальше: дропнуть или направить на базовую станцию. Во втором случае там прописаны параметры базовой станции, ее адрес и где находится мобильное устройство. Если UE в Idle Mode, трафик буферизируется. Отсюда летит отчет, что по мобильному устройству пошел трафик и его нужно «будить», то есть вытаскивать из Idle Mode — это отдельная контрольная процедура. Все это делается через FAR — он не относится к QoS и PCC, но без FAR трафик не будет работать.
Все, о чем я сказал, работает именно так, если у нас одна UPF в системе. Но стандарт говорит, что сценарии использования бывают похитрее. Покажу пример:
Здесь у нас та же самая концепция. Все управление политиками заключается в том, что SMF расставляет правила обработки трафика на всех UPF по полученным им PCC-правилам.
На схеме две UPF зачейнены через интерфейс N9 — это отдельный тип, который используется именно для связи между UPF. Еще мы видим, что SMF ставит два N4-интерфейса для обоих UPF и выдает им соответствующие правила. Задача SMF — раздать правила всем UPF так, чтобы они соответствовали поставленным PCC rules.
Ну что, время итогов. Во всей архитектуре Policy Control именно SMF решает, что и как делать остальным. Она должна поставить задачи таким образом, чтобы трафик обрабатывался в соответствии с поставленной сервисной моделью. А еще из UPF можно выстраивать не только цепочки, но и деревья (3GPP подразумевает такую историю):
На схеме реализовано Selective IP Traffic Offload. Представьте: у нас есть выход в сеть, а главная UPF стоит где-нибудь далеко. Например, мы во Владивостоке, а UPF в Москве. Если вы смотрите местный ресурс, трафик идет из Владивостока в Москву, а потом обратно. Конечно, это неудобно. Можно частично настроить UPF так, чтобы часть трафика замаршрутизировалась локально, куда-нибудь на маленький местный UPF. Для этого предназначен инструмент под названием ULCL UPF. ULCL (Uplink Classifier) принимает решение, куда заслать трафик: подальше или поближе.
По схеме, которую я привел выше, видно, что сложные цепочки обработки трафика тоже можно использовать. Но рулить всеми UPF неизменно будет один и тот же SMF.
ссылка на оригинал статьи https://habr.com/ru/articles/1024588/