GTP - Википедия - GTP

GTP ' (GTP prime) - это IP протокол на основе, используемый в GSM и UMTS сети. Его можно использовать с UDP или же TCP. GTP 'использует ту же структуру сообщения, что и GTP (GTP-C, GTP-U), но в значительной степени это отдельный протокол. GTP 'использует зарегистрированный Порт UDP / TCP 3386.

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

GTP 'используется на интерфейсе Ga в пределах Базовая сеть 3GPP GPRS определение.

GTP 'повторно использует аспекты GTP, хотя, если цитировать 3GPP TS 32.295, «только плоскость сигнализации GTP частично повторно используется».^[1] GTP 'определяет другой заголовок, дополнительные сообщения, значения полей, а также протокол синхронизации, чтобы избежать потери или дублирования. CDR на CGF или SGSN /GGSN отказ. Переданные CDR, если они следуют стандартам 3GPP, кодируются в ASN.1.

Заголовок

Заголовки GTP 'v1 и v2 содержат следующие поля

+	Биты 0-2			3	4	5	6	7	8-15								16-31																32-47
0	Версия			PT [0]	Зарезервированный			HDR Len	Тип сообщения								Длина																Порядковый номер

Версия: Первое поле заголовка в GTP ' пакет 3-битное поле версии. Для GTP 'v2 это значение равно 2 (отсюда и название GTP' v2).
Тип протокола (PT): 1-битное значение, которое отличает GTP '(значение 0) от GTP (значение 1).
Зарезервированный: 3-битное зарезервированное поле (должно быть единиц).
Длина заголовка (Hdr len): 1-битное значение, которое для версии 0 GTP указывает, используется ли 20-байтовый заголовок (значение 0) (согласно GTP ) или этот 6-байтовый заголовок. Этот бит должен быть сброшен (значение 0) для последующих версий GTP, и в них не указывается длина заголовка, поскольку она всегда должна быть 6 байтов.
Тип сообщения: 8-битное поле, указывающее тип сообщения. Возможные значения:

Тип сообщения	Описание
1	Эхо-запрос
2	Эхо-ответ
3	Версия не поддерживается
4	Node Alive Request
5	Узел живой ответ
6	Запрос перенаправления
7	Ответ на перенаправление
240	Запрос на передачу записи данных
241	Ответ передачи записи данных

Длина: 16-битовое поле, в котором указывается длина пакета, инкапсулируемого GTP '(не включая сам заголовок GTP).
Порядковый номер: 16-битное поле, которое однозначно идентифицирует этот пакет и позволяет обнаруживать потерю или дублирование.

Типы сообщений

GTP 'использует сообщения GTP Version Not Supported, Echo Request и Echo Response без изменений, но добавляет следующие сообщения

Node Alive Request
Узел живой ответ
Запрос перенаправления
Ответ на перенаправление
Запрос на передачу записи данных
Ответ передачи записи данных

Node Alive Запрос / ответ

Сообщения Node Alive используются для информирования других сетевых компонентов о том, что узел запустил службу. Запрос отправляется с запуска узла и поэтому обеспечивает более быстрый способ повторного включения службы, чем опрос использование Echo Request / Response делает. Это сообщение также можно использовать для извещения о возобновлении работы других узлов и (в версии 2 GTP) для извещения о IPv6 адрес CGF.

Запрос / ответ перенаправления

Сообщения перенаправления используются для:

отвлечь поток CDR от CDF (SGSN /GGSN ) другому CGF, когда отправитель выводится из эксплуатации (для обслуживания / отказа).
сообщить, что CGF потерял связь с системой ниже по потоку

В любом случае функциям CDF предоставляется больше информации о надвигающемся или немедленном отказе, чем в случае, если бы функция CDF выполняла опрос с использованием сообщений эхо-запроса.

Это сообщение содержит подробную информацию о причине и, возможно, адрес (а) альтернативного CGF.

Запрос / ответ передачи записи данных

Сообщения Data Record Transfer используются для надежной передачи CDR из точки генерации (SGSN /GGSN ) в энергонезависимую память в CGF.

Запрос на передачу записи данных

Каждое сообщение запроса передачи записи данных может содержать сообщение одного из четырех типов:

Отправить пакет записи данных - это сообщение содержит ноль или более CDR. CDR могут быть закодированы в ASN.1 с помощью BER или, реже, PER.
Отправить возможно дублированный пакет записи данных - это сообщение содержит один или несколько CDR, и это сообщение ранее было отправлено другому CGF.
Отменить пакет записи данных - это сообщение предписывает функции CGF удалить один или несколько пакетов записи данных из ожидающей очереди «возможно дублированной» очереди CGF.
Освободить пакет записи данных - это сообщение предписывает CGF записать содержимое одного или нескольких пакетов записи данных из «возможно дублированной» ожидающей очереди CGF.

Существует механизм, позволяющий избежать потери или записи любых повторяющихся CDR. Это подробно описано в 3GPP TS 32.295. Основная предпосылка состоит в том, что каждый пакет упорядочен, и, если он не подтвержден индивидуально, он будет повторно отправлен, пока не будет подтвержден любым CGF. Пакеты обычной записи данных немедленно записываются в энергонезависимое хранилище (например, на диск), но повторно отправленные пакеты помечаются как «возможно дублированные» и попадают в специальную очередь, которая не сразу записывается в энергонезависимое хранилище - второе подтверждение от CDF требуется.

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

Ответ передачи записи данных

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

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

внешняя ссылка

[1] 3GPP TS 32.295

[1]