Передача контекста в сети связи, содержащей несколько разнородных сетей доступа

Изобретение относится к способу передачи контекста в сети связи, содержащей множество разнородных сетей доступа, причем к одной из этих сетей доступа подключен мобильный терминал, а также изобретение относится к средству управления передачей контекста и к мобильному терминалу передачи контекста. Технический результат - облегчение передачи контекста между разнородными сетями доступа. Для этого введено средство управления передачей контекста, формирующее, по меньшей мере, один контекст на основе возможностей и параметров, ассоциированных с мобильным терминалом, и возможностей и параметров соседних сетей доступа, учитывающих соответствующую технологию доступа. Дополнительно средство управления передачей контекста является общим для упомянутых разнородных сетей доступа в сети связи и выполняет передачи контекста, относящиеся к определенному мобильному терминалу. 3 н. и 24 з.п. ф-лы, 6 ил.

 

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

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

Предшествующий уровень техники

Для поддержания связности каждый перемещающийся мобильный узел, который подсоединен к сети, в то время когда он выходит из зоны обслуживания прежней сети, может выполнять передачу обслуживания в новую сеть. Если мобильный узел имеет действующий сеанс передачи данных через соединение, то это соединение должно быть приторможено по меньшей мере на время процесса передачи обслуживания. Дополнительные механизмы, подобные MobileIP (реализация протокола IP для мобильной связи), могут позволить перенаправить трафик к новой точке соединения, так что сеанс может быть возобновлен. Однако продолжительность передачи обслуживания является нижним временным пределом для разрыва сеанса связи.

Следовательно, очевидно, что следует поддерживать по возможности меньшую продолжительность передачи обслуживания. Механизмом для поддержания этого является упреждающая передача контекста. Упреждающая передача контекста позволяет устанавливать состояние сеанса в маршрутизаторе доступа (AR, МД) или в точке доступа (AP, ТД) до того, как мобильный узел (мобильный терминал) начинает передачу обслуживания в новую сеть. Упомянутая передача контекста осуществляется через основную сеть связи, к которой подсоединен маршрутизатор доступа или точка доступа. Например, это может быть Интернет.

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

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

CARD и CTP Seamoby

