Протокол туннелирования GPRS

Протокол туннелирования GPRS ( GTP ) — это группа IP связи на основе протоколов , используемых для передачи услуг пакетной радиосвязи общего пользования (GPRS) в GSM , UMTS , LTE и 5G NR радиосетях . В архитектурах 3GPP интерфейсы на основе GTP и Proxy Mobile IPv6 указаны в различных точках интерфейса.

GTP можно разложить на отдельные протоколы: GTP-C, GTP-U и GTP' .

GTP-C используется в базовой сети GPRS для передачи сигналов между шлюзовыми узлами поддержки GPRS (GGSN) и обслуживающими узлами поддержки GPRS (SGSN). Это позволяет SGSN активировать сеанс от имени пользователя ( активация контекста PDP ), деактивировать тот же сеанс, настраивать параметры качества обслуживания или обновлять сеанс для абонента, который только что прибыл из другого SGSN.

GTP-U используется для передачи пользовательских данных внутри базовой сети GPRS и между сетью радиодоступа и базовой сетью. Передаваемые пользовательские данные могут представлять собой пакеты в любом из форматов IPv4 , IPv6 или PPP .

GTP’ ( GTP prime ) использует ту же структуру сообщения, что и GTP-C и GTP-U, но имеет независимую функцию. Его можно использовать для передачи данных о зарядке от функции данных о зарядке (CDF) сети GSM или UMTS к функции шлюза зарядки (CGF). В большинстве случаев это должно означать переход от многих отдельных сетевых элементов, таких как GGSN, к централизованному компьютеру, который более удобно доставляет данные о зарядке в расчетный центр сетевого оператора.

Различные варианты GTP реализуются RNC, SGSN, GGSN и CGF в сетях 3GPP. Мобильные станции GPRS (MS) подключаются к SGSN, не зная о GTP.

GTP можно использовать с UDP или TCP . UDP либо рекомендуется, либо обязателен, за исключением туннелирования X.25 в версии 0. GTP версии 1 используется только для UDP.

Общие характеристики

Все варианты GTP имеют определенные общие черты. Структура сообщений одинакова: заголовок GTP следует за заголовком UDP/TCP.

ГТП версии 1

Заголовки GTPv1 содержат следующие поля: ^[1]

+	0-2	3	4	5	6	7	8-15	16-23	24-31
0	Версия	Тип протокола	Сдержанный	Флаг заголовка расширения	Флаг порядкового номера	Флаг номера N-PDU	Тип сообщения	Длина сообщения
32	ТЫ
64	Порядковый номер							Номер N-PDU	Тип заголовка следующего расширения

Версия: Это 3-битное поле. Для GTPv1 это значение равно 1.
Тип протокола (PT): 1-битное значение, которое отличает GTP (значение 1) от GTP' (значение 0).
Сдержанный: 1-битное зарезервированное поле (должно быть 0).
Флаг заголовка расширения (E): 1-битное значение, указывающее, имеется ли необязательное поле заголовка расширения.
Флаг порядкового номера (S): 1-битное значение, указывающее, имеется ли необязательное поле порядкового номера.
Флаг номера N-PDU (PN): 1-битное значение, указывающее, имеется ли необязательное поле номера N-PDU.
Тип сообщения: 8-битное поле, указывающее тип сообщения GTP. Различные типы сообщений определены в разделе 7.1 3GPP TS 29.060.
Длина сообщения: 16-битное поле, указывающее длину полезных данных в байтах (остальная часть пакета следует за обязательным 8-байтовым заголовком GTP). Включает необязательные поля.
Идентификатор конечной точки туннеля (TEID): 32-битное (4-октетное) поле, используемое для мультиплексирования различных соединений в одном туннеле GTP.
Порядковый номер: (необязательное) 16-битное поле. Это поле существует, если включен любой из битов E, S или PN. Поле должно интерпретироваться только в том случае, если бит S включен.
Номер N-PDU: (необязательное) 8-битное поле. Это поле существует, если включен любой из битов E, S или PN. Поле должно интерпретироваться только в том случае, если бит PN включен.
Тип заголовка следующего расширения: (необязательное) 8-битное поле. Это поле существует, если включен любой из битов E, S или PN. Поле должно интерпретироваться только в том случае, если бит E включен.

