Улучшение pmip-протокола

Улучшение pmip-протокола

Иллюстрации

Показать все

Реферат

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

Примерные варианты осуществления направлены на улучшение использования 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-плоскости управления в качестве формата плоскости управления по умолчанию.

Заключение

Таки