Рабочая группа Seamoby IETF (проблемная группа проектирования Интернет (ПГПИ)) разработала два протокола, относящихся к передаче контекста. Это протокол передачи контекста (CTP, см. Loughney и другие, "Context Transfer Protocol", Проект документа по Интернету (Internet Draft), октябрь 2003, все Проекты документов по Интернету и Запросы на комментарии (RFC) доступны по ссылке http://www.ietf.org), и Кандидатов маршрутизаторов доступа - Обнаружение (CARD, см. Liebsch и другие, "Candidate Access Router Discovery", Проект документа по Интернету, сентябрь 2003г.). CTP служит в качестве протокола для инициирования передачи контекста и для переноса данных контекста. В связь CTP вовлечены три стороны: мобильный узел (мобильный узел), предыдущий маршрутизатор доступа (pAD, пМД) и следующий маршрутизатор доступа (nAR, сМД). Все три, с использованием различных типов сообщений, могут инициировать смену протоколов. Если мобильный узел предпочитает или должен сменить свою точку доступа к сети, то он передает запрос по меньшей мере в следующий маршрутизатор доступа в случае, если он уже отсоединен от предыдущего маршрутизатора доступа. Если мобильный узел использует некоторого вида предсказание следующего маршрутизатора доступа, возможно, посредством CARD, то он даже непосредственно до соединения со следующим маршрутизатором доступа передает в предыдущий маршрутизатор доступа сообщение о начале передачи контекста в предсказанный следующий маршрутизатор доступа. Оно содержит IP-адрес следующего маршрутизатора доступа, предыдущий IP-адрес мобильного узла на предыдущем маршрутизаторе доступа, список данных контекста, которые должны быть переданы, возможно известный IP-адрес на следующем маршрутизаторе доступа и флажок запроса защищенной и/или надежной передачи контекста. Тогда данные контекста, называемые "характеристическим контекстом", передают в дополнительном сообщении.

Протокол CARD состоит только из двух сообщений, CARD-запроса и CARD-ответа. Как раз они могут использоваться между двумя маршрутизаторами доступа, возможным следующим маршрутизатором доступа (nAR) и текущим маршрутизатором доступа, называемым предыдущим маршрутизатором доступа (pAR), или между мобильным узлом и предыдущим маршрутизатором доступа или следующим маршрутизатором доступа. Между маршрутизаторами доступа CARD способствует получению информации относительно возможностей кандидатов на следующий маршрутизатор доступа, которая требуется для выбора наиболее соответствующего кандидата для передачи контекста и последующей передачи обслуживания мобильным узлом. Между мобильным узлом и предыдущим маршрутизатором доступа выдается CARD-запрос для запрашивания списка кандидатов на следующий маршрутизатор доступа. В этом запросе мобильный узел может передавать идентификаторы канального уровня (Уровня 2) передачи данных для любого следующего маршрутизатора доступа, которые он смог обнаружить посредством некоторого механизма, так что предыдущий маршрутизатор доступа имеет рекомендацию, какой маршрутизатор доступа находится в пределах дальности действия мобильного узла. В проекте документа CARD не определено, каким образом предыдущий маршрутизатор доступа идентифицирует следующий маршрутизатор доступа с использованием идентификатора Уровня 2. В ответе в мобильный узел предыдущий маршрутизатор доступа передает список следующих маршрутизаторов доступа, исходя из соответствия возможностей следующего маршрутизатора доступа, которые могут быть предварительно отфильтрованы с использованием критерия, определенного предыдущим маршрутизатором доступа, для уменьшения количества следующих маршрутизаторов доступа, которые мобильный узел должен обрабатывать как кандидатов.

Передача контекста в беспроводных локальных сетях

(IEEE 802.11f)

В беспроводных локальных сетях радиосвязи (WLAN) между точками доступа (AP, ТД), вовлеченными в передачу обслуживания, осуществляется обмен информацией относительно клиента или станции (STA, СТА), обеспечивая возможность процесса повторного ассоциирования в новой точке доступа. Для ускорения этого процесса повторного ассоциирования используют схему передачи контекста. В передачу контекста вовлечены два функциональных объекта, точка доступа и RADIUS-сервер. Для станции (STA) процесс управления является прозрачным. RADIUS-сервер выполняет задачу отображения доставленных Идентификаторов базового служебного набора (BSSID, ИДБСН) в IP-адреса или Полностью определенные доменные имена (FQDN, ПОИД) точек доступа. Это отображение косвенно показывает, относится ли точка доступа к тому же расширенному служебному набору (ESS, ОСН), что и RADIUS-сервер. При этом также по запросу на точки доступа распространяются ключи шифрования для обеспечения возможности шифрованной связи между двумя точками доступа. Связь включает в себя все данные управления, которые обеспечивают возможность перемещения клиентов между узлами и реализуют ассоциирование клиента только с одной точкой доступа одномоментно. Сообщения управления могут содержать данные контекста. Каждая точка доступа в ESS поддерживает динамическое представление своих соседних точек доступа. Это представление также определяется как Граф соседних узлов.

Важно отметить, что в "Recommended Practice for Multi-Vendor Access Point; Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation" IEEE 802.11f-D3 проекта IEEE, январь 2002 г., в приложении B, в секции B.3.1, утверждается, что не следует ожидать, что передачи контекста между средствами с различными моделями обслуживания будут успешны. Попытки передачи контекста между устройствами сотовой связи и точками доступа IEEE 802.11, согласно механизму передачи контекста IEEE 802.11, будут неуспешны, если только сотовые точки доступа не реализуют набор служб, идентичный точкам доступа 802.11. В заключение, в документе утверждается, что передачи контекста между разнородными технологиями будут неуспешны.

Другие механизмы

Дополнительно к маршрутизатору доступа и мобильному узлу сценария CTP, механизм, описанный в US 2003/0103496 A1, содержит Сервер политики (PS, СП), который обслуживает задачу (отыскания) соседних сетей доступа (AN, СД) и маршрутизаторов доступа, которые обеспечивают возможность передачи контекста (сопоставимо с механизмом CARD). Сети доступа указываются информацией Уровня 2 в принимаемых мобильным узлом сигналах радиомаяка, и PS осуществляет их поиск в локальной базе данных. PS осуществляет связь с соседними Серверами политики, если они обеспечивают возможность обслуживания мобильного узла, и через них предварительно аутентифицирует этот мобильный узел. Один недостаток этого механизма состоит в том, что требуются даже более защищенные соединения (или, в других терминах, Ассоциации Защиты), чем сценарий CTP. Затем он создает контекст из динамической и статической части перед передачей в новую сеть доступа, но он не учитывает никакие характеристики или возможности целевой сети связи.

В US 2003/0092444 A1 описан механизм, в котором при выборе соседних кандидатов учитываются динамические параметры, подобные текущей нагрузке трафика и правам пользователя. Вследствие этого для каждого мобильного узла список кандидатов может быть различен. Непосредственно процесс передачи выполняется между маршрутизаторами доступа сетей доступа.

Механизм для обнаружения соседних маршрутизаторов доступа, используемый для механизма передачи контекста, представлен в US 2003/0087646 A1 и имеет аббревиатуру GAARD. Он позволяет обнаруживать географически соседние сети доступа, даже если они не являются соседними топологически, например, при рассмотрении IP-адресов. В этом документе мобильный узел имеет локальный кэш адресов Уровня 2 (канального уровня передачи данных) и адресов Уровня 3 (сетевого уровня). Когда мобильный узел принимает сигнал радиомаяка с адресом Уровня 2 и предпочитает инициировать передачу контекста в этот узел, он осуществляет поиск соответствующего адреса Уровня 3 в кэше. Если поиск по кэшу является неуспешным, то мобильный узел запрашивает обслуживающий маршрутизатор доступа на поиск соответствующего адреса Уровня 3. Маршрутизатор доступа осуществляет поиск по своему кэшу. Если адрес не найден, то он начинает процесс динамического обнаружения для получения запрошенного адреса Уровня 3. Маршрутизатор доступа возвращает адрес в мобильный узел, который, в свою очередь, использует его для начала передачи контекста или других механизмов передачи обслуживания в идентифицированный маршрутизатор доступа. Функциональные возможности этой системы должны существовать в каждом маршрутизаторе доступа и мобильном узле, которым требуется использовать или поддерживать эту систему. Этот механизм может служить в качестве реализации процесса CARD.

В отличие от общего сценария передачи контекста, где все соседние маршрутизаторы доступа равно являются возможными точками доступа для мобильного узла, последнее допущение не является верным в сценарии сетей, совместно работающих на основе контракта. Соседний маршрутизатор доступа может принадлежать оператору сети, не имеющему соглашения по роумингу с собственным оператором мобильного узла. Так что мобильный узел принимает сигналы радиомаяка чужой сети связи, но процесс аутентификации будет неуспешным, так как Центр Аутентификации в чужой сети не обеспечен возможностью соединяться с опорным сервером AAA (аутентификации, авторизации и учета (ААУ)) мобильного узла или по меньшей мере не будет считать этот неизвестный сервер доверенным. По этим же причинам передача контекста в такую сеть связи также будет неуспешной.

Вариантом интегрирования сетей без прямого соглашения по роумингу с собственным оператором мобильного узла является использование посреднических серверов (прокси-серверов) AAA. Оператор сети доступа считает доверенным посреднический сервер AAA оператора, который сам считает доверенным собственного оператора мобильного узла. Соответственно мобильный узел может быть авторизован даже в этой чужой сети связи.

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

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

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

Так как эти отношения технически представлены некоторым обменом ключами шифрования между равноправными узлами сети для обеспечения возможности шифрованной связи, то большое количество n означает большой объем памяти для наборов данных ключей, в этом примере n-1 наборов данных на маршрутизатор доступа. Также эти отношения должны быть установлены до того, как станет возможной передача контекста между равноправными узлами сети, что требует функции управления. Следовательно, способ для уменьшения количества доверительных отношений должен сэкономить объем памяти и работу по управлению. Уже существующей технологией для защищенной передачи данных являются Ассоциации Защиты (SA) доверительных отношений согласно наименованию IPSec.

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

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

Контекст, принятый мобильным терминалом, может также использоваться для предварительного конфигурирования мобильного терминала на основе контекста, принятого от менеджера передачи контекста. Следовательно, например, при предварительном конфигурировании сетевых интерфейсов не требуется выполнение этого процесса при подсоединении мобильного терминала к новой сети доступа.

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

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

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

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

Информация местоположения, принимаемая менеджером передачи контекста, может приниматься в сообщении персонального поискового вызова, передаваемом мобильным терминалом, по процедуре аутентификации, выполняемой между мобильным терминалом и сервером аутентификации или выполняемой объектом, расположенным в сети доступа, с которой соединяется мобильный терминал. Рассматривая второй возможный вариант, мобильный терминал, который выполняет, например, посредством ассоциированного сервера AAA, процедуру первичной аутентификации для подсоединения к сети доступа, может предоставлять информацию местоположения серверу AAA. Эта информация может быть также доступна для менеджера передачи контекста, так чтобы он мог использовать информацию местоположения из процедуры аутентификации для определения соседних сетей доступа. Дополнительно, менеджер передачи контекста может также инициировать передачу контекста в ответ на процедуру аутентификации мобильного терминала.

Дополнительно информация местоположения может основываться на географическом местоположении, полученном из устройства определения местоположения, например, приемника GPS, или на местоположении, относящемся к сети, определяемом на основе префикса сети и/или сетевого адреса. Рассматривая в виде возможного варианта использование протокола IP, сетевой адрес соответствует IP-адресу, в то время как префиксом сети должна быть маска подсети.

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

Для описания сформированного контекста может использоваться формат данных, основанный на языке разметки. Дополнительно этот формат может также использоваться для описания контекста, передаваемого от менеджера передачи контекста в несколько сетей доступа и в мобильный терминал.

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

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

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

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

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

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

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

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

Перечень фигур чертежей

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

Фиг.1 - упрощенная структура передачи контекста из опорного домена в WLAN через посредника, посещаемого домена, согласно одному варианту осуществления настоящего изобретения.

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

Фиг.3 - процесс формирования контекста согласно варианту осуществления настоящего изобретения.

Фиг.4 - процесс передачи контекста из внешнего сервера AAA с функциями передачи контекста в Сервер аутентификации (AS, СА) или маршрутизатор доступа WLAN согласно варианту осуществления настоящего изобретения.

Фиг.5 - блок-схема процесса передачи контекста согласно варианту осуществления настоящего изобретения.

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

Подробное описание осуществления изобретения

Общее представление архитектуры сети связи, которая управляет передачей контекста для мобильного узла согласно варианту осуществления настоящего изобретения, изображено на фиг.2. Архитектура является распределенной по сети опорного домена мобильного узла, непосредственно мобильному узлу 207 и сети доступа.

Менеджер 200 передачи контекста (CTM, ДПК) может использоваться совместно с сервером 206 AAA опорного домена. Менеджер 200 передачи контекста может передавать соответствующие динамически создаваемые данные контекста в сети доступа, соседние для текущей позиции мобильного узла. Этих соседей обнаруживает функциональный элемент 202 обнаружения соседей, который получил от менеджера 200 передачи контекста текущее местоположение мобильного узла 207 (например, IP-адрес или префикс сети) и возвращает список соседей. Этот список соседей совместно с информацией относительно пользователя мобильного узла 207 может быть предоставлен на средство 201 формирования контекста. Средство 201 формирования контекста может поддерживать базы данных относительно возможностей сетей доступа и мобильных узлов и относительно форматов контекста (см. Базу данных 203 профиля пользователя, Базу данных 204 контекстов сетей доступа, базу данных 205 Возможностей соседей). На основе этой информации может быть сформирован соответствующий контекст для каждой соседней сети доступа, например, с учетом индивидуальных идентификаторов терминала, информации подписки, предпочтений пользователя, возможностей терминала, параметров Качества Обслуживания, информации шифрования и сжатия, определенных атрибутов технологии доступа или определенных атрибутов сети доступа. Затем этот контекст может быть передан упреждающим образом в сети доступа, где он подвергается обработке менеджером 209, 210, 211 контекста (СМ, ДК) сети доступа (AN, СД). С использованием передачи контекста функциональный элемент - менеджер 208 мобильности на мобильном узле 207 также может быть проинформирован относительно соседних сетей 220, 221, 222, включая информацию, которая требуется для выполнения ускоренной передачи обслуживания в них. На основе контекста, принятого от менеджера 200 передачи контекста, мобильный узел 207 может (предварительно) сконфигурировать свои сетевые интерфейсы для следующих точек доступа. Решение о передаче обслуживания может принять непосредственно мобильный узел 207, когда он принимает сигналы радиомаяка соседней сети в границах досягаемости.

Когда мобильный узел 207 осуществляет роуминг в чужой домен, управление передачей контекста может осуществлять менеджер 600 передачи контекста посещаемого оператора (см. фиг.6). Процесс передачи контекста подобен случаю без роуминга, только добавляется передача обслуживания управления от опорного менеджера 200 передачи контекста посещаемому менеджеру 600 передачи контекста.

Далее будет более подробно описан менеджер 200, 600 передачи контекста. Основным представителем обработки контекста может быть менеджер 200, 600 передачи контекста (CTM). Он может управлять функциональными элементами, имеющими доступ к требуемой информации контекста. В архитектуре функциональными элементами для управления могут быть средство 201 формирования контекста, средство 202 обнаружения соседей, менеджер 209, 210, 211, 609, 610, 611 контекста сети доступа (AN) и функциональный элемент - менеджер 208 мобильности. Сначала менеджер 200, 600 передачи контекста может принимать текущее местоположение мобильного узла 207 посредством связи с менеджером 208 мобильности или посредством стандартной процедуры аутентификации, например, при включении мобильного терминала 207 и подключении его к сети доступа.

Затем менеджер 200, 600 передачи контекста может определять все соседние сети 220, 221, 222, 620, 621, 622 доступа для мобильного узла 207 с использованием средства 202, 602 обнаружения соседей. Затем менеджер 200, 600 передачи контекста может сигнализировать функциональному элементу 201, 601 формирования контекста для извлечения информации пользователя, релевантной для контекста, используемого соседними сетями 220, 221, 222, 620, 621, 622 доступа мобильного узла 207. Сигнализация может содержать ID (ИД) пользователя и применяемый ID сети, такой как префикс сети, для соседних сетей 220, 221, 222, 620, 621, 622. Другим параметром, включенным в контекст, может быть дополнительный уникальный статический или временный идентификатор для пользователя, который сеть доступа может использовать позже для автономного или интерактивного выставления счетов за поставляемые услуги. Можно предположить использование в качестве статического или временного идентификатора соответственно IMSI (Международный идентификатор мобильного абонента) в GSM или UMTS или, возможно, псевдоним NAI (Идентификатор доступа к сети, см. Aboba и другие, "Network Access Identifier", RFC 2486, январь 1999г.).

После объединения этой информации в данные контекста менеджер 200, 600 передачи контекста может передавать данные контекста менеджеру 209, 210, 211, 609, 610, 611 контекста сети доступа, и части этой сформированной информации контекста - менеджеру 208 мобильности мобильного клиента 207 (мобильного терминала). Эти части информации могут обеспечивать возможность конфигурирования мобильным узлом 207 сетевых интерфейсов и использования правильного идентификатора при следующих попытках доступа к соседним сетям.

В дополнение к информации отслеживания мобильного узла 207, менеджер 200, 600 передачи контекста может также подтверждать информацию состояния от менеджера 208 мобильности. В информации состояния мобильный узел 207 может сигнализировать о достигаемом Качестве Обслуживания (QoS) в текущей сети или о полном отказе в доступе к другой сети доступа. Это может обеспечивать возможность динамической настройки алгоритма выбора для наиболее соответствующих сетей доступа в списке соседей, способствуя выбору другими мобильными узлами, перемещающимися в той же зоне, соответствующей новой сети доступа. Таким образом, мобильный узел 207 может служить в качестве датчика сети, собирающего информацию относительно состояния сети. Если многие менеджеры мобильности сообщают о неуспешной передаче обслуживания, выполняемой с использованием контекста, в одной сети доступа, менеджер 200, 600 передачи контекста может информировать функциональный элемент управления и функционирования своей сети для дополнительного исследования этой ошибки или может информировать оператора сети доступа.

Дополнительно далее будет более подробно описан функциональный элемент формирования контекста в устройстве 201 формирования контекста. Как изложено выше, основная схема CTP Seamoby имеет ограничения при ее реализации в разнородных сетях или в сетях в различных административных доменах. Это относится к созданию 'контекста'. Контекст может не быть только набором данных, полностью относящихся к пользователю, подобных идентификатору, паролю или ключу шифрования. В частности, он может дополнительно описывать состояние сети, наблюдаемое с точки зрения клиента. Информация относительно состояния сети может содержать, например, права доступа к службам сети, алгоритм шифрования для передаваемых данных, политику маршрутизации для данных пользователя, класс трафика, назначенный для трафика сеанса связи пользователей, или доступные объекты сети (сервер DNS, шлюз, заданный по умолчанию, и т.д.). В одном административном домене эти данные могут поддерживаться статическими по всей сети, если это требуется оператору. При пересечении границы в другие домены эти данные могут изменяться или, так сказать, могут стать динамическими. Для предотвращения этого может требоваться очень тесная связь между операторами, если это вообще возможно. Следовательно, предложенный настоящим изобретением подход сделать передачу контекста адаптивной в отношении этой динамичности является предпочтительным и решает проблемы, изложенные выше.

На фиг.3 изображен процесс формирования контекста согласно варианту осуществления настоящего изобретения. Процесс создания контекста может быть разделен на четыре части, два объекта исходных данных, один функциональный элемент обработки и один объект результирующих данных. Два объекта статических данных представляют параметры 301 пользователя (включая возможности и параметры терминала) и возможности и параметры 302 сети. На основе двух указанных наборов параметров функциональный элемент 303 обработки может получать объект результирующих данных, то есть динамический контекст 304. Так как параметры, относящиеся к сети, также зависят от технологии доступа, используемой в соответствующей сети доступа, контексты для сетей доступа, имеющих различные технологии доступа, могут варьироваться. В виде возможного варианта предлагается несколько алгоритмов внутри функционального элемента обработки, которые создают дескрипторы идентификатора пользователя, флаги или ключи шифрования для сеанса связи. Объект данных для параметров пользователя может содержать дескриптор идентификатора пользователя, включая временные идентификаторы, предпочтения пользователя, подобные требованиям на QoS или допускаемым видам сеанса (например, видео, речевые), ключи шифрования или начальные числа и установленные шифры и возможности терминала, подобные разрешению экрана, мощности обработки, звуковым/видеокодекам и доступным приложениям, сетевым интерфейсам и т.д.

В объект данных могут быть включены не только данные, релевантные контексту. Это является доводом в пользу использования общей памяти (для хранения) данных пользователя, в конечном счете существующей для других целей (например, общий профиль пользователя GUP 3GPP). Объект данных для параметров сети может содержать информацию относительно определенной сети доступа, в которую может быть впоследствии передан результирующий контекст.

Учитывая параметры, специфические для конкретного пользователя и/или терминала, а также параметры, зависящие от соответствующей технологии доступа следующей сети доступа, можно создать динамический контекст, который может предотвращать неуспешную передачу контекста в случае доступа мобильного терминала 207 к новой сети. Это могут быть данные, подобные поддерживаемым криптографическим алгоритмам или SSID (идентификатору служебного набора) WLAN, включенные в сигналы радиомаяка сети, которые способствуют идентификации мобильным узлом 207 WLAN для выбора. Вновь в объект (304) данных (контекст) могут быть включены не только данные, релевантные контексту, но также наборы данных, относящиеся к другим приложениям, которые используют объект. В основном, для описания данных контекста, например, используемых для GUP или для Комбинированных возможностей/Профиля предпочтений (CC/PP), может использоваться язык, производный от XML. Могут быть применены W3C-языки XPATH и XQuery для поиска данных и отбора внутри документа XML и язык XSL. XSL может использоваться для преобразования документов XML и последующей их обработки в произвольные выходные форматы. Дополнительно для описания информации контекста может быть применен язык разметки, чтобы простым и безопасным способом расширить описание данных, при этом сохраняя совместимость с прежними описаниями. По мере того как формирование контекста по требованию может решать проблему передачи контекста в несвязные сети, дополнительно оно может обеспечивать возможность поддерживания некоторых или всех параметров пользователя динамическими. Пользователь может изменять свои предпочтения пользователя, предстоящая следующая передача контекста в сети связи может быть немедленно настроена в соответствии с новыми предпочтениями (более высокое QoS сеанса связи, новый режим шифрования и т.д.).

Менеджер 208 мобильности в мобильном терминале 207, кроме прочего, может управлять сетевыми интерфейсами и может отслеживать перемещение мобильного узла 207. Следовательно, его наилучшим местоположением может быть мобильный узел 207. В виде варианта, сеть доступа также может отслеживать местоположение мобильного узла на основе перемещения терминала при смене одной точки доступа на другую. В случае менеджера 208 мобильности, размещенного в мобильном узле 207, информация состояния может быть включена в сообщения персонального поискового вызова, передаваемые от мобильного клиента 207 менеджеру 200 передачи контекста. Менеджер 208 мобильности может сигнализировать о перемещении и позиции мобильного узла 207 менеджеру 200 передачи контекста. Следовательно, он может использовать информацию, собранную посредством встроенного устройства определения позиции, такого как приемник GPS (Глобальной системы местоопределения) или, например, посредством оценки принятых сигналов радиомаяка сети или принятых Извещений Маршрутизатора.

Местоположение может быть представлено местоположением географическим или виртуальным, то есть относящимся к сети. Для описания местоположения мобильного терминала 207s может поддерживаться несколько форматов для обеспечения возможности реализации в мобильном узле 207 различных способов и для получения различной информации из несходных представлений местоположения. Это мотивировано тем фактом, что единственный способ не удовлетворяет всем потребностям. Например, GPS может обеспечивать высокоточную информацию местоположения относительно местоположения терминала, но для нее требуется прямая линия видения на спутники GPS для вычисления местоположения. В частности, иногда в городах, где высокая линия горизонта, этого достичь невозможно. В виде другого возможного варианта местоположение, относящееся к сети (например, сетевой адрес и префикс сети) мобильного узла 207, может способствовать сбору информации относительно сети, к которой подсоединен мобильный узел 207 (например, для получения адреса сервера доступа). Но единственный сетевой адрес мобильного узла 207 не будет подобен адресу географически смежной сети. Следовательно, может быть использован дополнительный механизм для вычисления соседей для заданного сетевого адреса (например, Граф Соседних узлов).

Часть управления сетью связи в менеджере 208 мобильности может быть обеспечена возможностью предварительного конфигурирования сетевого интерфейса(ов) мобильного узла 207 с использованием информации, принятой внутри контекста от менеджера 200 передачи контекста. Часть управления сетью связи может содержать внутри локального кэша различные предварительно установленные конфигурации для любой из соседних сетей доступа, о которых передан сигнал, и может вводить соответствующую конфигурацию, когда обнаруживает ситуацию передачи обслуживания. Передача обслуживания может быть начата активно менеджером 208 мобильности, если он определяет необходимость переключения, например, приложение может требовать большей полосы пропускания, или текущее соединение может испытывать замирание.

Дополнительно менеджер 208 мобильности может решать задачу передачи менеджеру 200 передачи контекста изменения в предпочтениях пользователя относительно сетевого соединения или требований на QoS. Эти предпочтения влияют на выбор соответствующих соседей сети и на процесс формирования контекста.

Менеджер 209, 210, 211, 609, 610, 611 контекста сети доступа (менеджер контекста AN) может обрабатывать принятые данные контекста. В этом процессе объекты управления доступом, то есть Серверы 212, 213, 214, 612, 613, 614 доступа в сетях 220, 221, 222, 620, 621, 622 доступа (см. фиг.2 и фиг.6), могут быть сконфигурированы для возможного перемещения мобильного узла 207. Процесс конфигурирования может быть прозрачным для внешней сети и для объекта передачи контекста, который передал контекст. Единственным требованием может быть использование определенного шаблона, описывающего формат контекста, который может заполнять устройство 201, 601 формирования контекста в менеджере 200, 600 передачи контекста и который может быть распознан и обработан менеджером 209, 210, 211, 609, 610, 611 контекста сети доступа. Может быть включена внутренняя информация относительно сети, так как обе стороны имеют доверительные отношения в отношении защиты от злоупотребления данными передачи контекста. Внутреннее конфигурирование сети доступа менеджером 209, 210, 211, 609, 610, 611 контекста сети доступа может включать в себя механизм передачи широкого контекста сети доступа для обеспечения возможности ускорения внутридоменных передач обслуживания.

Средство 202, 602 обнаружения соседей может отыскивать соседние сети доступа мобильного узла 207. Средство 202, 602 обнаружения соседей может заранее получать местоположение мобильного узла от менеджера 200, 600 передачи контекста. С использованием информации местоположения оно может осуществлять поиск представления сети, которое хранит отношения соседства (см. базы данных 203, 204, 205 на фиг.2 или базы данных 603, 604, 605 на фиг.6). Представление может быть динамическим или статическим.

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

В сценарии взаимодействия 3G-WLAN существует централизованная структура AAA с серверами Diameter. Эта структура также имеет Ассоциации Защиты (SA), которые могут использоваться многократно для защиты передачи контекста, здесь между посещаемой наземной сетью мобильной связи общего пользования (VPLMN), опорной наземной сетью мобильной связи общего пользования (HPLMN) и сетями доступа WLAN. Настоящее изобретение может обеспечивать цепные доверительные отношения между опорным и посещаемым менеджером передачи контекста, так чтобы могла быть возможной успешная передача контекста в чужую сеть. Следовательно, техническое решение передачи контекста для этого сценария может реализовывать функциональные возможности посредника для передачи контекста, строя систему для иерархической передачи контекста. Фиг.1 изображает упрощенную структуру передачи контекста из опорного домена (например. HPLMN) через посредника, посещаемого домена (например VPLMN), в WLAN, где обрабатывается и вводится контекст.

Следовательно, может быть изменен сценарий передачи контекста “из маршрутизатора доступа в маршрутизатор доступа", то есть передачи контекста из предыдущего маршрутизатора доступа (pAR) в следующий маршрутизатор доступа (nAR).

Тремя задействуемыми объектами согласно настоящему изобретению теперь могут быть мобильный узел 207, следующий маршрутизатор доступа и сервер 206 AAA. Мобильный узел 207 может передавать в сервер 206 AAA запрос на передачу контекста. При этом сервер 206 AAA может передавать контекст мобильного узла 207 в следующий маршрутизатор доступа. Это может предполагать доверительные отношения между следующим маршрутизатором доступа и сервером 206 AAA, которые уже существуют, если оператор AR WLAN имеет соглашение по роумингу с оператором сервера 206 AAA. Количество партнеров по роумингу задано равным m, что приводит к m ассоциациям защиты на каждого из n маршрутизаторов доступа, n∙m ассоциациям защиты в целом.

Это количество, по существу, должно быть меньшим, чем в сценарии передачи контекста “от маршрутизатора доступа в маршрутизатор доступа". Другое преимущество состоит в том, что в маршрутизаторах доступа больше могут не требоваться функциональные возможности, подобные CARD, так как сервер 206 AAA осуществляет обнаружение соседей. В маршрутизаторах доступа может существовать только агент передачи контекста. В основном, функциональные возможности обнаружения соседей могут быть невидимы для сети и, следовательно, вариант их реализации может зависеть от поставщика. С использованием сервера 206 AAA, имитирующим предыдущий маршрутизатор доступа, даже проблема несовместимости данных контекста между двумя маршрутизаторами доступа, ожидаемая по меньшей мере при вертикальной передаче обслуживания между различными административными доменами, может быть решена более эффективно.

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

Опорный менеджер 200 передачи контекста может не оказывать непосредственное содействие мобильному узлу 207, который осуществляет роуминг в чужом или посещаемом домене (например, VPLMN), так как менеджер 600 передачи контекста может не иметь или иметь недостаточную информацию относительно сетей 621, 622 доступа чужого домена. Опорный менеджер 200 передачи контекста, то есть менеджер 200 передачи контекста в опорном домене мобильного клиента 207, может не иметь возможности формировать данные контекста для сетей доступа. Следовательно, мобильному узлу 207 может содействовать менеджер 600 передачи контекста чужого домена, то есть посещаемый менеджер 600 передачи контекста (VCTM). Чтобы обеспечить возможность содействия от VCTM 600, опорный менеджер 200 передачи контекста (HCTM) может доставлять в VCTM 600 необходимые части профиля мобильного узла или пользователя.

Фиг.6 изображает архитектуру сети для опорного и посещаемого домена, управляющей отдельными сетями доступа. Менеджер 600 передачи контекста в посещаемом домене (VPLMN) может обладать возможностью настраивать принятые данные для целевой точки доступа или сети доступа. Подобно менеджеру 200 передачи контекста опорного оператора, VCTM 600 может поддерживать базы данных 603, 604, 605 относительно сетей 621, 622 доступа, которые имеют Соглашения по уровню обслуживания (SLA) с их собственным оператором, относительно их возможностей и требуемого для них формата контекста. Дополнительно посещаемый менеджер 600 передачи контекста также может извлекать информацию из сервера 606 AAA. Отличие обслуживания мобильного узла 207 и менеджера 208 мобильности менеджером 600 передачи контекста в VPLMN (VCTM) может состоять в непостоянном хранении профиля пользователя для мобильного узла 207, осуществляющего роуминг.

Заменой для этого профиля может служить то, что передается между менеджерами передачи контекста. Может быть полезно для сигнализации использовать Общий профиль пользователя (GUP, ОПП) или производную от CC/PP. Однако переданные данные могут быть неточной копией исходного профиля пользователя, размещенного в базе данных опорного менеджера 200 передачи контекста. По меньшей мере, идентификатор пользователя может быть заменен на временный псевдоним, который обеспечивает возможность идентификации сеанса пользователя и учета поставляемых услуг для псевдонима, но не обеспечивает возможности сбора информации относительно привычек пользователя или схемы перемещения по нескольким сеансам связи. Дополнительно из временного профиля, передаваемого опорным менеджером 200 передачи контекста в посещаемый менеджер 600 передачи контекста, могут быть удалены все данные, которые не влияют на процесс формирования контекста.

Передача временного профиля пользователя может быть защищена с использованием шифрования. Процесс шифрования может поддерживать конфиденциальность, а также защиту целостности. Только конфиденциальность все еще может допустить вставку злоумышленником фиктивных данных в профиль пользователя, что может служить как атака типа Отказа в Обслуживании (DoS). Защищенное соединение может быть установлено непосредственно с использованием Ассоциации Защиты, которая существует между двумя операторами. Конкретный прикладной протокол для данных может не требоваться.

Рекомендуемым режимом для передачи контекста может быть упреждающий режим, так как он менее критичен по времени. Однако также можно использовать ответный режим. В этом случае мобильный узел 207 запрашивает передачу контекста после начала процесса передачи обслуживания. Менеджер 200, 600 передачи контекста может принять запрос через новую сеть 221, 621 доступа и может возвратить контекст мобильного узла 207 менеджеру контекста 209, 210, 211, 609, 610, 611 сети доступа. Менеджер 200, 600 передачи контекста может обеспечивать возможность поддержки короткого времени ответа, отслеживая перемещение мобильного узла 207 и предварительно обрабатывая и кэшируя контекст для соседей.

Ниже, согласно фиг.4, будет приведен возможный вариант процесса передачи контекста из внешнего сервера AAA с функциональными элементами передачи контекста (CTM, устройство 201 формирования контекста и т.д.) в Сервер аутентификации (AS) или маршрутизатор доступа WLAN.

Для этого возможного варианта могут быть сделаны следующие предположения: Мобильному узлу разрешено использовать WLAN в соответствии с соглашением между оператором 3GPP и WLAN. Собственный оператор мобильного узла имеет достаточную информацию относительно возможностей WLAN, которая хранится в базе данных, и имеет техническую возможность получать требуемые криптографические данные. Мобильный узел находится в состоянии соединения с сетью доступа и еще не начинает передачу обслуживания в новую сеть доступа. Дополнительно Сервер аутентификации (AAA) в WLAN обеспечен возможностью передавать в точки доступа сообщение IAPP.CACHE-NOTIFY, запрашивая AP на вставку входа контекста для мобильного узла в ее кэш, сообщение, которым обычно обмениваются в сети точки доступа, согласно IEEE 802.11f-D5 "Recommended Practice for Multi-Vendor Access Point; Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", проект документа IEEE, январь 2003г.

Сервер AAA может передавать 401 соответствующий контекст в Серверы аутентификации сетей WLAN, которые были обнаружены в качестве соседей в процессе Выбора Соседей. Затем сервер AAA через текущую линию связи может информировать 402 UE (то есть менеджер мобильности в мобильном терминале) относительно своих контекстных параметров (например, Попарном Главном Ключе, идентификаторах SSID сетей WLAN и т.д.) для следующих возможных подсоединений к другим сетям доступа. Контекстные параметры могут использоваться также для характеристических контекстов внутри-WLAN. Также могут быть включены другие независимые поля контекста.

Каждый соседний Сервер аутентификации, который принял контекст с достоверными данными, может инициировать сообщение 403 IAPP.CACHE-NOTIFY во все релевантные точки доступа, содержащие принятый контекст. Каждая точка доступа WLAN может иметь приложение, которое считывает контекст, доставленный в сообщении IAPP.CACHE-NOTIFY, и вставляет контекст, которым в этом случае может быть Ассоциация Защиты (SA) Попарного Главного Ключа (PMK, ПГК), в таблицу PMK SA. Для точки доступа это представляется так, как будто мобильный узел прошел процесс установления ключа, который обычно должен выполняться при доступе нового клиента к сети доступа.

Когда мобильный узел или клиент ассоциируется 404 с точкой доступа, для которой он принял данные контекста через прежнее соединение, он может передать непосредственно PMKID внутри Элемента информации Сети с надежной защитой (RSN, СНЗ), в котором перечислены шифры ключей, алгоритмы управления ключами и аутентификации, поддерживаемые STA (см. раздел 7.3.2.9 в IEEE 802. 11i-D5 "Medium Access Control (MAC) Security Enhancements", проект документа IEEE, август 2003 г.), запроса на ассоциацию.

Затем точка доступа может идентифицировать PMK, на который ссылается PMKID, и начинает непосредственно 4-проходное установление связи (квитирование) 405 с клиентом, обходя начальный процесс EAPOL. При этом сохраняется и квитирование аутентификации между точкой доступа, и сервером доступа и квитирование аутентификации между сервером доступа WLAN и сервером AAA.

При 4-проходном квитировании между клиентом и точкой доступа формируются новые временные Попарные и Групповые ключи (PTK и GTK) для защиты последующих однонаправленных и многоабонентских передач данных пользователя. Если клиент дополнительно осуществляет роуминг 406 внутри расширенного служебного набора (ESS), то передача контекста, происходящая в WLAN, может быть выполнена внутренними механизмами без взаимодействия с удаленным сервером AAA.

Для серверов AAA сети VPLMN и сети HPLMN процесс передачи контекста между сервером AAA и Сервером аутентификации в WLAN идентичен. Он может быть выполнен посредством передачи обслуживания управления передачей контекста между менеджерами передачи контекста в опорном и посещаемом домене. Сервер аутентификации WLAN не может различить исходный контекст и контекст после обработки из посреднического менеджера передачи контекста. Он может проводить различия только между данными контекста из доверенных или недоверенных источников.

Существует возможность, что перечисленный процесс будет неуспешным из-за истечения лимита по времени ожидания Ассоциации Защиты в кэше ассоциации защиты PMK точки доступа или полностью неуспешной передачи контекста в WLAN. В этом случае 4-проходное квитирование является неуспешным, и начинается обычная процедура аутентификации с использованием, например, квитирования Наращиваемого протокола аутентификации (EAP). Для этого квитирования может использоваться механизм EAP, который допускает взаимную аутентификацию. В приведенном возможном варианте взаимная аутентификация может быть обеспечена с использованием механизмов, таких как описаны в проектах документов IETF EAP-SIM и EAP-AKA (см. Haverinen и другие, "EAP SIM Authentication", IETF Проект документа по Интернету, октябрь 2003 г., и Arkko и другие, "EAP AKA Authentication", IETF Проект документа Интернет, октябрь 2003 г.). В них для идентификации пользователя и формирования ключа используют криптографические функции в картах SIM (Модуля Идентификации Абонента) или USIM (UMTS SIM).

Более подробно формирование данных ассоциации защиты PMK будет пояснено в следующих разделах. В стандартном механизме для создания PMKID используется хэш-функция (HMAC-SHA1-128). Хэш-функция является необратимой функцией, так что она не может непосредственно использоваться для восстановления исходной информации для хэш-алгоритма. Хэш-функция позволяет только осуществлять проверку в отношении того, имела ли хэш-функция с неизвестными входными параметрами тот же результат, что и опорная хэш-функция с известными входными параметрами. Если результаты идентичны, то и входные параметры должны быть также идентичны. Для формирования PMKID в качестве входных значений для хэш-функции можно взять значения PMK, Имени PMK, BSSID (идентификатора базового служебного набора) и адреса MAC клиента. Эти значения доступны для точки доступа, когда к ней подключается клиент. Так что точка доступа может создать полный вход ассоциации защиты PMK. В нашем возможном варианте этот вход не может быть создан локальной точкой доступа, но вход может быть создан менеджером 200 передачи контекста. Менеджер 200 передачи контекста может иметь информацию относительно SSID сети WLAN посредством своей базы данных возможностей сетей доступа, но он не имеет никакой информации относительно точек доступа, в частности, их идентификаторов BSSID, в сети доступа, в которой клиент осуществляет роуминг. Это подразумевает, что менеджер 200 передачи контекста 200 не может использовать BSSID при вычислении PMKID с использованием алгоритма HMAC-SHA1.

Одно решение может состоять в задержке вычисления PMKID и соответственно передачи контекста в сеть доступа до тех пор, пока клиент не услышал BSSID и SSID через сообщения сигнала радиомаяка, и до того, как он уже переключился на эту сеть доступа. Затем менеджер 208 мобильности может передать обнаруженный BSSID и SSID обратно в менеджер 200 передачи контекста, который посредством SSID определяет сеть доступа.

Согласно другому варианту осуществления настоящих изобретений менеджер 200 передачи контекста может вычислять PMKID и осуществлять передачу контекста в менеджер 200 передачи контекста сети доступа и посредством его в точку доступа с обнаруженным BSSID. Существует вероятность, что контекст не достигнет точки доступа, что должно привести вновь к ответной передаче контекста. Для каждой точки доступа в сети доступа может передаваться одно сообщение с контекстом. Это может требовать от менеджера 200 передачи контекста наличия полной информации относительно инфраструктуры WLAN, что ожидать невозможно.

Другое решение проблемы формирования ассоциации защиты PMK может состоять в делегировании обработки PMKID менеджеру 209, 210, 211 контекста в WLAN. Менеджер 209, 210, 211 контекста может передавать вычисленный PMKID в точку доступа совместно с дополнительным контекстом клиентов, принятым от менеджера 200 передачи контекста. Возможно, непосредственно клиент вычислил тот же PMKID с использованием информации относительно сети доступа, принятой через менеджер 208 мобильности от менеджера 200 передачи контекста, и BSSID, обнаруженного в сигналах радиомаяка WLAN. В этом техническом решении вычисления PMKID загружаются из менеджера 200 передачи контекста и распространяются на менеджеры 209, 210, 211 контекста WLAN и мобильный клиент 207, что может приводить только к проблеме производительности. Клиент в любом случае должен быть выполнен с возможностью осуществления вычисления, в случае, если передача контекста является неуспешной.

Для WLAN PMKID служит только в качестве уникального и непредсказуемого идентификатора для выбора из кэша Ассоциации Защиты PMK. Достоверность непосредственно Ассоциации Защиты может быть проверена внутри 4-проходного квитирования (см. фиг.4) способом вызова/ответа с использованием PMK, обмен которым никогда не осуществляется между равноправными узлами сети. Соответственно правильное предположение клиента-злоумышленника относительно PMKID все еще не компрометирует Попарный Главный Ключ. Это может позволить упростить нашу проблему в невозможности вычислить правильный PMKID. Менеджер 200 передачи контекста может в качестве PMKID формировать случайное 128-битовое число без использования хэш-функции. Указанное упрощение может подразумевать два результата: во-первых, PMKID может распространяться от менеджера 200 передачи контекста через менеджер 209, 210, 211 контекста WLAN в точку доступа, во-вторых, может существовать вероятность наложения между PMKID, сформированным случайным образом, и входами в локальном кэше ассоциации защиты PMK точки доступа. Следующие разделы обеспечивают оценку вероятности наложения.

Можно предположить, что алгоритм HMAC-SHA1 создает равномерно распределенные случайные значения. PMKID имеет 128 битов, что приводит к 3,4·10³⁸ возможным значениям и дает вероятность вывода точного значения, равную P(x)=2,9·10^-39. Для рассматриваемого случая это означает, что PMKID, вычисленный случайным образом, соответствует входу PMKID в кэше, содержащем один вход, с указанной вероятностью P(наложения) = P(x)=2,9·10^-39. Если принимается размер кэша в n входов PMKID, то вероятность наложения достигает P(наложения) = n P(x)=n·2,9·10^-39. Для 1000 входов кэша это приводит к вероятности P(наложения) = 2.9·10^-36, что остается очень малой вероятностью.

Преимуществом является то, что менеджер 200 передачи контекста может распространять PMKID заранее и может не требоваться вычисление идентификатора PMKID ни непосредственно клиентом, ни непосредственно менеджером 209, 210, 211 контекста WLAN, что экономит время обработки и мощность и, возможно, укорачивает время до того, как может быть готов запрос на ассоциацию от клиента для передачи в точку доступа. Для менеджера 209, 210, 211 контекста WLAN это может подразумевать передачу одного набора данных контекста во все требуемые точки доступа, а не вычисление определенного контекста для любой точки доступа.

Далее, согласно блок-схеме, изображенной на фиг.5, будет в общих чертах обрисован механизм передачи контекста, предложенный в настоящем изобретении, согласно другому варианту осуществления. Менеджер 200 передачи контекста может принимать 501 информацию местоположения, которая должна быть оценена из мобильного узла 207 или доступна менеджеру 200 передачи контекста посредством AAA. После приема информации местоположения из источника доставки менеджер 200 передачи контекста может передавать информацию на функциональный элемент или в средство, определяющие 502 на основе позиции мобильного узла соседнюю сеть доступа, к которой мобильный узел 207 может подсоединиться в случае передачи обслуживания. Эта функция может быть реализована, например, устройством 202 обнаружения соседей, как изображено на фиг.2 и фиг.6.

Соседние сети доступа, к которым может подсоединиться мобильный узел 207, идентифицированы, например, идентификатором, таким как обрисован ранее. Дополнительно идентификатор мобильного узла также может быть включен в информацию, доставляемую на следующий этап обработки. На основе идентификации, основывающейся на идентификаторе ID, соседних сетей и мобильного узла 207, менеджер 200 передачи контекста может затем использовать средство или функциональный элемент формирования контекста для динамического формирования 503 соответствующего контекста для соседних сетей доступа и мобильного узла 207. Важно отметить, что в зависимости от технологий доступа соседних сетей контексты, сформированные менеджером 200 передачи контекста, могут отличаться своими параметрами. Мобильный узел 207 также может принять контекст, который специально приспособлен для информации, требуемой для передачи обслуживания, как обрисовано ранее.

После формирования различных контекстов для соседних сетей и мобильного узла 207 менеджер 200 передачи контекста может передать 504 все контексты в соответствующие сети доступа и мобильный узел 207.

При приеме 505 контекста в мобильном узле 207 и для возможных целей при предположении, что еще не была выполнена передача обслуживания в следующую сеть доступа, мобильный узел 207 может предварительно сконфигурировать 506 свои сетевые устройства на основе информации, содержащейся в контексте, принятом от менеджера 200 передачи контекста. Например, в случае использования интерфейса WLAN в сети IPv6 мобильный терминал 207 может создать предварительно сконфигурированный сетевой интерфейс с новым IP-адресом, новым шлюзом, заданным по умолчанию, и т.д., так чтобы после определения 507 сети доступа для следующего подсоединения и после передачи ей обслуживания могли быть взяты установочные параметры предварительной конфигурации, и передача данных в новую сеть доступа могла быть начата 508 немедленно с использованием новой конфигурации сетевого интерфейса.

Сеть доступа, принимая 509 контекст от менеджера 200 передачи контекста, может также использовать находящуюся в нем информацию для подготовки 510 сети доступа для возможного подключения мобильного клиента 207. Для обеспечения возможности ассоциирования определенной конфигурации для подключающегося мобильного клиента 207 идентификатор может быть включен в контекст, переданный в менеджер 209, 210, 211 контекста в соседней сети доступа, обеспечивая возможность идентификации им мобильного узла 207 после его подключения к сети и использования информации контекста для связи 511.

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

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

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

4. Способ по п.3, в котором статический или временный идентификатор используется средством управления контекстом в новой сети доступа для ассоциирования мобильного терминала с его контекстом, принятым от средства управления передачей контекста.

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

6. Способ по п.1, дополнительно включающий в себя этап, на котором выполняют предварительное конфигурирование мобильного терминала на основе контекста, принятого от средства управления передачей контекста.

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

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

9. Способ по п.1, дополнительно включающий в себя этап, на котором сохраняют информацию относительно неуспешных попыток доступа к сетям доступа, о которых информировал мобильный терминал, в средстве управления передачей контекста.

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

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

12. Способ по п.1, в котором информация местоположения, принимаемая средством управления передачей контекста, принимается в сообщении персонального поискового вызова, передаваемом мобильным терминалом, или посредством сообщения сигнализации от сервера аутентификации в опорном домене средства управления передачей контекста после процедуры аутентификации, выполняемой между мобильным терминалом и сервером аутентификации.

13. Способ по п.1, в котором информация местоположения основана на географическом местоположении, полученном из устройства определения местоположения, или местоположении, относящемся к сети, определяемом на основе префикса сети и/или сетевого адреса.

14. Способ по п.2, в котором передачу обслуживания выполняют после приема информации контекста, относящейся к новой сети доступа, от средства управления передачей контекста.

15. Способ по п.1, в котором для описания контекста, передаваемого от средства управления передачей контекста в упомянутое множество сетей доступа и мобильный терминал, используют формат данных, основанный на языке разметки.

16. Способ по п.1, дополнительно включающий в себя этап приема сервером аутентификации в соседней сети доступа контекста от средства управления передачей контекста, выполнения соседней сетью доступа процедуры регистрации и/или аутентификации мобильного терминала с использованием принятой информации контекста.

17. Способ по п.16, в котором процедура регистрации и/или аутентификации включает в себя регистрацию секретного ключа мобильного терминала.

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

19. Способ по п.1, в котором средство управления передачей контекста постоянно находится в посещаемой сети связи.

20. Способ по п.19, дополнительно включающий в себя этап, на котором передают данные, релевантные для формирования, по меньшей мере, одного контекста, средством управления передачей контекста в опорной сети связи мобильного терминала в средство управления передачей контекста посещаемой сети связи.

21. Способ по п.1, дополнительно включающий в себя этап, на котором принимают контекст в средстве управления контекстом в сети доступа от средства управления передачей контекста, причем средство управления контекстом не поддерживает соединение с другим средством управления контекстом в другой сети доступа.

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

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

24. Мобильный терминал по п.23, который выполнен с возможностью предварительного конфигурирования интерфейса со второй сетью доступа посредством конфигурирования, по меньшей мере, одного из идентификатора терминала, криптографического ключа, криптографического алгоритма, идентификатора служебного набора (SSID) беспроводной локальной сети (WLAN), нового IP-адреса и нового шлюза, используемого по умолчанию, согласно информации, содержащейся в упомянутом контексте.

25. Мобильный терминал по п.23, в котором передатчик выполнен с возможностью передачи информации местоположения средству управления передачей контекста в сообщении персонального поискового вызова.

26. Мобильный терминал по п.23, дополнительно содержащий средство хранения для хранения информации о неуспешных попытках доступа к сетям доступа.

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