УЛУЧШЕНИЕ PMIP-ПРОТОКОЛА Российский патент 2016 года по МПК H04W88/18 

Область техники, к которой относится изобретение

Примерные варианты осуществления направлены на улучшение использования PMIP-протокола. В частности, некоторые примерные варианты осуществления направлены на предоставление сетевого узла, определяющего то, какой PMIP-протокол должен быть использован при сетевой связи.

Уровень техники

В типичной системе сотовой связи, также называемой сетью беспроводной связи, беспроводные терминалы, также известные как мобильные станции и/или модули абонентских устройств, обмениваются данными через сеть радиодоступа (RAN) с одной или более базовых сетей. Беспроводные терминалы могут представлять собой мобильные станции или модули абонентских устройств, к примеру, мобильные телефоны, также известные как "сотовые" телефоны, и переносные компьютеры с поддержкой беспроводной связи, например мобильный терминал, и в силу этого могут представлять собой, например, портативные, карманные, переносные, включенные в компьютер или устанавливаемые в автомобилях мобильные устройства, которые обмениваются речью и/или данными с сетью радиодоступа.

Сеть радиодоступа покрывает географическую область, которая разделяется на сотовые области, при этом каждая сотовая область обслуживается посредством базовой станции, например базовой радиостанции (RBS), которая в некоторых сетях также называется "узлом B (NodeB)" или "узлом B" (B node) и которая в этом документе также упоминается в качестве базовой станции. Сота является географической областью, в которой покрытие радиосвязью предоставляется посредством оборудования базовой радиостанции в узле базовой станции. Каждая сота идентифицируется посредством идентификационных данных в локальной зоне радиосвязи, которые передаются в широковещательном режиме в соте. Базовые станции обмениваются данными по радиоинтерфейсу, работающему на радиочастотах, с модулями абонентских устройств в пределах дальности базовых станций.

В некоторых версиях сети радиодоступа несколько базовых станций типично подключаются (например, посредством наземных линий или микроволн) к контроллеру радиосети (RNC). Контроллер радиосети, также иногда называемый контроллером базовой станции (BSC), контролирует и координирует различные действия нескольких базовых станций, подключенных к нему. Контроллеры радиосети типично подключаются к одной или более базовых сетей.

Универсальная система мобильной связи (UMTS) является системой мобильной связи третьего поколения, которая получена в результате усовершенствования глобальной системы мобильной связи (GSM) и предназначена для того, чтобы предоставлять улучшенные услуги мобильной связи на основе технологии широкополосного множественного доступа с кодовым разделением каналов (WCDMA). Наземная сеть радиодоступа UMTS (UTRAN) по существу является сетью радиодоступа с использованием широкополосного множественного доступа с кодовым разделением каналов для модулей абонентских устройств (UE). Партнерский проект третьего поколения (3GPP) взял на себя ответственность за дополнительное усовершенствование технологий сетей радиодоступа на основе UTRAN и GSM. Стандарт долгосрочного развития (LTE) наряду с усовершенствованным ядром пакетной коммутации (EPC) является новейшим дополнением в 3GPP-семействе.

Мобильный Интернет-протокол прокси-узла версия 6 (PMIPv6) является сетевым протоколом управления мобильностью, стандартизированным посредством IETF. PMIPv6 является протоколом для компоновки общей технологии и технологии доступа независимо от мобильных базовых сетей, приспособления различных технологий доступа, таких как архитектуры доступа на основе WiMAX, 3GPP, 3GPP2 и WLAN.

Сущность изобретения

По меньшей мере одна примерная цель примерных вариантов осуществления, представленных в данном документе, заключается в том, чтобы улучшать PMIPv6-связь. Принцип примерных вариантов осуществления, представленных в данном документе, заключается в том, чтобы предоставлять механизм в стеке PMIP-протоколов для того, чтобы давать возможность MAG-узлу, к примеру, SGW (который может поддерживать как PMIP-проект, так и PMIP RFC) или LMA, определять то, какой стек PMIP-протоколов должен быть использован для того, чтобы обмениваться данными с равноправным узлом, т.е. LMA/MAG. Некоторые примерные варианты осуществления, представленные в данном документе, могут быть направлены на решение проблем обратной несовместимости между PMIP RFC и PMIP-проектом.

Примерные варианты осуществления могут содержать механизм для узла с поддержкой двойного стека PMIP-протоколов (PMIP RFC или PMIP-проекта), например MAG/LMA, когда транспортная сеть является IPv4-сетью, и он инициирует связь с равноправным узлом, например отправку сообщения обновления привязки прокси-узла. Механизм может содержать отправку сообщения в двух форматах при самой первой связи с равноправным узлом, либо он не знает, какой PMIP-протокол поддерживает равноправный узел, причем первый задается с учетом PMIP-проекта, т.е. PMIPv6-сообщения/IPv6/с IPv4- или IPv4 UDP-инкапсуляцией, а другой соответствует PMIP RFC, т.е. PMIPv6/UDP/IPv4. Следовательно, если равноправный узел поддерживает один стек PMIP-протоколов, то он имеет возможность отвечать только на одно из сообщений; а если равноправный узел поддерживает оба стека PMIP-протоколов, узел может отвечать исключительно на сообщения на основе RFC-версии. Посредством вышеуказанного механизма стек протоколов на основе либо PMIP-проекта, либо PMIP RFC может быть выбран для остальной связи.

Соответственно, некоторые примерные варианты осуществления могут быть направлены на способ в первом равноправном сетевом узле для определения PMIPv6-плоскости управления, используемой посредством второго равноправного сетевого узла. Первый и второй равноправные сетевые узлы находятся в транспортной сети на основе Интернет-протокола версия 4 (IPv4). Способ содержит отправку, во второй равноправный сетевой узел по меньшей мере одного сообщения связи по меньшей мере в одном формате плоскости управления. Способ дополнительно содержит прием по меньшей мере одного ответа по осуществлению связи относительно по меньшей мере одного сообщения связи. Способ также содержит определение версии PMIPv6-плоскости управления, которая используется посредством второго равноправного сетевого узла, на основе по меньшей мере одного ответа по осуществлению связи.

