Создание протокола туннелирования GPRS (GTP) было практически невозможно, но также нежелательно давать его для новой системы, но, с другой стороны, вполне понятно, что необходимы улучшения, чтобы иметь возможность взаимодействовать с миром устаревших PS гладко и функции поддержки, необходимые для новейшей системы.
Туннельный протокол GPRS (GTP)
Протокол GTP предназначен для туннелирования и инкапсуляции блоков данных и управляющих сообщений в GPRS. Со времени его разработки в конце 1990-х годов он был развернут в широком масштабе, и накоплен солидный опыт.
GTP для системы Evolved 3GPP доступен в двух вариантах: для управления и для пользователя. GTP-C управляет сигнализацией плоскости управления, и это необходимо в дополнение к протоколу передачи данных о чистоте пользователя, GTP-U; это называется плоскостью пользователя. Текущими версиями, подходящими для EPS, являются GTPv1 US и GTPv2-C.
Особенность GTP заключается в том, что он поддерживает разделение трафика внутри своего основного держателя туннеля GTP или, другими словами, возможность группировать их вместе и обрабатывать несущих. Концы туннелей GTP идентифицируются с помощью TEID (идентификаторов конечных точек туннелей); они назначаются на локальный уровень для восходящей линии связи и нисходящей линии связи одноранговыми объектами и передаются попеременно между ними. TEID используются с разной степенью детализации на конкретном примере соединения PDN на S5 и S8 и EU на интерфейсах S3 / S4 / S10 / S11.
Плоскость управления протоколом туннелирования GPRS
GTPv2-C используется на интерфейсах сигнализации EPC (включая SGSN, по крайней мере, отн. 8). Например —
- S3 (между SGSN и MME),
- S4 (между SGSN и обслуживающим GW),
- S5 и S8 (между обслуживающим GW и PDN GW),
- S10 (между двумя MME) и
- S11 (между MME и обслуживающим GW).
В соответствии с этим, типичному блоку данных протокола GTPv2-C, как показано на рисунке выше, конкретной части GTP предшествуют заголовки IP и UDP, она состоит из заголовка GTPv2-C и части, содержащей информацию переменной GTPv2-C в количестве, длина и формат, в зависимости от типа сообщения. Поскольку эхо и уведомление о версии протокола не поддерживаются, информация TEID отсутствует. Версия явно установлена на 2 в этой версии протокола.
GTP имел сложный устаревший механизм расширений заголовков; он не используется в большинстве GTPv2-C. Тип сообщения определяется вторым байтом (поэтому для будущих расширений можно определить максимум 256 сообщений). Ниже в таблице представлен обзор сообщений, определенных в настоящий момент GTPv2-C. Длина сообщения кодируется в байтах 3 и 4 (измеряется в байтах и не содержит самих первых четырех байтов).
TEID — это идентификатор конечной точки туннеля, одно значение на противоположной / принимающей стороне; это позволяет мультиплексировать и демультиплексировать туннели на одном конце в очень частых случаях через GTP-туннель.
| Тип сообщения | Сообщение | Дополнительное объяснение |
|---|---|---|
| 0 | Зарезервированный | Никогда не должен использоваться (преднамеренно исключен из протокола, чтобы обеспечить явную настройку) |
| 1/2 | Эхо-запрос / ответ | Используется для проверки, поддерживается ли версия GTP отправляющим узлом. |
| 3 | Версия не поддерживается | Содержит последнюю версию GTP, поддерживаемую отправляющим узлом. |
| 4/5 | Прямой запрос на передачу / ответ | Используется для туннелирования сигнального сообщения на интерфейсе S101 для оптимизированной передачи обслуживания, между доступом HRPD нет и MME |
| 6/7 | Запрос / ответ на уведомление | Используется для туннельного уведомления на S101 между узлом доступа HRPD и MME |
| 25/26 | Запрос SRVCC PS на CS | Используется для запуска и подтверждения инициации SRVCC между SGSN / MME и сервером MSC |
| 27/28 | SRVCC PS в CS завершить уведомление | Используется для указания и подтверждения завершения SRVCC между сервером MSC и SGSN / MME |
| 32/33 | Создать запрос сеанса | Используется для установления соединения между двумя узлами |
| 34/35 | Изменить запрос на предъявителя | Используется для изменения свойств одного или нескольких каналов-носителей, включая контекстную информацию канала-носителя |
| 36/37 | Удалить запрос сеанса | Срывает контрольную сессию GTP |
| 38/39 | Запрос на изменение уведомления | Используется для сообщения информации о местоположении |
| 66/67 | Удалить команду передачи / индикация отказа | Поручить узлам удалить канал и подтвердить обратно |
| 68/69 | Команда ресурса носителя / индикация сбоя | Используется для распределения или изменения ресурсов |
| 73 | Индикация остановки пейджинга | Отправляется из SGW в MME или SGSN |
| 95/96 | Создать запрос / ответ на предъявителя | Поручить узлам установить носители и подтвердить обратно |
| 97/98 | Обновить запрос на предъявителя | Используется для информирования узлов плоскости управления от плоскости пользователя об изменениях канала-носителя |
Улучшенная GTPv1-U
Только небольшое, но эффективное улучшение было применено к GTP-U, и для этого не было сочтено необходимым усиливать количество версий протокола. Таким образом, мы все еще ожидаем GTPv1-U, но, по крайней мере, это последняя версия Rel. 8.
Стек протоколов, по сути, такой же, как и для GTPv2-C, только с соответствующими названиями уровней и протоколов. Механизм расширения заголовка остается на месте; это позволяет вставить два элемента при необходимости.
-
UDP-порт источника инициирующего сообщения (два октета);
-
PDU PDU номер — относится к передаче характеристики без потерь; в этом случае пакеты данных должны быть пронумерованы в EPC (два октета).
UDP-порт источника инициирующего сообщения (два октета);
PDU PDU номер — относится к передаче характеристики без потерь; в этом случае пакеты данных должны быть пронумерованы в EPC (два октета).
Улучшение заключается в способности передавать «конечный рынок» в плоскости пользователя. Он используется в процедуре передачи обслуживания между eNodeB и дает указание на то, что путь активируется сразу после пакета данных, например, функция не является необходимой для предварительной версии 8, поскольку GTP-U не заканчивался в радиодоступе узел (то есть не в BS или NodeB) существует только несколько сообщений. GTPv1-U, и они перечислены в таблице выше.
Ясно, что на самом деле очень ограниченный тип передачи сигналов возможен через GTPv1-U (механизмы эха и маркировка конца). Единственное сообщение о том, что передача реальных пользовательских данных имеет тип 255, так называемое сообщение G-PDU; единственная часть информации, которую он несет, после заголовка — это исходный пакет данных от пользователя или внешнего оборудования PDN.
Не все экземпляры туннелей GTP-U перечислены в эталонной архитектуре (которая предназначена для захвата ассоциаций, которые больше не существуют между узлами сети); возможны временные тоннели —
Между двумя обслуживающими GW, применимыми для передачи на основе S1, в случае, если услуга перемещена GW;
Между двумя SGSN, соответствует предыдущему случаю, но в традиционной сети PS;
Между двумя RNC, применимыми для перемещения RNC в сети 3G PS (никакого отношения к EPC, здесь упоминается только для полноты).