Следующие заголовки расширений следующие:

+	Биты 0–7	8-23	24-31
0	Длина удлинения	Содержание
...	...
...	Содержание		Следующий заголовок расширения

Длина удлинения: 8-битное поле. В этом поле указывается длина этого заголовка расширения, включая длину, содержимое и следующее поле заголовка расширения, в модулях по 4 октета, поэтому длина расширения всегда должна быть кратна 4.
Содержание: содержимое заголовка расширения.
Следующий заголовок расширения: 8-битное поле. Он указывает тип следующего расширения или 0, если следующего расширения не существует. Это позволяет объединить несколько заголовков следующих расширений.

ГТП версии 2

Он также известен как развитый GTP или eGTP. Заголовки GTPv2-C содержат следующие поля: ^[2]

+	Бит 0-2	3	4	5-7	8-15	16-23	24-31
0	Версия	Совмещенный флаг (P)	Флаг TEID (T)	Запасной	Тип сообщения	Длина сообщения
32	TEID (присутствует только если T=1)
64 (32, если TEID отсутствует)	Порядковый номер						Запасной

Протокола GTPv2-U нет, GTP-U в LTE также использует GTPv1-U.

Версия: Это 3-битное поле. Для GTPv2 это значение равно 2.
Флаг контрейлерной связи: Если этот бит установлен в 1, то в конце текущего сообщения должно присутствовать другое сообщение GTP-C со своим собственным заголовком. Существуют ограничения на то, какой тип сообщения может быть передан в связке, в зависимости от того, какое сообщение GTP-C верхнего уровня.
Флаг ТЕЙД: Если этот бит установлен в 1, то поле TEID будет присутствовать между длиной сообщения и порядковым номером. Для всех сообщений, кроме Echo и Echo-ответа, требуется присутствие TEID.
Длина сообщения: В этом поле указывается длина сообщения в октетах, исключая обязательный заголовок GTP-C (первые 4 октета). TEID (если присутствует) и порядковый номер должны быть включены в подсчет длины.

Механизмы подключения

Помимо общей структуры сообщения, существует также общий механизм проверки соединения от одного GSN к другому GSN. При этом используются два сообщения.

эхо-запрос
эхо-ответ

Каждые 60 секунд GSN может отправлять эхо-запрос всем остальным GSN, с которыми он имеет активное соединение. Если другой конец не отвечает, его можно считать отключенным, и активные соединения с ним будут удалены.

Помимо двух ранее упомянутых сообщений, нет других сообщений, общих для всех вариантов GTP. ^[3] это означает, что по большей части они фактически образуют три совершенно отдельных протокола.

ГТП-С - контроль ГТП

Протокол GTP-C — это раздел управления стандарта GTP. Когда подписчик запрашивает контекст PDP , SGSN отправит сообщение GTP-C запроса создания контекста PDP на GGSN, предоставляя подробную информацию о запросе подписчика. Затем GGSN ответит ответным сообщением GTP-C о создании контекста PDP , которое либо предоставит подробную информацию о фактически активированном контексте PDP, либо укажет на сбой и укажет причину этого сбоя. Это UDP-сообщение на порту 2123.

Протокол eGTP-C (или GTPv2-C) отвечает за создание, обслуживание и удаление туннелей на нескольких интерфейсах Sx. Он используется для управления маршрутами плоскости управления, управления туннелями и управления мобильностью. Он также контролирует пересылку сообщений о переезде; Контекст SRNS и создание прямых туннелей во время передачи обслуживания между LTE.