Некоторые примерные варианты осуществления могут быть направлены на первый равноправный сетевой узел для определения PMIPv6-плоскости управления, используемой посредством второго равноправного сетевого узла. Первый и второй равноправные сетевые узлы находятся в транспортной IPv4-сети. Первый равноправный сетевой узел содержит передающую схему, выполненную с возможностью отправлять, во второй равноправный сетевой узел по меньшей мере одно сообщение связи по меньшей мере в одном формате плоскости управления. Первый равноправный сетевой узел дополнительно содержит приемную схему, выполненную с возможностью принимать по меньшей мере один ответ по осуществлению связи относительно по меньшей мере одного сообщения связи. Первый равноправный сетевой узел также содержит схему обработки, выполненную с возможностью определять версию PMIPv6-плоскости управления, которая используется посредством второго равноправного сетевого узла, на основе по меньшей мере одного ответа по осуществлению связи.

Краткое описание чертежей

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

Фиг. 1-3 являются иллюстративными примерами трактов миграции.

Фиг. 4 является схематическим видом сетевого узла, согласно некоторым примерным вариантам осуществления.

Фиг. 5 является блок-схемой последовательности операций способа, иллюстрирующей примерные операции сетевого узла по фиг. 4.

Определения

3GPP - Партнерский проект третьего поколения

3GPP2 - Партнерский проект третьего поколения 2

BNG - широкополосный сетевой шлюз

BSC - контроллер базовой станции

DNS - система доменных имен

EPC - усовершенствованное ядро пакетной коммутации

ePDG - усовершенствованный шлюз пакетной передачи данных

GPRS - общая служба пакетной радиопередачи

GSM - глобальная система мобильной связи

GTP - протокол GPRS-туннелирования

GW - шлюз

HRPD - стандарт высокоскоростной передачи пакетных данных

HSGW - обслуживающий HRPD-шлюз

IE - информационный элемент

IETF - Инженерная группа по развитию Интернета

IPv4 - Интернет-протокол версия 4

IPv6 - Интернет-протокол версия 6

LMA - локальная привязка для мобильности

LTE - стандарт долгосрочного развития

MAG - мобильный шлюз доступа

MME - объект управления мобильностью

PDN - сеть пакетной передачи данных

PGW - PDN-шлюз

PLMN - наземная сеть мобильной связи общего пользования

PMIP - мобильный Интернет-протокол прокси-узла

PMIPv6 - мобильный Интернет-протокол прокси-узла версия 6

RAN - сеть радиодоступа

RBS - базовая радиостанция

RNC - контроллер радиосети

S4-SGSN - обслуживающий S4-узел поддержки GPRS

SGW - обслуживающий шлюз

UE - абонентское устройство

UDP - протокол пользовательских датаграмм

UMTS - универсальная система мобильной связи

UTRAN - наземная сеть радиодоступа UMTS

WCDMA - широкополосный множественный доступ с кодовым разделением каналов

WiMAX - стандарт общемировой совместимости широкополосного беспроводного доступа

WLAN - беспроводная локальная вычислительная сеть

Подробное описание изобретения

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

В качестве средства пояснения примерных вариантов осуществления, представленных в данном документе, проблема сначала должна идентифицироваться и обсуждаться. 3GPP CT4 пришла к выводу о необходимости обновлять стек PMIP-протоколов C-плоскости согласно TS29.275 с тем, чтобы согласовывать RFC с Rel-9 и выше. Хотя ссылка на документ IETF Rel-9 уже обновлена на RFC5844 с предварительного документа IETF "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17, изменение для стека протоколов C-плоскости не отражено.

Одновременно CT4 выяснила, что RFC не является обратно совместимым с проектом при использовании PMIPv6 по транспортной IPv4-сети. В предварительной версии рекомендован NAT-обход, при котором UDP-инкапсуляция может необязательно выбираться в зависимости от того, обнаружено или нет NAT на тракте. В PMIP RFC, UDP-инкапсуляция становится обязательной, и внутренний IPv6-заголовок удаляется. Таким образом, PMIP-узел на основе предварительной версии не может обмениваться данными с PMIP-узлом на основе RFC-версии. Кроме того, PMIP-оператор на основе предварительной версии не может всегда поддерживать PMIP-узел на основе предварительной версии, поскольку стек PMIP-протоколов на основе предварительной версии более не поддерживается посредством IETF. Тем не менее, проблема межсетевого взаимодействия также вызывает сложность при миграции PMIP-сети на основе предварительной версии на PMIP-сеть на основе RFC. Таким образом, требуются некоторые механизмы или обратно совместимый способ для того, чтобы обновлять технические требования с Rel-8 на Rel-9 и выше.

Решение на основе DNS, содержащееся в статье 3GPP CT4 "C4-111205", предложено компанией NTT DOCOMO для того, чтобы улучшать DNS-процедуры для GW-выбора, в которые введены новые служебные параметры "x-3gpp-sgw:x-s5-pmip2", "x-3gpp-sgw:x-s8-pmip2", "x-3gpp-pgw:x-s5-pmip2" для того, чтобы указывать характеристики PMIP-плоскости A управления на основе RFC, при следовании существующим служебным параметрам "x-3gpp-sgw:x-s8-pmip", "x-3gpp-sgw:x-s5-pmip", "x-3gpp-pgw:x-s5-pmip", которые отражают характеристики PMIP-плоскости управления на основе предварительной версии. Посредством введения вышеуказанного нового служебного параметра MME/S4-SGSN имеет возможность выбирать SGW/PGW на основе идентичного стека PMIP-протоколов.

Ниже поясняются различные способы для улучшения PMIP-связи.

Тракт миграции - случай без роуминга

Далее поясняются тракты миграции для того, чтобы обновлять эти узлы на основе PMIP-проекта, например SGW/PGW/ePDG, на формат на основе PMIP RFC.

Альтернатива 1: обновление всех PMIP-узлов на стек PMIP-протоколов на основе RFC за один вечер

Обновление программного обеспечения на всех PMIP-узлах с формата на основе предварительной версии на формат на основе RFC за очень короткое время. За счет ограниченного простоя системы сеть может мигрировать на новый стек PMIP-протоколов одновременно.

Доводы "за":

- Отсутствие влияния на не-PMIP-узлы

- Тракт быстрой миграции (одноэтапная миграция)

Доводы "против":

- Ограниченный простой системы

- Все узлы должны обновляться вместе

Заключение:

- Не требуется дополнительных решений по миграции.

Альтернатива 2: двухэтапная миграция

В этой альтернативе, оператор может поддерживать PMIP-узлы на основе предварительной версии в течение большего времени. При добавлении новых PMIP-узлов в сеть новые PMIP-узлы (LMA и/или MAG) должны допускать одновременную поддержку стека PMIP-протоколов на основе RFC и на основе предварительной версии.

