Переключение адресов и корреляция сообщений между сетевыми узлами
Патент 2273104
Авторы
Правообладатели
Классы МПК
Переключение адресов и корреляция сообщений между сетевыми узлами
Иллюстрации
Настоящее изобретение относится к способу, системе и сетевому элементу для обеспечения переключения адресов, если точку соединения на одном конце соединения изменяют от первого сетевого узла ко второму сетевому узлу сети сотовой связи. Информацию об адресе и информацию по меньшей мере об одном альтернативном адресе передают в сообщении сигнализации от первого сетевого узла во второй сетевой узел. Информацию об адресе или информацию об альтернативном адресе выбирают во втором сетевом узле и используют для повторного установления соединения с другим концом соединения. Таким образом, новой точке соединения позволяют повторно установить соединение с другим концом соединения, даже если она имеет возможность осуществлять связь только с использованием одного из двух адресов. Кроме того, сообщения сигнализации, например, сообщения, относящиеся к определению затрат, правомочному перехвату и/или специализированным приложениям, принятые от различных сетевых узлов, могут быть коррелированы на основании альтернативных адресов. Техническим результатом является создание способа и устройства для обеспечения переключения адресов или функции корреляции, посредством которой можно достичь обратную совместимость адресов. 7 н. и 25 з.п. ф-лы., 3 ил., 6 табл.
Реферат
ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Настоящее изобретение в целом относится к способу, системе и сетевому элементу, предназначенным для обеспечения переключения адресов, например, переключения или перехода от IPv4-адреса (Интернет-протокол, версия 4) к IPv6-адресу между первым сетевым узлом и вторым сетевым узлом сети сотовой связи, например сети УОНПР (Услуги общего назначения пакетной радиосвязи, GPRS), и/или корреляции сообщений.
УРОВЕНЬ ТЕХНИКИ
УМТС (Универсальная мобильная телекоммуникационная система, UMTS) является более общим термином для систем передачи данных 3П (третьего поколения, 3G), основанных на интерфейсе радиосвязи ШМДКР (широкополосный множественный доступ с кодовым разделением каналов, WCDMA), обладающем большой емкостью. ГСПС (Глобальная система подвижной связи, GSM) является наиболее широко распространенной системой передачи данных 2П (второго поколения, 2G), основанной на радиосвязи МДВР (Множественный доступ с временным разделением каналов, TDMA). Целью системы УОНПР является обеспечение связности узлов, поддерживаемое на глобальном 2-ом уровне, с использованием средств радиосвязи 2G или 3G (например, ГСПС, Американский стандарт МДВР, УМТС, ГРСРД (ГСПС/РДГС (Enhanced Data for ГСПС, Расширенные данные для Глобальной системы подвижной связи, EDGE) Глобальная расширенная сеть радиодоступа, GERAN) от подвижного терминала (ПТ, MT) сотовой связи (иногда также обозначаемого как подвижная станция (ПС, MS) или пользовательское оборудование (ПО, UE)) к внешней сети передачи пакетных данных. УОНПР может поддерживать различные протоколы 3-го уровня (например. IPv4; IPv6; PPP (ПДС, Протокол двухточечной связи)).
Главными узлами сети УОНПР являются ОУПУ (Обслуживающий Узел поддержки УОНПР, SGSN) и УПМУ (Узел поддержки межсетевых УОНПР, GGSN). Узлами ОУПУ являются узлы, обслуживающие ПТ. Каждый ОУПУ поддерживает УОНПР для ГСПС и/или УМТС. Узлом УПМУ является узел для обработки межсетевого обмена с сетями СППД (Сеть пакетной передачи данных, PDN). Обмен сигнализацией и данными между ОУПУ и УПМУ или ОУПУ и ОУПУ осуществляют с использованием протокола GTP (Протокол туннелирования УОНПР (GPRS)). Протокол GTP обрабатывает мобильность и создание, модификацию и удаление туннелей GTP, а также передачу пользовательских данных между узлами УПУ (GSN). GTP позволяет осуществлять туннелирование многопротокольных пакетов между узлами УПУ и между ОУПУ и наземной сетью радиодоступа УМТС (НСРДУ (UTRAN) не показана), через которую устанавливают соединение с рассматриваемым ПТ. Другим компонентам системы не требуется быть осведомленными о GTP. Обычно для отдельного туннеля используют два IP-адреса, один для управляющего сообщения GTP (то есть, сигнализации) и один для GTP пользовательского пакета (то есть, несущего пользовательские данные).
При подсоединении, осуществляемом УОНПР, узел ОУПУ устанавливает контекст управления мобильностью (УМ, ММ), содержащий информацию, относящуюся, например, к мобильности и безопасности для рассматриваемого ПТ. При активизации контекста PDP (Протокол передачи пакетных данных, ПППД) узел ОУПУ устанавливает контекст PDP, подлежащий использованию для целей маршрутизации, совместно с УПМУ, который будет использован абонентом. Подсоединенному УОНПР подвижному терминалу (ПТ) может быть назначен либо статический, либо динамический IP-адрес (обозначаемый так же как PDP-адрес). Статический адрес назначает оператор связи национальной сухопутной подвижной сети общего пользования (НСПСОП, HPLMN) во время подписки. Динамический IP-адрес может быть назначен посредством УПМУ (Узел поддержки межсетевых УОНПР, GGSN) оператором связи либо НСПСОП, либо визитной (гостевой) СПСОП (Сухопутная подвижная сеть общего пользования, PLMN) (Визитная (зарубежная) ВСПСОП (Визитная сухопутная подвижная сеть общего пользования, VPLMN)) во время активизации контекста PDP (ПППД, Протокол передачи пакетных данных). В дополнение к распределению адресов УПМУ осуществляет пересылку IP-пакетов из туннеля GTP (Протокол Туннелирования УОНПР) в сеть передачи пакетных данных (СППД) и обратно. Есть два вида магистральных сетей СПСОП, магистральная сеть Intra-PLMN («Внутри-СПСОП») и магистральная сеть Inter-PLMN («Между-СПСОП»). Магистральная сеть Intra-PLMN является частной IP-сетью, предназначенной для данных домена пакетной передачи и сигнализации только внутри СПСОП, тогда как межсетевую СПСОП магистральную сеть используют для роуминга (или автоматического подключения к местной сети связи) от одной СПСОП к другой (через граничные шлюзы). Обслуживающие узлы поддержки УОНПР (узлы ОУПУ) и узлы УПМУ используют магистральную сеть Intra-PLMN для обмена доменными данными и сигнализации, относящимися к УОНПР.
В течение роуминга магистральные сети Intra-PLMN как домашней сети, так и визитной сети используют в качестве дополнения к магистральной сети Inter-PLMN. Когда абонент осуществляет роуминг в другой СПСОП, то есть ВСПСОП, то пользователь сначала должен подсоединиться к сети. При подсоединении, осуществляемом УОНПР, ПТ посредством выдачи информации о своей идентификации (идентификационном номере), возможности(ях) и местоположении сообщает обслуживающему ОУПУ о своем намерении подсоединиться к сети. Затем ОУПУ проверяет идентификацию ПТ и выполняет процедуру аутентификации для того, чтобы обеспечить безопасность маршрута передачи. Подсоединение является завершенным после того, как ОУПУ принял данные об осуществляющем роуминг абоненте от регистра исходного местонахождения (РИМ, HLR) сети НСПСОП абонента и завершена процедура обновления местоположения. После подсоединения, осуществляемого УОНПР, ПТ посылает запрос «Активизировать контекст PDP», в котором имя точки доступа (ИТД, APN) является ссылкой на точку доступа (ТД, AP) УПМУ, предназначенную для использования как в домашней, так и в визитной СПСОП. ОУПУ выбирает УПМУ на основании регистрации подписки контекста PDP и посылает данные контекста к выбранному УПМУ. Затем УПМУ маршрутизирует пакеты в соответствующую сеть пакетной передачи данных (СППД).
Когда абонент осуществляет роуминг в ВСПСОП, то есть две следующие возможности для выбора УПМУ. В соответствии с первой, домашнюю сеть УПМУ можно использовать через магистральную сеть Inter-PLMN и шлюзы ГШ. Затем домашний УПМУ маршрутизирует пакеты их адресату. В соответствии со второй, визитный домен УПМУ можно использовать для маршрутизации пакетов от ВСПСОП к их адресату непосредственно через сеть пакетной передачи данных (СППД), например, сеть Интернет.
Следует отметить, что существуют два уровня IP-адресации:
пользовательский IP-адрес, соответствующий пакетам, передаваемым по протоколу GTP. Соответствующий IP-адрес обозначают как PDP-адрес или пользовательский адрес; и
сетевой IP-адрес, соответствующий пакетам, передаваемым по протоколу ниже GTP. Соответствующие IP-адреса являются IP-адресами узлов, используемыми при обмене пакетами GTP между узами УПУ. Такие IP-адреса можно также использовать для сетевой операции такой, как определение затрат или ЭиТО (Эксплуатация и техническое обслуживание, O&M).
Пользовательские и сетевые адреса являются независимыми между собой, благодаря протоколу GTP, и оба могут быть как IPv4, так и IPv6.
Узлы магистральной сети УОНПР, относящиеся ко второму (2П) и третьему (3П) поколениям, для сетевых адресов могут дополнительно использовать адресацию, основанную на IPv6. Однако, существующие описания, допускающие использование адресов IPv6, не определяют, как поддерживать обратную совместимость с узлами, основанными на IPv4. ОУПУ должны быть осведомлены заранее о том, что выбранные УПМУ поддерживают IPv6-адреса перед вставкой IPv6-адреса, например, в сообщение запроса на создание контекста PDP.
Более того, другая трудность возникает с известными процедурами. Если ПТ перемещается от ОУПУ, использующего IPv6, который соединен с УПМУ, использующим IPv6, к ОУПУ, использующим только IPv4, связь будет потеряна, поскольку новый ОУПУ не может использовать переданный IPv6-адрес. Такой сценарий очень реалистичен в особенности, когда два оператора связи с оборудованием от различных изготовителей (или только различной версии программного обеспечения) имеют соглашения о роуминге (например, о национальном роуминге). Следует отметить, что существующие способы перехода от IPv4-к-IPv6 в данном случае не применимы, поскольку они не воздействуют на IP-адреса, переносимые в GTP.
В дополнение, практическим требованием является то, что замены протокола должны быть сделаны так, чтобы узлы, основанные на прежней (более ранней) версии описаний (и поэтому не поддерживающей расширения, предлагаемого в настоящем документе), должны продолжить межсетевое взаимодействие с новыми узлами, поддерживающими предлагаемое в настоящем документе расширение.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Следовательно, задача настоящего изобретения заключается в том, чтобы создать способ и систему для обеспечения переключения адресов или функции корреляции, посредством которой можно достичь обратную совместимость адресов.
Данную задачу решают посредством способа и системы так, как сформулировано в пунктах 1, 13, 17 и 19 формулы изобретения, соответственно.
Дополнительно, вышеупомянутую задачу решают посредством сетевого узла так, как сформулировано в пунктах 23, 27 и 30 формулы изобретения, соответственно.
Соответственно, если одну из точек соединения изменяют (например, при обновлении зоны маршрутизации между ОУПУ; изменении местоположения обслуживающего РСК (Радиосетевой контроллер, RNC)), прежняя точка соединения (например, прежний ОУПУ) должна послать новой точке соединения (например, новому ОУПУ) как первый, так и второй адрес, чтобы позволить новой точке соединения повторно установить соединение с другим концом соединения (УПМУ), даже если она может осуществлять связь с использованием только одного из 2 адресов.
Более того, сообщения сигнализации, например сообщения, относящиеся к определению затрат, правомочному перехвату, и/или специализированным (заказным) приложениям (например, специализированным приложениям для архитектуры расширенной логики сетей подвижной связи, (СПАРЛСПС, CAMEL)), принятые от различных сетевых узлов, могут быть коррелированы на основании альтернативных адресов.
Усовершенствованные дополнительные разработки определены в зависимых пунктах формулы изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
В нижеследующем настоящее изобретение будет описано более подробно на основании предпочтительного варианта осуществления со ссылками на прилагаемые чертежи, на которых:
Фиг. 1 - принципиальная блок-схема архитектуры магистральной сети УОНПР, в которой может быть осуществлено настоящее изобретение;
Фиг. 2 - схема сигнализации, на которой показана процедура обновления зоны маршрутизации между ОУПУ согласно предпочтительному варианту осуществления, и
Фиг. 3 - схема сигнализации, на которой показана обслуживающая процедура изменения местоположения ОПСР согласно предпочтительному варианту осуществления.
ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
Далее на основании домена пакетной передачи архитектуры магистральной сети СПСОП, показанной на Фиг. 1, будет описан предпочтительный вариант осуществления, в котором используют способ переключения адресов IPv6 к IPv4.
Согласно Фиг. 1, сеть 10 пакетной передачи данных (СППД) (например, IP-сеть) соединена через первый УПМУ 31 с первой СПСОП 71, содержащей первую магистральную сеть 51 Intra-PLMN. Дополнительно первая СПСОП 71 включает в себя по меньшей мере первый ОУПУ 61 и второй ОУПУ 62, соединенные между собой и с первым УПМУ 31 через первую магистральную сеть 51 Intra-PLMN. Дополнительно СППД 10 соединены между собой через второй УПМУ 32 со второй СПСОП 72, включающей в себя вторую магистральную сеть 52 Intra-PLMN. Кроме того, вторая СПСОП 72 включает в себя по меньшей мере третий ОУПУ 63, соединенный со вторым УПМУ 32 через вторую магистральную сеть 52 Intra-PLMN. Первая и вторая СПСОП 71, 71 соединены между собой через магистральную сеть 20 Inter-PLMN. Соединение между первой СПСОП 71 и магистральной сетью 20 Inter-PLMN обеспечивают через первый граничный шлюз (ГШ) 41. Подобным образом соединение между второй СПСОП 72 и магистральной сетью 20 Inter-PLMN обеспечивают через второй ГШ 42.
Каждая из магистральных сетей Intra-PLMN 51, 52 может быть частной IP-сетью, предназначенной для данных домена пакетной передачи и сигнализации. Частная IP-сеть является IP-сетью, к которой применяют некоторые средства управления доступом, чтобы достичь требуемого уровня безопасности. Магистральная сеть 20 Inter-PLMN может быть сетью пакетной передачи данных, например сетью Интернет общего пользования или арендуемой (выделенной) линией связи, которая может быть выбрана в соответствии с соглашением о роуминге, включающем в себя функциональные возможности обеспечения безопасности ГШ (то есть, обычно только маршрутизатор с функциями обеспечения безопасности). Первый и второй шлюзы ГШ 41, 42 не определены в рамках домена пакетной передачи.
Узлы поддержки УОНПР (УПУ), то есть, от первого до третьего ОУПУ от 61 до 63 и первый и второй узлы УПМУ 31, 32, имеют функциональные возможности, необходимые для поддержки функциональных возможностей УОНПР для ГСПС (Глобальная система подвижной связи) и/или УМТС. В частности, первый и второй узлы УПМУ 31, 31 представляют сетевые узлы, к которым осуществляют доступ посредством СППД 10 в результате вычисления PDP-адреса. Он содержит информацию о маршрутизации для подсоединенных к УОНПР пользователей. Информацию о маршрутизации используют для туннелирования блоков пакетных данных (БПД) в текущей точке подсоединения ПТ, то есть, соответствующего обслуживающего ОУПУ. Таким образом, первый и второй узлы УПМУ 31, 32 являются первыми точками межсоединения СППД с первой и второй сетями СПСОП 71, 72, соответственно. От первого до третьего узлы ОУПУ от 61 до 63 представляют собой узлы для обслуживания ПТ. Каждый ОУПУ поддерживает УОНПР для ГСПС и/или УМТС.
Дополнительные подробности, относящиеся к архитектуре сети и процедурам (передачи) сигнализации, могут быть получены из описания TS 23.060 версии 4 для ПП3П (Проект партнерства систем 3-го поколения, 3GPP).
Согласно предпочтительному варианту осуществления ОУПУ, который намерен использовать адресацию IPv6, будет всегда указывать адреса ОУПУ по IPv6, а также IPv4 в соответствующем сообщении GTP, предназначенном для сигнализации, которое используют для запроса на создание туннеля GTP к выбранному УПМУ. Дополнительно ОУПУ может также указывать адреса ОУПУ по IPv6, а также IPv4 в соответствующем сообщении GTP, предназначенном для запроса на обновление туннеля GTP. Но это не является необходимым, если перед посылкой обновления, ОУПУ уже «знает» тип адресов, поддерживаемых УПМУ. Однако, может быть полезным, если оператор связи предпочитает изменять установки на узле на основании «от узла к узлу» для тех средств, которые подлежат использованию (возможно, вследствие промежуточной сети).
Если выбранный УПМУ на сетевом уровне поддерживает IPv6, то он должен также указать IPv6-адреса в соответствующем ответном сообщении GTP вместе с адресами IPv4. IPv4-адреса сохраняют в ОУПУ и не используют для передачи. IPv6-адреса используют для передачи на сетевом уровне. Для варианта передачи обслуживания между ОУПУ, адреса IPv4 и IPv6 будут даны новому ОУПУ таким способом, который является обратно совместимым. Если новый ОУПУ не поддерживает IPv6-адреса, он использует принятые IPv4-адреса для обновления туннеля к УПМУ. УПМУ также может начинать прием пользовательских данных от нового ОУПУ прежде, чем туннель будет обновлен. Поэтому первый и второй узлы УПМУ 31, 32 должны быть готовы принимать пакеты GTP (сигнализацию или пользовательские данные) по адресам либо IPv6, либо IPv4.
Следует отметить, что в будущем может быть предусмотрен новый ОУПУ, который будет иметь возможность использования на сетевом уровне только IPv6, и те же принципы будут применимы.
В качестве альтернативного варианта осуществления узел может выбирать подлежащие использованию способы передачи (IPv4 или IPv6) на основании установок оператора связи.
Если выбранный УПМУ не поддерживает IPv6 на сетевом уровне, он указывает только IPv4-адреса в соответствующем ответном сообщении GTP. Затем IPv4-адреса используют для передачи на сетевом уровне так, как определено на настоящее время.
Поскольку предложено посылать IPv6-адрес в качестве нового дополнительного информационного элемента, то обратную совместимость можно обеспечить так, чтобы внести IPv6 в состав узлов будущей сети и поддерживать соединения на сетевом уровне, даже если новый ОУПУ поддерживает только IPv4.
В нижеследующем со ссылкой на Фиг. 2 и 3 будут описаны примеры конкретных сообщений сигнализации и объединения конкретных полей адресов для передачи альтернативных адресов. Конкретные подробности, относящиеся к сообщениям сигнализации и процедурам, могут быть получены из описаний TS 29.060 и TS 23.060 версии 4 3GPP.
Запрос на создание контекста PDP посылают от узла ОУПУ к узлу УПМУ как часть процедуры УОНПР для активизации контекста PDP. Действительный запрос инициирует создание туннеля между контекстом PDP в ОУПУ и контекстом PDP в УПМУ. Если ОУПУ предпочитает использовать IPv6 ниже GTP, то он включает IPv6-адреса в состав новых полей сообщения, предназначенных для альтернативных адресов ОУПУ, и альтернативный или эквивалентный IPv4-адрес в существующие поля сообщения для адресов ОУПУ. Если УПМУ поддерживает IPv6 ниже GTP, то он сохраняет и использует альтернативные IPv6-адреса ОУПУ для связи с ОУПУ. Если УПМУ ниже GTP поддерживает только IPv4, то он сохраняет и использует IPv4-адреса ОУПУ для связи с ОУПУ. ОУПУ принимает пакеты, посланы ли они по его IPv4 или IPv6 адресу. УПМУ не должен сохранять IP-адреса для ОУПУ, которые он не использует. Такой способ обеспечивает максимальную гибкость, поскольку он не основан на специальных функциональных возможностях СДИ (Служба доменных имен, DNS) и позволяет УПМУ осуществлять обработку, использующую только IPv4, и обработку, использующую и IPv4, и IPv6.
Нижеследующая Таблица 1 показывает конкретные информационные элементы, предусмотренные в сообщении, предназначенном для запроса на создание контекста PDP.
| Таблица 1 | |
| Информационный элемент | Требование наличия |
| МИНПА (Международный идентификационный номер подвижного абонента, IMSI) | Условный |
| Восстановление | Дополнительный |
| Выбор | Условный |
| Данные идентификатора конечной точки туннеля | Обязательный |
| Идентификатор конечной точки туннеляУровень управления | Условный |
| NSAPI | Обязательный |
| Связанный NSAPI | Условный |
| Характеристики определения затрат | Дополнительный |
| Ссылка на трассировку | Дополнительный |
| Тип трассировки | Дополнительный |
| Адрес конечного пользователя | Условный |
| Имя точки доступа | Условный |
| Дополнительные установки протокола | Условный |
| Адрес ОУПУ для сигнализации | Обязательный |
| Адрес ОУПУ для пользовательского трафика | Обязательный |
| Альтернативный адрес ОУПУ для сигнализации | Дополнительный |
| Альтернативный адрес ОУПУ для пользовательского трафика | Дополнительный |
| Международный номер подвижной ЦСиО-станции(MSISDN) | Условный |
| Профиль для качества обслуживания | Обязательный |
| TFT | Условный |
| Идентификатор триггера | Дополнительный |
| Идентификация ЦУО (Центр управления и обслуживания, ОМС) | Дополнительный |
| Частное расширение | Дополнительный |
Сообщение «Ответ на создание контекста PDP» посылают от узла УПМУ к узлу ОУПУ в качестве отклика на запрос «Создать контекст PDP». Когда ОУПУ принимает «Ответ на создание контекста PDP» со значением (поля) «Cause» («Причина»), указывающим «Запрос принят», ОУПУ активизирует PDP контекст и может начинать пересылку БПД в/из ПТ из/во внешнюю сеть передачи данных.
Если УПМУ поддерживает IPv6 ниже протокола GTP, и ОУПУ включил IPv6-адрес ОУПУ в состав запроса, то УПМУ должен включить IPv6-адреса в новые поля для альтернативных адресов УПМУ, и эквивалентные IPv4-адреса в поля для адресов УПМУ. ОУПУ использует альтернативные IPv6-адреса УПМУ для связи с УПМУ, за исключением тех случаев, когда оператор связи установил использование IPv4. ОУПУ сохраняет адреса УПМУ и посылает их новому ОУПУ в ответном сообщении о контексте PDP (сообщение, посылаемое прежним ОУПУ к новому ОУПУ после того, как ПС выполнила процедуру обновления зоны маршрутизации к новому ОУПУ, о том, что новый ОУПУ послал сообщение с запросом контекста PDP прежнему ОУПУ). УПМУ должен принять пакеты, посланы ли они по его IPv4 или IPv6 адресу. Такой способ избегает потерю соединения, если новый ОУПУ поддерживает ниже GTP только IPv4.
В таблице 2 показаны конкретные информационные элементы, предусмотренные в сообщении «Ответ на создание контекста PDP».
| Таблица 2 | |
| Информационный элемент | Требование наличия |
| Причина | Обязательный |
| Необходимо переупорядочение | Условный |
| Восстановление | Дополнительный |
| Данные идентификатора конечной точки туннеля | Условный |
| Идентификатор конечной точки туннеляУровень управления | Условный |
| ИД (ID) определения затрат | Условный |
| Адрес конечного пользователя | Условный |
| Дополнительные установки протокола | Дополнительный |
| Адрес УПМУ для Уровня управления | Условный |
| Адрес УПМУ для пользовательского трафика | Условный |
| Альтернативный адрес УПМУ для уровня управления | Условный |
| Альтернативный адрес УПМУ для пользовательского трафика | Условный |
| Профиль для качества обслуживания | Условный |
| Адрес шлюза определения затрат | Дополнительный |
| Частное расширение | Дополнительный |
Кроме того, сообщение «Запрос обновления контекста PDP» посылают от ОУПУ к УПМУ как часть процедуры УОНПР «Обновить маршрутизацию между ОУПУ» или процедуры «Обновление контекста PDP» или для перераспределения контекстов вследствие совместного использования нагрузки. ОУПУ может использовать IPv6-адреса ОУПУ, только если он принял IPv6-адрес УПМУ от прежнего ОУПУ (вариант «Обновить маршрутизацию между ОУПУ») или УПМУ («Обновление контекста PDP»). Иначе ОУПУ использует IPv4-адреса ОУПУ.
Если УПМУ поддерживает IPv6 ниже GTP и ОУПУ включил IPv6-адрес ОУПУ в состав запроса, то УПМУ включает IPv6-адреса в состав полей для альтернативных адресов УПМУ и эквивалентный IPv4-адрес в поля адреса УПМУ. ОУПУ использует альтернативные IPv6-адреса УПМУ для связи с УПМУ. ОУПУ может сохранять и IPv4, и IPv6 адреса УПМУ и посылать их новому ОУПУ в ответном сообщении о контексте PDP. Поля альтернативных адресов УПМУ не посылают, если не послано поле адреса УПМУ. Данный способ гарантирует, что ОУПУ всегда сохраняет соответствующие IPv4 и IPv6 адреса УПМУ, так что соединение не будет потеряно при перемещении к новому ОУПУ, поддерживающему ниже GTP только IPv4.
В нижеследующей Таблице 3 показаны конкретные информационные элементы сообщения «Ответ на обновление контекста PDP».
| Таблица 3 | |
| Информационный элемент | Требование наличия |
| Причина | Обязательный |
| Восстановление | Дополнительный |
| Данные идентификатора конечной точки туннеля | Условный |
| Идентификатор конечной точки туннеляУровень управления | Условный |
| ИД определения затрат | Условный |
| Адрес УПМУ для уровня управления | Условный |
| Адрес УПМУ для пользовательского трафика | Условный |
| Альтернативный адрес УПМУ для уровня управления | Условный |
| Альтернативный адрес УПМУ для пользовательского трафика | Условный |
| Профиль для качества обслуживания | Условный |
| Адрес шлюза определения затрат | Дополнительный |
| Частное расширение | Дополнительный |
Кроме того, что касается сообщения «Запрос контекста ОУПУ», то новый ОУПУ посылает данное сообщение прежнему ОУПУ, чтобы получить управление мобильностью (УМ), и контексты PDP для ПТ. В качестве отклика прежний ОУПУ выдает «Ответ о контексте ОУПУ».
Новый ОУПУ добавляет адрес ОУПУ для уровня управления. Если новый ОУПУ поддерживает IPv6 ниже GTP, то он добавляет свой IPv6-адрес в поле «Альтернативный адрес ОУПУ для уровня управления». Затем прежний ОУПУ выбирает адрес ОУПУ для уровня управления в зависимости от поддержки им IPv6 и сохраняет данный выбранный адрес ОУПУ и использует его при посылке сообщений уровня управления для ПТ к новому ОУПУ в процедуре ОУПУ, предназначенной для передачи контекста.
В Таблице 4 показаны конкретные информационные элементы, предусмотренные в сообщении «Запрос контекста ОУПУ».
| Таблица 4 | |
| Информационный элемент | Требование наличия |
| МИНПА (Международный идентификационный номер подвижного абонента, IMSI) | Условный |
| Идентификация зоны маршрутизации (ИЗМ) | Обязательный |
| Временный идентификатор логической линии связи (ВИЛЛС) | Условный |
| ВНПА-П Временный номер подвижного абонента (для) пакета (TMSI пакета) | Условный |
| Подпись ВНПА-П | Условный |
| ПС проверена на достоверность | Дополнительный |
| Идентификатор конечной точки туннеляУровень управления | Обязательный |
| Адрес ОУПУ для уровня управления | Обязательный |
| Альтернативный адрес ОУПУ для уровня управления | Условный |
| Частное расширение | Дополнительный |
Прежний ОУПУ посылает сообщение «Ответ о контексте ОУПУ» новому ОУПУ в качестве отклика на предыдущий «Запрос контекста ОУПУ». Прежний ОУПУ может использовать IPv6-адреса ОУПУ, только если он принял IPv6-адрес ОУПУ от нового ОУПУ. Иначе ОУПУ должен использовать IPv4-адреса ОУПУ.
Новый ОУПУ посылает сообщение «Подтверждение контекста ОУПУ» к прежнему ОУПУ в качестве отклика на сообщение «Ответ о контексте ОУПУ». Только после приема сообщения «Подтверждение контекста ОУПУ» прежний ОУПУ начинает пересылать пакеты пользовательских данных. «Подтверждение контекста ОУПУ» указывает для прежнего ОУПУ, что новый ОУПУ корректно принял информацию о контексте PDP и готов принимать пакеты пользовательских данных.
Новый ОУПУ использует для пользовательского трафика адрес ОУПУ, который может отличаться от того, который предусмотрен базовыми сетевыми службами (например, IP). Прежний ОУПУ сохраняет данный адрес ОУПУ и использует его при посылке блоков БПД по нисходящей линии связи к новому ОУПУ для ПТ. ОУПУ может использовать IPv6-адреса, только если он принял IPv6-адрес ОУПУ для уровня управления от прежнего ОУПУ. Иначе ОУПУ использует IPv4-адреса ОУПУ.
На Фиг. 2 показана схема сигнализации, указывающая процедуру обновления маршрутизации зоны «между» ОУПУ согласно предпочтительному варианту осуществления.
В данном примере сигнализации ПТ посылает запрос «Обновить зону маршрутизации» к новому ОУПУ, чтобы инициировать обновление зоны маршрутизации. В отклике на запрос новый ОУПУ посылает к прежнему ОУПУ сообщение «Запрос контекста ОУПУ», включающее в себя поля адресов ОУПУ и поля альтернативных адресов ОУПУ. В отклике на него прежний ОУПУ возвращает сообщение «Ответ о контексте ОУПУ», в котором для полей уровня управления в адресе ОУПУ установлен требуемый тип адреса, и, если доступны, в состав включены все адреса IPv4 и IPv6 для УПМУ. Новый ОУПУ отвечает сообщением «Подтверждение контекста ОУПУ», включающим в себя информацию об используемом типе адреса. Затем новый ОУПУ посылает сообщение «Запрос обновления контекста PDP», включающего в себя информацию о наборе типов адресов, к соответствующему УПМУ. Данное сообщение посылают, используя IP-адрес УПМУ, принятый от прежнего ОУПУ. Если новый ОУПУ и УПМУ поддерживают IPv6 на сетевом уровне, то предпочтительно используют IPv6-адрес УПМУ. Если либо ОУПУ, либо УПМУ не поддерживает IPv6, то используют IPv4-адреса. В данном случае, предполагают, что на первой стадии переключения к IPv6 все узлы поддерживают IPv4. УПМУ возвращает сообщение «Ответ об обновлении контекста PDP», включающее в себя поля адресов УПМУ и поля альтернативных адресов УПМУ. Данные поля адресов особенно необходимы в следующих случаях:
- Прежний ОУПУ поддерживал только IPv4 и не сохранил альтернативный адрес УПМУ, так что новому ОУПУ необходимо принять его от УПМУ, чтобы иметь возможность использовать IPv6 для соединения.
- УПМУ изменил свой IP-адрес (обычно вследствие перераспределения контекста PDP на новой обрабатывающей плате (схеме обработки)).
В дополнение, если по некоторой причине УПМУ выполнен с возможностью использования IPv4 для связи с новым ОУПУ (вследствие возможных трудностей в промежуточной IP-сети), УПМУ вернет только IPv4-адреса и не будет посылать поле альтернативного адреса, содержащее IPv6-адрес.
В заключение выполняют процедуру обновления требуемой зоны маршрутизации.
В качестве дополнительного сообщения сигнализации GTP определено сообщение «Запрос прямого перемещения», который посылает прежний ОУПУ новому ОУПУ для передачи необходимой информации, чтобы выполнить процедуру ОПСР (Обслуживающая подсистема сети радиосвязи), предназначенную для перемещения между новым ОУПУ и целевым РСК (Радиосетевой контроллер) в НСРДУ. В данном случае прежний ОУПУ добавляет адрес ОУПУ к информации поля «Уровень управления». Если прежний ОУПУ поддерживает IPv6 ниже GTP, то он добавляет свой IPv6-адрес в поле «Альтернативный адрес ОУПУ» для уровня управления. Новый ОУПУ выбирает адрес ОУПУ для уровня управления в зависимости от поддержки им IPv6, и сохраняет данный выбранный адрес ОУПУ, и использует его при посылке сообщений уровня управления для ПТ к прежнему ОУПУ в процедуре ОПСР, предназначенной для перемещения.
В Таблице 5 показаны конкретные информационные элементы, предусмотренные в сообщении «Запрос прямого перемещения».
| Таблица 5 | |
| Информационный элемент | Требование наличия |
| МИНПА (Международный идентификационный номер подвижного абонента, IMSI) | Обязательный |
| Идентификатор конечной точки туннеляУровень управления | Обязательный |
| Причина RANAP | Обязательный |
| Контекст УМ | Обязательный |
| Контекст PDP | Условный |
| Адрес ОУПУ для уровня управления | Обязательный |
| Альтернативный адрес ОУПУ для уровня управления | Дополнительный |
| Идентификация целевого объекта | Обязательный |
| «Прозрачный контейнер» НСРДУ | Обязательный |
| Частное расширение | Дополнительный |
Новый ОУПУ посылает сообщение «Ответ на прямое перемещение» прежнему ОУПУ в качестве отклика на предыдущее сообщение «Запрос прямого перемещения». Новый ОУПУ добавляет адрес ОУПУ для информации уровня управления. ОУПУ может вставлять IPv6-адреса, только если он принял IPv6-адрес ОУПУ для уровня управления от прежнего ОУПУ. Иначе новый ОУПУ использует IPv4-адреса ОУПУ. Прежний ОУПУ сохраняет данный адрес ОУПУ и использует его при посылке сообщений уровня управления для ПТ к новому ОУПУ в процедуре ОПСР, предназначенной для перемещения. На Фиг. 3 показана схема сигнализации, указывающая процедуру ОПСР (Обслуживающая подсистема сети радиосвязи), предназначенную для перемещения согласно предпочтительному варианту осуществления.
В данном примере сигнализации исходная ОПСР, относящаяся к НСРДУ, принимает решение о выполнении или инициации перемещения ОПСР и посылает сообщение «Необходимо перемещение» прежнему ОУПУ. В качестве отклика на него, прежний ОУПУ определяет, является ли перемещение ОПСР перемещением ОПСР «между» ОУПУ, и, если это так, он посылает сообщение «Запрос прямого перемещения», включающее в себя поле адреса ОУПУ и поле альтернативного адреса ОУПУ для сигнализации уровня управления, в соответствующий новый ОУПУ. В качестве отклика на него новый ОУПУ посылает сообщение «Запрос перемещения» целевому Радиосетевому контроллеру (РСК), относящемуся к НСРДУ. Затем между целевым РСК и новым ОУПУ устанавливают поддерживающие Iu-интерфейс каналы-носители (однонаправленные каналы), относящиеся к каналам-носителям радиодоступа (КНРД), поскольку существующие радиоканалы-носители будут перераспределены между ПТ и целевым РСК, когда целевой РСК выполняет роль «Обслуживающего РСК» в новом ОПСР. После того, как новый ОУПУ принял сообщение «Подтверждение запроса перемещения» от НСРДУ, устанавливают туннели GTP между целевым РСК и новым ОУПУ. Затем сообщение «Ответ на прямое перемещение» посылают от нового ОУПУ к прежнему ОУПУ, чтобы таким образом указать, что целевой РСК готов к приему от исходного ОРСК (Обслуживающий РСК), относящегося к ОПСР, пересылаемых блоков пакетных данных (БПД). Прежний ОУПУ продолжает перемещение ОПСР, посредством посылки сообщения «Команда перемещения» к исходному ОРСК. Исходный ОРСК теперь готов пересылать по нисходящей линии связи пользовательские данные непосредственно целевому РСК. Когда пересылка данных завершена, целевой РСК посылает сообщение «Обнаружить перемещение» новому ОУПУ. В качестве отклика на него новый ОУПУ посылает сообщение «Запрос обновления контекста PDP» к рассматриваемому УПМУ. УПМУ возвращает сообщение «Ответ об обновлении контекста PDP», включающего в себя поля адреса УПМУ и поля альтернативного адреса УПМУ. Когда новый ОУПУ принимает от ОРСК сообщение «Изменение местоположения завершено», осуществляют обмен сигнализацией «Пересылка изменения местоположения завершена» между новым и прежним ОУПУ, и затем прежний ОУПУ инициирует процедуру освобождения интерфейса Iu в ОРСК. В заключение, если идентификация новой зоны маршрутизации отличается, то ПТ инициирует процедуру «Обновить зону маршрутизации».
Кроме того, информационный элемент контекста PDP содержит параметры управления сеансом, определяемые для внешнего адреса сети передачи пакетных данных, и которые являются необходимыми для передачи между узлами ОУПУ в процедуре «Обновить зону маршрутизации между ОУПУ».
Если УПМУ «согласовал» с прежним ОУПУ использование IPv6 ниже GTP, то прежний ОУПУ устанавливает альтернативный адрес УПМУ для пользовательского трафика, и альтернативный адрес УПМУ для полей уровня управления, содержащими IPv6-адреса, подлежащие использованию для связи с УПМУ. Новый ОУПУ, не поддерживающий IPv6 ниже GTP, игнорирует данные альтернативные адреса УПМУ и использует для связи адрес УПМУ для пользовательского трафика и адрес УПМУ для полей уровня управления. Новый ОУПУ, поддерживающий IPv6 ниже GTP, сохраняет адрес УПМУ для пользовательского трафика и адреса УПМУ для уровня управления, но использует для передачи данных альтернативный адрес УПМУ для пользовательского трафика и альтернативный адрес УПМУ для уровня управления.
В Таблице 6 показано информационное поле контекста PDP.
| Таблица 6 | |||||
| 1 | Тип = 130 (Десятичное) | ||||
| 2-3 | Длина | ||||
| 4 | Резерв | VAA | Резерв | Упорядочение | NSAPI |
| 5 | X | X | X | X | ИТДУ (SAPI) |
| 6 | КО (QoS) Sub Длина | ||||
| 7-(q+6) | КО (QoS) Sub [4..255] | ||||
| Q+7 | КО (QoS) Req Длина | ||||
| (q+8)-(2q+7) | КО (QoS) Req [4..255] | ||||
| 2q+s | КО (QoS) Neg. Длина | ||||
| (2q+9)-(3q+8) | КО (QoS) Neg [4..255] | ||||
| (3q+9)-(3q+10) | Номер последовательности Ниже (НПН)1) | ||||
| (3q+11)-(3q+12) | Номер последовательности Выше (НПВ)1) | ||||
| 3q+13 | Послать номер1) Н-БПД | ||||
| 3q+14 | Принять номер1) Н-БПД | ||||
| (3q+15)-(3q+18) | Идентификатор конечной точки туннеля восходящей линии связи Уровень управления | ||||
| (3q+19)-(3q+22) | Данные идентификатора конечной точки туннеля восходящей линии связи | ||||
| 3q+23 | Идентификатор контекста PDP | ||||
| 3q+24 | Свободно 1111 | Тип структуры PDP | |||
| 3q+25 | Номер типа PDP | ||||
| 3q+26 | Длина адреса PDP | ||||
| (3q+27)-m | Адрес PDP [1..63] | ||||
| M+1 | Адрес УПМУ для уровня управления Длина | ||||
| (m+2)-n | Адрес УПМУ для уровня управления [4..16] | ||||
| N+1 | Адрес УПМУ для пользовательского трафика Длина | ||||
| (n+2)-o | Адрес УПМУ для пользовательского трафика [4..16] | ||||
| O+1 | ИТД Длина | ||||
| (o+2)-p | ИТД | ||||
| P+1 | Сво |