UMTS - протокол туннелирования GPRS
Создание протокола туннелирования 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 not и MME |
| 6/7 | Запрос на уведомление / ответ | Используется для уведомления о туннелировании на S101 между узлом доступа HRPD и MME |
| 25/26 | SRVCC PS в запрос CS | Используется для запуска и подтверждения инициации SRVCC между SGSN / MME и сервером MSC |
| 27/28 | SRVCC PS to 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 PDCP - относится к передаче характеристики без потерь; в этом случае пакеты данных должны быть пронумерованы в EPC (два октета).
Улучшение заключается в возможности передавать "конечный рынок" в плоскости пользователя. Он используется в процедуре хэндовера между eNodeB и указывает, что путь активирован сразу после пакета данных, например, эта функция не требуется до версии 8, поскольку GTP-U не завершился радиодоступом. node (т.е. не в BS или NodeB) существует только несколько сообщений. GTPv1-U, и они перечислены в таблице выше.
Понятно, что на самом деле через GTPv1-U возможна очень ограниченная передача сигналов (механизмы эха и маркировка концов). Единственное сообщение о том, что передача реальных данных пользователя относится к типу 255, так называемое сообщение G-PDU; единственная часть информации, которую он несет после заголовка, - это исходный пакет данных от пользователя или внешнего оборудования PDN.
Не все экземпляры туннелей GTP-U перечислены в эталонной архитектуре (целью которой было зафиксировать связи, которые больше не существовали между узлами сети); возможны временные туннели -
Между двумя обслуживающими GW, применимыми для передачи на основе S1, в случае, если услуга перемещается GW;
Между двумя SGSN, соответствует предыдущему случаю, но в унаследованной сети PS;
Между двумя RNC, применимыми для перемещения RNC в сети 3G PS (не имеет отношения к EPC, он упоминается здесь только для полноты).