Как показано на фиг. 1, LMA1 и MAG1 представляют собой PMIP-узлы на основе предварительной версии. Этап 1 тракта миграции заключается в том, чтобы добавлять LMA2 и MAG2, которые имеют поддержку двойного стека. Оба MAG могут обмениваться данными с двумя LMA без каких-либо проблем.

В этой альтернативе, добавленные новые PMIP-узлы могут быть частью существующей PMIP-сети для целей обслуживания другой PDN или разделения нагрузки, или резервирования системы и т.д. Проблема мобильности между покрытием MAG1 и MAG1 отсутствует.

Тем не менее, для того чтобы исключать проблемы связи в самый первый раз, в новом MAG может требоваться индикатор до отправки самого первого PMIP-сообщения в конкретную LMA. Этот индикатор, возможно, также должен перенаправляться в целевую систему в процедуре активации мобильности. На этом этапе, индикатор должен сообщать MAG1 то, что либо должен применяться стек протоколов на основе предварительной версии, либо должен применяться любой стек протоколов.

Этап 2 тракта миграции, проиллюстрированный на фиг. 2, заключается в том, чтобы добавлять LMA3 и MAG3, которые имеют поддержку RFC-стека, когда PMIP-узлы на основе предварительной версии полностью удалены (или обновлены). Это служит для того, чтобы исключать проблему межсетевого взаимодействия и мобильности между LMA1/MAG1 и LMA3/MAG3.

Аналогично этапу 1, для того чтобы исключать проблемы связи в самый первый раз, в MAG может требоваться индикатор до отправки самого первого PMIP-сообщения в конкретную LMA. Этот индикатор, возможно, также должен перенаправляться в целевую систему в процедуре активации мобильности. На этом этапе, индикатор должен сообщать MAG2 то, что либо должен применяться стек протоколов на основе RFC, либо должен применяться любой стек протоколов.

Доводы "за":

- Все новые PMIP-узлы и старые PMIP-узлы могут без проблем обмениваться данными друг с другом

- Обновление PMIP-узлов может выполняться поочередно

- Отсутствие простоя системы

Доводы "против":

- Более длинный тракт миграции

- Двухэтапная миграция

- На этапе 1, новый разработанный PMIP-узел должен одновременно поддерживать оба стека протоколов на основе предварительной версии и на основе RFC.

Альтернатива 3: добавление новых PMIP-узлов (LMA и/или MAG), которые имеют поддержку только RFC-стека

В этой альтернативе, оператор может поддерживать PMIP-узлы на основе предварительной версии в течение большего времени. При добавлении новых PMIP-узлов в сеть новые PMIP-узлы (LMA и/или MAG) могут допускать поддержку только стека PMIP-протоколов на основе RFC.

Как показано на фиг. 3, LMA1 и MAG1 представляют собой PMIP-узлы на основе предварительной версии. LMA2 и MAG2 представляют собой новый PMIP-узел, который основан только на RFC. Связь между LMA1 и MAG1 или между LMA2 и MAG1 не осуществляется вследствие проблемы несовместимости поддерживаемого стека PMIP-протоколов.

В этой альтернативе, добавленные новые PMIP-узлы становятся раздельной PMIP-сетью по отношению к существующей PMIP-сети. Межсетевое взаимодействие и мобильность между двумя сетями отсутствуют до тех пор, пока узлы на основе PMIP-проекта не обновятся так, чтобы они поддерживают как RFC, так и предварительную версию, либо поддерживают только RFC. Дополнительный индикатор должен добавляться в процедуре GW-выбора. Этот индикатор, возможно, также должен перенаправляться в целевую систему в процедуре активации мобильности.

Индикатор должен задаваться в расчете на каждое абонентское устройство.

Доводы "за":

- Отсутствие простоя системы

- Одноэтапная миграция

- Новый PMIP-узел не должен поддерживать PMIP-проект, который, в конечном счете, должен удаляться из 3GPP.

Доводы "против":

- Необходимо поддерживать две раздельные сети

- Отсутствие разделения нагрузки, межсетевого взаимодействия и мобильности между двумя сетями.

Анализ

Альтернатива 1 представляет собой простое и быстрое решение. Она также не требует работ по стандартизации. Применение альтернативы 3 маловероятно вследствие проблем межсетевого взаимодействия и мобильности и одновременных работ по техобслуживанию двух сетей.

Альтернатива 2 является очень вероятной, поскольку она предоставляет тракт плавной миграции. Если можно предположить, что альтернатива 2 представляет собой возможный тракт миграции, этот новый индикатор может быть реализован несколькими различными способами:

- Решение 1: локальная конфигурация в MAG1

- На этапе 1 миграции MAG1 должен быть сконфигурирован с активированной предварительной версией.

- На этапе 2 миграции MAG1 должен быть переконфигурирован с активированной RFC-версией.

-- Доводы "за"

--- Отсутствие влияния в виде стандартизации

--- Отсутствие влияния на не-PMIP-узлы

--- Низкие затраты

-- Доводы "против"

--- Затраты на управление сетью для переконфигурирования в SGW

- Решение 2: новый GTP-индикатор отправляется посредством MME

- Перед этапом 1 миграции все MME в сети должны обновляться с тем, чтобы поддерживать новый GTP-индикатор.

- На этапе 1 миграции MME отправляет новый индикатор "предварительная версия должна быть использована" в MAG1 в сообщении с запросом на создание сеанса.

- На этапе 2 миграции MME отправляет новый индикатор "RFC-версия должна быть использована" в MAG1 в сообщении с запросом на создание сеанса.

-- Доводы "за"

--- Отсутствие переконфигурирования в MAG

-- Доводы "против"

--- Влияние в виде стандартизации на GTP

--- Все MME должны сначала обновляться перед тем, как начинается миграция

--- Затраты на управление сетью для переконфигурирования в MME

--- Дополнительные затраты

- Решение 3: новый GTP-индикатор отправляется посредством MME плюс новая функция очистки DNS-имен

-- Перед этапом 1 миграции все MME в сети должны обновляться с тем, чтобы поддерживать новый GTP-индикатор.

-- На этапе 1 миграции только "PMIP на основе предварительной версии" должен быть выбран в процедуре MME DNS-очистки. Так же, MME отправляет новый индикатор "предварительная версия должна быть использована" в MAG1 в сообщении с запросом на создание сеанса.

-- Перед этапом 2 миграции, новая DNS-конфигурация для нового PMIP DNS-имени.

