Когда UE запускает видеоприложение, реальный пользовательский трафик должен пройти от gNB к UPF, прежде чем попасть в сеть передачи данных. Плоскость управления устанавливает PDU Session, назначает адреса и задаёт правила пересылки, однако протоколом, который фактически переносит пользовательские IP-пакеты через пользовательскую плоскость доступа и ядра 5G, является GTP-U. Чтобы понять GTP-U, недостаточно запомнить только «UDP-порт 2152» и «TEID». В 5G один туннель N3 может переносить несколько QoS Flow, а контроль доступности пути, обработка неизвестных туннелей и очистка пользовательской плоскости после событий мобильности также опираются на управляющие сообщения GTP-U. Если рассматривать стек протоколов, туннели, TEID, QFI и процедуры управления как единый сквозной путь пользовательской плоскости, становится намного проще понять, как трафик 5G в действительности достигает UPF.

Где находится GTP-U в архитектуре 5G?

GTP-U расшифровывается как GPRS Tunnelling Protocol for the User Plane. В архитектуре пользовательской плоскости 5G он главным образом используется для инкапсуляции и передачи пользовательского трафика верхних уровней между узлами пользовательской плоскости.

С точки зрения 5G Core двумя наиболее распространёнными интерфейсами, использующими GTP-U, являются N3 и N9. N3 соединяет gNB с UPF и переносит пользовательский трафик между сетью радиодоступа и 5G Core. N9 используется между UPF. Внутри RAN интерфейс Xn-U между gNB также может использовать GTP-U.

Это заметно отличается от архитектуры плоскости управления 5G. Такие сетевые функции, как AMF и SMF, используют сервисные интерфейсы, в значительной степени основанные на HTTP/2, тогда как путь пользовательской плоскости по-прежнему использует GTP-U для переноса фактического трафика абонента. Переход 5G к Service-Based Architecture не означает, что сама пользовательская плоскость перешла на HTTP.

GTP-U работает поверх UDP и по-прежнему использует UDP-порт 2152. Если рассматривать стек протоколов от пакета пользовательского приложения к нижним уровням, его структуру можно представить следующим образом.

Трафик приложения сначала формируется как TCP- или UDP-пакет, а затем как IP-пакет, принадлежащий UE. После попадания в пользовательскую плоскость 5G исходный пользовательский пакет инкапсулируется в GTP-U. Затем для передачи между конечными точками GTP-U добавляются внешний UDP-заголовок, внешний IP-заголовок и Ethernet-кадр нижнего уровня.

Поэтому в захвате пакетов могут присутствовать два разных набора IP-адресов. Внутренние IP-адреса описывают связь между UE и сервером приложения в сети передачи данных, а внешние IP-адреса используются между конечными точками туннеля GTP-U, например gNB и UPF. Путаница между внутренними и внешними IP-заголовками — одна из распространённых причин ошибок при поиске неисправностей трафика N3.

Чем отличаются GTP Path, туннель и TEID?

GTP Path, GTP Tunnel, Tunnel Endpoint и TEID — тесно связанные понятия, однако они описывают разные уровни модели передачи GTP-U.

GTP Path можно рассматривать как путь без установления соединения между двумя конечными точками GTP-туннеля. Если gNB и UPF могут обмениваться пакетами GTP-U через IP-сеть, между этими конечными точками существует GTP Path. Несколько туннелей GTP-U могут совместно использовать один и тот же Path.

GTP Tunnel представляет собой более конкретный логический туннель пользовательской плоскости. Туннель GTP-U идентифицируется сочетанием TEID, IP-адресации и транспортной информации UDP, тогда как сама конечная точка туннеля определяется IP-адресом узла и UDP-портом.

TEID, или Tunnel Endpoint Identifier, — одно из наиболее важных полей GTP-U. В базовом заголовке GTPv1-U TEID имеет длину четыре байта. Когда пакет GTP-U поступает на принимающий узел, тот использует TEID вместе со своим локальным контекстом туннеля, чтобы определить, к какому туннелю пользовательской плоскости относится пакет и какой контекст PDU Session или пересылки должен его обработать.

Именно поэтому TEID нельзя интерпретировать изолированно. Одно и то же числовое значение TEID может встречаться в разных контекстах туннеля. Если пакеты относятся к разным конечным точкам GTP или к разным направлениям, они не обязательно принадлежат одному туннелю.

При анализе полезной нагрузки полезны ещё два термина. T-PDU — это исходные пользовательские данные верхнего уровня, а G-PDU — это T-PDU после добавления заголовка GTP-U. Поэтому по N3 передаётся не просто исходный IP-пакет UE, а G-PDU, инкапсулированный в GTP-U.

