GTP
GTP (англ. GTP prime) — это протокол, основанный на интернет-протоколе, который используется внутри сетей GSM и UMTS. Он может работать поверх дейтграммного протокола пользователя (UDP) или протокола управления передачей (TCP). Протокол GTP' («GTP штрих») использует ту же структуру сообщений, что и протокол туннелирования в передаче данных GTP (GTP-C, GTP-U), однако в значительной степени является отдельным протоколом. Для GTP' закреплён зарегистрированный порт UDP/TCP номер 3386. В отличие от GTP-C, отвечающего за управление сессиями (порт 2123), и GTP-U, предназначенного для передачи пользовательского трафика (порт 2152), GTP' выполняет независимую функцию передачи данных тарификации[1].
GTP' может применяться для передачи данных о тарификации («Charging Data Function», CDF) в сетях GSM или UMTS к функции шлюза тарификации («Charging Gateway Function», CGF). Как правило, речь идёт о передаче информации от множества отдельных элементов сети (например, GGSN) к централизованному серверу, который затем более удобно доставляет данные о тарификации в центр биллинга оператора связи.
GTP' используется на интерфейсе Ga согласно определению ядра сети GPRS (3GPP GPRS core network) стандарта 3GPP. Протокол применяется в сетях 2G, 3G и 4G, тогда как в сетях 5G с сервисно-ориентированной архитектурой (SBA) функциональность GTP' заменена интерфейсом Nchf[2].
GTP' заимствует некоторые аспекты GTP: как отмечается в 3GPP TS 32.295, «только сигнальная часть GTP частично используется повторно»[3]. GTP' определяет собственный заголовок, дополнительные типы сообщений, значения полей, а также протокол синхронизации, предотвращающий потерю или дублирование записей о тарификации (CDR) при отказе CGF, SGSN или GGSN. Передаваемые CDR, согласно стандартам 3GPP, кодируются в формате ASN.1, который остаётся актуальным стандартом для протокола[4].
Заголовок
Заголовки GTP' версий 1 и 2 содержат следующие поля:
| + | Биты 0–2 | 3 | 4 | 5 | 6 | 7 | 8–15 | 16–31 | 32–47 | |||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Версия | PT [0] | Зарезервировано | Длина заголовка | Тип сообщения | Длина | Порядковый номер | |||||||||||||||||||||||||||||||||||||||||
- Версия
- Первое поле в заголовке GTP' пакета — это 3-битное поле версии. Для GTP' версии 2 это значение равно 2 (что дало название версии GTP' v2).
- Тип протокола (PT)
- 1-битовое значение, которое различает GTP' (значение 0) и GTP (значение 1).
- Зарезервировано
- 3-битовое зарезервированное поле (должно быть выставлено в 1).
- Длина заголовка
- 1-битовое поле; для версии GTP' 0 указывает, используется ли 20-байтный заголовок (значение 0, как в GTP), либо сокращённый 6-байтный заголовок. Для последующих версий GTP' это поле всегда должно быть обнулено, а длина заголовка всегда равна 6 байтам.
- Тип сообщения
- 8-битовое поле, определяющее тип сообщения. Возможные значения:
| Тип сообщения | Описание |
|---|---|
| 1 | Echo Request (Запрос эха) |
| 2 | Echo Response (Ответ на запрос эха) |
| 3 | Version Not Supported (Версия не поддерживается) |
| 4 | Node Alive Request (Запрос о работоспособности узла) |
| 5 | Node Alive Response (Ответ о работоспособности узла) |
| 6 | Redirection Request (Запрос перенаправления) |
| 7 | Redirection Response (Ответ на запрос перенаправления) |
| 240 | Data Record Transfer Request (Запрос передачи записей) |
| 241 | Data Record Transfer Response (Ответ на запрос передачи записей) |
- Длина
- 16-битовое поле, указывающее длину инкапсулируемого GTP' пакета (без учёта самого заголовка GTP').
- Порядковый номер
- 16-битовое поле, которое однозначно идентифицирует данный пакет и позволяет выявлять потерю или дублирование.
Типы сообщений
GTP' использует стандартные для GTP сообщения «Version Not Supported», «Echo Request» и «Echo Response» без изменений, но добавляет следующие типы:
- Node Alive Request (Запрос о работоспособности узла)
- Node Alive Response (Ответ о работоспособности узла)
- Redirection Request (Запрос перенаправления)
- Redirection Response (Ответ на запрос перенаправления)
- Data Record Transfer Request (Запрос передачи записей)
- Data Record Transfer Response (Ответ на запрос передачи записей)
Сообщения Node Alive («узел в сети») используются для информирования других компонентов сети о том, что узел начал работу. Запрос отправляется от запускаемого узла и обеспечивает более быструю реактивацию сервиса, чем опрос с использованием Echo Request/Echo Response. Это сообщение также может использоваться для уведомления о возвращении в работу других узлов, и (в версии GTP' v2) для сообщения IPv6-адреса CGF. В отличие от механизма Echo Request, который применяется для активного опроса пиринговых узлов и обнаружения сбоев, Node Alive представляет собой проактивное уведомление о восстановлении узла после сбоя или перезагрузки[4].
Сообщения перенаправления используются для:
- переадресации потока CDR с CDF (SGSN/GGSN) на другой CGF при выводе исходящего узла из эксплуатации (по причине обслуживания или сбоя);
- сообщения о том, что CGF потерял соединение с нижестоящей системой.
В обоих случаях CDF получает больше информации о предстоящей или уже наступившей ошибке, чем при опросе посредством Echo Request.
Данное сообщение содержит детали о причине событий, а также, при необходимости, адрес или адреса альтернативного CGF.
Сообщения передачи записей используются для надёжной транспортировки CDR от точки их генерации (SGSN/GGSN) к энергонезависимой памяти в CGF.
Каждое сообщение Data Record Transfer Request может нести один из четырёх типов сообщений:
- Отправка пакета с записями данных — сообщение содержит одну или несколько CDR. Для кодирования может использоваться ASN.1 c базовыми правилами кодирования или, реже, сжатыми правилами.
- Отправка, возможно, дублированного пакета записей — сообщение содержит одну или несколько CDR и ранее могло быть отправлено другому CGF.
- Отмена пакета записей — сообщение предписывает CGF удалить один или несколько пакетов записей из очереди «возможно дублированных» сообщений.
- Подтверждение пакета записей — сообщение обязывает CGF сохранить содержимое одного или нескольких пакетов записей из очереди «возможно дублированных».
Для предотвращения потерь или дублирования CDR реализован специальный механизм: каждое сообщение получает уникальный порядковый номер, и если не подтверждено явно, оно отправляется повторно, пока не будет получено подтверждение от любого CGF. Обычные пакеты записей немедленно сохраняются в энергонезависимой памяти (например, на диск), тогда как повторные помечаются как «возможно дублированные» и попадают в особую очередь — их запись возможна только после получения второго подтверждения с CDF. Надёжность доставки обеспечивается индивидуальным подтверждением каждого сообщения (запрос-ответ), а не механизмом скользящего окна (windowing)[4].
Возможность отправки запроса передачи без CDR используется для проверки того, успешно ли CGF уже сохранил записи, связанные с данным порядковым номером; это важная часть описанного механизма.
Сообщение Data Record Transfer Response подтверждает приём одного или нескольких сообщений передачи записей; ответы могут быть сгруппированы для повышения эффективности, но должны отправляться чаще, чем таймаут исходящей стороны (CDF).
В подтверждении указывается причина, и возможно отклонение переданных записей. Успешное сохранение подтверждается значением «Request Accepted» в поле причины (Cause). При этом CGF обязан обеспечить безопасное сохранение данных в энергонезависимую память до отправки данного ответа[4].
Безопасность
Протокол GTP' изначально не имеет встроенных механизмов шифрования и аутентификации[5]. Безопасность передачи данных тарификации обеспечивается за счёт изоляции сети оператора и применения протокола IPsec на сетевом уровне в рамках архитектуры безопасности домена сети (NDS/IP)[6]. Кроме того, для защиты инфраструктуры от подмены данных и атак типа «отказ в обслуживании» (DoS) используются специализированные межсетевые экраны (GTP Firewall)[5].
Примечания
Литература
- 3GPP TS 32.295