Механизм расширения ie типа в gtp
Изобретение относится к Протоколу туннелирования (GTP) общей службы пакетной радиосвязи (GPRS). Технический результат изобретения заключается в повышении эффективности использования информационных элементов IEs в GTP сообщениях. Способ, реализуемый узлом основной сети (200, 300, 400, 500), для формирования сообщения протокола туннелирования (GTP) общей службы пакетной радиосвязи (GPRS), при этом GTP сообщение содержит GTP заголовок, за которым следует по меньшей мере один информационный элемент IE, ассоциированный с конкретным IE типом в наборе заданных IE типов, и при этом IE содержит множество полей, в которых конкретный IE тип идентифицируют значением, закодированным в поле заданного IE типа в первом октете IE, причем способ содержит этапы, на которых: осуществляют резервирование (1110) поля расширения IE типа в четвертом и пятом октетах IE или в пятом и шестом октетах IE для обеспечения определения дополнительного набора новых IE типов, являющегося расширением конкретного IE типа; и конфигурирование (1120) зарезервированного поля расширения IE типа для определения по меньшей мере одного нового IE типа в дополнение к заданному набору IE типов. 2 н. и 8 з.п. ф-лы, 12 ил.
Область техники, к которой относится изобретение
Настоящее изобретение относится к способам и основным сетевым узлам для формирования и отправки сообщения протокола туннелирования (GTP) общей службы пакетной радиосвязи (GPRS), содержащего GTP заголовок, за которым следует по меньшей мере один информационный элемент IE, содержащий множество полей.
Уровень техники
Протокол туннелирования (GTP) общей службы пакетной радиосвязи (GPRS) является широко известным протоколом, используемым для установки GTP туннелей между узлами для разделения трафика на различные потоки связи.
Как известно, в GTP версии 1 (GTPv1) GTP туннели, например, устанавливают через Gn интерфейс между GPRS узлами поддержки (GSNs), такими как узлы поддержки обслуживания GPRS (SGSNs) и узлами поддержки функций шлюза GPRS (GGSNs) в рамках наземной сети мобильной связи общего пользования (PLMN) и через Gp интерфейс между GSNs в различных PLMNs.
В GTP версии 2 (GTPv2), которая модифицирует и расширяет GTPv1, используемая в 2G и 3G сетях мобильной связи, и обычно упоминается как усовершенствованный GTP (eGTP) для использования в сети развитого ядра пакетной коммутации (EPC) в системе «Долгосрочное развитие» (LTE), GTP туннели устанавливают между различными интерфейсами, такими как S5/S8 интерфейс между обслуживающим шлюзом (SGW) и шлюзом сети пакетной передачи данных (PGW), S11 интерфейс между узлом управления мобильностью (MME) и SGW, S2b интерфейс между усовершенствованным шлюзом пакетных данных (ePDG) и PGW и т.д.
GTP сообщение состоит из заголовка, за которым следуют ноль или более информационных элементов (IEs). Заголовок определяет, например, GTP версию, общую длину сообщения и идентификатор конечной точки туннеля. В GTPv2 используют 256 различных IE типов, каждый IE тип идентифицируется значением IE типа от 0 до 255.
Значение IE типа определяет большое разнообразие характеристик сообщений, например, идентификатор оборудования мобильной связи (MEI) - значение 75, информация о местоположении пользователя (ULI) - значение 86, контекст канала - значение 93, идентификатор потока пакетов - значение 123 и т.д., см., например, техническую спецификацию 3GPP TS 29.274 V13.2.0.
В последнее время, для реализации новых признаков «Проекта партнерства 3-го поколения» (3GPP) в GTPv1 и GTPv2 протокола, указано большое количество новых IE типов, что приводит к уменьшению (возможно, менее 20 в GTPv1 и, возможно, менее 50 в GTPv2) новых IE типов, оставленных как резервные IE. Что повышает риск предоставления эффективной поддержки многих признаков в GTPv2 протокола в будущем.
Раскрытие сущности изобретения
Задачей настоящего изобретения является решение или, по меньшей мере, частичное решение одной или нескольких технических задач в данной области техники, как указано выше, и предоставление способа и узла основной сети для повышения эффективности использования IEs в GTP сообщениях.
В первом аспекте настоящего изобретения упомянутую техническую задачу решают способом, выполняемым в узле основной сети формирования GTP сообщения, в котором GTP сообщение содержит GTP заголовок, за которым следует, по меньшей мере, один IE, ассоциированный с конкретным IE типом в наборе заданных IE типов, и при этом IE содержит множество полей, в которых идентифицируют конкретный IE тип посредством значения, закодированного в поле заданного IE типа в первом октете IE. Этот способ содержит резервирование поля расширения IE типа в четвертом и пятом октетах IE или в пятом и шестом октетах IE для предоставления определения дополнительного набора новых IE типов, являющимися расширением конкретного IE типа; и конфигурирование зарезервированного поля расширения IE типа для определения, по меньшей мере, одного нового IE типа в дополнение к заданному набору IE типов.
Во втором аспекте настоящего изобретения упомянутую задачу решают посредством узла основной сети, выполненного с возможностью эффективно формировать GTP сообщение, при этом GTP сообщение содержит GTP заголовок, за которым следует, по меньшей мере, один IE, ассоциированный с конкретным IE типом в наборе заданных IE типов, и при этом, IE содержит множество полей, в которых конкретный IE тип идентифицируют значением, закодированным в поле заданного IE типа в первом октете IE. Узел основной сети содержит память с инструкциями, и процессор, выполненный с возможностью эффективно выполнять инструкции, чтобы: зарезервировать поле расширения IE типа в четвертом и пятом октетах IE или в пятом и шестом октетах IE для обеспечения определения дополнительного набора новых IE типов, являющихся расширением конкретного IE типа; и сконфигурировать зарезервированное поле расширения IE типа для определения, по меньшей мере, одного нового IE типа в дополнение к заданному набору IE типов.
Таким образом, посредством резервирования одного или более полей для обеспечения определения дополнительного набора новых IE типов, являющихся расширением конкретного IE типа; и конфигурирования зарезервированного одного или более полей для определения, по меньшей мере, одного нового IE типа в дополнение к заданному набору IE типов, может быть предпочтительно предоставлено более двоичных битов для определения дополнительных IE типов.
Следует отметить, что описанное здесь решение со ссылкой на иллюстративные варианты осуществления относится ко всем возможным сочетаниям признаков, приведенных в формуле изобретения. Дополнительные признаки и преимущества настоящего изобретения станут очевидными при изучении прилагаемой формулы изобретения и последующего описания. Специалисты в данной области техники понимают, что для формирования вариантов осуществления, отличных от описанных ниже, различные признаки настоящего изобретения могут быть объединены.
Краткое описание чертежей
Вышеизложенное будет очевидным из следующего более подробного описания примерных вариантов осуществления, как проиллюстрировано на прилагаемых чертежах, на которых одинаковые ссылочные позиции относятся к одинаковым частям, показанных на разных видах.
Фиг.1 является схематической примерной иллюстрацией хорошо известной LTE архитектуры для 3GPP доступа в рамках усовершенствованной пакетной системы (EPS).
Фиг.2 является еще одной схематической иллюстрацией хорошо известной LTE
архитектуры.
Фиг. 3 является схематической иллюстрацией GTPv1 заголовка.
Фиг.4 является схематической иллюстрацией GTPv1 заголовка, за которым следуют один или более последующих IEs.
Фиг.5 является схематической иллюстрацией GTPv2-С заголовка.
Фиг.6 является схематической иллюстрацией EPC конкретного GTPv2-C заголовка.
Фиг.7 является схематической иллюстрацией GTPv2-C заголовка с последующим нулем или одним (1) или более последующих IEs.
Фиг.8 является схематической иллюстрацией формата примерного GTPv2 информационного элемента (IE).
Фиг.9 является схематической иллюстрацией примерного GTPv1 типа информационного элемента (IE) с новым полем расширения IE типа.
Фиг.10 представляет собой схематическую иллюстрацию примерного GTPv2 типа информационного элемента (IE) с новым полем расширения IE типа.
Фиг.11 является иллюстративной блок-схемой последовательности операций, которая схематически иллюстрирует примерные описанные здесь варианты осуществления.
Фиг.12 является схематической иллюстрацией примерного узла 200 управления мобильностью, выполненного с возможностью эффективно выполнять операций, описанными здесь иллюстративными вариантами осуществления.
Осуществление изобретения
В нижеследующем описании для целей пояснения, а не для ограничения, приведены конкретные детали, такие как конкретные компоненты, элементы, способы и т.д. для обеспечения полного понимания примерных вариантов осуществления. Однако специалисту в данной области техники будет очевидно, что примерные варианты осуществления могут быть осуществлены другими способами, отличные от этих конкретных деталей. В других случаях, с целью упрощения описания примерных вариантов осуществления подробные описания известных способов и элементов опущены. Используемая здесь терминология предназначена для описания примерных вариантов осуществления и не предназначена для ограничения представленных вариантов осуществления.
На фиг. 1 приведена схематическая иллюстрация известной примерной системы беспроводной связи. Система является так называемой LTE-основанной системой. Следует подчеркнуть, что термины «LTE» и «основанная на LTE» система, используемые здесь, содержат как настоящие, так и будущие LTE системы, такие как, например, усовершенствованные LTE системы. Дополнительно, следует понимать, что, хотя на фиг. 1 показана система беспроводной связи в виде LTE системы, приведенные здесь примерные варианты осуществления, могут также использоваться совместно с другими системами беспроводной связи, содержащими узлы и функции, которые соответствуют узлам и функциям системы на фиг.1.
На фиг.2 показана еще одна схематическая иллюстрация известной системы беспроводной связи в форме иллюстративной архитектуры на основе LTE. Как можно видеть на фиг. 2, система содержит базовую станцию в виде eNodeB, подключенную к обслуживающему шлюзу (SGW), в свою очередь, соединенную с узлом управления мобильностью (MME) и PDN шлюзом (PGW), который, в свою очередь, подключен к модулю правил и политики тарификации (PCRF).
еNodeB представляет собой узел радиодоступа, который взаимодействует с радиотерминалом, который обозначен как устройство пользователя (UE) в LTE. Фактически, eNodeB системы образуют сеть радиодоступа E-UTRAN для LTE.
SGW 200 маршрутизирует и направляет пакеты пользовательских данных, а также выступает в качестве привязки мобильности для пользовательской плоскости во время передачи обслуживания между eNB, и в качестве привязки мобильности между LTE и другими технологиями 3GPP (завершение интерфейса S4 и перенаправление трафика между 2G/3G системами и PDN GW). В режиме ожидания UEs, SGW прекращает передачу данных DL и инициирует пейджинговую связь, когда данные DL поступают для UE. Управляют и сохраняют контексты UE, например, параметры услуги IP-канала, информация внутренней маршрутизации сети. Также выполняют репликацию пользовательского трафика в случае законного перехвата.
MME 400 является ключевым узлом управления для LTE сети доступа. Узел выполнен с возможностью выполнять процедуру отслеживания и пейджинга в режиме ожидания UE, включающие в себя повторные передачи. Узел используют в процессе активации/деактивации канала, а также выполнен с возможностью выбирать SGW для UE при первоначальном подключении и во время передачи обслуживания внутри LTE с учетом изменения местоположения узла основной сети (CN). Узел выполнен с возможностью выполнять аутентификацию пользователя (путем взаимодействия с HSS). Сигнализация уровня без доступа (NAS) заканчивается в MME, который выполнен с возможностью генерировать и распределять временные идентификаторы для UEs. Он проверяет аутентификацию UE в режиме ожидания услуги провайдера наземной сети мобильной связи общего пользования (PLMN) и устанавливает ограничения на роуминг UE. MME представляет собой оконечную точку в сети для защиты шифрования/целостности NAS сигнализации и управления ключами безопасности. MME поддерживает также законный перехват сигнализации. MME также обеспечивает функцию плоскости управления для мобильности между LTE и 2G/3G сетями доступа с S3 интерфейсом, заканчивающимся на MME из SGSN. MME также завершает S6a интерфейс в направлении опорного HSS для роуминга UEs.
PGW 300 обеспечивает подключение UE к внешним сетям 250 пакетных данных, являясь точкой выхода и входа трафика для UE. UE может иметь одновременную связь с более чем одним PGW для доступа к множеству PDNs. Как правило, PGW выполняет одно или несколько из: реализацию политики, фильтрацию пакетов для каждого пользователя, поддержку тарификации, законный перехват и скрининг пакета. Другая ключевая роль PGW заключается в том, чтобы выступать в качестве привязки мобильности между 3GPP и non-3GPP технологиями, такими как WiMAX и 3GPP2 (CDMA 1X и EvDO).
PCRF 500 определяет правила политики в режиме реального времени в отношении радиотерминалов системы. Это может, например, включать в себя агрегирование информации в режиме реального времени в и из основной сети и систем оперативной поддержки и т.д. системы, чтобы поддерживать формирование правил и/или автоматически принимать решения относительно политики для пользовательских радиотерминалов, действующих в настоящее время в системе, на основе таких правил или аналогичных. PCRF предоставляет PGW такими правилами и/или политиками или аналогичные, которые будут использоваться посредством применения функции правил и политики тарификации (PCEF).
SGW, MME, PGW и PCRF все являются примерами основных сетевых узлов, в то время как eNodeB является примером узла сети радиодоступа (RAN). Основные сетевые узлы взаимодействуют друг с другом посредством GTP сообщений.
Как уже указывалось выше в разделе «Уровень техники», как хорошо известно, что GTPv1 и GTPv2 используются для установки GTP туннелей и для передачи различных GTP сообщений между основными сетевыми узлами в базовой сети. Как правило, GTP сообщение состоит из заголовка, за которым следуют ноль или более информационных элементов (IE).
Ниже будет приведено подробное описание GTPv1 заголовка и GTPV1 IEs в GTPv1 сообщении, а также GTPv2 заголовка и GTPv2 IEs в GTPv2 сообщении.
Заголовок GTPv1
GTPv1 заголовок в GTPv1 сообщении является заголовком переменной длины, используемым для как GTP-C, так и GTP-U протоколов, то есть, для протоколов GTP плоскости управления и GTP плоскости пользователя.
Как показано на фиг.3, в GTPv1 заголовке есть три флага, которые используют для сигнализации наличия дополнительных возможных полей: PN флаг, S флаг и E флаг. PN флаг используют для сигнализации наличия N-PDU значений. S флаг используют для сигнализации наличия поля GTP порядкового номера. E флаг используют для сигнализации наличия поля заголовка расширения, используемого для обеспечения будущих расширений GTP заголовка. Если и только если установлен один или более из этих трех флагов, должны быть поля порядкового номера, N-PDU и заголовка расширения. Как известно, в GTPv1 заголовке также есть значение идентификаторов конечных точек туннеля (TEIDs).
GTP-C (плоскость управления) и GTP-U (плоскость пользователя) используют некоторые из полей в GTP заголовке по-разному.
GTPv1-C заголовок и информационные элементы (IEs)
Как показано на фиг.4, GTP-C заголовок может сопровождаться одним или несколькими последующими IEs, в зависимости от типа сообщения плоскости управления. В одном GTPv1-C сообщении разрешен только один IE каждого типа, за исключением триплета аутентификации, PDP контекста, данных II идентификатора конечной точки туннеля, NSAPI, XID параметров PS хэндовера, идентификатора потока пакетов, RFSP индекса, PDU номеров, приоритет II развитого выделения/удержания, APN-AMBR с NSAPI, индикация приоритета сигнализации с NSAPI, идентификатор локальной домашней сети (LHN-ID) с NSAPI, характеристики тарификации и информационный элемент FQDN, где допускается наличие нескольких вариантов каждого типа.
GTPv1 информационные элементы (IEs)
GTP сообщение (сигнализация) может содержать несколько IEs. Предпочтительно, чтобы в GTP сообщениях сигнализации IEs сортировались по типу полей в порядке возрастания. В пределах IEs некоторые поля могут быть описаны как запасные. Чтобы обеспечить будущие признаки, приемник не должен анализировать эти биты. Однако, в соответствии с вариантами осуществления настоящего изобретения, некоторые такие поля могут быть использованы.
В приведенной ниже таблице показаны доступные в настоящее время GTPv1 GTPv1 информационные элементы (IEs). В таблице тип длины может быть фиксированным, переменным или расширяемым.
Они определены следующим образом:
- информационные элементы с типом фиксированной длины имеют фиксированный набор полей и фиксированное количество октетов. Они имеют номер последнего октета с фиксированным значением, например, «4».
- информационные элементы с типом переменной длины имеют фиксированный набор полей и переменное число октетов. Они имеют номер последнего октета с переменным значением, например «n». Информационные элементы переменной длины никогда не должны иметь никаких новых полей октетов, добавленных после последнего переменного октета.
- информационные элементы с типом расширяемой длины имеют переменное количество полей и переменное количество октетов. Они имеют номер последнего октета с переменным значением, например, «n», а также имеют следующее описание: «Этот октет (ы) присутствует/присутствуют только при явном указании».
Информационные элементы TV формата всегда должны иметь фиксированный тип длины. Информационные элементы TLV формата могут иметь тип фиксированной, переменной и расширяемой длины.
GTPv1 информационные элементы (IEs)
| Значение типа IE | Формат | Информационный элемент | Ссылка | Тип длины | Количество фиксированных октетов |
| 0 | TV | Зарезервирован | |||
| 1 | TV | Причина | 7.7.1 | фиксированная | 1 |
| 2 | TV | Международный идентификатор мобильного абонента (IMSI) | 7.7.2 | фиксированная | 8 |
| 3 | TV | Идентификатор области маршрутизации (RAI) | 7.7.3 | фиксированная | 6 |
| 4 | TV | Идентификатор временного логического соединения (TLLI) | 7.7.4 | фиксированная | 4 |
| 5 | TV | Пакет TMSI (P-TMSI) | 7.7.5 | фиксированная | 4 |
| 6-7 | Запасной | ||||
| 8 | TV | Требует переупорядочивания | 7.7.6 | фиксированная | 1 |
| 9 | TV | Триплет аутентификации | 7.7.7 | фиксированная | 28 |
| 10 | Запасной | ||||
| 11 | TV | MAP причина | 7.7.8 | фиксированная | 1 |
| 12 | TV | P-TMSI сигнатура | 7.7.9 | фиксированная | 3 |
| 13 | TV | MS достоверный | 7.7.10 | фиксированная | 1 |
| 14 | TV | Восстановление | 7.7.11 | фиксированная | 1 |
| 15 | TV | Режим выбора | 7.7.12 | фиксированная | 1 |
| 16 | TV | Данные I идентификатор конечной точки туннеля | 7.7.13 | фиксированная | 4 |
| 17 | TV | Идентификатор конечной точки туннеля Плоскость управления | 7.7.14 | фиксированная | 4 |
| 18 | TV | Данные II идентификатор конечной точки туннеля | 7.7.15 | фиксированная | 5 |
| 19 | TV | ID освобождения | 7.7.16 | фиксированная | 1 |
| 20 | TV | NSAPI | 7.7.17 | фиксированная | 1 |
| 21 | TV | RANAP причина | 7.7.18 | фиксированная | 1 |
| 22 | TV | RAB контекст | 7.7.19 | фиксированная | 9 |
| 23 | TV | SMS приоритет радио | 7.7.20 | фиксированная | 1 |
| 24 | TV | Приоритет радио | 7.7.21 | фиксированная | 1 |
| 25 | TV | ID потока пакетов | 7.7.22 | фиксированная | 2 |
| 26 | TV | Характеристики тарификации | 7.7.23 | фиксированная | 2 |
| 27 | TV | Ссылка отслеживания | 7.7.24 | фиксированная | 2 |
| 28 | TV | Тип отслеживания | 7.7.25 | фиксированная | 2 |
| 29 | TV | MS причина недосягаемости | 7.7.25A | фиксированная | 1 |
| 30-116 | TV | Зарезервирован (ни один из TV типов не может быть распределен) | |||
| 117-126 | Зарезервирован для GPRS протокола тарификации (см. GTP' в 3GPP TS 32.295 [33]) | ||||
| 127 | TV | ID тарификации | 7.7.26 | Фиксированная | 4 |
| 128 | TLV | Адрес конечного пользователя | 7.7.27 | Переменная | Не применяется |
| 129 | TLV | MM контекст | 7.7.28 | Переменная | Не применяется |
| 130 | TLV | PDP контекст | 7.7.29 | Переменная | Не применяется |
| 131 | TLV | Название точки доступа | 7.7.30 | Переменная | Не применяется |
| 132 | TLV | Конфигурация протокола выбора | 7.7.31 | Переменная | Не применяется |
| 133 | TLV | GSN адрес | 7.7.32 | Переменная | Не применяется |
| 134 | TLV | MS международный PSTN/ISDN номер (MSISDN) | 7.7.33 | Переменная | Не применяется |
| 135 | TLV | Профиль качества услуги | 7.7.34 | Переменная | Не применяется |
| 136 | TLV | Квинтоль аутентификации | 7.7.35 | Переменная | Не применяется |
| 137 | TLV | Шаблон потока трафика | 7.7.36 | Переменная | Не применяется |
| 138 | TLV | Целевая идентификация | 7.7.37 | Переменная | Не применяется |
| 139 | TLV | UTRAN прозрачный контейнер | 7.7.38 | Переменная | Не применяется |
| 140 | TLV | RAB информация установки | 7.7.39 | Переменная | Не применяется |
| 141 | TLV | Перечень типа заголовка расширения | 7.7.40 | Переменная | Не применяется |
| 142 | TLV | Id триггера | 7.7.41 | Переменная | Не применяется |
| 143 | TLV | OMC идентификатор | 7.7.42 | Переменная | |
| 144 | TLV | RAN прозрачный контейнер | 7.7.43 | Переменная | Не применяется |
| 145 | TLV | PDP контекст приоритизации | 7.7.45 | Фиксированная | 0 |
| 146 | TLV | Дополнительная RAB информация установки | 7.7.45A | Переменная | Не применяется |
| 147 | TLV | SGSN число | 7.7.47 | Переменная | Не применяется |
| 148 | TLV | Общие флаги | 7.7.48 | Фиксированная | 1 |
| 149 | TLV | APN ограничение | 7.7.49 | Фиксированная | 1 |
| 150 | TLV | LCS приоритет радио | 7.7.25B | Фиксированная | 1 |
| 151 | TLV | RAT тип | 7.7.50 | Фиксированная | 1 |
| 152 | TLV | Информация о местоположении пользователя | 7.7.51 | Переменная | Не применяется |
| 153 | TLV | MS временной пояс | 7.7.52 | Фиксированная | 1 |
| 154 | TLV | IMEI(SV) | 7.7.53 | Фиксированная | 8 |
| 155 | TLV | CAMEL контейнер информации тарификации | 7.7.54 | Переменная | Не применяется |
| 156 | TLV | MBMS UE контекст | 7.7.55 | Переменная | Не применяется |
| 157 | TLV | Временный идентификатор мобильной группы (TMGI) | 7.7.56 | Фиксированная | 6 |
| 158 | TLV | RIM адрес маршрутизации | 7.7.57 | Переменная | Не применяется |
| 159 | TLV | MBMS Конфигурация протокола выбора | 7.7.58 | Переменная | Не применяется |
| 160 | TLV | MBMS область обслуживания | 7.7.60 | Переменная | Не применяется |
| 161 | TLV | Источник RNC PDCP информация контекста | 7.7.61 | Переменная | Не применяется |
| 162 | TLV | Дополнительная информация отслеживания | 7.7.62 | Фиксированная | 9 |
| 163 | TLV | Счетчик сетевых сегментов | 7.7.63 | Фиксированная | 1 |
| 164 | TLV | Выбранный PLMN ID | 7.7.64 | Фиксированная | 3 |
| 165 | TLV | MBMS идентификатор сеанса | 7.7.65 | Фиксированная | 1 |
| 166 | TLV | MBMS 2G/3G индикатор | 7.7.66 | Фиксированная | 1 |
| 167 | TLV | Усовершенствованный NSAPI | 7.7.67 | Фиксированная | 1 |
| 168 | TLV | MBMS продолжительность сеанса | 7.7.59 | Фиксированная | 3 |
| 169 | TLV | MBMS дополнительная информация отслеживания | 7.7.68 | Фиксированная | 8 |
| 170 | TLV | MBMS число повторения сенса | 7.7.69 | Фиксированная | 1 |
| 171 | TLV | MBMS время до передачи данных | 7.7.70 | Фиксированная | 1 |
| 172 | Зарезервирован (Примечание 1) | ||||
| 173 | TLV | BSS контейнер | 7.7.72 | Переменная | Не применяется |
| 174 | TLV | Идентификация соты | 7.7.73 | Фиксированная | 17 |
| 175 | TLV | PDU числа | 7.7.74 | Фиксированная | 9 |
| 176 | TLV | BSSGP причина | 7.7.75 | Фиксированная | 1 |
| 177 | TLV | MBMS требуемые функциональные возможности канала | 7.7.76 | Переменная | Не применяется |
| 178 | TLV | RIM дискриминатор адреса маршрутизации | 7.7.77 | Фиксированная | 1 |
| 179 | TLV | Перечень установки PFCs | 7.7.78 | Переменная | Не применяется |
| 180 | TLV | PS параметры XID хэндовера | 7.7.79 | Переменная | Не применяется |
| 181 | TLV | MS информация изменения отчетности | 7.7.80 | Фиксированная | 1 |
| 182 | TLV | Флаги прямого туннеля | 7.7.81 | Переменная | Не применяется |
| 183 | TLV | ID корреляции | 7.7.82 | Фиксированная | 1 |
| 184 | TLV | Режим управления канала | 7.7.83 | Фиксированная | 1 |
| 185 | TLV | MBMS идентификатор потока | 7.7.84 | Переменная | Не применяется |
| 186 | TLV | MBMS IP многоадресного распределения | 7.7.85 | Переменная | Не применяется |
| 187 | TLV | MBMS подтверждение распределения | 7.7.86 | Фиксированная | 1 |
| 188 | TLV | INTER RAT информация надежного хэндовера | 7.7.87 | Фиксированная | 1 |
| 189 | TLV | RFSP индекс | 7.7.88 | Фиксированная | 2 |
| 190 | TLV | Полностью уточненное доменное имя (FQDN) | 7.7.90 | Переменная | Не применяется |
| 191 | TLV | Усовершенствованное распределение/удержание Приоритет I | 7.7.91 | Фиксированная | 1 |
| 192 | TLV | Усовершенствованное распределение/удержание Приоритет II | 7.7.92 | Фиксированная | 2 |
| 193 | TLV | Общие флаги расширения | 7.7.93 | Переменная | Не применяется |
| 194 | TLV | CSG пользовательская информация (UCI) | 7.7.94 | Фиксированная | 8 |
| 195 | TLV | CSG информация отчетности | 7.7.95 | Переменная | Не применяется |
| 196 | TLV | CSG ID | 7.7.96 | Фиксированная | 4 |
| 197 | TLV | CSG индикация подписки (CMI) | 7.7.97 | Фиксированная | 1 |
| 198 | TLV | Агрегированная максимальная битовая скорость (AMBR) | 7.7.98 | Фиксированная | 8 |
| 199 | TLV | UE возможности сети | 7.7.99 | Переменная | Не применяется |
| 200 | TLV | UE-AMBR | 7.7.100 | Переменная | Не применяется |
| 201 | TLV | APN-AMBR с NSAPI | 7.7.101 | Фиксированная | 9 |
| 202 | TLV | GGSN время высвобождения | 7.7.102 | Расширяемая | 1 |
| 203 | TLV | Индикация приоритета сигнализации | 7.7.103 | Расширяемая | 1 |
| 204 | TLV | Индикация приоритета сигнализации с NSAPI | 7.7.104 | Расширяемая | 2 |
| 205 | TLV | Флаг более высокой битовой скорости, чем 16 Mbps | 7.7.105 | Фиксированная | 1 |
| 206 | Зарезервирован (Примечание 1) | ||||
| 207 | TLV | Дополнительный MM контекст для SRVCC | 7.7.107 | Расширяемая | "e - 3" (См фиг. 7.7.107-1) |
| 208 | TLV | Дополнительные флаги для SRVCC | 7.7.108 | Расширяемая | 1 |
| 209 | TLV | STN-SR | 7.7.109 | Переменная | Не применяется |
| 210 | TLV | C-MSISDN | 7.7.110 | Переменная | Не применяется |
| 211 | TLV | Расширенный RANAP причины | 7.7.111 | Расширяемая | 2 |
| 212 | TLV | eNodeB ID | 7.7.112 | Переменная | Не применяется |
| 213 | TLV | Выбор режима с NSAPI | 7.7.113 | Фиксированная | 2 |
| 214 | TLV | ULI Временная метка | 7.7.114 | Расширяемая | 4 |
| 215 | TLV | ID локальной опорной сети (LHN-ID) с NSAPI | 7.7.115 | Переменная | Не применяется |
| 216 | TLV | CN объект выбора оператором | 7.7.116 | Расширяемая | 1 |
| 217-238 | TLV | Запасной. Для будущего использования. | |||
| 239-250 | Зарезервирован для GPRS протокола тарификации (см GTP' в 3GPP TS 32.295 [33]) | ||||
| 251 | TLV | Адрес шлюза тарификации | 7.7.44 | 4/16 | |
| 252-254 | Зарезервирован для GPRS протокола тарификации (см GTP' в 3GPP TS 32.295 [33]) | ||||
| 255 | TLV | Индивидуальное расширение | 7.7.46 | Не применяется | |
| Примечание 1: Данное значение было распределено в более ранней версии спецификации. Примечание 2: Размер TL (тип и длина) полей, т.е. «3» октета, вычитается из числа фиксированных октетов IEs типа фиксированной длины и расширенного типа, для которых длина определена с переменным числом октетов, «3» явным образом вычитается при определении фиксированного числа октетов. Например, длина дополнительного MM контекста для SRVCC определена как «e» и фиксированное число октетов для того же определено как «e-3». |
Следует добавить, что самый старший бит в поле TV и TLV типа установлен на 0, когда используется TV формат для IE, и устанавливается на 1 для TLV формата.
Поле типа для TV и TLV формата
GTP v2 заголовок для плоскости управления
На фиг. 5 показан общий формат GTPv2 заголовка плоскости управления (GTPv2-C заголовок) в GTPv2-C сообщении. GTPv2-C использует заголовок переменной длины. Длина GTP заголовка плоскости управления должна быть кратна 4 октетам. Порядок использования GTPv2-C заголовка по EPC конкретным интерфейсам определен в 3GPP TS 29274 подпункт 5.5 «Использование GTPv2-C заголовка».
В GTPv2-C заголовке:
- если T = 0, TEID поле отсутствует, k = 0, m = 0 и n = 5;
- если T = 1, TEID поле присутствует, k = 1, m = 5 и n = 9.
Октет 1 бит кодируют следующим образом:
- биты 6-8 представляют поле версии.
- бит 5 представляет флаг совмещения (P).
- бит 4 представляет TEID флаг (T).
- биты 3-1 являются запасными, отправитель должен установить их на «0», и принимающий объект должен их игнорировать.
На фиг.6 показана схематическая иллюстрация EPC конкретного GTP-C заголовка. Можно отметить, что помимо сообщений эхо-запрос, эхо-ответ и индикации отсутствия поддержки версии, GTP-C заголовок сообщения должен содержать поля TEID и порядкового номера, за которыми следует один запасной октет. Запасные биты должны быть установлены на ноль отправителем и проигнорированы получателем.
На фиг.7 показана схематическая иллюстрация GTPv2-C заголовка, за которым следует нуль или один (1) или более последующих IEs, в зависимости от типа сообщения плоскости управления.
GTPv2-C информационные элементы (IEs)
GTPv2 (сигнализация) сообщение плоскости управления может содержать несколько IEs. Чтобы обеспечить определение совместимых типов для GTPv2 IEs, все они должны быть закодированы в TLIV формате (тип, длина, экземпляр, значение).
В приведенной ниже таблице показаны доступные в настоящее время GTPv2 информационные элементы (IEs). Последний столбец этой таблицы указывает, является ли информационный элемент:
- фиксированной длины: IE имеет фиксированный набор полей и фиксированное количество октетов.
- переменной длины: IE имеет фиксированный набор полей и имеет переменное количество октетов. Например, последние октеты могут быть пронумерованы как «5 до (n + 4)». В этом примере, если значение поля длины, n, равно 0, то последнее поле отсутствует.
- расширяемым: IE имеет переменное количество полей и имеет переменное количество октетов. Последние поля обычно задают посредством определения: «Этот октет (ы) присутствует/присутствуют, только если явно указано». Унаследованный принимающий объект должен игнорировать неизвестные октеты.
Типы информационных элементов для GTPv2
| Значение типа IE (десятичный разряд) |
Информационные элементы | Комментарии/ссылка | Количество фиксированных октетов |
| 0 | Зарезервирован | ||
| 1 | Международный идентификатор мобильного абонента (IMSI)) | Переменная длина / 8.3 | Не применяется |
| 2 | Причина | Переменная длина / 8.4 | Не применяется |
| 3 | Восстановление (Повторный запуск счетчика) | Переменная длина / 8.5 | Не применяется |
| 4 по 34 | Зарезервирован для S101 интерфейса | См. 3GPP TS 29.276 [14] | См 3GPP TS 29.276 [14] |
| 35 по 50 | Зарезервирован для S121 интерфейса | См 3GPP TS 29.276 [14] | См 3GPP TS 29.276 [14] |
| 51 | STN-SR | См.3GPP TS 29.280 [15] | См 3GPP TS 29.280 [15] |
| 52 по 70 | Зарезервирован для Sv интерфейса | См. 3GPP TS 29.280 [15] | См 3GPP TS 29.280 [15] |
| 71 | Наименование точки доступа (APN) | Переменная длина / 8.6 | Не применяется |
| 72 | Агрегированная максимальная битовая скорость (AMBR) | Фиксированная длина / 8.7 | 8 |
| 73 | EPS ID канала (EBI) | Расширяемая / 8.8 | 1 |
| 74 | IP адрес | Переменная длина / 8.9 | Не применяется |
| 75 | Идентификатор устройства мобильной связи (MEI) | Переменная длина / 8.10 | Не применяется |
| 76 | MSISDN | Variable Length / 8.11 | Не применяется |
| 77 | Индикация | Расширяемая / 8.12 | 2 |
| 78 | Конфигурация протокола выбора (PCO) | Переменная длина / 8.13 | Не применяется |
| 79 | PDN адрес распределения (PAA) | Переменная длина / 8.14 | Не применяется |
| 80 | Уровень качества канала (QoS канала) | Расширяемая / 8.15 | 22 |
| 81 | Качество потока услуги (QoS потока) | Расширяемая / 8.16 | 21 |
| 82 | RAT тип | Расширяемая / 8.17 | 1 |
| 83 | Обслуживающая сеть | Расширяемая / 8.18 | 3 |
| 84 | EPS уровень канала шаблон потока трафика (TFT канала) | Переменная длина / 8.19 | Не применяется |
| 85 | Описание агрегации трафика (TAD) | Переменная длина / 8.20 | Не применяется |
| 86 | Информация о местоположении пользователя (ULI) | Расширяемая/8.21 | "f+4-4" (см фиг. 8.21-1) |
| 87 | Полностью уточненный идентификатор конечной точки туннеля (F-TEID) | Расширяемая / 8.22 | 9/21/25 |
| 88 | TMSI | Переменная длина / 8.23 | Не применяется |
| 89 | Глобальный CN-Id | Переменная длина / 8.24 | Не применяется |
| 90 | S103 PDN информация о направлении данных (S103PDF) | Переменная длина / 8.25 | Не применяется |
| 91 | S1-U информация о направлении данных (S1UDF) | Переменная длина / 8.26 | Не применяется |
| 92 | Величина задержки | Расширяемая / 8.27 | 1 |
| 93 | Контекст канала | Расширяемая / 8.28 | Не применяется |
| 94 | ID тарификации | Расширяемая / 8.29 | 4 |
| 95 | Характеристики тарификации | Расширяемая / 8.30 | 2 |
| 96 | Информация отслеживания | Переменная длина / 8.31 | Не применяется |
| 97 | Флаги канала | Расширяемая / 8.32 | 1 |
| 98 | Зарезервирован | ||
| 99 | PDN тип | Расширяемая / 8.34 | 1 |
| 100 | ID процедуры транзакции | Расширяемая / 8.35 | 1 |
| 101 | Зарезервирован | ||
| 102 | Зарезервирован | ||
| 103 | MM Контекст (GSM ключ и триплет) | Расширяемая / 8.38 | "r+1-4" (см фиг.8.38-1) |
| 104 | MM Контекст (UMTSключ, использованный шифрообраз и квинтоль) | Расширяемая / 8.38 | "r+1-4" (см фиг.8.38-2) |
| 105 | MM Контекст (GSM ключ, использованный шифрообраз и квинтоль) | Расширяемая / 8.38 | "r+1-4" (см фиг.8.38-3) |
| 106 | MM контекст (UMTS ключ и квинтоль) | Расширяемая / 8.38 | "r+1-4" (см фиг.8.38-4) |
| 107 | MM контекст (EPS контекст безопасности, квартоль и квинтоль) | Расширяемая / 8.38 | "s+64-4" (см фиг.8.38-5) |
| 108 | MM контекст (UMTS ключ, квартоль и квинтоль) | Расширяемая / 8.38 | "r+1-4" (см фтг.8.38-6) |
| 109 | PDN соединение | Расширяемая / 8.39 | Не применяется |
| 110 | PDU числа | Расширяемая / 8.40 | 9 |
| 111 | P-TMSI | Переменная длина / 8.41 | Не применяется |
| 112 | P-TMSI сигнатура | Переменная длина / 8.42 | Не применяется |
| 113 | Счетчик сетевых состояний | Расширяемая / 8.43 | 1 |
| 114 | UE временной пояс | Расширяемая / 8.44 | 2 |
| 115 | Ссылка отслеживания | Фиксированная длина / 8.45 | 6 |
| 116 | Сообщение запроса | Переменная длина / 8.46 | Не применяется |
| 117 | GUTI | Переменная длина / 8.47 | Не применяется |
| 118 | F-контейнер | Переменная длина / 8.48 | Не применяется |
| 119 | F-причина | Переменная длина / 8.49 | Не применяется |
| 120 | PLMN ID | Переменная длина / 8.50 | Не применяется |
| 121 | Целевая идентификация | Переменная длина / 8.51 | Не применяется |
| 122 | Зарезервирован | ||
| 123 | ID потока пакетов | Переменная длина / 8.53 | Не применяется |
| 124 | RAB Контекст | Фиксированная длина / 8.54 | 9 |
| 125 | Источник RNC PDCP информация | Переменная длина / 8.55 | Не применяется |
| 126 | UDP номер порта источника | Расширяемая / 8.56 | 2 |
| 127 | APN ограничение | Расширяемая / 8.57 | 1 |
| 128 | Режим выбора | Расширяемая / 8.58 | 1 |
| 129 | Идентификация источника | Переменная длина / 8.59 | Не применяется |
| 130 | Зарезервирован | ||
| 131 | Изменение отчетности | Переменная длина / 8.61 | Не применяется |
| 132 | Полностью достоверный PDN идентификатор набора соединенийr (FQ-CSID) | Расширяемая / 8.62 | "q+1-4" (См. Фиг.8.62-1) |
| 133 | Требуемый канал | Переменная длина / 8.63 | Не применяется |
| 134 | eMLPP приоритет | Переменная длина / 8.64 | Не применяется |
| 135 | Тип узла | Расширяемая / 8.65 | 1 |
| 136 | Полностью определенное доменное имя (FQDN) | Переменная длина / 8.66 | Не применяется |
| 137 | Идентификатор транзакции (TI) | Переменная длина / 8.68 | Не применяется |
| 138 | MBMS Продолжительность сеанса | Расширяемая / 8.69 | 3 |
| 139 | MBMS Область обслуживания | Переменная длина / 8.70 | Не применяется |
| 140 | MBMS Идентификатор сеанса | Расширяемая / 8.71 | 1 |
| 141 | MBMS Идентификатор потока | Расширяемая / 8.72 | 2 |
| 142 | MBMS IP многоадресное распределение | Расширяемая / 8.73 | "m+1-4" (См. Фиг.8.73-1) |
| 143 | MBMS подтверждение распределения | Расширяемая / 8.74 | 1 |
| 144 | RFSP индекс | Фиксированная длина / 8.77 | 2 |
| 145 | CSG информация пользователя (UCI) | Расширяемая / 8.75 | 8 |
| 146 | CSG информация отчетности | Расширяемая / 8.76 | 1 |
| 147 | CSG ID | Расширяемая / 8.78 | 4 |
| 148 | CSG индикация подписки (CMI) | Расширяемая / 8.79 | 1 |
| 149 | Индикатор услуги | Фиксированная длина / 8.80 | 1 |
| 150 | Тип разъединения | Фиксированная длина/ 8.81 | 1 |
| 151 | Наименование локальной распределенной сети (LDN) | Переменная длина / 8.82 | Не применяется |
| 152 | Признаки узла | Расширяемая / 8.83 | 1 |
| 153 | MBMS время до передачи данных | Расширяемая/ 8.84 | 1 |
| 154 | Троттлинг | Расширяемая / 8.85 | 2 |
| 155 | Приоритет распределения/удержания (ARP) | Расширяемая/ 8.86 | 1 |
| 156 | EPC таймер | Расширяемая/ 8.87 | 1 |
| 157 | Индикация приоритета сигнализации | Расширяемая/ 8.88 | 1 |
| 158 | Временный идентификатор мобильной группы (TMGI) | Расширяемая/ 8.89 | 6 |
| 159 | Дополнительный MM контекст для SRVCC | Расширяемая/ 8.90 | "e-4" (См. фиг. 8.90-1) |
| 160 | Дополнительный флаги для SRVCC | Расширяемая / 8.91 | 1 |
| 161 | Зарезервирован | ||
| 162 | MDT конфигурация | Расширяемая/ 8.93 | "q-4" (См. Фиг. 8.93-1) |
| 163 | Дополнительный протокол конфигурации выбора (APCO) | Расширяемая/ 8.94 | "m-4" (См. фиг.8.94-1) |
| 164 | Абсолютное время MBMS передачи данных | Расширяемая/ 8.95 | 8 |
| 165 | H(e)NB информация отчетности | Расширяемая/ 8.96 | 1 |
| 166 | IPv4 параметры конфигурации (IP4CP) | Расширяемая/ 8.97 | 5 |
| 167 | Изменить флаги отчетности | Расширяемая/ 8.98 | 1 |
| 168 | Индикация действия | Расширяемая/ 8.99 | 1 |
| 169 | TWAN идентификатор | Расширяемая/ 8.100 | "k+6-4" (См. Фиг.8.100-1) |
| 170 | ULI временная отметка | Расширяемая / 8.101 | 4 |
| 171 | MBMS Флаги | Расширяемая / 8.102 | 1 |
| 172 | RAN/NAS причина | Расширяемая / 8.103 | "m-4" (См. Фиг.8.103-1) |
| 173 | CN выбор объекта оператором | Расширяемая / 8.104 | 1 |
| 174 | Доверенная WLAN индикация режима | Расширяемая / 8.105 | 1 |
| 175 | Номер узла | Расширяемая / 8.106 | "p-4" (См. Фиг.8.106-1) |
| 176 | Идентификатор узла | Расширяемая / 8.107 | "q-4" (См. Фиг. 8.107-1) |
| 177 | Наличие действия в области отчетности | Расширяемая / 8.108 | "t-4" (См. фиг.8.108-1) |
| 178 | Информация наличия области отчетности | Расширяемая / 8.109 | 4 |
| 179 | TWAN Идентификатор временной отметки | Расширяемая / 8.110 | 4 |
| 180 | Информация управления устранением перегрузки | Расширяемая / 8.111 | Не применяется |
| 181 | Информация управление нагрузкой | Расширяемая / 8.112 | Не применяется |
| 182 | Метрика | Фиксированная длина/8.113 | 1 |
| 183 | Порядковый номер | Фиксированная длина/8.114 | 4 |
| 184 | APN и относительная емкость | Расширяемая / 8.115 | "m-4" (См. Фиг.8.115 |
| 185 | WLAN индикация недопустимой нагрузки | Расширяемая / 8.116 | 1 |
| 186 | Информация услуги и пейджинга | Расширяемая / 8.117 | m-4 См. Фиг.8.117-1) |
| 187 по 254 | Запасной для будущего использования | ||
| 255 | Индивидуальное расширение | Переменная длина/ 8.67 | Не применяется |
| Примечание 1: Размер TLI (тип и длина и вариант) полей, т.е. «4» октета, был вычтен из числа фиксированных октетов IEs типа фиксированной длины и расширенного типа. Следовательно, для некоторых IEs «расширенного типа», для которых длина определена с переменным числом октетов, «4» явным образом вычитается при определении фиксированного числа октетов. Например, длина информации местоположения пользователя определена как «f+4» и фиксированное число октетов для того же определено как «f+4-4». |
На фиг.8 показан формат иллюстративного GTPv2 информационного элемента (IE). Как правило, IE имеет следующие поля:
- поле типа: это поле указывает тип информационного элемента. Значения доступных в настоящее время GTPv2-C типов IE определены в приведенной выше таблице.
- длина: это поле содержит информацию о длине информационного элемента, исключая первые четыре октета, которые являются общими для всех информационных элементов (тип, длина и контент октета 4) и обозначены как «n» на фиг.8.2-1. Для всех полей длины бит 8 наименьшего пронумерованного октета является самым старшим битом, и бит 1 наивысшего пронумерованного октета является младшим битом.
- IE может также иметь поле варианта: это поле должно использоваться для различия между различными параметрами в одном конкретном сообщении, которое использует один и тот же тип информационного элемента.
Как правило, IE кодируется TLIV (тип, длина, вариант, значение).
GTPv1 поле расширения IE типа
Как уже указывалось выше в разделе «Уровень техники», с целью удовлетворения требований новых признаков 3GPP, в GTPv1 сформировано много новых IE типов. При вводе нового IE типов для новой признаков желательно использовать резервные IE типы (см., например, типы IE 217-238 в приведенной выше таблице GTPv1 типов IE), поскольку это обычно обеспечивают спецификацию более чистого протокола с наилучшей обратной совместимостью. Например, унаследованный приемник может безопасно отбросить новый IE тип. Однако это приводит к тому, что все новые и новые IE типы остаются запасными. Таким образом, уменьшение количества запасных IE типов может поставить под угрозу эффективную поддержку большего количества признаков в GTPv1 протоколе, что является серьезным недостатком.
Таким образом, для удовлетворения требований вновь введенных признаков в 3GPP, исчерпывается возможность рассмотрения запасных IE типов, что может угрожать эффективной поддержке большего количества признаков в GTPv1 протоколе, желательно использовать механизм расширения существующего диапазона IE типов, предпочтительно обратно совместимым способом.
На фиг.9 показана схема иллюстративного примера GTPv1 IE типа с новым полем расширения IE типа, обеспечивающим расширенный диапазон IE типов. Новый IE тип идентифицируют значением, закодированным в существующем заданном поле IE типа в первом (1-ый) октете IE, плюс дополнительное новое значение, закодированное в поле расширения IE типа. В этом примере, существующий заданный GTPv1 IE тип 238 выбран как конкретный IE тип, то есть, один из запасных IE типов 217-238 в приведенной выше таблице GTPv1 IE типов. Однако может быть использован любой подходящий существующий заданный IE тип в приведенной выше таблице GTPv1 IE типов, например, такой как любой другой из резервных IE типов 217-237. Новый IE тип определяется существующим заданным IE типом, закодированным в первом (1-ый) октете IE, как это обычно известно, но теперь, совместно с дополнительным значением, сконфигурированным в зарезервированное поле расширения IE типа, предпочтительно в октете 4 и 5 IE. Конкретный IE тип 238 соответствует IE типу 238 «запасной для будущего использования» в приведенной выше таблице GTPv1 IE типов. Как указано выше, использование существующего заданного запасного IE типа (например, как IE тип 238) решает задачу обратной совместимости, поскольку такие новые IE типы могут быть безопасно отброшены унаследованным приемником. Однако следует добавить, что могут использоваться другие IE типы, чем запасные IE типы, но такие варианты осуществления не могут быть обратно совместимы.
GTPv2 поле расширения IE типа
Как уже указывалось выше в разделе «Уровень техники», с целью удовлетворения требований новых признаков 3GPP, в GTPv2 сформировано много новых IE типов. При вводе нового IE типа для нового признака желательно использовать запасные IE типы (см., например, IE типы 187-254 в приведенной выше таблице GTPv2 IE типов), поскольку это обычно обеспечивает наилучшую спецификацию и обратную совместимость. Например, унаследованный приемник может безопасно отбросить новый IE тип. Однако это приводит к тому, что все меньше и меньше новых IE типов остаются запасными. Таким образом, уменьшение количества запасных IE типов может поставить под угрозу эффективную поддержку большего количества признаков в GTPv1 протоколе, что является серьезным недостатком.
Таким образом, с целью удовлетворения требований недавно введенных признаков в 3GPP, исчерпывается возможность рассмотрения запасных IE типов, что может угрожать эффективной поддержке большего количества признаков в GTPv2 протоколе, желательно использовать механизм расширения существующего диапазона IE типов, предпочтительно обратно совместимым способом.
На фиг.10 показана схематическая иллюстрация примерного GTPv2 IE типа с новым полем расширения IE типа, обеспечивающим расширенный диапазон IE типов. Новый IE тип идентифицируют значением, закодированным в существующем поле заданного IE типа в первом (1-ый) октете IE, плюс дополнительное новое значение, закодированное в поле расширения IE типа. В этом примере, существующий заданный GTPv2 IE тип 254 выбирается как конкретный IE тип, то есть, один из запасных IE типов 187-254 в приведенной выше таблице GTPv2 IE типов. Однако может быть использован любой подходящий существующий заданный IE тип в приведенной выше таблице GTPv2 IE типов, например, такой как любой другой из запасных IE типов 187-253. Новый IE тип определяется существующим заданным IE типом, закодированным в первом (1-ый) октете IE, как это обычно известно, но теперь совместно с дополнительным значением, сконфигурированным в зарезервированном поле расширения IE типа, предпочтительно в октетах 5 и 6 IE. Конкретный IE тип 254 соответствует IE типу 254 «Запасной для будущего использования» в приведенной выше таблице GTPv2 IE типов. Как указано выше, использование существующего заданного запасного IE типа (например, IE тип 254) обеспечивает обратную совместимость, поскольку такие новые IE типы могут быть безопасно отброшены унаследованным приемником. Однако следует добавить, что могут использоваться другие IE типы, чем резервные IE типы, но такие варианты осуществления не могут быть обратно совместимы.
На фиг.11 показана иллюстративная блок-схема последовательности операций, которая схематически иллюстрирует описанные здесь примерные варианты осуществления.
На фиг.11 проиллюстрирован способ, в котором узел основной сети (200, 300, 400, 500) формирует GTP сообщение. GTP сообщение содержит GTP заголовок, за которым следует, по меньшей мере, один IE, ассоциированный с конкретным IE типом, в наборе заданных IE типов. IE содержит множество полей, в котором конкретный IE тип идентифицируют значением, закодированным в существующем поле заданного IE типа в первом октете IE, причем способ содержит:
Первое действие 1110, в котором поле расширения IE типа зарезервировано в четвертом и пятом октетах IE или в пятом и шестом октетах IE для обеспечения определения дополнительного набора новых IE типов, являющегося расширением конкретного заданного IE типа; и
Второе действие 1120, в котором зарезервированное поле расширения IE типа выполнено с возможностью определять, по меньшей мере, один новый IE тип в дополнение к заданному набору IE типов.
Третье действие 1130, в котором отправляют GTР сообщение, например, отправляют на другой узел основной сети в основной сети. Это действие может быть возможным.
На фиг.12 показан примерный узел основной сети, выполненный с возможностью эффективно выполнять операций иллюстративных вариантов осуществления, описанных здесь. Как показано на фиг.9, узел основной сети может содержать устройство 910 процессора и устройство 920 памяти. Устройство процессора предпочтительно выполнено с возможностью оперативного устанавливать связь с другими сетевыми узлами и блоками, например, как проиллюстрировано на фиг.2, и выполнено с возможностью оперативно выполнять инструкции, сохраненные в устройстве памяти. Устройство памяти содержит инструкции, выполняемые упомянутым устройством процессора, так что примерный сетевой узел выполнен с возможностью выполнять операции описанных здесь иллюстративных вариантов осуществления. Устройство 910 процессора может содержать любую подходящую цифровую и аналоговую схему, которая позволяет выполнять инструкции, хранящиеся в устройстве памяти, для выполнения операций и функций иллюстративных описанных здесь вариантов осуществления. Цифровая и аналоговая схема устройства 910 процессора и устройства 920 памяти могут, например, быть такими же или похожими, что и в известных основных сетевых узлах, таких как SGW, PGW, MME или PCRF или аналогичные, тогда как инструкции являются конкретными для описанного здесь варианта осуществления.
Некоторые из вышеописанных примерных вариантов осуществления могут быть обобщены следующим образом:
Первый примерный вариант осуществления относится к способу, выполняемому в узле основной сети для формирования GTP сообщения, причем GTP сообщение содержит GTP заголовок, за которым следует, по меньшей мере, один IE, ассоциированный с конкретным IE типом, в наборе заданных IE типов, и который IE содержит множество полей, в которых конкретный IE тип идентифицируют значением, закодированным в поле заданного IE типа в первом октете IE, при этом способ содержит: резервирование поля расширения IE типа в четвертом и пятом октетах IE или в пятом и шестом октетах IE для определения дополнительного набора новых IE типов, являющихся расширением конкретного IE типа; и конфигурирование зарезервированного поля расширения IE типа для определения, по меньшей мере, одного нового IE типа в дополнение к заданному набору IE типов.
Способ может дополнительно содержать: отправку GTP сообщения.
Конкретный заданный IE тип может быть запасным IE типом, зарезервированным для будущего использования.
Конкретный заданный IE тип может быть частным расширением IE типа.
Узел основной сети может быть любым из: SGW или PGW или MME или PCRF.
Другой примерный вариант осуществления относится к узлу основной сети, выполненному с возможностью оперативно формировать GTP сообщение, при этом GTP сообщение содержит GTP заголовок, за которым следует, по меньшей мере, один информационный элемент IE, ассоциированный с конкретным IE типом в наборе заданных IE типов, и при этом IE содержит множество полей, в которых конкретно IE тип идентифицируют значением, закодированным в поле заданного IE типа в первом октете IE, при этом узел основной сети содержит непереходную память с инструкциями и процессор, выполненный с возможностью оперативно выполнять инструкции, чтобы: зарезервировать поле расширения IE типа в четвертом и пятом октетах IE или в пятом и шестом октетах IE для определения дополнительного набора новых IE типов, являющегося расширением конкретного IE типа; и конфигурировать зарезервированное поле расширения IE типа для определения, по меньшей мере, одного нового IE типа в дополнение к заданному набору IE типов.
Узел основной сети может быть выполнен с возможностью оперативно отправлять GTP сообщение.
Конкретный заданный IE тип может быть запасным IE типом, зарезервированным для будущего использования.
Конкретный заданный IE тип может быть частным расширением IE типа.
Узел основной сети может быть любым из: SGW или PGW или MME или PCRF.
Различие между запасным IE типом и зарезервированным частным расширением IE типа (и так же с большинством других заданных IEs) заключается в том, что унаследованный приемник инициирует процесс исправления ошибок, если отправитель использует зарезервированный IE тип; в случае, если приемник не распознает IE тип, данный запасной IE тип будет просто проигнорирован.
Как показано в приведенных выше примерных вариантах осуществления, новое зарезервированное поле расширения IE типа может содержать октет 4 и 5 или октет 5 и 6 в IE, при этом каждый октет содержит восемь (8) двоичных бит каждый. Таким образом, зарезервированное поле может содержать 2 октета, то есть, 2x8 = 16 бит. Эти 16 бит позволяют определить дополнительный набор из 2 * 16 = 65536 новых IE типов, являющихся расширением конкретного IE типа.
Дополнительно, некоторые варианты осуществления могут резервировать дополнительные поля для обеспечения определения дополнительного набора новых IE типов, являющегося расширением конкретного IE типа. Например, октеты 7 и 8 могут быть зарезервированы во втором поле в дополнение к октетам 5 и 6, уже зарезервированным в первом поле. Здесь приведенные в качестве примера два (2) зарезервированных поля могут быть добавлены друг к другу, чтобы обеспечить определение дополнительного набора новых IE типов p (2*nx8), при этом число зарезервированных полей равно p = 2, и число октетов в каждом поле равно n = 2. Это позволяет определить дополнительный набор из 2 (2 * (2x8)) = 2 (2*16) = 2x65536 = 131072 новых IE типов. Альтернативно, примерные два (2) зарезервированных поля могут быть объединены друг с другом, что позволяет определить дополнительный набор из 2 * pn8 новых IE типов, при этом количество полей равно p = 2, и число октетов в каждом поле равно n = 2. Это позволяет определить дополнительный набор 2 * (2x2x8) = 2 * 32 = 4294967296 новых IE типов. Добавление зарезервированных полей друг к другу обеспечивает более простой способ обратной совместимости, но не может определять много новых IE типов, как это может быть в случае конкатенации зарезервированных полей.
IE может быть закодированным типом, значением (TV), или закодированным типом, длиной, значением (TVL) или закодированным типом, длиной, вариантом, значением (TLIV).
Заданный набор IE типов может быть определен в поле типа, содержащем один (1) октет из восьми (8) двоичных бит, предоставляющий набор из 256 различных заданных IE типов.
1. Способ, реализуемый узлом основной сети (200, 300, 400, 500) для формирования сообщения протокола туннелирования (GTP) общей службы пакетной радиосвязи (GPRS), при этом GTP сообщение содержит GTP заголовок, за которым следует по меньшей мере один информационный элемент (IE), ассоциированный с конкретным IE типом в наборе заданных IE типов, при этом IE содержит множество полей, в которых конкретный IE тип идентифицируют значением, закодированным в поле заданного IE типа в первом октете IE, причем способ содержит этапы, на которых:
осуществляют резервирование (1110) поля расширения IE типа в четвертом и пятом октетах IE или в пятом и шестом октетах IE для обеспечения определения дополнительного набора новых IE типов, являющихся расширением конкретного IE типа; и
конфигурируют (1120) зарезервированное поле расширения IE типа для определения по меньшей мере одного нового IE типа в дополнение к заданному набору IE типов.
2. Способ по п.1, дополнительно содержащий этап, на котором:
передают (1130) GTP сообщение.
3. Способ по п. 1 или 2, в котором конкретный заданный IE тип является запасным IE типом, зарезервированным для будущего использования.
4. Способ по любому из пп. 1-3, в котором конкретный заданный IE тип является частным расширением IE типа.
5. Способ по любому из пп. 1-4, в котором упомянутый узел основной сети является одним из обслуживающего шлюза (SGW) (200) или PDN шлюза (PGW) (300) или узла управления мобильностью (MME) (400) или модуля правил и политики тарификации (PCRF) (500).
6. Узел основной сети (200, 30, 400, 500), выполненный с возможностью оперативного формирования сообщения протокола туннелирования (GTP) общей службы пакетной радиосвязи (GPRS), при этом GTP сообщение содержит GTP заголовок, за которым следует по меньшей мере один информационный элемент (IE), ассоциированный с конкретным IE типом в наборе заданных IE типов, при этом IE содержит множество полей, в которых конкретный заданный IE тип идентифицируют значением, закодированным в поле заданного IE типа в первом октете IE, при этом узел основной сети (200, 30, 400, 500) содержит память (920), хранящую инструкции, и процессор (910), выполненный с возможностью оперативного выполнения инструкций, для:
резервирования поля расширения IE типа в четвертом и пятом октетах IE или в пятом и шестом октетах IE для обеспечения определения дополнительного набора новых IE типов, являющихся расширением конкретного IE типа; и
конфигурирования зарезервированного поля расширения IE типа для определения по меньшей мере одного нового IE типа в дополнение к заданному набору IE типов.
7. Узел основной сети по п.6, в котором узел основной сети выполнен с возможностью оперативной передачи GTP сообщения.
8. Узел основной сети по п.6 или 7, в котором конкретный заданный IE тип является запасным IE типом, зарезервированным для будущего использования.
9. Узел основной сети по п.6 или 7, в котором конкретный заданный IE тип является частным расширением IE типа.
10. Узел основной сети по любому из пп.6-9, характеризующийся тем, что является одним из обслуживающего шлюза (SGW) (200) или PDN шлюза (PGW) (300) или узла управления мобильностью (MME) (400) или модуля правил и политики тарификации (PCRF) (500).
