ГТП'

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 содержат следующие поля

Версия

Первое поле заголовка в пакете GTP' — это 3-битное поле версии. Для GTP' v2 оно имеет значение 2 (отсюда и название GTP' v2).

Тип протокола (PT)

1-битное значение, которое отличает GTP' (значение 0) от GTP (значение 1).

Сдержанный

3-битное зарезервированное поле (должно быть 1).

Длина заголовка (Hdr len)

1-битное значение, которое для версии GTP' 0 указывает, используется ли 20-байтовый заголовок (значение 0) (согласно GTP ) или этот 6-байтовый заголовок. Этот бит должен быть не установлен (значение 0) для последующих версий GTP' и в них не указывает длину заголовка, поскольку она всегда должна быть 6 байт.

Тип сообщения

8-битное поле, указывающее тип сообщения. Возможные значения:

Длина

16-битное поле, в котором указывается длина пакета, инкапсулируемого GTP' (не включая сам заголовок GTP').

Порядковый номер

16-битное поле, которое однозначно идентифицирует этот пакет и позволяет обнаружить потерю или дублирование.

GTP' использует сообщения «Версия GTP не поддерживается», «Эхо-запрос» и «Эхо-ответ» без изменений, но добавляет следующие сообщения

• Запрос на активный узел
• Ответ живого узла
• Запрос на перенаправление
• Ответ на перенаправление
• Запрос на передачу записи данных
• Ответ на передачу записи данных

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

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

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

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

В этом сообщении содержатся сведения о причине и, по желанию, адрес(а) альтернативного CGF.

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

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

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

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

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

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

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

• Прямой доступ к пронумерованным спецификациям 3GPP
• Функция шлюза зарядки с открытым исходным кодом (CGF)