-- На этапе 2 миграции только "PMIP на основе RFC-версии" должен быть выбран в процедуре MME DNS-очистки. Так же, MME отправляет новый индикатор "RFC-версия должна быть использована" в MAG1 в сообщении с запросом на создание сеанса.

-- Доводы "за"

--- Отсутствие переконфигурирования в MAG

-- Доводы "против"

--- Влияние в виде стандартизации на GTP

--- Все MME должны сначала обновляться перед тем, как начинается миграция

--- Новая процедура MME DNS-очистки, которая может не быть обратно совместимой

--- Затраты на управление сетью для переконфигурирования в MME и DNS

--- Дополнительные затраты

- Решение 4: идентично решению 3, но с двумя новыми DNS-именами в сети миграции.

- При использовании этого решения, текущее DNS-имя является неизменным в стандартах. Два новых PMIP DNS-имени добавляются для S5-интерфейса: s5-pmip-rfc и s5-pmip-draft.

- Только два новых PMIP DNS-имени используются в сети миграции. Это позволяет полностью исключать влияние на существующие R8/R9/R10 MME-реализации.

Введение в примерные варианты осуществления

Альтернатива 2 является очень вероятной, поскольку она предоставляет тракт плавной миграции. Тем не менее, может требоваться решение по миграции. Это обусловлено тем, что MAG2 должен знать, какая PMIP-версия должна применяться, до отправки PMIP-сообщения в LMA. Он может использовать решение на основе DNS, в котором вводятся новые служебные параметры для того, чтобы давать возможность MME выбирать набор SGW/PGW-узлов, которые поддерживают идентичный стек PMIP-протоколов; тем не менее, для того, чтобы поддерживать роуминг и процедуры активации мобильности между SGW, процедуры между 3GPP- и не-3GPP-узлами, готовое DNS-решение должно обновлять множество протоколов, например DNS/GTP/Diameter-протокол, и это оказывает влияние на многие интерфейсы S11/S4/S3/S10/S1 S6a/S6d/SWx. Еще более важным является тот факт, что для того, чтобы поддерживать роуминг на основе PMIP, MME (даже если он расположен в обслуживающей сети, в которой развернут только один PMIP RFC, но имеет роуминговое соглашение с проблематичной собственной PLMN, в которой развернуты оба PMIP-стека) должен поддерживать новое PMIP-именование и должен поддерживать новый IE стека PMIP-протоколов в GTPv2, что не является надлежащим. С другой стороны, поддержка двойных стеков в качестве промежуточного этапа в ходе миграции не может быть исключена, следовательно, может использоваться другое преимущественное решение, которое представляет собой просто улучшение стека PMIP-протоколов.

Примерные обновления для связанных с MAG процедур

Некоторые примерные варианты осуществления могут содержать обновления связанных с MAG процедур. Когда MAG-узел поддерживает оба стека PMIP-протоколов, как указано выше, и IPv4 используется в транспортной сети при первой связи с равноправным узлом, или если MAG-узел не знает, какой PMIP-протокол поддерживает равноправный узел, MAG-узел может отправлять PMIP-сообщение, например обновление привязки прокси-узла, в LMA с двумя форматами с использованием различных стеков PMIP-протоколов, если MAG не знает, какой стек PMIP-протоколов поддерживается посредством равноправного LMA-узла. Если ответное сообщение принимается в двух форматах, может учитываться формат только на основе RFC.

Примерные обновления для связанных с LMA процедур

Некоторые примерные варианты осуществления могут содержать обновления связанных с LMA процедур. Когда LMA-узел поддерживает оба стека PMIP-протоколов, как указано выше, и IPv4 используется в транспортной сети, и он принимает PMIP-сообщение в двух форматах из идентичного MAG, LMA-узел может отправлять ответное сообщение только в RFC-формате.

Примерные обновления для механизмов подтверждения работоспособности

Некоторые примерные варианты осуществления могут содержать обновления для механизмов подтверждения работоспособности. Механизмы подтверждения работоспособности также могут быть использованы для того, чтобы сообщать равноправному узлу то, какой стек PMIP-протоколов должен быть использован.

Когда MAG- или LMA-узел поддерживает оба стека PMIP-протоколов, как указано выше, и IPv4 используется в транспортной сети при первой связи с равноправным узлом (или MAG- или LMA-узел не знает, какой PMIP-протокол поддерживает равноправный узел), MAG- или LMA-узел может отправлять сообщение с запросом на подтверждение работоспособности в двух форматах в соответствии с PMIP-проектом и PMIP RFC.

Когда MAG- или LMA-узел поддерживает оба стека PMIP-протоколов, как указано выше, и IPv4 используется в транспортной сети, если сообщение с запросом на подтверждение работоспособности принимается из идентичного равноправного узла в двух форматах в соответствии с PMIP-проектом и PMIP RFC, равноправный узел может отправлять ответ по подтверждению работоспособности только в RFC-формате. Если ответное сообщение принимается в двух форматах, может учитываться формат только на основе RFC.

Примерные механизмы обновления

Некоторые примерные варианты осуществления могут быть направлены на механизм обновления в процедуре управления PMIP-туннелированием. Когда MAG- или LMA-узел поддерживает оба стека PMIP-протоколов, как указано выше, и IPv4 используется в транспортной сети, в случае обновлений программного обеспечения, например обновлений на PMIP-версию на основе RFC, MAG- или LMA-узел может увеличивать значение счетчика перезапусков, который инициирует механизм подтверждения работоспособности, чтобы сообщать равноправному узлу то, какую PMIP-версию он поддерживает.

Примерная конфигурация узла

Фиг. 4 иллюстрирует пример сетевого узла (например, MAG, LMA и/или равноправного узла), который может включать некоторые примерные варианты осуществления, поясненные в данном документе. Сетевой узел 14 может содержать любое число портов или схем связи, например приемную схему 20 и передающую схему 24. Порты или схемы связи могут быть выполнены с возможностью принимать и передавать любую форму передаваемых данных или инструкций. Следует принимать во внимание, что сетевой узел 14 альтернативно может содержать один порт или схему приемо-передающего устройства. Дополнительно следует принимать во внимание, что порт или схема связи или приемо-передающего устройства может иметь форму любого порта или схемы ввода-вывода при связи, известного в данной области техники.

Сетевой узел 14 дополнительно может содержать по меньшей мере одно запоминающее устройство 26. Запоминающее устройство 26 может быть выполнено с возможностью сохранять принимаемые, передаваемые и/или измеренные данные любого типа и/или исполняемые программные инструкции. Запоминающее устройство 26 может представлять собой любой подходящий тип машиночитаемого запоминающего устройства и может иметь энергозависимый и/или энергонезависимый тип.