GTP-U — туннелирование пользовательских данных GTP

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

Отдельные туннели идентифицируются по TEID (идентификатору конечной точки туннеля) в сообщениях GTP-U, который должен представлять собой динамически выделяемое случайное число. Если это случайное число имеет криптографическое качество, оно обеспечит определенную степень защиты от определенных атак. Несмотря на это, требование стандарта 3GPP заключается в том, что весь трафик GTP, включая пользовательские данные, должен отправляться внутри защищенных частных сетей, а не напрямую подключенных к Интернету. Это происходит на порту UDP 2152.

Протокол GTPv1-U используется для обмена пользовательскими данными через туннели GTP через интерфейсы Sx. IP-пакет для UE (конечная точка пользователя) инкапсулируется в пакет GTPv1-U и туннелируется между P-GW и eNodeB для передачи в отношении UE через интерфейсы S1-U и S5/S8.

GTP' - передача начисления

Протокол GTP используется для передачи данных о зарядке в функцию шлюза оплаты. GTP использует порт TCP/UDP 3386.

В базовой сети GPRS

GTP — это основной протокол, используемый в базовой сети GPRS. Это протокол, который позволяет конечным пользователям сетей GSM или UMTS перемещаться с места на место, продолжая при этом подключаться к Интернету, как если бы они находились в одном месте в GGSN. Это делается путем переноса данных абонента из текущего SGSN абонента в GGSN, который обрабатывает сеанс абонента. В базовой сети GPRS используются три формы GTP.

GTP-U для передачи пользовательских данных в отдельных туннелях для каждого контекста PDP
GTP-C по причинам контроля, включая:
- настройка и удаление контекстов PDP
- проверка достижимости ГСН
- обновления; например, когда абоненты переходят от одного SGSN к другому.
GTP' для передачи данных о начислении платы от GSN на функцию начисления платы.

GGSN и SGSN (вместе называемые GSN) прослушивают сообщения GTP-C через порт UDP 2123 и сообщения GTP-U через порт 2152. Эта связь происходит внутри одной сети или может, в случае международного роуминга, происходить на международном уровне, вероятно. через роуминговую станцию GPRS (GRX).

Функция шлюза оплаты (CGF) прослушивает сообщения GTP, отправленные из сетей GSN через порт TCP/UDP 3386. Базовая сеть отправляет информацию о оплате в CGF, обычно включая время активации контекста PDP и количество данных, переданных конечным пользователем. . Однако эта связь, происходящая внутри одной сети, менее стандартизирована и, в зависимости от производителя и параметров конфигурации, может использовать собственную кодировку или даже полностью собственную систему.

Использование на интерфейсе IuPS

GTP-U используется в IuPS между базовой сетью GPRS и RAN, однако протокол GTP-C не используется. В этом случае RANAP используется в качестве протокола управления и устанавливает туннели GTP-U между SGSN и контроллером радиосети (RNC).

Стек протоколов

Протоколы приложений

IP (пользователь)

ГТП

UDP

ИП

Уровень 2 (например, WAN или Ethernet)

Стек протоколов GTP-U

GTP можно использовать с UDP или TCP . GTP версии 1 используется только в UDP.

По состоянию на 2018 год ^[update] определены три версии: версии 0, 1 и 2. Версия 0 и версия 1 значительно различаются по структуре. В версии 0 протокол сигнализации (протокол, который устанавливает туннели путем активации контекста PDP) объединен с протоколом туннелирования на одном порту. Каждая из версий 1 и 2 фактически представляет собой два протокола: один для управления (называемый GTP-C), а другой для туннелирования пользовательских данных (называемый GTP-U). Версия GTP 2 отличается от версии 1 только в GTP-C. Это связано с тем, что 3GPP определяет усовершенствования GTP-C для EPS в версии 2 для улучшения обработки носителя.