GTP-U не ограничивается переносом пользовательских данных. У него есть собственные управляющие сообщения. Поэтому наличие UDP-порта 2152 в захвате пакетов не означает автоматически, что пакет относится к трафику пользовательского приложения. Echo Request, Echo Response, Error Indication, End Marker и другие сообщения GTP-U используют ту же протокольную основу.

Зачем 5G нужен QFI, если уже есть TEID?

Если сначала изучать GTP-U с точки зрения 4G, легко предположить, что для определения bearer достаточно идентифицировать TEID. В 5G такое представление уже неполно.

Архитектура QoS в 4G основана на EPS Bearers. Разные bearers имеют собственные транспортные контексты пользовательской плоскости и туннели GTP-U, поэтому туннель и TEID естественным образом помогают различать трафик разных bearers.

В 5G модель QoS меняется на PDU Session плюс QoS Flow. Одна PDU Session может содержать один или несколько QoS Flow, и один DRB также может переносить один или несколько QoS Flow. Однако N3 не создаёт отдельный туннель GTP-U для каждого QoS Flow в пределах одной PDU Session.

Иными словами, TEID может идентифицировать туннель GTP-U, связанный с PDU Session, но несколько QoS Flow по-прежнему могут совместно использовать этот туннель.

Возникает следующий вопрос: как принимающий узел определяет, к какому QoS Flow относится конкретный пакет?

Это одна из основных причин существования расширенного заголовка PDU Session Container. 5G использует этот расширенный заголовок GTP-U для передачи информации пользовательской плоскости, связанной с PDU Session, включая QFI, или QoS Flow Identifier.

QFI — это 6-битный идентификатор QoS Flow. Поэтому при анализе трафика 5G N3 TEID и QFI можно рассматривать на двух разных уровнях:

TEID идентифицирует туннель GTP-U или контекст PDU Session, а QFI идентифицирует конкретный QoS Flow, передаваемый внутри этого туннеля.

PDU Session Container в нисходящем направлении также может переносить такую информацию, как RQI и PPI. RQI используется для сигнализации, связанной с Reflective QoS, а PPI связан с Paging Policy Differentiation и может обеспечивать различную обработку пейджинга для разных типов трафика в одной PDU Session.

Бит E в базовом заголовке GTP-U указывает, следует ли далее Extension Header. Это означает, что не каждый пакет GTP-U обязательно несёт одинаковый набор расширенных заголовков. Наличие PDU Session Container зависит от конкретного пакета и выполняемой функции.

Что в действительности происходит с пользовательским пакетом N3?

Предыдущие понятия становятся намного понятнее, если рассмотреть их в реальном потоке пакетов восходящего направления.

Предположим, UE обращается к онлайн-видеосервису. UE сначала формирует трафик приложения, который передаётся по TCP или UDP, а затем помещается в обычный IP-пакет. Во внутреннем IP-заголовке исходным адресом является IP-адрес, назначенный UE, а адрес назначения принадлежит серверу интернет-приложения.

Когда пакет достигает gNB, gNB не пересылает IP-пакет UE напрямую в UPF. Вместо этого он выполняет инкапсуляцию GTP-U на основе текущего контекста пользовательской плоскости PDU Session.

Заголовок GTP-U содержит соответствующий TEID. Если в пакете требуется обозначить конкретный QoS Flow, PDU Session Container также может переносить QFI. Затем gNB добавляет UDP-заголовок с портом назначения 2152, после чего добавляется внешний IP-заголовок.

На этом этапе внешние IP-адреса больше не описывают связь между UE и интернетом. Они отражают транспортное взаимодействие между интерфейсом N3 gNB и интерфейсом N3 UPF.

Когда пакет поступает в UPF, процесс выполняется в обратном порядке. UPF принимает пакет на основании внешней транспортной информации, считывает TEID, чтобы найти правильный контекст туннеля пользовательской плоскости, при необходимости обрабатывает QFI и другие расширенные данные, удаляет инкапсуляцию GTP-U, а затем пересылает исходный IP-пакет UE в сторону сети передачи данных.

При поиске неисправностей трафика N3 с помощью Wireshark или другого анализатора пакетов полезно двигаться снаружи внутрь. Сначала проверяются внешние IP-адреса gNB и UPF, затем UDP-порт 2152, после него TEID, при наличии — PDU Session Container и QFI, и только после этого внутренние IP, TCP или UDP пользователя и трафик прикладного уровня.

Такой подход часто эффективнее, чем начало анализа с пакета приложения, поскольку многие неисправности N3 вызваны контекстом туннеля, TEID или проблемами конечных точек, а не самим пользовательским приложением.

Зачем GTP-U нужны собственные управляющие сообщения?