Сетевой узел 14 также может содержать схему 22 обработки, которая может быть выполнена с возможностью устанавливать множество оптических маршрутов на основе информации, принимаемой на SSL 11. Следует принимать во внимание, что схема 22 обработки может представлять собой любой подходящий тип модуля вычисления, например микропроцессор, процессор цифровых сигналов (DSP), программируемую пользователем вентильную матрицу (FPGA) или специализированную интегральную схему (ASIC). Также следует принимать во внимание, что схема 22 обработки не должна обязательно содержаться в качестве одного модуля. Схема 22 обработки может содержаться в качестве любого числа модулей или схем.

Примерные операции сетевого узла

Фиг. 5 является блок-схемой последовательности операций способа, иллюстрирующей примерные операции первого равноправного сетевого узла, такого как сетевой узел по фиг. 4. Примерная последовательность операций направлена на способ в первом равноправном сетевом узле для определения PMIPv6-плоскости управления, используемой посредством второго равноправного сетевого узла. Первый и второй равноправные сетевые узлы находятся в транспортной IPv4-сети. Первый и второй равноправные сетевые узлы могут представлять собой MAG/LMA-узлы, такие как MAG/LMA-узлы, описанные на фиг. 1-3. Следует принимать во внимание, что согласно некоторым примерным вариантам осуществления LMA-узел может представлять собой PGW. Согласно некоторым примерным вариантам осуществления, MAG-узел может представлять собой SGW, усовершенствованный шлюз пакетной передачи данных (ePDG), обслуживающий HRPD-шлюз (HSGW) и/или широкополосный сетевой шлюз (BNG).

Этап 50

Первый равноправный сетевой узел отправляет (50) во второй равноправный сетевой узел по меньшей мере одно сообщение связи по меньшей мере в одном формате плоскости управления. Передающая схема 24 выполнена с возможностью отправлять, во второй равноправный сетевой узел по меньшей мере одно сообщение связи по меньшей мере в одном формате плоскости управления. Следует принимать во внимание, что формат плоскости управления может представлять собой формат плоскости A управления или плоскости B управления.

Согласно некоторым примерным вариантам осуществления, первый равноправный сетевой узел представляет собой MAG-узел, а второй равноправный сетевой узел представляет собой LMA-узел. В таких примерных вариантах осуществления по меньшей мере одна связь может представлять собой сообщение подтверждения работоспособности или запрос на обновление привязки прокси-узла.

Согласно некоторым примерным вариантам осуществления, первый равноправный сетевой узел представляет собой LMA-узел, а второй равноправный сетевой узел представляет собой MAG-узел. В таких примерных вариантах осуществления по меньшей мере одна связь представляет собой сообщение подтверждения работоспособности.

Примерный этап 52

Согласно некоторым примерным вариантам осуществления по меньшей мере одно сообщение связи может представлять собой первое и второе сообщение связи первого и второго типа управления (например, формата A плоскости управления и формата C плоскости управления), соответственно. Отправка (50) дополнительно может содержать одновременную отправку (52) первого и второго сообщений связи во второй равноправный сетевой узел. Передающая схема 24 может быть выполнена с возможностью одновременно отправлять первое и второе сообщения связи.

Примерный этап 54

Согласно некоторым примерным вариантам осуществления по меньшей мере одно сообщение связи может представлять собой первое сообщение связи первого типа управления. Если ответ из второго равноправного сетевого узла не принимается в течение времени, по меньшей мере один ответ по осуществлению связи представляет собой первый ответ по осуществлению связи. Первый ответ по осуществлению связи представляет собой первое внутреннее уведомление относительно того, что должно отправляться второе сообщение связи второго типа управления. Например, неприем ответа из второго равноправного сетевого узла может быть результатом неподдержки посредством второго равноправного сетевого узла первого типа управления, в котором отправлено первое сообщение связи. Прием первого внутреннего уведомления может быть основан на программируемых пользователем правилах в первом равноправном сетевом узле. Следует принимать во внимание, что вышеуказанный сценарий может быть использован для того, чтобы описывать примерные этапы 54, 58, 62 и 64.

Таким образом, согласно некоторым примерным вариантам осуществления, первый равноправный сетевой узел может отправлять (54) второе сообщение связи второго типа плоскости управления. Передающая схема 24 может отправлять второе сообщение связи второго типа плоскости управления.

Этап 56

Первый равноправный сетевой узел дополнительно выполнен с возможностью принимать (56) по меньшей мере один ответ по осуществлению связи (например, первый ответ по осуществлению связи и/или второй ответ по осуществлению связи) относительно по меньшей мере одного сообщения связи (например, первого сообщения связи и/или второго сообщения связи), соответственно. Приемная схема 20 выполнена с возможностью принимать по меньшей мере один ответ по осуществлению связи относительно по меньшей мере одного сообщения связи.

Примерный этап 58

В примерных вариантах осуществления, в которых отправлено несколько сообщений связи (например, примерный этап 52), или в которых второе сообщение связи отправлено после предварительно определенного периода времени (например, примерный этап 54), первый равноправный сетевой узел может принимать (58) второй ответ по осуществлению связи относительно второго сообщения связи. Приемная схема может быть выполнена с возможностью принимать второй ответ по осуществлению связи относительно второго сообщения связи.

Этап 60

Первый равноправный сетевой узел дополнительно определяет (60) версию PMIPv6-плоскости управления, которая используется посредством второго равноправного сетевого узла, на основе по меньшей мере одного ответа по осуществлению связи. Схема 22 обработки выполнена с возможностью определять версию PMIPv6-плоскости управления, которая используется посредством второго равноправного сетевого узла, на основе по меньшей мере одного ответа по осуществлению связи.

Примерный этап 62

Согласно некоторым примерным вариантам осуществления, если ответ из второго равноправного сетевого узла не принимается в течение предварительно определенного периода времени, второй ответ по осуществлению связи представляет собой второе внутреннее уведомление, которое указывает то, что связь со вторым сетевым узлом является невозможной. Таким образом, определение (60) дополнительно может содержать определение (62) PIMPv6-плоскости управления в качестве нулевого значения. Схема 22 обработки может быть выполнена с возможностью определять PIMPv6-плоскость управления в качестве нулевого значения.