GTP-U также используется для транспортировки пользовательских данных от RNC к SGSN в сетях UMTS. Однако в этом случае передача сигналов осуществляется с использованием RANAP вместо GTP-C.

Исторические версии GTP

Исходная версия GTP (версия 0) имела существенные отличия от текущих версий (версии 1,2):

идентификация туннеля была неслучайной;
были предусмотрены варианты транспортировки X.25 ;
фиксированный номер порта 3386 использовался для всех функций (а не только для зарядки, как в GTPv1);
TCP был разрешен в качестве варианта транспорта вместо UDP, но его поддержка была необязательной;
Поля, связанные с подпиской, такие как качество обслуживания, были более ограниченными.

Неслучайный TEID в версии 0 представлял собой проблему безопасности, если злоумышленник имел доступ к сети любого партнера по роумингу или мог найти другой способ удаленной отправки пакетов в магистраль GPRS. Версия 0 выходит из употребления и заменяется версией 1 почти во всех сетях. К счастью, использование разных номеров портов позволяет легко заблокировать версию 0 с помощью простых списков IP-доступа.

Стандартизация ГТП

Первоначально GTP был стандартизирован в рамках ETSI (стандарт GSM 09.60). ^[4]). С созданием стандартов UMTS он был перенесен в 3GPP , который с 2005 г. ^[update] поддерживает его как стандарт 3GPP 29.060. ^[5] GTP использует тот же формат сообщений, но его особые применения описаны в стандарте 32.295 вместе со стандартизированными форматами передаваемых данных о начислении платы.

В более поздних версиях TS 29.060 взаимодействие GTPv1/v0 прекращено. ^[6] таким образом, чтобы не было резервного варианта в случае, если GSN не поддерживает более высокую версию.

GTPv2 (для развитых пакетных сервисов) был разработан в начале 2008 года и выпущен в декабре того же года. GTPv2 предлагает возврат к GTPv1 через более ранний механизм «Версия не поддерживается», но явно не предлагает поддержки возврата к GTPv0.

См. также

Примечания

^ 3GPP TS 29.060, раздел 6
^ 3GPP TS 29.274, раздел 5
^ 3GPP TS 29.060, раздел 7
^ «3GPP TS 09.60, версия 7.10.0, выпуск 1998» (PDF) . etsi.org .
^ «3GPP TS 29.060 v16.0.0» (PDF) . etsi.org .
^ «3GPP TS 29.060 v16.0.0, раздел 4.2» (PDF) . etsi.org .

Ссылки

Стандарт GSM 09.60, ETSI, 1996–98, этот стандарт охватывает исходную версию 0 GTP.
3GPP TS 29.060 V6.9.0 (2005-06) , Проект партнерства 3-го поколения, 650 Route des Lucioles - София Антиполис, Вальбонн - ФРАНЦИЯ, 2005–06. Это основной стандарт, определяющий все варианты GTP для GTP версии 1.
3GPP TS 32.295 V6.1.0 (2005-06) , Проект партнерства 3-го поколения, 650 Route des Lucioles - София Антиполис, Вальбонн - ФРАНЦИЯ, 2005–06. Этот стандарт охватывает использование GTP для зарядки.
3GPP TS 29.274 V8.1.0 (2009-03) , Проект партнерства 3-го поколения, 650 Route des Lucioles - София Антиполис, Вальбонн - ФРАНЦИЯ, 2009–03. GTPv2 для развитого GPRS.

Внешние ссылки

[1] 3GPP TS 29.060, раздел 6

[2] 3GPP TS 29.274, раздел 5

[3] 3GPP TS 29.060, раздел 7

[4] «3GPP TS 09.60, версия 7.10.0, выпуск 1998» (PDF) . etsi.org .

[5] «3GPP TS 29.060 v16.0.0» (PDF) . etsi.org .

[6] «3GPP TS 29.060 v16.0.0, раздел 4.2» (PDF) . etsi.org .

[1]

[2]

[3]

[4]

[5]

[6]