Хотя GTP-U является протоколом пользовательской плоскости, он не ограничивается сообщениями G-PDU с пользовательскими данными. Он также определяет сообщения управления путями и туннелями, которые помогают поддерживать работу транспорта пользовательской плоскости.

Echo Request и Echo Response проверяют доступность пути

Echo Request используется для проверки того, доступны ли GTP Path и удалённый GTP-узел и находятся ли они в рабочем состоянии. Удалённая сторона отвечает сообщением Echo Response.

Эти сообщения проверяют базовую связь между двумя конечными точками GTP. Если gNB многократно не получает Echo Response от UPF, проблема может уже не ограничиваться одним UE или одной PDU Session. Это может указывать на неисправность самого GTP Path или удалённого узла.

GTP-U также определяет сообщение Supported Extension Headers Notification, с помощью которого узел сообщает, какие расширенные заголовки GTP он поддерживает. Это важно, когда функции пользовательской плоскости 5G зависят от таких расширенных заголовков, как PDU Session Container.

Error Indication обрабатывает неизвестные TEID

Если конечная точка GTP получает G-PDU, но не может найти локальный EPS Bearer или контекст PDU Session, соответствующий полученному TEID, и TEID не равен нулю, она может отправить удалённой стороне Error Indication.

Такое сообщение сообщает передающему узлу, что он направляет данные в туннель пользовательской плоскости, который принимающая сторона больше не распознаёт.

Если при диагностике сообщения Error Indication появляются неоднократно, в первую очередь следует проверить согласованность состояния TEID на обоих концах, а также не привели ли обновление PDU Session, процедура мобильности или изменение пути пользовательской плоскости к рассинхронизации сторон.

End Marker помогает завершить переключение пути пользовательской плоскости

End Marker обычно связан с мобильностью и переключением пути пользовательской плоскости. Он указывает, что последний G-PDU по старому пути GTP-U уже отправлен и последующий пользовательский трафик больше не должен продолжать идти по прежнему пути.

Например, когда UE перемещается от исходного gNB к целевому gNB, путь пользовательской плоскости ядра также может измениться. Трафик не должен бесконечно продолжать идти по старому пути, иначе старый и новый пути могут перекрываться и вызывать проблемы с порядком пакетов или пересылкой.

Поэтому End Marker — это не просто уведомление «удалить туннель». Он скорее служит границей старого пути пользовательской плоскости и сообщает принимающей стороне, что последний пакет по этому пути уже доставлен.

Если рассматривать все эти механизмы вместе, роль GTP-U становится намного понятнее. Это не просто протокол, добавляющий TEID перед IP-пакетом пользователя. Он предоставляет полноценную систему туннелирования пользовательской плоскости, которую можно идентифицировать, контролировать, управлять ею и обновлять при изменении состояния сети.

Практическая последовательность диагностики GTP-U в 5G такова: сначала убедиться в исправности конечных точек GTP и Path, затем проверить TEID и контекст Tunnel, при необходимости изучить PDU Session Container и QFI и только после этого переходить к исходному пользовательскому трафику. Если проблема возникает при мобильности или обновлении пути, следует также проверить сообщения Error Indication и End Marker.

Такой порядок превращает захват N3 с большим количеством пакетов UDP 2152 в путь пересылки пользовательской плоскости, который можно восстановить уровень за уровнем.

Часто задаваемые вопросы

Каждый ли пакет на UDP-порту 2152 переносит пользовательский трафик?

Нет. Сообщения G-PDU переносят данные пользовательской плоскости через GTP-U и UDP-порт 2152, но управляющие сообщения GTP-U, такие как Echo Request, Echo Response, Error Indication, End Marker и Supported Extension Headers Notification, используют ту же протокольную основу. Чтобы определить реальное назначение пакета, следует проверить GTP-U Message Type.

Должен ли TEID быть глобально уникальным во всей сети 5G?

Нет. TEID не следует считать глобально уникальным идентификатором для всей сети. Идентификация туннеля GTP-U также зависит от его конечных точек, IP-адресации, транспортной информации и направления. Поэтому при поиске неисправностей необходимо учитывать полный контекст туннеля, а не сравнивать только значения TEID.

Каждый ли пакет GTP-U в 5G содержит PDU Session Container?

Нет. PDU Session Container является расширенным заголовком GTP-U, и его наличие зависит от конкретного пакета и выполняемой функции. Бит E базового заголовка GTP-U указывает, следуют ли дополнительные Extension Headers, поэтому не все пакеты N3 имеют одинаковую структуру заголовков.

Означает ли End Marker освобождение всей PDU Session?

Не обязательно. End Marker главным образом указывает, что трафик по определённому пути пользовательской плоскости GTP-U завершён, и часто встречается при переключении пути после событий мобильности. Он отмечает окончание трафика на этом пути, а не полную процедуру освобождения PDU Session.