Это может означать, что второй равноправный сетевой узел в данный момент недоступен. Таким образом, согласно некоторым примерным вариантам осуществления, первый равноправный сетевой узел может выполнять попытку повторной передачи второго и/или первого сообщения связи с тем, чтобы исключать сбой вследствие неустановившегося тракта.

Примерный этап 64

Согласно некоторым примерным вариантам осуществления, если второй ответ по осуществлению связи принимается из второго равноправного сетевого узла, определение (60) дополнительно может содержать определение (64) значения PIMPv6-плоскости управления в качестве второго типа управления (например, типа управления второго сообщения связи). Схема 22 обработки выполнена с возможностью определять значение PIMPv6-плоскости управления в качестве второго типа управления.

Примерный этап 66

Согласно некоторым примерным вариантам осуществления, если по меньшей мере один ответ по осуществлению связи принимается из второго равноправного сетевого узла, определение (60) дополнительно может содержать определение (66) значения PIMPv6-плоскости управления в качестве по меньшей мере одного формата плоскости управления для (или ассоциированного с) по меньшей мере одного сообщения связи. Схема 22 обработки может быть выполнена с возможностью определять значение PIMPv6-плоскости управления в качестве по меньшей мере одного формата плоскости управления по меньшей мере одного сообщения связи.

Согласно некоторым примерным вариантам осуществления по меньшей мере одно значение плоскости управления может представлять собой плоскость A управления. Например, согласно некоторым примерным вариантам осуществления, возможно только одно сообщение связи может отправляться за раз, чтобы экономить системные ресурсы. Таким образом, отправка может выполняться иерархическим способом. Согласно некоторым примерным вариантам осуществления, сообщения связи типа A плоскости управления могут отправляться первыми. Если ответ по осуществлению связи не принимается, первый равноправный сетевой узел после этого может отправлять сообщение связи типа B плоскости управления.

Примерный этап 68

Согласно некоторым примерным вариантам осуществления, если множество ответов по осуществлению связи принимается из второго равноправного сетевого узла (например, после того, как передаются множество или два сообщения связи), определение (60) дополнительно может содержать определение (68) значения PIMPv6-плоскости управления в качестве формата плоскости управления по умолчанию. Согласно некоторым примерным вариантам осуществления, значение формата плоскости управления по умолчанию может представлять собой плоскость A управления. Схема 22 обработки может быть выполнена с возможностью определять значение PIMPv6-плоскости управления в качестве формата плоскости управления по умолчанию.

Заключение

Таким образом, примерные варианты осуществления разрешают различные проблемы, описанные в данном документе. Неограничивающие примеры проблем, сложностей, соображений или преимуществ, ассоциированных с примерными вариантами осуществления, могут представлять собой следующее:

a. В конечном счете, 3GPP PMIP-протокол должен соответствовать IETF RFC, так что все 3GPP-узлы на основе PMIP-проекта должны обновляться с тем, чтобы поддерживать PMIP RFC.

b. Примерные варианты осуществления должны позволять минимизировать возможные простои системы.

c. Примерные варианты осуществления должны минимизировать влияние на другие сетевые элементы, например MME/HSS, которые основаны на совершенно других стеках протоколов.

d. Примерные варианты осуществления не должны влиять на сети другого оператора, в которых не развернуты узлы на основе PMIP или развернуты только PMIP RFC-узлы.

e. Примерные варианты осуществления дополнительно разрешают проблему обратной несовместимости для PMIP без какого-либо влияния на другие сетевые элементы и/или стеки протоколов.

Некоторые примерные варианты осуществления могут содержать способ в сетевом узле для улучшения PMIP-протокола, при этом сетевой узел может находиться в IPv4-сети. Способ может содержать этапы инициирования связи с равноправным узлом; и передачи, в равноправный узел, PMIP-сообщения в двух форматах. Примерные варианты осуществления, описанные выше, дополнительно могут содержать передачу PMIP-сообщения в формате PMIP-проекта и PMIP RFC-формата.

Любое из примерных вариантов осуществления, описанных выше, дополнительно могут содержать прием посредством равноправного узла PMIP-сообщения в двух форматах. Если равноправный узел имеет возможность поддерживать только один из двух передаваемых форматов, равноправный узел может отвечать в поддерживаемом формате. Если равноправный узел имеет возможность поддерживать оба из передаваемых форматов, равноправный узел может отвечать в PMIP RFC-формате.

Любые из примерных вариантов осуществления, описанных выше, дополнительно могут содержать инициирование связи в форме запроса на подтверждение работоспособности.

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

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

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

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

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

Следует отметить, что слово "содержащий" не обязательно исключает присутствие элементов или этапов, отличных от перечисленных элементов или этапов, и слова "a" или "an" перед элементом не исключают присутствие множества таких элементов. Дополнительно следует отметить, что ссылки с номерами не ограничивают объем формулы изобретения, что примерные варианты осуществления могут быть реализованы по меньшей мере частично посредством как аппаратных средств, так и программного обеспечения, и что несколько "средств", "модулей" или "устройств" могут представляться посредством идентичного элемента аппаратных средств.

"Устройство", когда этот термин используется в данном документе, должно быть широко интерпретировано как включающее в себя радиотелефон, имеющий возможности доступа в Интернет/сеть intranet, веб-обозреватель, органайзер, календарь, камеру (например, видео- и/или фотокамеру), звуковое записывающее устройство (например, микрофон) и/или приемное устройство на основе глобальной системы позиционирования (GPS); терминал по стандарту системы персональной связи (PCS), который может комбинировать сотовый радиотелефон с обработкой данных; персональное цифровое устройство (PDA), которое может включать в себя радиотелефон или систему беспроводной связи; переносной компьютер; камеру (например, видео- и/или фотокамеру), имеющую возможности связи; и любое другое вычислительное устройство или устройство связи, допускающее приемо-передачу, такое как персональный компьютер, электронная бытовая мультимедийная система, телевизионный приемник и т.д.

Различные примерные варианты осуществления, описанные в данном документе, описываются в общем контексте этапов способа или процессов, которые могут быть реализованы в одном аспекте посредством компьютерного программного продукта, осуществленного в машиночитаемом носителе, включающего в себя машиноисполняемые инструкции, такие как программный код, выполняемый посредством компьютеров в сетевых окружениях. Машиночитаемый носитель может включать в себя съемные и стационарные устройства хранения данных, включающие в себя, но не только, постоянное запоминающее устройство (ROM), оперативное запоминающее устройство (RAM), компакт-диски (CD), универсальные цифровые диски (DVD) и т.д. В общем, программные модули могут включать в себя процедуры, программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют конкретные абстрактные типы данных. Машиноисполняемые инструкции, ассоциированные структуры данных и программные модули представляют примеры программного кода для осуществления этапов способов, раскрытых в данном документе. Конкретная последовательность этих исполняемых инструкций или ассоциативно связанных структур данных представляет примеры соответствующих действий для реализации функций, описанных на этих этапах или процессах.

Изобретение относится к системам связи. Изобретение направлено на определение плоскости управления на основе мобильного Интернет-протокола прокси-узла версия 6 (PIMPv6), используемой посредством равноправного узла сетевого узла в транспортной сети на основе Интернет-протокола версия 4 (IPv4). Технический результата заключается в обеспечении обратной совместимости. Предоставлен механизм в стеке PMIP-протоколов, чтобы давать возможность узлу мобильного шлюза доступа/локальной привязки для мобильности (MAG/LMA), к примеру, SGW (который может поддерживать как PMIP-проект, так и PMIP RFC), определять то, какой стек PMIP-протоколов должен быть использован для того, чтобы обмениваться данными с равноправным узлом, т.е. LMA/MAG. 2 н. и 28 з.п. ф-лы, 5 ил.

1. Способ в первом равноправном сетевом узле для определения плоскости управления на основе мобильного Интернет-протокола прокси-узла версия б (PMIPv6), используемой посредством второго равноправного сетевого узла, причем первый и второй равноправные сетевые узлы находятся в транспортной сети на основе Интернет-протокола версия 4 (IPv4), при этом способ содержит этапы, на которых:
отправляют, во второй равноправный сетевой узел, первое сообщение связи в первом формате плоскости управления, при этом первый формат плоскости управления является одним из: форматом плоскости управления в соответствии с RFC (запрос на комментарий) 5844 (формат плоскости управления на основе RFC), и форматом плоскости управления в соответствии с предварительной версией RFC 5844 (формат плоскости управления на основе предварительной версии RFC);
получают первую информацию относительно первого сообщения связи, при этом первая информация указывает на одно из: 1) что второй равноправный сетевой узел отвечает на первое сообщение связи путем передачи ответного сообщения связи в указанном первом формате плоскости управления, и 2) что второй равноправный сетевой узел не отвечает на первое сообщение связи путем передачи ответного сообщения связи в указанном первом формате плоскости управления; и
определяют, используя указанную полученную первую информацию, является ли второй равноправный сетевой узел: а) использующим первую версию PMIPv6-плоскости управления или вторую версию PMIPv6-плоскости управления, или b) не использующим первую версию PMIPv6-плоскости управления или вторую версию PMIPv6-плоскости управления, при этом первая версия PMIPv6-плоскости управления является версией, соответствующей версии RFC 5844, и вторая версия PMIPv6-плоскости управления является версией, соответствующей предварительной версии RFC 5844.

2. Способ по п. 1, в котором первый равноправный сетевой узел представляет собой узел мобильного шлюза доступа (MAG), a второй равноправный сетевой узел представляет собой узел локальной привязки для мобильности (LMA), и по меньшей мере одна связь представляет собой сообщение подтверждения работоспособности или запрос на обновление привязки прокси-узла.

3. Способ по п. 1, в котором первый равноправный сетевой узел представляет собой узел локальной привязки для мобильности
(LMA), а второй равноправный сетевой узел представляет собой узел мобильного шлюза доступа (MAG), и по меньшей мере одна связь представляет собой сообщение подтверждения работоспособности.

4. Способ по любому из пп. 1-3, в котором по меньшей мере одно сообщение связи представляет собой первое сообщение связи первого типа плоскости управления, и если ответ из второго равноправного сетевого узла не принимается в течение предварительно определенного периода времени, по меньшей мере один ответ по осуществлению связи представляет собой первый ответ по осуществлению связи, причем упомянутый первый ответ по осуществлению связи представляет собой первое внутреннее уведомление в отношении того, что должно отправляться второе сообщение связи второго типа плоскости управления.

5. Способ по п. 4, дополнительно содержащий этапы, на которых:
отправляют (54) второе сообщение связи второго типа плоскости управления; и
принимают (58) второй ответ по осуществлению связи относительно второго сообщения связи.

6. Способ по п. 5, в котором если ответ из второго равноправного сетевого узла не принимается в течение предварительно определенного периода времени, второй ответ по осуществлению связи представляет собой второе внутреннее уведомление, которое указывает то, что связь со вторым равноправным сетевым узлом является невозможной, и определение (60) дополнительно содержит этап, на котором определяют (62) то, что PMIPv6-плоскость управления является нулевым значением.

7. Способ по п. 5, в котором если второй ответ по осуществлению связи принимается из второго равноправного сетевого узла, определение (60) дополнительно содержит этап, на котором определяют (64) то, что значение PIMPv6-плоскости управления имеет второй тип управления.

8. Способ по любому из пп. 1-3, в котором если по меньшей мере один ответ по осуществлению связи принимается из второго равноправного сетевого узла, определение (60) дополнительно содержит этап, на котором определяют (66) значение PMIPv6-плоскости управления в качестве по меньшей мере одного формата плоскости управления по меньшей мере одного сообщения связи.

9. Способ по п. 8, в котором по меньшей мере один формат плоскости управления представляет собой плоскость А управления.

10. Способ по любому из пп. 1-3, в котором по меньшей мере одно сообщение связи представляет собой первое и второе сообщение связи первого и второго типа управления, соответственно, отправка (50) дополнительно содержит этап, на котором одновременно отправляют (52) первое и второе сообщения связи.

11. Способ по п. 10, в котором если только один ответ по осуществлению связи принимается из второго равноправного сетевого узла, определение (60) дополнительно содержит этап, на котором определяют (66) значение PMIPv6-плоскости управления в качестве формата плоскости управления принимаемого ответа по осуществлению связи.

12. Способ по п. 10, в котором если множество ответов по осуществлению связи принимается из второго равноправного сетевого узла, определение (60) дополнительно содержит этап, на котором определяют (68) значение PMIPv6-плоскости управления в качестве формата плоскости управления по умолчанию.

13. Способ по п. 12, в котором формат плоскости управления по умолчанию представляет собой плоскость А управления.

14. Способ по п. 10, в котором если ответы из второго равноправного сетевого узла не принимаются в течение предварительно определенного периода времени, ответ по осуществлению связи представляет собой внутреннее уведомление, которое указывает то, что связь со вторым равноправным сетевым узлом является невозможной, и определение (60) дополнительно содержит этап, на котором определяют (62) то, что PMIPv6-плоскость управления является нулевым значением.

15. Способ по любому из пп. 4-7, 10-14, в котором первый формат плоскости управления представляет собой плоскость А управления, а второй формат плоскости управления представляет собой плоскость С управления.

16. Первый равноправный сетевой узел для определения плоскости управления на основе мобильного Интернет-протокола прокси-узла версия 6 (PMIPv6), используемой посредством второго равноправного сетевого узла, причем первый и второй равноправные сетевые узлы находятся в транспортной сети на основе Интернет-протокола версия 4 (IPv4), причем первый равноправный сетевой узел содержит:
- передающую схему;
- приемную схему; и
- схему обработки, выполненную с возможностью: использовать передающую схему для отправления, во второй равноправный сетевой узел, первого сообщения связи в первом формате плоскости управления, при этом первый формат плоскости управления является одним из: форматом плоскости управления в соответствии с RFC (запрос на комментарий) 5844 (формат плоскости управления на основе RFC), и форматом плоскости управления в соответствии с предварительной версией RFC 5844 (формат плоскости управления на основе предварительной версии RFC);
использовать приемную схему для получения первой информации относительно первого сообщения связи, при этом первая информация указывает на одно из: 1) что второй равноправный сетевой узел отвечает на первое сообщение связи путем передачи ответного сообщения связи в указанном первом формате плоскости управления, и 2) что второй равноправный сетевой узел не отвечает на первое сообщение связи путем передачи ответного сообщения связи в указанном первом формате плоскости управления; и
определять, используя указанную полученную первую информацию, является ли второй равноправный сетевой узел: а) использующим первую версию PMIPv6-плоскости управления или вторую версию PMIPv6-плоскости управления, или b) не использующим первую версию PMIPv6-плоскости управления или вторую версию PMIPv6-плоскости управления, при этом первая версия PMIPv6-плоскости управления является версией, соответствующей версии RFC 5844, и вторая версия PMIPv6-плоскости управления является версией, соответствующей предварительной версии RFC 5844.

17. Первый равноправный сетевой узел по п. 16, при этом первый равноправный сетевой узел представляет собой узел мобильного шлюза доступа (MAG), а второй равноправный сетевой узел представляет собой узел локальной привязки для мобильности (LMA), и по меньшей мере одна связь представляет собой сообщение подтверждения работоспособности или запрос на обновление привязки прокси-узла.

18. Первый равноправный сетевой узел по п. 16, при этом первый равноправный сетевой узел представляет собой узел локальной привязки для мобильности (LMA), а второй равноправный сетевой узел представляет собой узел мобильного шлюза доступа (MAG), и по меньшей мере одна связь представляет собой сообщение подтверждения работоспособности.

19. Первый равноправный сетевой узел по любому из пп. 16-18, в котором по меньшей мере одно сообщение связи представляет собой первое сообщение связи первого типа плоскости управления, и если ответ из второго равноправного сетевого узла не принимается в течение предварительно определенного периода времени, по меньшей мере один ответ по осуществлению связи представляет собой первый ответ по осуществлению связи, причем упомянутый первый ответ по осуществлению связи представляет собой первое внутреннее уведомление в отношении того, что должно отправляться второе сообщение связи второго типа плоскости управления.

20. Первый равноправный сетевой узел по п. 19, в котором передающая схема (24) дополнительно выполнена с возможностью отправлять второе сообщение связи второго типа плоскости управления; и приемная схема (20) также выполнена с возможностью принимать второй ответ по осуществлению связи относительно второго сообщения связи.

21. Первый равноправный сетевой узел по п. 20, в котором если ответ из второго равноправного сетевого узла не принимается в течение предварительно определенного периода времени, второй ответ по осуществлению связи представляет собой второе внутреннее уведомление, которое указывает то, что связь со вторым равноправным сетевым узлом является невозможной, и схема (22) обработки дополнительно выполнена с возможностью определять то, что PMIPv6-плоскость управления является нулевым значением.

22. Первый равноправный сетевой узел по п. 20, в котором если второй ответ по осуществлению связи принимается из второго равноправного сетевого узла, схема (22) обработки дополнительно выполнена с возможностью определять то, что значение PMIPv6-плоскости управления имеет второй тип управления.

23. Первый равноправный сетевой узел по любому из пп. 16-18, в котором если по меньшей мере один ответ по осуществлению связи принимается из второго равноправного сетевого узла, схема (22) обработки дополнительно выполнена с возможностью определять значение PMIPv6-плоскости управления в качестве по меньшей мере одного формата плоскости управления по меньшей мере одного сообщения связи.

24. Первый равноправный сетевой узел по п. 23, в котором по меньшей мере один формат плоскости управления представляет собой плоскость А управления.

25. Первый равноправный сетевой узел по любому из пп. 16-18, в котором по меньшей мере одно сообщение связи представляет собой первое и второе сообщение связи первого и второго типа управления, соответственно, передающая схема (24) дополнительно выполнена с возможностью отправлять первое и второе сообщения связи.
26. Первый равноправный сетевой узел по п. 25, в котором если только один ответ по осуществлению связи принимается из второго равноправного сетевого узла, схема (22) обработки дополнительно выполнена с возможностью определять значение PMIPv6-плоскости управления в качестве формата плоскости управления принимаемого ответа по осуществлению связи.

27. Первый равноправный сетевой узел по п. 25, в котором если множество ответов по осуществлению связи принимается из второго равноправного сетевого узла, схема (22) обработки дополнительно выполнена с возможностью определять значение PMIPv6-плоскости управления в качестве формата плоскости управления по умолчанию.

28. Первый равноправный сетевой узел по п. 27, в котором формат плоскости управления по умолчанию представляет собой плоскость А управления.

29. Первый равноправный сетевой узел по п. 25, в котором если ответы из второго равноправного сетевого узла не принимаются в течение предварительно определенного периода времени, ответ по осуществлению связи представляет собой внутреннее уведомление, которое указывает то, что связь со вторым равноправным сетевым узлом является невозможной, и схема (22) обработки дополнительно выполнена с возможностью определять то, что PMIPv6-плоскость управления является нулевым значением.

30. Первый равноправный сетевой узел по любому из пп. 19-22, 25-29, в котором первый формат плоскости управления представляет собой плоскость А управления, а второй формат плоскости управления представляет собой плоскость С управления.