Средства и способы для улучшения характеристик хэндовера интегрированных сетей радиодоступа

Изобретение относится к системам связи. Технический результат заключается в повышении эффективности хэндовера в сетях с множеством технологий радиодоступа (RAT). Указанный способ реализуется контроллером радиосети (RNC1), установленным в указанной сети, при этом способ содержит следующие этапы, на которых принимают сообщение "Кандидат для хэндовера", содержащее информационный элемент о типе идентификатора, идентифицирующем указанное сообщение как являющееся сообщением "Кандидат для хэндовера", причем сообщение идентифицирует указанный сеанс, при этом сообщение дополнительно идентифицирует RNC-кандидата указанной сети, причем указанный RNC-кандидат является RNC-кандидатом для хэндовера указанного сеанса, устанавливают идентичность указанного RNC путем рассмотрения указанного сообщения, ассоциируют указанный сеанс связи с указанным RNC-кандидатом, идентифицированным на предыдущем этапе. 6 н. и 32 з.п. ф-лы, 18 ил., 8 табл.

 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

На фиг.1 показана основная архитектура сотовой радиосети в виде обычного UTRAN, соединенного с Интернетом 180, и обычного WLAN. UTRAN содержит узел-B 150 базовой станции, соединенный с контроллером 130 радиосети RNC. UTRAN соединен с Интернетом 180 через SGSN (узел поддержки обслуживания GPRS) 120 и GGSN (шлюзовой узел поддержки GPRS) 110 обычным способом. WLAN на фиг.1 представляет собой обычный WLAN, выполненный согласно IEEE 802-стандарту, и обычно содержит по меньшей мере одну точку 165 радиодоступа, AP, которая, как правило, соединена с контроллером 162 точки доступа, APC. APC WLAN далее называется М-L2S (коммутатор уровня 2 с возможностью многоадресной рассылки). Поскольку Ethernet-протокол (IEEE 802.3) используется для большинства протоколов WLAN 2 уровня для связи с фиксированной сетевой инфраструктурой, М-L2S идентичен коммутатору Ethernet. UT 140 (пользовательский терминал) двойного назначения, выполненный с возможностью работы как в UTRAN, так и в WLAN, может установить UTRAN радиосоединение с узлом-B 150 базовой станции через свой первый порт 141 передачи данных и WLAN радиосоединение с AP 165 WLAN через свой второй порт 142 передачи данных. UTRAN и WLAN взаимодействуют между собой обычным способом через SGSN 120 или, как показано на фиг.1, через GGSN 110. Как правило, WLAN, то есть APC 162, может быть соединен непосредственно с GGSN 110, как показано на фиг.1, или может быть соединен через AR (маршрутизатор доступа) и/или IP-сеть (на фиг.1 не показано).

Сеанс связи может быть установлен между UT 140 и поддерживающей связь стороной, такой как хост/сервер или одноранговый узел, соединенный с Интернетом 180. Сеанс связи может быть реализован, например, обычным способом посредством сеанса с PDP-контекстом (протоколом пакетной передачи данных) между UT 140 и GGSN 110 по пути UTRAN, согласно стандарту 3GPP, для услуг пакетной радиосвязи.

В случае хэндовера сеанса с PDP-контекстом из пути маршрутизации UTRAN в направлении пути маршрутизации WLAN необходим большой объем сигнализации, и предполагаются значительные задержки, поскольку пользовательские данные, то есть PDP пакеты, передаваемые по нисходящей линии связи, которые были посланы и кэшированы в соответствующем узле UTRAN, то есть RNC 130, но еще не переданы пользовательскому терминалу UT 140, должны быть отправлены назад через базовую сеть, то есть назад в GGSN 110 и далее в UT 140 через APC 162 и AP 165.

Другая проблема заключается в том, что у сотовой сети радиодоступа, то есть RNC 130, в архитектуре сети, показанной на фиг.1, отсутствует какой-либо доступ к RRM-WLAN (управлению радиоресурсами)-информации, а у WLAN отсутствует какой-либо доступ к информации RRM сотовой радиосети, препятствуя эффективному управлению множеством радиоресурсов полной интегрированной UTRAN-WLAN-сети, что, в свою очередь, уменьшает емкость всей интегрированной UTRAN-WLAN-сети.

Более конкретно, относительно WLAN по фиг.1, в случае, когда WLAN требует аутентификации UT 140 перед установлением сеанса передачи данных по пути WLAN, установление защищенной ассоциации между UT 140 и AP 165, например, с использованием обычной стандартной EAP (расширяемый протокол аутентификации) аутентификации согласно спецификации безопасности IEEE 802.1Ii может затронуть критическую проблему относительно возникающего временного интервала прерывания, то есть это может привести к задержке/потере пакетов, недопустимой для приложений, работающих в реальном масштабе времени, таких как голос и/или видео, в случае хэндовера сеанса связи/передачи данных, например, из UTRAN в WLAN по фиг.1.

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

Настоящее изобретение направлено на облегчение/решение вышеупомянутых проблем.

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

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

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

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

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

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

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

- устанавливают идентичность указанного RNC путем рассмотрения указанного сообщения,

- ассоциируют указанный сеанс связи с указанным RNC-кандидатом, идентифицированным на предыдущем этапе.

В одном из вариантов осуществления указанное сообщение "Кандидат для хэндовера" содержит:

- идентификатор пользовательского терминала UT ID, идентифицирующий указанный UT,

- идентификатор точки доступа, AP2 ID, точки радиодоступа, AP2, или идентификатор узла-B, Node-B ID, сигнал маяка которого детектируется указанным UT, причем указанный AP2 ID идентифицируется согласно указанному альтернативному протоколу сети радиодоступа, или мобильному IP-адресу, MIP, или защищенному MIP-адресу, MIPSec, UT, наряду с IP-адресом маршрутизатора доступа, AR, ассоциированного с RNC-кандидатом, при этом этап установления идентичности указанного RNC-кандидата содержит этап, на котором:

- проверяют сохраненную информацию, связывающую указанный AP2 ID/Node-B ID/IP-адрес AR с идентичностью указанного RNC-кандидата,

причем этап ассоциации указанного сеанса связи с указанным RNC-кандидатом содержит этап, на котором:

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

В одном из вариантов осуществления указанное сообщение "Кандидат для хэндовера^" содержит сетевой адрес указанного RNC-кандидата в качестве исходного адреса указанного сообщения, таким образом идентифицируя RNC-кандидата, причем указанное сообщение "Кандидат для хэндовера" получают через RNC-интерфейс, соединяющий указанный RNC1 с указанным RNC-кандидатом.

В одном из вариантов осуществления указанное сообщение "Кандидат для хэндовера^" содержит сетевой адрес указанного RNC-кандидата, идентифицирующий RNC-кандидата, причем UT ID представляет собой альтернативный сетевой адрес указанного UT, и при этом AP2 ID представляет собой альтернативный сетевой адрес указанного AP2, причем способ дополнительно содержит этап, на котором:

- принимают указанное сообщение "Кандидат для хэндовера" по первому пути сети радиодоступа или по альтернативному пути сети радиодоступа.

В одном из вариантов осуществления первый протокол маршрутизации сети представляет собой 3GPP-протокол, а альтернативный протокол сети доступа представляет собой IEEE 802-стандартный протокол или протокол мобильного IP, MIP или протокол защищенного мобильного IP, MIPSec, и в котором:

- указанное сообщение "Кандидат для хэндовера" представляет собой RRC-сообщение, удовлетворяющее 3GPP-стандарту в случае, если указанное сообщение "Кандидат для хэндовера" принято по первому пути сети радиодоступа, и в котором

- указанное сообщение "Кандидат для хэндовера" представляет собой UDP/IP-сообщение, удовлетворяющее IAPP-протоколу или LWAP-протоколу в случае, если указанное сообщение "Кандидат для хэндовера" принято по альтернативному пути сети радиодоступа.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

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

- сигнализируют данные на уровне управления и/или RRM-информацию, ассоциированную с указанным сеансом, в/из указанного UT по указанному первому пути сети радиодоступа посредством указанного первого протокола маршрутизации радиосети или

- сигнализируют данные на уровне управления и/или RRM-информацию, ассоциированную с указанным сеансом в/из указанного UT по указанному альтернативному пути сети радиодоступа посредством указанного альтернативного протокола маршрутизации сети доступа.

В одном из вариантов осуществления способ содержит этап, на котором:

- отменяют назначение канала радиотрафика, выполненное посредством указанного первого протокола радиосети, причем указанное назначение ассоциировано с указанным сеансом.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

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

- сигнализируют данные на уровне управления и/или RRM-информацию, ассоциированную с указанным сеансом, в UT по указанному альтернативному пути сети радиодоступа.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

- отменяют назначение канала радиотрафика, выполненное посредством указанного первого протокола радиосети, причем указанное назначение ассоциировано с указанным сеансом,

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

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

- устанавливают, что указанный RNC-кандидат не является RNC1,

- принимают решение о маршрутизации указанного сеанса связи через указанный RNC-кандидат,

- устанавливают меж-RNC-туннельный канал через меж-RNC-интерфейс, соединяющий RNC1 с указанным RNC-кандидатом.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

- формируют сообщение “Запрос на установку линии радиосвязи”, содержащее:

- идентификатор типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением “Запрос на установку линии радиосвязи”,

- информационный элемент запроса на установку линии радиосвязи;

- альтернативный сетевой адрес UT,

- номер порта туннеля указанного меж-RNC-туннельного канала, и;

- посылают указанное сообщение “Запрос на установку линии радиосвязи” в указанный RNC-кандидат через меж-RNC-интерфейс, соединяющий RNC1 с RNC-кандидатом.

В одном из вариантов осуществления указанный информационный элемент “Запрос на установку линии радиосвязи” дополнительно содержит идентификатор типа хэндовера сеанса и/или идентификатор, идентифицирующий сигнализацию управления, ассоциированную с сеансом, и/или идентификатор, идентифицирующий сеанс, причем указанный идентификатор/идентификаторы определяют один из следующих типов хэндовера:

(1) хэндовер сеанса и хэндовер на уровне управления от WLAN-пути, ассоциированного с AP1, к UTRAN-пути, ассоциированному с узлом-B RNC2, или

(2) хэндовер сигнализации на уровне управления от узла-B радиодоступа, ассоциированного с RNC1, к узлу-В-кандидату радиодоступа, ассоциированному с RNC-кандидатом, причем хэндовер только сигнализации на уровне управления и/или RRM-информации, ассоциированной с сеансом и сигнализированной через указанный узел-B, должен выполняться к указанному узлу-B-кандидату, при этом указанная сигнализация реализуется посредством указанного первого протокола маршрутизации радиосети, или

(3) хэндовер на уровне пользователя указанного сеанса из точки AP1 радиодоступа, ассоциированной с RNC1, в точку-кандидата AP2 радиодоступа, ассоциированную с RNC-кандидатом, причем сеанс в текущий момент времени проводят через RNC1 и через указанную точку AP1 доступа, и он должен быть выполнен через RNC-кандидата и через указанную точку-кандидата AP2 доступа, при этом маршрутизация сеанса через указанные точки AP1 и AP2 доступа осуществляется посредством указанного альтернативного протокола маршрутизации сети доступа, или

(4) хэндовер на уровне пользователя или управления указанного сеанса из точки AP1 радиодоступа, ассоциированной с RNC1, в точку-кандидата AP2 радиодоступа, ассоциированную с RNC-кандидатом, причем данные на уровне управления и/или RRM-информация, ассоциированная с сеансом, маршрутизируется, наряду с самим сеансом, в текущий момент времени через RNC1 и через указанную точку AP1 доступа, и должны быть маршрутизированы через RNC-кандидата и через указанную точку-кандидата AP2 доступа, при этом маршрутизация через указанные точки AP1 и AP2 доступа осуществляется посредством указанного альтернативного протокола маршрутизации сети доступа.

В одном из вариантов осуществления указанное сообщение “Запрос на установку линии радиосвязи” дополнительно содержит

- информационный элемент, определяющий требуемый уровень QoS для запрашиваемой линии/линий радиосвязи.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

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

- добавляют LLC-заголовки к исходным пользовательским пакетам данных IP-сеанса, передаваемым по нисходящей линии связи, преобразуя их в формат LLC согласно указанному альтернативному протоколу сети доступа с адресом исходной LLC-сети RNC1,

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

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

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

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

В одном из вариантов осуществления UT ID сообщения "Кандидат для хэндовера" представляет собой адрес мобильного IP, MIP или защищенный адрес MIP, MIPSec, UT; и сообщение "Кандидат для хэндовера" содержит IP-адрес маршрутизатора доступа, AR, ассоциированный с RNC-кандидатом, причем способ дополнительно содержит этапы, на которых:

- идентифицируют сеанс посредством MIP/MIPSec-адреса UT, связанного с сеансом,

- обновляют таблицу маршрутизации сеанса при помощи IP-адреса AR,

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

- инкапсулируют пакеты IP-сеанса исходного формата передачи посредством UDP/IP или TCP/IP с IP-адресом AR в виде адреса назначения,

- инкапсулируют таким образом полученные UDP/IP или TCP/IP-пакеты сеанса с UDP/IP, формируя пакеты туннелирования, причем номер UDP порта пакетов туннелирования идентифицирует меж-RNC-туннель для RNC-кандидата, установленного, как описано выше, и

- связывают указанный идентификатор сеанса с номером UDP-порта меж-RNC-туннеля, таким образом туннелируя инкапсулированные пакеты сеанса, передаваемые по нисходящей линии связи, в RNC-кандидат, и маршрутизируют пакеты через AR2 вместо AR.

В одном из вариантов осуществления RNC1 маршрутизирует сеанс связи для RNC-кандидата по меж-RNC-туннелю, причем указанный способ дополнительно содержит этап, на котором:

- маршрутизируют сеанс по альтернативному пути сети радиодоступа через второй порт параллельно с маршрутизацией сеанса по меж-RNC-туннелю для RNC-кандидата.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

- принимают сообщение “Подтверждение хэндовера” из UT, причем сообщение содержит:

- идентификатор типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением “Подтверждение хэндовера”,

- информационный элемент диссоциации и сетевой адрес точки AP1 радиодоступа, причем UT больше не ассоциирован с AP1, и

- информационный элемент “Подтверждение хэндовера”, наряду с сетевым адресом точки AP2 радиодоступа, с которой в текущий момент времени ассоциирован UT, причем сетевые адреса указанных AP1 и AP2 определяются согласно указанному альтернативному протоколу сети доступа, и при этом способ дополнительно содержит этап, на котором:

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

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

- принимают решение о маршрутизации сеанса через указанного RNC-кандидата,

- устанавливают, что сеанс не может быть маршрутизирован последовательно через RNC1 и RNC-кандидата,

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

- формируют сообщение "Необходимое RNC-перемещение", содержащее:

- информационный элемент идентификатора типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Необходимое RNC-перемещение",

- идентификатор, идентифицирующий RNC-кандидата,

- сетевой адрес UT, как определено согласно альтернативному протоколу сети доступа,

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

- направляют указанное сообщение "Необходимое RNC-перемещение" в указанный узел поддержки передачи пакетных данных, таким образом запрашивая для сеанса перемещение обслуживания RNC из указанного RNC1 в указанный RNC-кандидат.

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

- принимают сообщение “Подтверждение хэндовера” из UT, причем сообщение содержит:

- информационный элемент идентификатора типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением “Подтверждение хэндовера”,

- информационный элемент диссоциации и сетевой адрес точки AP1 радиодоступа, причем UT больше не ассоциирован с АP1, и

- информационный элемент “Подтверждение хэндовера”, наряду с сетевым адресом точки AP2 радиодоступа, с которой UT ассоциирован в текущий момент времени, причем сетевые адреса указанных AP1 и AP2 определены согласно указанному альтернативному протоколу сети доступа, и при этом способ дополнительно содержит этап, на котором:

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

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

- собирают RRM-информацию относительно по меньшей мере точек AP1 и AP2 радиодоступа, чьи сигналы маяка в текущий момент времени детектируются UT, причем указанная RRM-информация сигнализируется по первому пути сети радиодоступа или по альтернативному пути сети радиодоступа,

- принимают предварительное решение о хэндовере, основанное на указанной собранной RRM-информации, и

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

В одном из вариантов осуществления этап сбора RRM-информации относительно по меньшей мере точек AP1 и AP2 радиодоступа, сигналы маяка которых в текущий момент времени детектируются UT, дополнительно содержит этап, на котором:

- принимают управление радиоресурсами, RRC, сообщение-отчет об измерении по первому пути сети радиодоступа или по меж-RNC-интерфейсу, причем сообщение соответствует формату 3GPP RRC-стандарта и содержит информационный элемент "Дополнительные измеренные результаты", указывающий на AP2 как на целевую точку доступа, или

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

В одном из вариантов осуществления указанная сеть с множеством RAT представляет собой интегрированную 3GPP-UTRAN-IEEE 802-WLAN-сеть, указанный сеанс связи представляет собой 3GPP-сеанс с PDP-контекстом, указанный первый протокол маршрутизации радиосети представляет собой протокол 3GPP UTRAN-стандарта, указанный идентификатор сеанса представляет собой идентификатор конечной точки GTP-U-туннеля протокола 3GPP UTRAN-стандарта, TEID, UDP/IP-туннеля между RNC1 и SGSN, указанный радиоканал согласно указанному первому протоколу маршрутизации представляет собой 3GPP RB ID, указанный альтернативный идентификатор канала представляет собой идентификатор WLAN радиоканала, WLAN RB ID, или идентификатор радиоканала мобильного IP, MIP RB ID или идентификатор радиоканала защищенного мобильного IP, MIP/IPSec RB ID, указанный альтернативный протокол сети доступа представляет собой IEEE 802 WLAN-протокол или IP/MIP/IPSec-протокол, или их комбинацию, указанный UT ID представляет собой WLAN MAC-адрес UT, или MIP-адрес UT, или MIPSec-адрес UT, указанный AP2 ID представляет собой WLAN MAC-адрес AP2, указанный узел-B ID представляет собой 3GPP идентификатор, идентифицирующий узел-B, указанный второй адрес сети UT представляет собой MTP или MTPSec-адрес, указанный идентификатор, идентифицирующий указанного RNC-кандидата, представляет собой IP-адрес или UTRAN MAC-адрес RNC-кандидата, указанный первый интерфейс, соединяющий указанный RNC1 с указанным RNC-кандидатом, представляет собой 3GPP Iur-интерфейс, указанный сетевой адрес указанного RNC-кандидата представляет собой UTRAN MAC-адрес или IP-адрес RNC-кандидата, и причем указанное сообщение “Запрос на установку линии радиосвязи” соответствует 3GPP формату сообщения “Запрос на установку линии радиосвязи”, и при этом сетевой адрес точек радиодоступа, AP1, UT и AP2 представляют собой WLAN MAC-адреса AP1, UT и AP2, соответственно, указанный узел поддержки пакетной передачи данных представляет собой 3GPP SGSN, причем формат сообщения “Запрошенное RNC-перемещение” соответствует 3GPP формату сообщения “Запрошенное RNC-перемещение”.

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

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

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

- принимают сообщение “Запрос на установку линии радиосвязи” из соседнего RNC1, маршрутизирующего сеанс в текущий момент времени, ассоциированный с UT,

- извлекают из сообщения “Запрос на установку линии радиосвязи” номера туннельных портов меж-RNC-туннеля между RNC1 и RNC-кандидатом,

- извлекают из сообщения “Запрос на установку линии радиосвязи” идентификатор UT, идентифицирующий UT,

- ассоциируют указанные номера туннельных портов с UT и с сеансом, ассоциированным с UT,

- извлекают идентификатор типа хэндовера сеанса указанного сообщения “Запрос на установку линии радиосвязи”,

- устанавливают канал радиотрафика для маршрутизации сеанса указанного UT согласно указанному идентификатору типа хэндовера.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

- принимают сообщение "Кандидат для хэндовера", содержащего:

- информационный элемент идентификатора типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Кандидат для хэндовера" и

- идентификатор точки доступа, AP2 ID, точки AP2 радиодоступа или идентификатор узла-B, Node-B ID узла B, сигнал маяков которого детектируется указанным UT, причем указанный AP2 ID определяется согласно указанному альтернативному протоколу сети радиодоступа или мобильному IP-адресу, MIP, или защищенному адресу MIP, MIPSec, UT, наряду с IP-адресом маршрутизатора доступа AR, ассоциированного с RNC-кандидатом,

причем сообщение "Кандидат для хэндовера" идентифицирует UT и

- устанавливает, какой указанный UT не имеет активного сеанса, маршрутизируемого через RNC-кандидата.

В одном из вариантов осуществления указанное сообщение "Кандидат для хэндовера" принимают по меж-RNC-интерфейсу из RNC1, маршрутизирующему сеанс в текущий момент времени, причем способ дополнительно содержит этапы, на которых:

- узнают, что исходный адрес сети указанного сообщения "Кандидат для хэндовера" представляет собой сетевой адрес RNC1, и делают вывод о том, что в текущий момент времени сеанс маршрутизируется через RNC1,

- устанавливают меж-RNC-туннель между RNC1 и RNC-кандидатом.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

- принимают указанное сообщение "Кандидат для хэндовера" из UT по первому пути сети радиодоступа или по альтернативному пути сети радиодоступа,

- направляют указанное сообщение "Кандидат для хэндовера" в соседние с ним RNC.

В одном из вариантов осуществления идентификатор точки доступа представляет собой идентификатор соты узла доступа AP2 указанного альтернативного пути сети радиодоступа, причем указанный элемент идентификатора типа хэндовера сеанса указывает, что сеанс должен быть маршрутизирован через AP2, причем этап установки канала радиотрафика для UT дополнительно содержит этапы, на которых:

- устанавливают логическое LLC-соединение через порт с UT через AP2 (266), причем LLC-соединение устанавливают при помощи альтернативного протокола сети доступа,

- ассоциируют сеанс с LLC-соединением.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

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

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

- направляют полученные таким образом пакеты сеанса через порт, маршрутизируя таким образом пакеты в UT через AP2.

В одном из вариантов осуществления способ дополнительно содержит этапы, на которых:

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

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

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

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

- направляют сформированные таким образом LLC-пакеты сеанса через порт, таким образом маршрутизируя пакеты в UT через AP2.

В одном из вариантов осуществления сообщение "Кандидат для хэндовера" содержит мобильный IP-адрес, MIP, или защищенный адрес MIP, MIPSec, UT, наряду с IP-адресом маршрутизатора доступа, AR, ассоциированный с RNC-кандидатом, причем идентификатор UT-сообщения "Запрос на установку линии радиосвязи" представляет собой соответствующий MIP/MIPSec-адрес UT, при этом меж-RNC-туннель представляет собой UDP/IP-туннель, причем способ дополнительно содержит этапы, на которых:

- извлекают MIP/MTPSec UT из указанного сообщения "Запрос на установку линии радиосвязи",

- ассоциируют номер туннельного порта с MIP/MIPSec UT и с IP-адресом AR,

- принимают идентификацию сеанса при помощи MIP/MIPSec- адреса UT, ассоциированного с сеансом,

- обновляют таблицу маршрутизации сеанса с IP-адресом AR,

- принимают IP инкапсулированные пакеты IP-сеанса, передаваемые по нисходящей линии связи, по RNC UDP/IP-туннелю,

- вырезают UDP/IP-заголовки туннелирования из IP-инкапсулированных пакетов IP-сеанса, передаваемых по нисходящей линии связи, получая пакеты IP-сеанса, передаваемые по нисходящей линии связи, инкапсулированные с IP, причем IP-адрес капсуляции пакетов IP-сеанса представляет собой IP-адрес AR2, и

- направляют пакеты IP-сеанса, передаваемые по нисходящей линии связи, инкапсулированными с IP-адресом AR в порт, ассоциированный с AR, таким образом маршрутизируя пакеты IP- сеанса, передаваемые по нисходящей линии связи, в UT через AR и AP2.

В одном из вариантов осуществления указанная сеть с множеством RAT представляет собой интегрированную 3GPP-UTRAN-IEEE 802-WLAN-сеть, указанный сеанс связи представляет собой 3GPP-сеанс с PDP-контекстом, указанный первый протокол маршрутизации радиосети представляет собой 3GPP-протокол UTRAN-стандарта, указанный идентификатор представляет собой идентификатор конечной точки GTP-U-туннеля протокола 3GPP UTRAN-стандарта, TEID, UDP/IP-туннеля между RNC1 и RNC-кандидатом, указанный радиоканал согласно указанному первому протоколу маршрутизации представляет собой 3GPP RB ID, указанный альтернативный идентификатор канала представляет собой идентификатор радиоканала WLAN, WLAN RB ID, или идентификатор радиоканала мобильного IP, MIP RB ID, или идентификатор радиоканала защищенного мобильного IP, MIP/IPSec RB ID, указанный альтернативный протокол сети доступа представляет собой IEEE 802 WLAN-протокол или IP/MTP/IPSec-протокол или их комбинацию, указанный UT ID представляет собой MAC WLAN-адрес UT или MIP-адрес UT, или МIPSec-адрес UT, указанный AP2 ID представляет собой WLAN MAC-адрес AP2, указанный Node-B ID представляет собой 3GPP идентификатор, идентифицирующий узел-B, указанный второй адрес сети UT представляет собой MIP или MIPSec-адрес, причем указанное сообщение “Запрос на установку линии радиосвязи” соответствует 3GPP формату сообщения “Запрос на установку линии радиосвязи”, при этом сетевой адрес точек радиодоступа AP1, UT и AP2 представляет собой WLAN MAC-адреса AP1, UT и AP2 соответственно.

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

На фиг.1 показана архитектура сети обычной интегрированной сети радиодоступа, содержащей UTRAN и WLAN, соединенные с Интернетом.

На фиг.2 показан иллюстративный пример интегрированной архитектуры сети радиодоступа согласно одному из вариантов осуществления настоящего изобретения.

На фиг.3 показан стек протоколов на уровне пользователя для некоторых из узлов сети, показанных на фиг.2 согласно одному из вариантов осуществления изобретения.

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

На фиг.5 показан стек протоколов на уровне управления для некоторых из узлов сети, показанных на фиг.2 согласно одному из вариантов осуществления изобретения.

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

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

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

ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Настоящее изобретение более подробно описано ниже со ссылкой на фиг.2-8.

Как заявлено, изобретение относится к интегрированным сетям с множеством RAT (технология радиодоступа) и более подробно описано в виде примеров вариантов осуществления или способов работы, которые описаны ниже для определенного случая UTRAN-WLAN, интегрированной сети RAT. Однако изобретение применимо для любой сети сотовой радиосвязи, которая интегрирована с произвольной сетью радиодоступа IEEE 802 уровня 2 и, возможно, множеством модификаций и/или комбинаций. Например, в случае WMAN, IEEE 802.16, AP 265 затем может преобразовать IEEE 802.3 MAC кадры в 802.16 MAC кадры вместо 802.11 MAC кадров, как это очевидно специалисту в данной области техники. Сеть сотовой радиосвязи может представлять собой любую сеть сотовой радиосвязи, содержащую контроллер радиосети, RNC, выполненный с возможностью установки и маршрутизации сеанса данных (пакета) по различным путям передачи по сети, используя различные протоколы маршрутизации, сотовая сеть может представлять собой, например, UTRAN-GPRS-сеть, CDMA 2000-сеть, IS-95-сеть, D-AMPS-сеть и так далее. Например, в случае CDMA 2000-сети функциональные возможности RNC, описанные ниже согласно изобретению, предпочтительно могут быть реализованы в BSC (контроллерах базовой станции) CDMA 2000-сети, как это очевидно специалисту в данной области техники. Следовательно, термин RNC не следует интерпретировать строго как содержащий только RNC согласно 3GPP UTRAN-стандарту, а следует рассматривать как содержащий любой узел управления сетью, выполненный с возможностью отображения сеанса данных по различным путям передачи через свои различные порты, причем различные пути передачи используют различные протоколы маршрутизации. Термин протокол маршрутизации здесь следует интерпретировать как содержащий все протоколы передачи, используемые по определенному пути передачи сети радиодоступа, причем путь может содержать множество узлов передачи. Таким образом, RNC представляет собой любой узел, который может передавать сеанс данных в первый узел через первый порт, а во второй узел - через второй порт, при этом первый узел использует первый протокол маршрутизации, а второй узел использует второй, альтернативный, протокол маршрутизации. Таким образом, термин "протокол маршрутизации" не следует интерпретировать обычным способом как протокол, используемый между различными узлами сети для обмена информацией о доступности, но как механизм маршрутизации или передачи данных посредством определенной сетевой технологии по пути сети радиодоступа, причем путь обычно содержит множество узлов. Таким образом, протокол маршрутизации представляет собой средство передачи пакетов данных согласно определенной технологии и таким образом обычно содержит набор протоколов передачи согласно одной из стандартных технологий передачи, причем протоколы используются узлами в пределах сетевого пути. Например, 3GPP UTRAN-технология определяет первый набор протоколов для передачи данных и таким образом определяет первый протокол маршрутизации, а IEEE, 802 WLAN-технология определяет второй набор протоколов для передачи данных и таким образом определяет второй протокол маршрутизации. RNC согласно изобретению представляет собой таким образом любой узел сети, который, когда он связан по меньшей мере с двумя различными сетями, использующими различные технологии по меньшей мере через два различных порта данных, причем порты данных могут связываться непосредственно с пользовательским терминалом или связываться с пользовательским терминалом через промежуточные сетевые узлы, выполнен с возможностью отображения сеанса данных через первый и/или второй из портов данных.

На фиг.1-8 соответствующие элементы имеют одинаковые ссылочные позиции с приставкой номера чертежа, например, AP1 165 на фиг.1 упоминается на фиг.2 как AP1 265 и так далее.

На фиг.2 показан иллюстративный пример сетевой архитектуры с множеством RAT согласно настоящему изобретению в виде UTRAN-WLAN интегрированной сети с RAT. На фиг.2 узлы-B 250 и 251 соединены с RNC1 230 и RNC2 231 соответственно через обычные Iub-интерфейсы и порты 273 и 278 соответственно. Согласно изобретению часть WLAN соединена с RNC1 230 и RNC2 231 соответственно. Соответствующая часть WLAN содержит точки доступа AP1 265 и AP2 266 или непосредственно соединена с соответствующим им RNC или, как показано на фиг.2, соединена через обычные коммутаторы М-L2S1 262 и М-L2S2 263 уровня 2. В одном из вариантов осуществления маршрутизаторы AR 255 и AR 256 доступа установлены между М-L2S1 262 и RNC1 230 и между М-L2S2 263 и RNC2 231, как показано на фиг.2, а в другом варианте осуществления на пути маршрутизации между AP1 265 и RNC1 230 и между AP2 266 и RNC2 231 не установлены никакие маршрутизаторы доступа, но AP соединены непосредственно с соответствующим им RNC, не обязательно через коммутатор/коммутаторы М-L2S. Существуют много возможностей: несколько AP могут быть соединены с одним и тем же коммутатором М-L2S, несколько коммутаторов М-L2S могут быть соединены последовательно или параллельно с одним и тем же RNC, AR могут быть соединены с другими сетями передачи данных (например, IP-сетями), IP-сети могут быть установлены между несколькими AR и RNC, и на фиг.2 для объяснения изобретения показан исключительно иллюстративный пример. RNC1 230 и RNC2 231 соединены с SGSN 220 через обычный Iu-интерфейсы через порты 270 и 275 и согласно одному из аспектов изобретения соединены друг с другом через обычный интерфейс Iur через порты 271 и 276. Согласно другому аспекту изобретения между RNC1 230 и RNC2 231 соединение через интерфейс отсутствует. Они дополнительно соединены со своими соответствующими AR/M-L2S/AP (то есть WLAN-частью) через порты 272 и 277 соответственно, как показано на фиг.2. UT 240 выполнен с возможностью установления соединения/сеанса радиосвязи с узлами-В 250 и 251 через свой порт 241 и с AP 265 и 266 через свой порт 242 обычным способом, то есть он имеет возможность технологии сети с двойным радиодоступом (RAT).

На фиг.3 показаны основные пакеты протоколов на уровне пользователя для RNC1 230, М-L2S1 262, AP1 265 и UT 240, показанных на фиг.2, для случая, когда между RNC1 230 и AP1 265 не установлен AR (или IP-сеть). На фиг.3 показан случай, когда RNC соединены друг с другом через Iur-интерфейс согласно одному из аспектов изобретения. Пакеты протоколов на уровне пользователя для RNC2 231, М-L2S2 263, AP2 266 и узла-B 251 аналогичны. На фиг.3 RNC1 330 имеет обычный 3GPP GTP-U (GPRS-протокол туннелирования - на уровне пользователя), обычный UDP (протокол пользовательских дейтаграмм), обычный IP (интернет-протокол), обычный 3GPP L2 (уровень 2) и L1 (уровень 1) для обмена пакетами данных через порты 370 и 371 соответственно и имеет обычный 3GPP PDCP (протокол конвергенции пакетных данных), RLC (управление линией радиосвязи)-протокол, уровень 2 и уровень 1 UTRAN MAC для обмена пакетами данных через порт 373. Согласно изобретению RNC1 330 имеет дополнительный обычный IEEE 802.2 LLC (управление уровнем связи)-протокол, уровень IEEE 802.3 MAC (управление доступом к среде) и IEEE 802 физический уровень 1 (Ethernet физический уровень) для обмена пакетами данных через порт 372. Согласно изобретению RNC1 330 имеет объект маршрутизации для маршрутизации сеанса через порты 372 и 373 и объект управления множеством радиоресурсов (объект MRRM) для управления радиоресурсами UTRAN и WLAN интегрированным способом, как описано ниже. М-L2S1 362 имеет обычный IEEE 802.3 MAC-протокол и физический уровень 1. AP1 265 имеет обычный IEEE 802.11 MAC-протокол, IEEE 802.11-физический уровень, IEEE 802.3 MAC-протокол и IEEE 802.11-физический уровень. Узел-B 350 имеет обычный 3GPP-стек (как на уровне пользователя, так и на уровне управления, на фиг.3 не показано). UT 340 имеет обычный IEEE 802.11 LLC-протокол, IEEE 802.11 MAC-протокол, IEEE 802.11-физический уровень для обмена пакетами данных через порт 342 и имеет обычный PDCP-, RLC-, UTRAN MAC-протокол и UTRAN-физический уровень для обмена пакетами данных через порт 341. UT 340 имеет UDP/TCP-протокол/протоколы и установленный IP-протокол. Аналогично, как и в случае RNC1 330, UT 340 и 330 имеют объект маршрутизации для маршрутизации сеанса через порты 341 и 342 и объект управления множеством радиоресурсов (объект MRRM) для управления UTRAN и WLAN радиоресурсами интегрированным способом, как описано ниже.

На фиг.4 показаны принципиальные стеки протоколов на уровне управления для сетевых узлов по фиг.3. Кроме IEEE 802 уровней 1, 2, 3 и UTRAN уровней 1 и 2, и объектов маршрутизации и MRRM у UT 440 и RNC1 430, предоставленных или ставших возможными благодаря изобретению и описанных выше со ссылкой на фиг.3, на UT 440 установлены RLC (управление радиосвязью)-протокол, RRC (управления радиоресурсами)-протокол и STAME (объект управления станцией), на AP1 465 установлены APME (объект управления точкой доступа), IAPP (протокол взаимодействия между точками доступа согласно IEEE 802.11f-стандарту), UDP/TCP- и IP-протоколы, на RNC1 430 установлены IAPP, UDP/TCP- и IP-протоколы, RRC, RLC, RANAP (прикладная подсистема радиодоступа), SCCP (подсистема управления соединением сигнализации) и 3GPP-протокол канала передачи сигналов, как показано на фиг.4.

На фиг.5 показаны основные стеки протоколов на уровне управления/пользователя для UT 240, AP1 265, AR1 255 и RNC1 230 по фиг.2 согласно одному из вариантов осуществления изобретения, в котором AR1/AR2 установлены между АP1/АP2 и RNC1/RNC2 (М-L2S1 262 функционирует просто в качестве релейного коммутатора и на фиг.5 не учтен). В этом варианте осуществления между AR и RNC имеется IP-сеть. Как показано на фиг.5, на RNC1 530 и UT 540 установлены дополнительный Ipm-протокол (Mobile IP, MIP) и также необязательно IPSec-протокол, и AR1 555 связан с RNC 530 через TCP/IP по промежуточной IP-сети и связан с UT 540 через IEEE 802.2 LLC по WLAN-сети. IPm и IPSec-протоколы могут быть объединены. Другие протоколы, показанные на фиг.5, обсуждались со ссылкой на фиг.3 и 4. Стек протоколов для lur-интерфейса идентичен стеку Iu-интерфейса и на фиг.5 не показан.

Обычно на UT 240 дополнительно установлен объект аутентификации WLAN (не показан), например, согласно 802.IX EAP/TLS/TTLS/PFAP-стандарту, позволяющему UT 240 обмениваться данными с соответствующим объектом аутентификации WLAN, например, в виде RADIUS или DIAMETER-сервера, соединенного с AP1 265 с целью аутентификации. RADIUS или DIAMETER-сервер может быть интегрирован, например, в AR1 255 или RNC1 230, но существуют много возможностей. Существуют множество опций протокола, как очевидно специалисту в данной области техники, например, вместо IAPP может использоваться LWAPP (облегченный протокол точек доступа), или в случае UTRAN вместо LLC/IAPP могут использоваться RLC/RNC-протоколы и так далее. RADIUS-сервер, как правило, использует обычный RADIUS-протокол, например, как определено документами RFC 3579 (RADIUS-поддержка для EAP), RFC 2865, RFC 2869 (RADIUS-расширение), RFC 3576 (динамическое расширение авторизации для RADIUS) и RFC 3580 (IEEE 802.IX RADIUS руководство по эксплуатации), а DIAMETER-сервер, как правило, использует обычный DIAMETER-протокол, например, как определено RFC 3588 (DIAMETER-основной протокол), наряду с обычным EAP (расширенный протокол аутентификации), например, как определено стандартными AAA (аутентификация, авторизация и учет)-протоколами RFC 2284 - PPP EAP, RFC 4017 (EAP требования для WLAN) или RFC 3748 (EAP) или RFC 2716 (PPP EAP TLS) или EAP-TTLS (EAP туннелированный TLS-протокол аутентификации), изданными организацией стандартов IETF (целевой группы инженерной поддержки Интернета), и дополнительно может использовать EAP-PEAP (защищенный EAP-протокол).

Соответствующие стеки для RNC2 231 и ассоциированная с ним WLAN маршрутизация по фиг.2 аналогичны стекам по фиг.3, 4 и 5.

Ниже со ссылкой на фиг.2-7 более подробно описан способ согласно изобретению для варианта осуществления, в котором не установлен никакой из маршрутизаторов AR1 255 и AR2 256 доступа в сети, показанной на фиг.2, то есть он представляет собой только WLAN-путь между RNC1/RNC2 230/232 и AP1/AP2 265/266. Предполагается, что каждый AP поддерживает свою собственную современную базу данных, содержащую информацию о соседних AP, зоны покрытия которых могут перекрываться с его собственной. Таким образом, каждый AP выполнен с возможностью предоставления ассоциированных UT с частью отчета согласно IEEE 802.11k-спецификации, которая содержит информацию о других ближайших AP, к которым UT может переместиться (или осуществить передачу вызова). Это может быть достигнуто только, если все вовлеченные AP управляются одним и тем же оператором или если между операторами существуют специальные соглашения. Описанный здесь способ является исключительно иллюстративным примером для пояснения изобретения, и возможны многочисленные модификации, например, некоторые этапы/действия могут выполняться в другом/обратном порядке, приводя к такому же результату, как это является очевидным специалисту в данной области техники.

На этапе 6000 по фиг.6 имеется обычный активный сеанс передачи пакетных данных, такой как мультимедийный сеанс, между UT 240 и, например, одноранговым узлом или хостом, соединенным с Интернетом 280, по UTRAN-пути маршрутизации через узел-B 250 и RNC1 230. Для выполнения сеанса между UT 240, SGSN 220 и GGSN 210 используется обычный 3GPP-сеанс с PDP-контекстом (протокол передачи пакетных данных). Сеанс с PDP-контекстом может быть установлен обычным способом, например, по инициативе UT 240, в котором после обычной сигнализации между UT 240, SGSN 220 и GGSN 210 SGSN 220 инициирует установку GTP-U-туннеля при помощи сообщения Create_PDP_Context_Request в GGSN 210. GTP-туннель идентифицируется туннельным идентификатором конечной точки (TEID), IP-адресом (то есть IP-адресом принимающего узла) и номером UDP порта. TEID локально назначается принимающей стороной GTP-туннеля, которая однозначно идентифицирует конечную точку туннеля. Конечные точки туннеля обмениваются между собой значениями TEID, используя GTP-C-сообщения. Сеанс с PDP-контекстом характеризуется своим QoS-профилем и IP-адресом, и TEID (обычно номер UDP-порта) соответствующих узлов однозначно идентифицирует обычным способом определенный сеанс с PDP-контекстом, туннелирование которого происходит между RNC1 230, SGSN 220 и GGSN 210. Для маршрутизации PDP пакетов, которые маршрутизируют по GTP-U-туннелю в SGSN 220 в виде UDP/IP-пакетов, RNC1 идентифицирует TEID GTP-U-туннель с PDP-контекстом и маршрутизирует эти пакеты по UTRAN/RLC/MAC в виде PDCP-пакетов в/из UT 240 путем связывания указанного TEID с 3GPP RAB ID (идентификатором канала точки доступа), который связан с 3GPP RAB ID (идентификатором радиоканала), который, в свою очередь, однозначно обычным способом определяет "правильный^" 3GPP-канал/каналы (и параметры настройки) для передачи PDCP-пакетов в/из UT 240. В табл.1 показана таблица маршрутизации, используемая обычным способом ROUTIMG-объектом RNC1 230 для маршрутизации пакетов сеанса с PDP-контекстом.

Таблица 1
PDP-сеанс	3GPP RB ID	3GPP RAB ID	UT	TEID	GTP-U-туннель
Сеанс	RB ID 1	RAB ID 1	UT 1	TEID 1	GTP-U 1
Сеанс 2	RB ID 2	RAB ID 2	UT 2	TEID 2	GTP-U 2
Сеанс N	RB ID N	RAB ID N	UT N	TEID N	GTP-U Т

Как видно из табл.1, один UT может иметь множество активных PDP-сеансов. В нижеследующем описании предполагается, что UT 240 имеет только один активный PDP-сеанс, а именно сеанс 1 согласно табл.1. Этот сеанс с PDP-контекстом между UT 240 и SGSN 220 проиллюстрирован этапом 1 передачи на фиг.7A. UT 240 в нижеследующих таблицах называется UT1.

Затем способ переходит на этап 6010, в котором согласно изобретению UT 240 формирует и посылает сообщение относительно возможностей в RNC1 230 по пути UTRAN (то есть через узел-B 250), причем сообщение информирует RNC1 230 о том, что UT 240 имеет возможность двойного RAT, то есть выполнен с возможностью установления связи как по пути UTRAN, так и по пути WLAN. Это показано этапом 2 передачи на фиг.7A. Согласно изобретению это сообщение относительно возможностей содержит информационный элемент "Возможности многорежимного UT/множества RAT", информирующий RNC1 230, что UT 240 имеет и UTRAN, и WLAN-возможности, в случае, если альтернативная сеть представляет собой WLAN. Существует множество возможностей того, как определить информационный элемент "Возможности многорежимного UT/множества RAT", это может быть сделано, например, "идентификатором альтернативной сети", однозначно определяющим альтернативную сеть, которая, например, может быть определена посредством первого, точно определенного, четырехбитового поля данных в RRC-сообщении, позволяющего идентификацию 16 различных альтернативных сетей, наряду с альтернативным сетевым адресом UT 240 во втором, точно определенном, поле данных, то есть WLAN MAC-адресе UT 240 в случае, если альтернативная сеть представляет собой беспроводную LAN, соединенную непосредственно с RNC1 230 (то есть между AP1 265 и RNC1 230 не установлен промежуточный AR 255). В случае наличия AR 255, соединяющего WLAN часть с RNC1 230, как показано на фиг.2, например, через IP-сеть между AR 255 и RNC1 230 (не показано на фиг.2), альтернативным сетевым адресом UT 240 может быть IP-адрес UT 240, как описано ниже, но существует множество возможностей. "Альтернативный идентификатор сети" может, например, быть установлен в 0000 для идентификации того, что альтернативная сеть представляет собой WLAN и может быть установлена в ^"0001" для идентификации того, что альтернативная сеть представляет собой IP-сеть и так далее. Сообщение относительно возможностей может таким образом быть реализовано, например, в виде RRC-сообщения, включающего WLAN MAC-адрес UT, наряду с указанным информационным элементом "Возможности многорежимного UT/множества RAT", и может быть послано в MRRM-объект RNC1 (по DCCH), который, как правило, является обычным 3GPP RRM-объектом RNC1, также выполненным с возможностью интеграции WLAN RRM-информации, как описано ниже. Сообщение относительно возможностей, в качестве альтернативы, может быть реализовано в виде модифицированного обычного сообщения "Запрос на активацию PDP-контекста", например, путем включения указанного "идентификатора альтернативной сети", наряду с указанным альтернативным сетевым адресом UT 240 в указанное сообщение. Таким образом, UT 240 посылает сообщение "Запрос на активацию PDP-контекста" в SGSN 220 во время активации PDP-контекста, содержащее вышеуказанные поля данных, но существует множество других возможностей реализации сообщения о возможностях. Согласно изобретению важным является то, что RNC1 230 информируют о возможности двойного RAT UT 240 и об альтернативном сетевом адресе (то есть WLAN MAC-адрес в этом иллюстративном примере, в котором альтернативная сеть представляет собой WLAN) UT 240 и что RNC1 230 выполнен с возможностью ассоциации альтернативного сетевого адреса UT 240 (то есть WLAN MAC-адрес в этом иллюстративном примере, в котором альтернативная сеть представляет собой WLAN) с правильным сеансом с PDP-контекстом (то есть сеансом UT 240), как описано ниже.

На этапе 6020 MRRM-объект RNC1 230 направляет этот WLAN MAC-адрес UT 240 в ROUTING-объект RNC1, причем объект обновляет свою таблицу маршрутизации соответствующим образом, как показано в табл.2.

Таблица 2
PDP- сеанс	3GPP RB ID	3GPP RAB ID	UT	Ассоциация TEID/GTP-U-туннеля	Альтернативный сетевой адрес UT
Сеанс 1	RB ID 1	RAB ID 1	UT 1	TEID/GTP-U 1-RNC -SGSN	WLAN MAC-адрес UT 1

Таким образом, на этапе 6020 ROUTING-объект RNC1 ассоциирует WLAN MAC-адрес UT 240 с его активным сеансом PDP, однако ROUTING-объект продолжает маршрутизировать пакеты PDP по пути UTRAN (через узел-B 250) путем связывания TEID 1 с RAB ID 1 и RAB ID 1 с RB ID 1.

На этапе 6030 UT 240 перемещается в зону покрытия AP1 265 и детектирует обычным образом кадр маяка из AP1 265, причем кадр содержит MAC-адрес AP1 265, при этом MAC-адрес передается MRRM-объекту UT 240. Это показано этапом 3 передачи на фиг.7A.

На этапе 6040 UT 240 формирует сообщение “Кандидат для хэндовера", однозначно идентифицирующее UT 240 и AP1 265, и посылает это сообщение в RNC1 230. Существуют множество возможностей реализации этого сообщения, важным является то, что сообщение "Кандидат для хэндовера" содержит/несет информацию, позволяющую RNC1 (230) установить, что с этого момента времени сеанс может быть маршрутизирован через AP1 (265), и в случае, если AP1 265 не соединен с RNC1 230, а соединен с другим RNC, сообщение "Кандидат для хэндовера" должно нести информацию, позволяющую RNC1 230 установить идентичность этого RNC. Кроме того, если сеанс в текущий момент времени маршрутизирован через другой сеанс, то сообщение "Кандидат для хэндовера" должно позволить RNC1 230 установить идентичность этого RNC. Как правило, сообщение "Кандидат для хэндовера" содержит информационный элемент идентификатора типа сообщения, информирующий RNC1 (230), что указанное сообщение представляет собой сообщение "Кандидат для хэндовера", наряду с любым идентификатором сеанса, обычно WLAN MAC-адресом UT (240), так как этот адрес идентифицирует сеанс в RNC1 (230), наряду с идентификатором точки доступа, идентифицирующим AP1 (265), причем идентификатор точки доступа обычно представляет собой WLAN MAC-адрес (или другой ID соты) AP1 (265). Сообщение "Кандидат для хэндовера" может быть реализовано, например, в виде модифицированного RRC-сообщения, включающего WLAN MAC-сетевой адрес (или другой идентификатор соты) AP1 (265), и может быть послано в RNC1 230 по BCCH через узел-B 250, но существует множество возможностей. Эта передача сообщения "Кандидат для хэндовера" проиллюстрирована этапом 4 передачи на фиг.7A, являющимся примером. Например, сообщение "Кандидат для хэндовера" можно послать по пути WLAN на более поздней стадии при помощи STAME/APME/IAPP-протоколов.

На этапе 6050 из этого сообщения "Кандидат для хэндовера" RNC1 230 извлекает идентификатор альтернативной сетевой соты AP1 265, то есть в нашем иллюстративном примере WLAN MAC-адрес AP1 265, причем альтернативная сеть представляет собой WLAN, и передает этот идентификатор соты в его MRRM-объект и ROUTING-объект. Затем MRRM объект RNC1 230 обновляет соответствующую MRRM-информацию согласно, например, различным RRM-алгоритмам, снабжающим данными, указывающими, что UTRAN-радиоканал/радиоканалы UT 240 могут быть переданы в AP1 265, чтобы максимизировать полную емкость радиосети. Точные MRRM-алгоритмы, то есть точные критерии оптимизации и так далее, MRRM-объекта RNC1 230 для такой оптимизации не являются объектом настоящего изобретения, но важное преимущество изобретения заключается в том, что оно создает возможность для того, чтобы такие функциональные возможности MRRM стали более эффективными. Согласно изобретению затем MRRM-объект RNC1 230 устанавливает, что указанный AP1 265 RNC ассоциирован (связан), например, посредством поиска просмотровой таблицы, содержащей все идентификаторы сот (например, WLAN-адрес) AP всей интегрированной сети, с сетевым адресом RNC, ассоциированным с ними соответствующим образом (например, IP-адрес соответственно UTRAN RNC). Кроме того, на этапе 6050 MRRM-объект RNC1 передает указанный сетевой адрес RNC в ROUTING-объект RNC1 230, который соответственно обновляет его таблицу маршрутизации, как показано в табл.3 путем связывания сеанса 1 с PDP-контекстом UT 240 с сетевым адресом (например, IP-адресом) RNC, ассоциированным с альтернативной точкой доступа, то есть AP1 265, то есть в нашем иллюстративном примере с сетевым адресом (например, IP-адресом) RNC1 230, причем AP1 265 соединен (и "достигается" через) с RNC1 230.

Таблица 3
PDP-сеанс	3GPP RB ID	3GPP RAB ID	UT	Ассоциация TEID/GTP-U- туннеля	Альтернативный сетевой адрес UT	RNC- ассоциация AP1
Сеанс 1	RB ID 1	RAB ID 1	UT 1	TEID/GTP-U-RNC1-SGSN	WLAN MAC-адрес UT	IP-адрес RNC1

Следовательно, на этапе 6060 UT 240 посылает сообщение “Запрос на ассоциацию” согласно IEEE 802-стандарту в AP1 265, чтобы инициировать установку WLAN-соединения, которое проиллюстрировано этапом 5 передачи на фиг.7A. Это сообщение содержит WLAN MAC-адрес UT 240. AP1 265 соответственно обновляет его таблицу переадресации, создавая ассоциацию его соответствующего порта с WLAN MAC-адресом UT 240. Указанное сообщение “Запрос на ассоциацию” также может содержать идентификатор сеанса с PDP-контекстом, например RB ID или RAB ID, или IP-адрес сеанса с PDP-контекстом, или NSAPI UT 240, для соответствующего PDP-сеанса, причина которого объяснена ниже. AP1 265 отвечает, посылая сообщение “Ответ на ассоциацию” в виде 802.11-сообщения, в UT 240, как проиллюстрировано этапом 6 передачи на фиг.7A. UT 240 принимает это сообщение “Ответ на ассоциацию” и имеет установленное таким образом радиосоединение с WLAN через его второй (WLAN) порт 242.

На этапе 6070 AP1 265 продолжает согласно IEEE 802-стандарту передачу обновленного кадра уровня 2 в направлении системы распределения WLAN (DS), то есть для М-L2S1 262 в направлении RNC1 230, как проиллюстрировано этапом 7 передачи на фиг.7A. Указанный L2 обновленный кадр также может содержать идентификатор сеанса с PDP-контекстом для RNC1 230, посланным в AP1 265 на этапе 6060.

На этапе 6080 М-L2S1 262 отвечает, направляя этот обновленный кадр уровня 2 в RNC1 230, как проиллюстрировано этапом 8 передачи на фиг.7A. Этот обновленный кадр уровня 2 содержит WLAN MAC-адрес UT 240 в виде исходного MAC-адреса и предпочтительно является многоадресным. Цель этого кадра уровня 2 заключается в вызове переводной таблицы или таблицы переадресации в любых устройствах уровня 2, которые принимают кадр, предназначенный для обновления, соответственно с MAC- адресами UT 240, то есть в ассоциации порта, который принимал этот кадр, с MAC-адресом UT 240, так, чтобы весь будущий трафик, предназначенный UT 240, был направлен в правильный порт, то есть порт, который принимал этот кадр. Принятие использования коммутаторов (М-L2S), позволяющих множество абонентов, чтобы избежать заполнения кадра уровня 2 и таким образом слишком высокого трафика в операторской сети, обновленные кадры уровня 2 предпочтительно являются многоадресными для группы, которой принадлежат соседние с ней AP, обслуживающие RNC1 230, и соответствующий М-L2S1 262. В этом случае таким образом каждый AP до некоторой степени знает сетевую топологию уровня 2, например, имея сохраненную таблицу MAC-адресов своих соседних AP и ассоциированных М-L2S. Обновленный кадр слоя 2 также может содержать указанный идентификатор сеанса с PDP-контекстом, например RB ID или RAB ID, или IP-адрес сеанса с PDP-контекстом, или NSAPI, для соответствующего сеанса, посланного UT 240 в AP1 265 на этапе 6060.

На этапе 6090 AP1 265 принимает решение, посылать или не посылать IAPP-ADD.Notify пакет, в зависимости от его предварительной конфигурации. Как очевидно специалисту в данной области техники, вместо IAAP-ADD.Notify пакета можно использовать соответствующее сообщение согласно другому протоколу, например сообщение согласно LWAPP. Этот IAAP-ADD.Notify пакет не обязательно посылается API 265, и этап 6090 может быть опущен, то есть способ согласно изобретению после этапа 6080 может сразу перейти на этап 6100. В случае если AP1 265 предварительно сконфигурирован таким образом, чтобы послать IAPP-ADD NOTIFY пакет, этот пакет обычно посылают в виде UDP/IP пакета согласно IAPP-протоколу и возможностям мобильности IEEE 802-стандарта для того, чтобы известить другие AP, соединенные с RNC1 230, о новой ассоциации UT 240 с (новым целевым) AP1 265. Это проиллюстрировано этапом 9 передачи на фиг.7B. IAPP пакет обычно содержит WLAN MAC-адрес UT 240 и номер последовательности, который указывает обычным способом на валидность пакета. Многоадресный IP-адрес предпочтительно следует выбирать таким образом, чтобы IAPP пакет принимали только RNC1 230 и другие AP, которые расположены географически близко к посылающему AP1 265. Это делается для того, чтобы уменьшить сигнализацию в пределах WLAN-домена. Следовательно, промежуточный М-L2S1 262 предпочтительно заранее сконфигурирован соответствующим образом, то есть он имеет сохраненный список IP-адресов для многоадресной рассылки принятого IAPP-ADD.Notify-пакета. Главной целью этапа 6090 является информировать AP в сети уровня 2 (то есть WLAN), которая действительно выбирается AP для связи с UT 240 таким образом, чтобы можно было правильно выполнить хэндовер радиосвязи из одного AP на другой AP. Этап 6090 является частью обычного RRM (управления радиоресурсами) L2-RN. IAPP-ADD.Notify пакет также может содержать согласно изобретению обычные параметры управления WLAN радиоресурсами, такие как, например, текущая загрузка соты, сила сигнала и так далее, для установленного WLAN радиоканала между UT 240 и API 265. Это может быть выполнено путем добавления указанных WLAN RRM-параметров в определенный контекстный контейнер в IAPP-ADD.Notify-пакете, как это очевидно специалисту в данной области техники. Таким образом, для всей RAT-сети может быть обеспечена еще более эффективная/универсальная MRRM-производительность. IAPP-ADD.Notify-пакет согласно изобретению также содержит указанный идентификатор сеанса с PDP-контекстом, например, RB ID или RAB ID для соответствующего сеанса, посланный из UT 240 в AP1 265 на этапе 6060. Таким образом, в одном из альтернативных вариантов осуществления из этапа 6080 способ переходит непосредственно на этап 6100, и никакой IAPP-ADD.NOTIFY-пакет не посылается.

На этапе 6100 в случае, если UT 240 заранее конфигурируется таким образом, чтобы не посылать сообщение о возможностях на этапе 6010, MRRM-объект UT 240 формирует и передает сообщение о возможностях, как описано выше, или по UTRAN-пути или, в качестве альтернативы, по WLAN-части, и MRRM-объект RNC1 230 принимает это сообщение о возможностях, извлекает соответствующие параметры и создает соответствующие ассоциации, как описано выше. Однако другая возможность, в случае если в этой точке не посылается никакое сообщение о возможностях, заключается в том, что сообщение о линии радиосвязи, посланное из UT 240 в AP1 265 на этапе 6060, также может содержать идентификатор сеанса с PDP-контекстом, например 3GPP RB ID 1 или 3GPP RAB ID 1, для соответствующего сеанса, и этот идентификатор сеанса направляют в RNC1 230, например, с обновленным кадром уровня 2 в RNC1 230, или с указанным IAPP-ADD.Notify-пакетом, как описано на этапах 6060, 6070, 6080 и 6090 выше, и, следовательно, MRRM-объект RNC1 230 может интерпретировать этот принятый обновленный кадр уровня 2 или IAPP-ADD.Notify-пакет, описанный на этапе 6090, как сообщение о возможностях. Другая возможность заключается в том, что MRRM-объект UT 240 формирует сообщение о возможностях, содержащее альтернативный сетевой адрес UT (сетевой адрес), то есть WLAN-адрес UT 240 в этом случае, идентификатор сеанса для определенного сеанса с PDP-контекстом в запросе, то есть 3GPP RB ID 1 или 3GPP RAB ID 1 или IP-адрес сеанса с PDP-контекстом или его ассоциированный NSAPI, и передает это сообщение о возможностях в RNC1 230 по UTRAN-пути, например, при использовании DCCH или по WLAN-пути, преобразуя указанное сообщение о возможностях в формат LLC 802.2-кадра и проводя многоадресную рассылку указанного LLC 802.2-кадра в AP1 265. В качестве альтернативы, указанное сообщение о возможностях (кадр LLC) посылают в RNC1 230 в виде специализированного сообщения в случае, если MAC-адрес RNC известен UT 240 (например, был сигнализирован по UTRAN-пути). Затем MRRM-объект RNC1 230 принимает это сообщение о возможностях и ассоциирует альтернативный сетевой адрес, то есть WLAN-адрес UT 240, с определенным UT 240, с определенным идентификатором сеанса с PDP-контекстом, то есть 3GPP TEID 1, таким же способом, что и на этапе 6020 выше.

Кроме того, на этапе 6100 RNC1 230 и UT 240 создают альтернативный идентификатор маршрутизации, соответственно, в виде определенной идентичности WLAN радиоканала, предназначенной для определенного сеанса с PDP-контекстом, называемого здесь WLAN RB ID 1, как показано ниже в табл.4, и ассоциируют свои таблицы маршрутизации соответствующим образом. Таким образом, RNC1 230 ассоциирует этот WLAN RB ID 1 с альтернативным сетевым адресом, то есть WLAN MAC-адресом, UT 240 (содержащимся в L2-обновленном кадре, принятым в порте 372), а также ассоциирует WLAN RB ID 1 с портом 372. Аналогично UT 240 ассоциирует свой WLAN RB ID 1 с сеансом с PDP-контекстом и своим WLAN портом 242. Таким образом, ROUTING-объект RNC1 230 ассоциирует соответствующий сеанс с PDP-контекстом (то есть сеанс 1) с указанным альтернативным сетевым адресом (WLAN MAC-адресом UT 240), указанным альтернативным идентификатором маршрутизации, то есть WLAN RB ID 1, и портом 372, обновляя свою таблицу маршрутизации, как показано в табл.4. Таким образом, альтернативный идентификатор маршрутизации определяется согласно стандартной схеме протокола маршрутизации, указанной альтернативной сети доступа, то есть в этом случае WLAN. В качестве альтернативы, из UT 240 в RNC1 230 может быть сообщен альтернативный идентификатор маршрутизации. Так как альтернативный идентификатор маршрутизации создается согласно тем же самым критериям, например, относительно QoS параметров, формирующих входные значения в такой же схеме управления "альтернативной^" маршрутизацией и сеансом, то есть WLAN-схеме, альтернативный идентификатор маршрутизации в RNC1 230 идентичен таковому в UT 240.

Однако на этапе 6100 RNC1 230 продолжает маршрутизировать пользовательские данные сеанса с PDP-контекстом по UTRAN-пути, то есть через порт 273, продолжая связывать TEID-сеанс с PDP-контекстом с UTRAN (3GPP) RAB ID и (3GPP) RAB ID с (3GPP) RB ID. Таким образом, TEID связывается с 3GPP RB ID. Затем способ переходит на этап 6110.

На этапе 6110 MRRM-объект UT 240 посылает или не посылает сообщение об ассоциации в RNC1 230 в зависимости от своей предварительной конфигурации. Сообщение об ассоциации информирует RNC1 230 о том, что UT 240 установил радиосоединение с WLAN и что теперь физически возможен хэндовер сеанса с PDP-контекстом из UTRAN-пути на WLAN-путь. Одна из возможностей, например, в случае если сообщение о возможностях было послано на этапе 6100 по WLAN-пути, заключается в том, что это сообщение о возможностях также функционирует, поскольку посылаются сообщение об ассоциации и сообщение об отсутствии "дальнейшей" ассоциации, и затем способ переходит сразу на этап 6140. В качестве альтернативы, вышеописанное сообщение "Кандидат для хэндовера" также может функционировать как сообщение об ассоциации, например, в случае, если это сообщение "Кандидат для хэндовера" передается после того, как UT 240 физически ассоциируется с AP1 265 (то есть после приема сообщения “Ответ на ассоциацию” от AP1 265). Согласно изобретению важным является то, что MRRM-объекту RNC1 230 сообщают, что UT 240 имеет установленное радиосоединение с AP1 265. Существуют много возможностей и сообщение о возможностях, сообщение "Кандидат для хэндовера", и сообщение об ассоциации являются до некоторой степени взаимозаменяемыми, как это является очевидным специалисту в данной области техники. В случае если MRRM-объект UT 240 конфигурируют таким образом, чтобы на данном этапе сформировать и послать сообщение об ассоциации, способ переходит на этап 6120.

На этапе 6120 MRRM-объект UT 240 формирует сообщение об ассоциации, содержащее альтернативный сетевой адрес UT, то есть в этом случае WLAN-адрес, и обычно также идентификатор сеанса для определенного сеанса с PDP-контекстом, то есть в этом случае 3GPP RAB ID 1 или RB ID 1, обычно также наряду с некоторой информацией, заявляющей, что UT 240 установил радиосоединение с WLAN, например "идентификатор установки радиосоединения", и посылает это сообщение об ассоциации в RNC1 230 по UTRAN-пути, например, в виде RRC-сообщения, используя DCCH, или по WLAN в виде сообщения кадра многоадресной рассылки, или в случае, если MAC-адрес RNC известен UT 240, например, был сигнализирован по UTRAN-пути из RNC1 230 на более раннем этапе, сообщение об ассоциации можно послать по WLAN в виде специализированного L2-сообщения, имеющего MAC-адрес RNC в виде адреса назначения. В случае если сообщение об ассоциации посылают по WLAN-пути, сообщение об ассоциации обычно не содержит указанный "идентификатор установки радиосоединения". Существует много возможностей того, как сформировать и объединить сообщение о возможностях, сообщение “Кандидат для хэндовера” и сообщение об ассоциации. Например, в случае, если сообщение об ассоциации также содержит идентификатор определенного сеанса, сообщение об ассоциации может также функционировать как сообщение о возможностях, и способ согласно изобретению не требует, чтобы UT 240 посылал любое определенное сообщение о возможностях в RNC1 230. Таким образом, эти сообщения являются до некоторой степени взаимозаменяемыми согласно изобретению, как уже было сказано. Кроме того, сообщение об ассоциации может быть послано UT 240 по UTRAN-пути, например, сразу после приема сообщения “Ответ на ассоциацию” из AP1 265 на этапе 6060, но существует много возможностей. Как указано выше, сообщение об ассоциации обычно содержит информацию, которая уникальным образом идентифицирует определенный сеанс с PDP-контекстом. Таким образом, UT 240 может управлять тем сеансом/сеансами с PDP-контекстом среди набора активных сеанс/сеансов с PDP-контекстом, для которого хэндовер может быть желательным.

На этапе 6130 RNC1 230 принимает указанное сообщение об ассоциации, извлекает альтернативный сетевой адрес UT 240 и возможно также "идентификатор установки радиосоединения" в случае, если сообщение об ассоциации содержит такой идентификатор, и обновляет свою таблицу маршрутизации соответствующим образом, устанавливая альтернативный идентификатор маршрутизации, то есть в этом случае WLAN RB ID 1, для того, чтобы стать фактическим активным кандидатом связывания для идентификатора сеанса, то есть TEID 1, чтобы связать. Это означает, что RNC1 230 из этой точки может маршрутизировать сеанс с PDP-контекстом через UTRAN-радиоинтерфейс, то есть через порт 273, путем связывания идентификатора сеанса, то есть TEID, сеанса с PDP-контекстом с первым идентификатором маршрутизации, то есть в этом случае (3GPP) RB ID, или маршрутизировать сеанс с PDP-контекстом через WLAN-радиоинтерфейс, то есть через порт 272, путем связывания идентификатора сеанса, то есть в этом случае TEID 1, сеанса с PDP-контекстом с альтернативным идентификатором маршрутизации, то есть в этом случае WLAN RB ID 1. В случае если сообщение об ассоциации уникальным образом идентифицирует определенный сеанс среди ряда активных PDP-сеансов для UT 240, RNC1 230 обновляет только определенный альтернативный идентификатор маршрутизации, то есть в этом случае WLAN RB ID 1, для того чтобы стать фактическим активным кандидатом связывания для идентификатора сеанса, чтобы связать. В случае если сообщение об ассоциации не идентифицирует определенный сеанс, то есть оно содержит только альтернативный сетевой адрес UT 240, наряду с информационным элементом, заявляющим, что UT 240 установил радиосоединение с WLAN, то RNC1 230 обычно обновляет все альтернативные идентификаторы маршрутизации для всех PDP-сессий, ассоциированных с UT 240 для того, чтобы стать фактическими активными кандидатами связывания для всех сеансов. В одном из вариантов осуществления, например, в случае, если RNC1 230 принял сообщение о возможностях, уникальным образом идентифицирующее определенный сеанс с PDP-контекстом, то в сообщении об ассоциации может быть опущен "идентификатор установки радиосоединения", и RNC1 230 автоматически интерпретирует сообщение об ассоциации, поскольку это представляет собой второй случай, когда RNC1 230 принимает альтернативный сетевой адрес UT 240. Затем способ переходит на этап 6140.

Таким образом, на этапе 6140 RNC1 230 выполнен с возможностью маршрутизировать сеанс с PDP-контекстом UT 240 по UTRAN-пути, то есть через порт 273, путем связывания идентификатора сеанса, то есть TEID-сеанса, с PDP-контекстом с первым идентификатором маршрутизации, то есть в этом случае (3GPP) RB ID, или маршрутом сеанса с PDP-контекстом по WLAN-пути, то есть через порт 272, путем связывания идентификатора сеанса, то есть в этом случае TEID 1, сеанса с PDP-контекстом с альтернативным идентификатором маршрутизации, то есть в этом случае RB ID 1 WLAN. На этапе 6140 принимают решение о переключении маршрутизации указанного сеанса с PDP-контекстом из указанного пути сети сотовой радиосвязи (UTRAN-путь) через узел B 250 и порты 273 и 241 на указанный альтернативный путь сети передачи данных (WLAN-путь), через порты 372 и 242. Согласно изобретению это решение может быть принято MRRM-объектом UT 240 или MRRM-объектом RNC1 230 на основе различной RRM-информации. Точный критерий/критерии для этого решения не подчинен настоящему изобретению, как уже было сказано. MRRM-объект RNC1 230 может, например, принять RRM (управление радиоресурсами) сообщение/сообщения, содержащие информацию относительно, например, загрузки соты, качества радиоканала, BER, FER из AP1 265 при помощи обычного протокола управления радиоресурсами WLAN, то есть IAPP-протокола. AP1 265 собирает эту RRM-информацию посредством установленного обычного APME приложения и обычного STAME объединяющего приложения, установленного в UT 240, как показано на фиг.4. Стандарт IEEE 802.11k сигнализации может использоваться, чтобы сообщить радио/сотовую RRM-информацию AP 265, например, о загрузке канала, загрузке трафика, статистике успешных передач, качестве WLAN канала и так далее для IEEE 802.11 WLAN в RNC1 230. Как обсуждалось выше в отношении этапа 6090, IAPP-ADD.Notify пакет может содержать параметры управления радиоресурсами, такие как загрузка соты, сила сигнала, доступные скорости передачи данных и так далее, WLAN соединения. В качестве альтернативы, UT-MRRM-объект UT 240 выполняет измерения относительно качества линии радиосвязи как для UTRАN-линии, так и для WLAN линии и передает сообщение об измерении (RRC-сообщение) в MRRM-объект RNC1 230, например, по восходящей линии связи DCCH, например, используя обычный UTRAN RLC-протокол, или по WLAN-пути, используя LLC/WLAN-MAC-протокол, если UT 240 известен MAC-адрес RNC1, то есть как это было сообщено ранее, или посредством UDP/IP. Сообщение об измерении может содержать значения параметров относительно силы сигнала, QoS, BER, FER, уровня помех, скорости UT 240 и так далее для UTRAN линии/линий радиосвязи и/или WLAN линии/линий радиосвязи. На этапе 6140 MRRM-объект RNC1 230 может принять решение о выполнении эстафетной передачи из UTRAN-пути маршрутизации на WLAN-путь маршрутизации, например, если в текущий момент времени WLAN предлагает лучший/более высокий уровень QoS, чем UTRAN, или если уровень загрузки трафика UTRAN-сети превышает определенное пороговое значение, или может принять решение о сохранении UTRAN-пути маршрутизации, например, потому что скорость UT 240 слишком высока, но существуют много возможностей. В качестве альтернативы, MRRM-объект UT 240 принимает решение о переключении маршрутизации сеанса с PDP-контекстом на WLAN-путь маршрутизации, например, на основании указанного измеренного значения MRRM параметра и/или информации управления радиоресурсами, принятой от AP1 265, сигнализированной при помощи STAME-APME объединяющих приложений, показанных на фиг.4. Затем UT 240 сигнализирует это решение о хэндовере MRRM-объекту RNC1 230, например, в виде RRC-сообщения. В одном из альтернативных вариантов осуществления WLAN, всегда предпочитается путь маршрутизации сеанса с PDP-контекстом из-за измерения параметров, то есть стоимости/минуты или переданных Кбит. Таким образом, изобретение обеспечивает возможность разработки полностью новых и более эффективных функциональных возможностей MRRM, которые учитывают как UTRAN, так и другой интегрированный L2-RN, поскольку MRRM-объекты RNC1 230 и/или UT 240 имеют доступ и к UTRAN, и к WLAN RRM-информации. В качестве альтернативы, изобретение обеспечивает возможность обеспечения функциональных возможностей MRRM в AP1 265 или распределенных функциональных возможностей MRRM, то есть различные MRRM-задачи выполняются в различных узлах в RAT-сети. Обычно MRRM RNC1 230 принимает такие решения о хэндовере, которые дают определенные преимущества, описанные выше.

Согласно способу изобретения способ остается на этапе 6140 до тех пор, пока не будет принято решение о выполнении хэндовера сеанса с PDP-контекстом на WLAN-путь маршрутизации конкретным MRRM-объектом в сети (обычно MRRM RNC1 230), то есть пока не будет выполнен критерий RAT хэндовера указанного MRRM-объекта, и затем переходит на этап 6145.

На этапе 6145 MRRM-объект, который принял решение о хэндовере на этапе 6140, информирует MRRM-объект RNC1 230 об этом решении о хэндовере, например, сигнализированном по UTRAN или WLAN-пути. Затем MRRM-объект RNC1 230 принимает это решение о хэндовере и посылает в UT 240 сообщение "Переконфигурация физического канала", что проиллюстрировано этапом 9A передачи на фиг.7B, которое информирует UT 240 о решении о хэндовере, и что с этого момента UT 240 должен активно прислушиваться к пакетам сеанса, передаваемым по нисходящей линии связи также от AP1 265. Это сообщение обычно реализуется при помощи RRC/RLC-протокола и посылается по BCCH в UT 240 через узел-B 250. Например, 3GPP-сообщение “Переконфигурация физического канала" может использоваться путем добавления информационных элементов для идентификации узла/узлов радиодоступа, определенных согласно альтернативному протоколу сети доступа, например, в данном случае WLAN MAC-адрес AP1 265 также может использоваться как информационный элемент. Однако на данном этапе это сообщение также может быть послано по WLAN-пути, как это очевидно специалисту в данной области техники.

На этапе 6147 UT 240 информирует RNC1 230, что решение о хэндовере принято UT 240 и что UT 240 ассоциирован с AP1 265, посылая сообщение "Подтверждение хэндовера", проиллюстрированное этапом 9B передачи на фиг.7B. Это сообщение содержит:

- идентификатор типа сообщения, идентифицирующий указанное сообщение, как являющееся сообщением "Подтверждение хэндовера",

- информационный элемент диссоциации и сетевой адрес точки радиодоступа, в этом случае узел-B (250), с которым UT (240) больше не ассоциирован для маршрутизации сеанса, и,

- информационный элемент подтверждения хэндовера, наряду с сетевым адресом целевой точки радиодоступа, в этом случае AP1 (265), с которым UT (240) в текущий момент времени ассоциирован для маршрутизации сеанса. Сообщение "Подтверждение хэндовера" может, например, быть реализовано посредством 3GPP RRC-сообщения "Отчет об измерении", в котором информация, указывающая AP1 (265) в качестве новой точки доступа, может содержаться в информационном элементе "Дополнительные измеренные результаты". Цель этого сообщения "Подтверждение хэндовера" заключается в том, чтобы информировать RNC1 230 о том, что он в данный момент времени должен маршрутизировать пакеты, передаваемые по нисходящей линии связи, только через узел доступа, предназначенный для хэндовера, и может быть предпочтительным послать это сообщение на более позднем этапе, например после этапа 12 передачи на фиг.7B, чтобы обеспечить возможность для "мягкого хэндовера". Затем способ переходит на этап 6150.

Затем на этапе 6150 MRRM-объект RNC1 230 запускает хэндовер сеанса с PDP-контекстом из указанного пути сети сотовой радиосвязи (UTRAN) на указанный путь маршрутизации WLAN, то есть переключает передачу на уровне пользователя из UTRAN-пути на WLAN-путь, инструктируя ROUTING-объект RNC1 230 о формировании в настоящий момент времени связи идентификатора сеанса с PDP-контекстом, TEID 1, с альтернативной идентичностью радиоканала, то есть в этом случае WLAN RB ID 1, вместо обычного 3GPP RB ID, в табл.4, таким образом начиная маршрутизацию IP-пакетов по нисходящей линии связи PDP-сеанса в виде инкапсулированных IEEE LLC 802.2-пакетов по WLAN-пути маршрутизации через порт 272, вместо UTRAN-пути через порт 273. Переключение передачи крайне важно для IP-пакетов, передаваемых по нисходящей линии связи, принятых RNC1 230 из SGSN 220 по соответствующему GTP-U-туннелю передачи. При обычной передаче на уровне пользователя RNC декапсулирует IP-пакеты из GTP-U PDU и капсулирует их в PDCP до передачи по UTRAN каналам. Изобретение позволяет бесшовную передачу, переключающуюся без потери данных при наличии ROUTING-объекта RNC1 230, выполняющего следующие этапы:

1. Все IP-пакеты, передаваемые по нисходящей линии связи, которые уже инкапсулированы и кешированы как PDCP-пакеты, перед принятием решения о хендовере между RAT (технология радиодоступа), передаются в UT 240 с использованием UTRAN-пути. Такие IP-пакеты могут быть кешированы в RNC1 230, поскольку они ожидают своей передачи или были переданы в UT 240, но еще не подтверждены. При условии, что RNC1 230 принимает IP-пакеты, передаваемые по восходящей линии связи из UT 240 по своему UTRAN-пути маршрутизации, RLC-объект RNC 230 подтверждает прием пакетов, используя UTRAN-путь (в случае использования режима RLC-подтверждения).

2. В случае если услуга RLC-режима подтверждения сконфигурирована в PDP-контексте для передачи на уровне пользователя, установка LLC-соединения обычно сначала выполняется между LLC-объектами в RNC1 230 и UT 240, чтобы позволить подтвержденные передачи LLC-кадров типа 2. Это обычно осуществляется предоставлением возможности RNC1 230 послать в UT 240 кадр с сообщением об установке LLC-связи перед передачей первых (по нисходящей линии связи) PDP-IP-пакетов в виде Ethernet 802.3-кадров, используя услугу LLC-соединения типа 2 (режим подтверждения).

3. Все IP-пакеты, передаваемые по нисходящей линии связи, декапсулированные из GTP-U PDU после принятия решения о хэндовере между RAT на этапе 6140, инкапсулируют в виде LLC/Ethernet-кадров с WLAN MAC-адресом UT 240 в качестве адреса назначения и MAC-адресом RNC1 230 в качестве исходного адреса. Затем эти кадры посылают через (Ethernet) порт 372 RNC1 230 в UT 240, обычно через один или несколько М-L2S и через WLAN AP1 265.

LLC/Ethernet-кадры, передаваемые по нисходящей линии связи, созданные в (ROUTING-объекте) RNC1 230 на этапе 6150, затем передаются в порт 372 RNC1 230 в М-L2S1 262, как проиллюстрировано этапом 10 передачи на фиг.7B. Они представляют собой LLC/Ethernet 802.3-кадры, содержащие PDP IP-пакеты, передаваемые по нисходящей линии связи. Поскольку М-L2S1 262 и AP1 265 обновили свои таблицы переадресации в этой точке, эти Ethernet кадры, передаваемые по нисходящей линии связи, маршрутизированы точно по WLAN в направлении UT 240 на этапе 6150, как проиллюстрировано этапами 11 и 12 передачи на фиг.7B. ROUTING-объект RNC1 230 может добавить идентификатор сеанса для определенного сеанса, например, в этом случае WLAN RB ID 1 или 3GPP ID 1 RB, в LLC-кадрах до инкапсулирования пакетов, передаваемых по нисходящей линии связи, в виде LLC/Ethernet-кадров. Это обеспечивает возможность для ROUTING-объекта UT 240 уникально идентифицировать определенный PDP-сеанс, к которому относятся LLC PDP IP-пакеты, передаваемые по нисходящей линии связи, при их получении по WLAN-пути маршрутизации через порт 242.

На этапе 6160 М-L2S1 262 направляет в UT 240 принятые по нисходящей линии связи LLC/Ethernet 802.3-кадры, то есть в AP1 265. AP1 265 преобразует IEEE 802.3-кадры, передаваемые по нисходящей линии связи, в обычные IEEE 802.11 кадры и передает их в UT 240.

На этапе 6170 UT 240 переключает путь маршрутизации указанного сеанса с PDP-контекстом из UTRAN-пути маршрутизации на альтернативный WLAN-путь маршрутизации после приема альтернативного исходного сетевого адреса RNC1 230, NSA, то есть в этом случае WLAN MAC-адрес RNC1 230. Например, UT 240 может извлечь указанный NSA из указанного LLC-кадра установки соединения или из принятого первым IP-пакета, передаваемого по LLC 802.2 PDP нисходящей линии связи, из RNC1 230. В качестве альтернативы, MAC-адрес RNC1 230 сигнализируют в UT 240 на более раннем этапе. Затем ROUTING-объект UT 240 обновляет свою таблицу маршрутизации путем связывания идентификатора/идентификаторов сеанса с NSA RNC1, то есть в этом случае WLAN MAC-адрес RNC1 230. В случае если UT 240 выполняет указанный хэндовер пути маршрутизации после приема первых PDP-IP-пакетов, UT 240 декапсулирует принятые IP-PDP-пакеты, передаваемые по нисходящей линии связи, из LLC/802.11-кадров и идентифицирует, что WLAN-путь передачи успешно установлен, поскольку он может принять PDP-пользовательские данные через его WLAN-интерфейс. Затем UT 240 обновляет свою таблицу маршрутизации соответствующим образом путем связывания соответствующего идентификатора сеанса с PDP-контекстом, то есть 3GPP RAB ID 1, с WLAN RB ID 1 таким же способом, как описано для RNC1 230.

Таблица 5
PDP- сеанс	3GPP RB ID	3GPP RAB ID	NSAPI	NSA для RNC	ID WLAN радиоканала	Приложение
Сеанс 1	RB ID 1	RAB ID 1	NSAPI 1	MAC-адрес RNC	WLAN RB ID 1	Веб-браузер
Сеанс 2	RB ID 2	RAB ID 2	NSAPI 2			Электронная почта
Сеанс N	RB ID N	RAB ID N	NSAPI N			Мультимедийная загрузка

UT 240 выполняет указанный хэндовер пути маршрутизации после приема первых PDP-IP-пакетов. UT 240 декапсулирует принятые IP-PDP-пакеты, передаваемые по нисходящей линии связи, из LLC/802.11-кадров и идентифицирует, что WLAN-путь передачи установлен успешно, поскольку он может принимать PDP-пользовательские данные через его WLAN-интерфейс. Затем UT 240 обновляет свою таблицу маршрутизации, то есть табл.5, соответствующим образом путем связывания соответствующего идентификатора сеанса с PDP-контекстом, то есть 3GPP RAB ID 1, с WLAN RB ID 1. Таким образом, UT 240 заканчивает свою передачу по восходящей линии связи через свой UTRAN порт передачи 241 и начинает передавать последующие IP PDP-пакеты, передаваемые по восходящей линии связи, через свой WLAN порт 242 в виде LLC/Ethernet 802.11-кадров в AP 265. Более конкретно, коммутатор передачи на уровне пользователя в UT 240 обычно содержит следующие этапы, выполняемые ROUTING-объектом приложения в UT 240, на которых:

1. Как уже выполнялось RNC1 230 для IP-пакетов, передаваемых по нисходящей линии связи, все IP-пакеты, передаваемые по восходящей линии связи, которые были инкапсулированы и кешированы в виде PDCP пакетов в UT 240 до принятия решения о переключении передачи между RAT, передаются в RNC1 230 путем использования UTRAN-пути, то есть путем использования выделенных UTRAN радиоканалов/каналов. Такие IP-пакеты могут быть кешированы, поскольку они ожидают своей передачи или уже были переданы в RNC1, но еще не подтверждены. При условии, что UT 240 принимает IP-пакеты, передаваемые по нисходящей линии связи, из RNC1 230 по своему UTRAN-пути передачи, RLC-объект UT 240 подтверждает прием пакетов, также используя UTRAN-путь (в случае использования RLC-режима подтверждения).

2. Как указывалось в поле DSAP (пункт назначения) LLC-кадров, принятых через ее WLAN-интерфейс, извлеченная полезная нагрузка, то есть PDP-IP-пакеты, передаваемые по нисходящей линии связи, должна быть направлена в вышележащий IP-уровень в UT 240.

3. После приема первого IP-пакета, передаваемого по нисходящей линии связи, через его WLAN-порт 242, ROUTING-объект UT 240 связывает идентификатор сеанса передачи данных, то есть 3GPP RAB ID 1, с альтернативным идентификатором маршрутизации, то есть WLAN RB ID 1, что означает, что он прекращает инкапсулировать PDP IP-пакеты, передаваемые по восходящей линии связи, с PDCP и вместо их инкапсуляции в виде LLC/802.11-кадров использует WLAN MAC-адрес UT 240 в качестве исходного адреса и WLAN MAC-адрес RNC1 230 в качестве адреса назначения. Затем эти кадры посылают через WLAN-интерфейс через порт 242 в AP1 265, как проиллюстрировано этапом 13 передачи на фиг.7B.

На этапе 6180 AP1 265 преобразует IEEE 802.11 кадры, передаваемые по восходящей линии связи, из UT 240 в IEEE 802.2 кадры и посылает их в М-L2S1 262. Затем М-L2S1 262 направляет эти IEEE 802.2-кадры в RNC1 230, проиллюстрированные этапами 14 и 15 передачи на фиг.7B.

На этапе 6190 ROUTING-объект RNC1 230 извлекает PDP IP-пакеты из принятых IEEE 802.2 LLC/Ethernet-кадров, преобразует их в обычные кадры PDP IP-пакетов, инкапсулирует и направляет в соответствующий GTP-U-объект для дальнейшей GTP-U инкапсуляции и передачи по GTP-U-туннелю в направлении UMTS PS (Переключенный Пакет)-домена. Идентификация конкретного GTP-U-объекта и туннеля производится при помощи отношения "один-к-одному" между WLAN MAC-адресом UT (указанным в качестве исходного адреса Ethernet кадров, передаваемых по восходящей линии связи), WLAN RB ID 1 и TEID 1, установленных для рассматриваемого PDP-контекста, как описано выше. Таким образом, в этой точке теперь закончен хэндовер сеанса с PDP-контекстом по восходящей и нисходящей линиям связи из UTRAN-пути маршрутизации через узел-B 250 на WLAN-путь маршрутизации через AP1 265, как проиллюстрировано этапом 16 передачи на фиг.7B.

Необходимо отметить, что инкапсулирование IP-пакетов с GTP-U между RNC1 230 и SGSN 220, так же как между SGSN 220 и GGSN 210, остается неизменным во время всего хэндовера между RAT и впоследствии. Также не происходит никакого изменения IP-адресов PDP IP-пакетов. Это является преимущественным для обеспечения непрерывности сеанса с удаленного хоста или однорангового узла Интернет и устраняет задержку, вызванную DHCP (протоколом динамической конфигурации хоста) для назначения нового IP-адреса.

Таким образом, на данном этапе RNC1 230 выполнен с возможностью маршрутизировать указанный сеанс по первому пути сети радиодоступа через его первый порт (273) согласно 3GPP UTRAN-протоколу путем связывания идентификатора сеанса, однозначно идентифицирующего указанный сеанс, то есть в этом случае TEID1, с радиоканалом (то есть 3GPP RB ID) согласно 3GPP UTRAN-протоколу, и указанный RNC1 230 дополнительно выполнен с возможностью маршрутизировать указанный сеанс по альтернативному пути сети радиодоступа (то есть WLAN-пути) через второй порт (272) путем связывания указанного идентификатора сеанса с альтернативным идентификатором канала (WLAN RB ID 1), определяемым согласно IEEE 802.2-стандарту.

Затем способ переходит на этап 6200 или, в качестве альтернативы, непосредственно на этап 6220 в зависимости от предварительной конфигурации UT 240/RNC1 230, и ниже объяснены другие случаи.

На этапе 6200 отменяют UTRAN канал радиотрафика, ассоциированный с указанным сеансом. Это инициируется MRRM-объектом RNC1, который переключает объект назначения канала, чтобы отменить указанный канал трафика. Это разгружает UTRAN и предоставляет выгодное решение, в котором информация на уровне управления сигнализируется через узел-B 250, который, как правило, имеет большую зону покрытия, чем AP1 265, в то время как данные на уровне пользователя сеанса одновременно маршрутизируются через (горячую точку) AP1 265, которая открыта для более гибкого и эффективного назначения радиоресурсов для всей сети RAT. Затем способ переходит на этап 6210.

На этапе 6210 выделенный UTRAN канал/каналы управления (DCCH), назначенные для UT 240, отменяются и UT 240 входит в так называемый режим ожидания, в котором UT 240 прослушивает только новые входящие вызовы, а UTRAN обновляет обычным способом только информацию роуминга, ассоциированную с UT 240. Это может быть выгодным, например, для того, чтобы дополнительно разгрузить UTRAN и/или для случая, когда имеется большое количество радиоресурсов высокого качества, доступных через WLAN-путь (исследованный и установленный, например, MRRM-объектом UT 240). Это обеспечивает возможность для еще более гибкого и эффективного назначения радиоресурсов для всей сети RAT. Затем данные на уровне управления, ассоциированные с PDP-сеансом, наряду с другой (M)RRC-информацией (отчеты об измерении и так далее), маршрутизируют по WLAN-пути при помощи описанного выше IAPP-протокола, наряду с STAME и APME-объектами в UT 240 и AP1 265. Вместо IAAP-протокола может использоваться вышеописанный LWAPP.

На этапе 6220 сеанс маршрутизируют таким образом по WLAN-пути, в котором сигнализация на уровне управления, ассоциированная с сеансом, и/или RRM-сообщение сигнализируется по UTRAN-пути обычным способом и/или WLAN-пути, например, при помощи отчетов об измерении сигнализации согласно IEEE 802.11k-стандарту между UT 240 и AP1 265 и при помощи IAPP/LWAP-протокола между AP1 265 и RNC1 230. Это позволяет более гибкие функциональные возможности для сети с множеством RRM.

Ниже описаны различные типы сценариев хэндовера между RNC в результате роуминга UT 240 в "зоне покрытия" RNC2 231.

В общем случае, в зависимости от зоны покрытия AP1 (265) и узла-B, ассоциированного с RNC1 (230), и AP2 (266) и узла-B (251), ассоциированного с RNC2 (231), возможны четыре основных типа хэндовера в случае, если UT 240 перемещается в "зону покрытия" RNC2 231:

1. И сеанс, и информация на уровне управления в текущий момент времени маршрутизируются/сигнализируются через AP1 (265), ассоциированный с RNC1 (230), и в определенной точке сигнал маяка UTRAN узла-B (251), ассоциированного с RNC2 (231), становится более сильным, чем сигнал маяка AP1 (265), и могут быть желательными хэндовер сеанса и хэндовер на уровне управления из WLAN-пути, ассоциированного с AP1 (265), на UTRAN-путь, ассоциированный с узлом-B (251) RNC2 (231), называемый здесь хэндовером типа 1.

2. Сеанс в текущий момент времени маршрутизируют через AP1 (265), и информация на уровне управления, ассоциированная с сеансом, в текущий момент времени сигнализируется через узел-B (250), ассоциированный с RNC1 (230), и, в определенной точке сигнал маяка узла-B (251), ассоциированный с RNC2 (231), становится более сильным, чем сигнал маяка узла-B (250), ассоциированный с RNC1 (230), и может быть желательным хэндовер на уровне управления из UTRAN-пути, ассоциированного с узлом-B (250) RNC1 (230), на UTRAN-путь, ассоциированный с узлом-B (251) RNC2 (231), называемый хэндовером типа 2.

3. Сеанс в текущий момент времени маршрутизируют через AP1 (265) и информацию на уровне управления, ассоциированную с сеансом, в текущий момент времени сигнализируют через узел-B (250), ассоциированный с RNC1 (230), и в определенной точке сигнал маяка AP2 (266), ассоциированный с RNC2 (231), становится более сильным, чем сигнал маяка AP1 (265), ассоциированный с RNC1 (230), и может быть желательным хэндовер сеанса из WLAN-пути, ассоциированного с AP1 (265) и RNC1 (230), на WLAN-путь, ассоциированный с AP2 (266) и RNC2 (231), называемый хэндовером типа 3. Обычно сигнализацию на уровне управления продолжают маршрутизировать через узел-B 250, но существуют другие возможности.

4. И сеанс, и информацию на уровне управления в текущий момент времени маршрутизируют/сигнализируют через AP1 (265), ассоциированный с RNC1 (230), и в определенной точке сигнал маяка AP2 (266), ассоциированный с RNC2 (231), становится более сильным, чем сигнал маяка AP1 (265), ассоциированный с RNC1 (230), и может быть желательным хэндовер сеанса на уровне управления из WLAN-пути, ассоциированного с AP1 (265) и RNC1 (230), на WLAN-путь, ассоциированный с AP2 (266) и RNC2 (231), называемый здесь хэндовером типа 4.

Затем из этапа 6220 способ переходит на этап 6230. На этапе 6230 UT 240 перемещается в зону покрытия AP2 266 и ассоциируется с AP2 266. Ассоциация с AP2 (266) аналогична ассоциации с AP1 (265), описанной выше на этапе 6060, и проиллюстрирована этапом 17 передачи на фиг.7C. Способ переходит на этап 6240.

На этапе 6240 WLAN MAC-адрес UT 240 регистрируют в RNC2 таким же образом, как регистрировали в RNC 230, как описано выше на этапах 6070, 6080 и 6090 и проиллюстрировано этапом 18 передачи на фиг.7C. Способ переходит на этап 6250.

На этапе 6250 UT 240 посылает в RNC1 230 или в RNC2 231 сообщение "Кандидат для хэндовера", причем RNC2 может направить его в RNC1 230. Как описано выше, главная цель этого сообщения заключается в том, чтобы информировать RNC1 230 об идентичности RNC2 231 для проведения хэндовера между RNC. Однако при отправке в RNC2 231 целью также является сообщить RNC2 231 о том, что UT 240 имеет сеанс, маршрутизируемый через другой RNC, и, возможно, идентичность этого RNC позволяет RNC2 230 “переключить” хэндовер (например, запрашивая хэндовер на основании различной MRRM-информации и устанавливая RNC Iur-туннель с RNC1 231 на более позднем этапе). Это обеспечивает гибкость функциональных возможностей MRRM-сети. RNC2 231 может просто направить это сообщение "Кандидат для хэндовера" в RNC1 230, причем в обычном случае RNC1 230 будет устанавливать туннель между RNC через Iur-интерфейс для маршрутизации сеанса на более позднем этапе, или в качестве альтернативы, в случае, когда сообщение "Кандидат для хэндовера" включает идентификатор, идентифицирующий RNC1 230, RNC2 может установить такой туннель между RNC через Iur-интерфейс, как уже было описано. Это сообщение “Кандидат для хэндовера” преимущественно содержит следующее:

- информационный элемент идентификатора типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Кандидат для хэндовера",

- идентификатор пользовательского терминала, ID UT, идентифицирующий указанный UT (240),

- идентификатор точки доступа, ID AP2, точки-кандидата AP2 (266) радиодоступа для хэндовера в случае хэндовера типа 4, или идентификатор узла-B, Node-B ID узла-В-кандидата (251), для хэндовера в случае хэндовера типа 2, или мобильный IP-адрес, MIP, или безопасный адрес MIP, MIPSec, UT (240), наряду с IP-адресом маршрутизатора доступа, AR (256), ассоциированным с RNC-кандидатом (231), и причины, которые описаны ниже,

- сетевой адрес указанного RNC-кандидата RNC2 231 в качестве исходного адреса указанного сообщения, таким образом идентифицируя RNC-кандидата (231) в случае, если это сообщение посылают из RNC2 231 в RNC1 230,

- сетевой адрес указанного RNC-кандидата (231), идентифицирующий RNC-кандидата (231), в случае, если UT 240 посылает это сообщение в RNC1 230 по UTRAN-пути через узел-B 250 или по WLAN-пути через AP1 265, причем сетевой адрес RNC2 231, возможно, был сигнализирован в UT 240 посредством АP2 265, и

- идентификатор точки доступа, ID AP1, точки AP1 (265) радиодоступа или идентификатор узла-B, Node-B ID узла-B (250), идентифицирующий точку доступа или узел B, через который в текущий момент времени маршрутизируется сеанс.

Сообщение "Кандидат для хэндовера" может быть реализовано, например, в виде 3GPP RRC-сообщения и послано из UT 240 в (MRRM-объект) RNC1 230 через узел-B 250, или в виде IAPP-сообщения, посланного из UT 240 в (MRRM-объект) RNC1 230/RNC2 231 через AP1 265/AP2 266, или в виде UDP/IP-сообщения более высокого уровня, в зависимости от типа хэндовера между RNC.

В случае, если сообщение "Кандидат для хэндовера" посылают в MRRM-объект RNC1 230, проиллюстрированный этапом 19 передачи на фиг.7C, RNC1 извлекает идентификатор, идентифицирующий AP2 266, обычно WLAN MAC-адрес AP2 266, или 3GPP-сетевой идентификатор, идентифицирующий узел-B 251, ассоциированный с RNC2 231. Затем MRRM-объект RNC1 230 проверяет просмотровую таблицу, связывающую идентификатор AP2 266 или узел-B 251 с идентичностью RNC2 231, и затем соответствующим образом обновляет свою таблицу маршрутизации, сохраняя идентичность RNC2 231, обычно IP-адрес или UTRAN MAC-адрес RNC2, в указанной таблице маршрутизации и ассоциируя ее с сеансом. Затем MRRM-объект RNC1 230 устанавливает, при наличии Iur-интерфейса между RNC1 230 и RNC2 231 или без проверки, указанную просмотровую таблицу.

В случае если сообщение "Кандидат для хэндовера" посылают в MRRM-объект RNC2 231, то есть по WLAN-пути, например, посредством IEEE 802.11-сообщения из UT 240 в AP2 266 и посредством IAPP/LWAP-протокола или в виде UDP/IP-сообщения из AP2 266 в RNC2 230, как правило, RNC2 230 просто преобразует это сообщение в подходящий 3GPP RRC-формат и направляет его всем соседним RNC через свой Iur-интерфейс, например, при помощи RNSAP (прикладной подсистемы сети радиосвязи)-протокола. Затем RNC1 230 сможет распознать, что этот сеанс в текущий момент времени маршрутизируют через RNC1 230 (поскольку это сообщение идентифицирует сеанс, например, путем включения WLAN MAC-адреса UT 240), и сможет направить ответ в RNC2 230, посылая сообщение "Запрос на установку линии радиосвязи", как описано ниже. В качестве альтернативы, RNC2 231 может извлечь идентификатор, идентифицирующий AP1 265, обычно WLAN MAC-адрес AP1 265, или 3GPP-сетевой идентификатор, идентифицирующий узел-B 250, ассоциированный с RNC1 230. Затем MRRM-объект RNC2 231 проверяет просмотровую таблицу, связывающую идентификатор AP1 265 или узел-B 250 с идентичностью RNC1 230, и таким образом делает вывод о том, что UT 240 имеет активный сеанс, маршрутизируемый через RNC1 230. В этом случае RNC2 230 посылает сообщение "Кандидат для хэндовера" в RNC1 230, содержащее сетевой идентификатор узла-кандидата для хэндовера, например WLAN MAC-адрес AP2 266. Существуют много возможностей. Затем способ переходит на этап 6260.

На этапе 6260 логическое соединение между UT 240 и RNC2 230 через узел-B 251 или через AP 266 устанавливают в зависимости от типа хэндовера. Установление логического соединения через узел-B 251 происходит обычным способом и не будет здесь описано. В случае установления IEEE WLAN LLC-логического соединения через AP2 266, проиллюстрированного этапом 20 передачи на фиг.7C, RNC2 231 действует как маршрутизатор доступа и устанавливает это соединение с UT 240, WLAN-адрес которого был принят на этапе 6240. IEEE WLAN LLC-установление аналогично вышеописанному IEEE LLC-установлению и содержит передачу L2-обновленных кадров и передачу APPI ADD Notify пакета из АP2 266 в RNC1 230 (как описано выше относительно этапов 7, 8 и 9 передачи). После этого установление логического LLC-соединения с UT (240) через AP2 (266) имеет определенный порт (277), ассоциированный с ним. В одном из вариантов осуществления RNC2 231 использует WLAN MAC-адрес RNC1 230 в качестве исходного адреса для этого WLAN LLC-соединения и таким образом UT 240 снова использует этот WLAN MAC-адрес RNC1 230 также для того, чтобы посылать пакеты, передаваемые по восходящей линии связи, через RNC2 231. В другом варианте осуществления RNC2 231 использует свой собственный WLAN MAC-адрес в качестве исходного адреса для этого WLAN LLC-соединения и таким образом UT 240 будет использовать этот WLAN MAC-адрес RNC2 231 для того, чтобы посылать пакеты, передаваемые по восходящей линии связи, через RNC2 231. Затем способ переходит на этап 6270.

На этапе 6270 принимается решение о хэндовере сеанса из AP1 265 на АP2 266 или узел-B 251. Решение может быть принято посредством распределенных MRRM функциональных возможностей сети, однако обычно это решение принимает MRRM-объект RNC1 (230). Соответствующие MRRM-объекты сети собирают MRRM формирование посредством вышеупомянутых путей сигнализации/протоколов и соответственно принимают адекватное решение о хэндовере, то есть решение о хэндовере для выполнения хэндовера типа 1, 2, 3 или 4, как описано выше. Это решение, в случае распределенных MRRM функциональных возможностей в сети, сигнализируется затем в MRRM-объект RNC1 (230) посредством любых подходящих протоколов/путей сети, описанных выше. Критерием для этого решения обычно является возможность AP2 (266)/узла-B (251), ассоциированного с RNC2 (231), предложить более лучший QoS, чем AP1 (265)/узел-B (250), ассоциированный с RNC1 (230), например, он может предложить канал/каналы трафика с более высоким качеством (улучшенный SNR, уменьшенный BER или более высокую пропускную способность и так далее) для маршрутизации сеанса, но точные критерии для решения о хэндовере не являются объектом настоящего изобретения. Это решение, в случае распределенных MRRM функциональных возможностей в сети, причем решение не принимается непосредственно в RNC1 (230), затем сигнализируется в MRRM-объект RNC1 (230) посредством любых подходящих протоколов/путей сети, описанных выше. Это делает доступными гибкие и эффективные MRRM функциональные возможности сети с множеством RAT, как это очевидно специалистам в данной области техники. Затем способ переходит на этап 6280 в случае варианта осуществления, при котором между RNC1 230 и RNC2 231 существует Iur-интерфейс, и переходит на этап 6293 в случае варианта осуществления, при котором не существует никакого Iur-интерфейса (установленного RNC1 230, как описано на этапе 6250).

На этапе 6280 устанавливают туннель между RNC через Iur-интерфейс, соединяющий RNC1 230 с RNC2 231. Обычно такое соединение устанавливает MRRM-объект RNC1 230 (он принимает решение о хэндовере и знает идентичность RNC2 231), но Iur-туннель может быть установлен по инициативе RNC2 231, как обсуждалось выше. Таким образом, MRRM-объект RNC1 230 устанавливает обычный 3GPP Iur-туннель, то есть GTP-U/C UDP/IP-туннель, для пакетов сеанса туннелирования в RNC2 231 проиллюстрировано этапом 22 передачи на фиг.7C. Для того чтобы ассоциировать этот меж-RNC-туннель с правильным сеансом, RNC1 230 посылает сообщение "Запрос на установку линии радиосвязи" в RNC2 231, информируя RNC2 231 о правильной ассоциации связывания между идентификатором меж-RNC-туннеля (обычно номером UDP-порта) и идентичностью UT 240 (обычно WLAN MAC-адресом UT 240). Это сообщение "Запрос на установку линии радиосвязи" содержит:

- идентификатор типа сообщения, идентифицирующий указанное сообщение, как являющееся сообщением "Запрос на установку линии радиосвязи",

- информационный элемент “Запрос на установку линии радиосвязи”,

- номер порта туннеля, установленного меж-RNC-туннеля между RNC1 (230) и RNC-кандидатом (231),

- идентификатор UT, идентифицирующий UT (240), который обычно является WLAN MAC-адресом UT 240, или 3GPP идентификатор, идентифицирующий UT 240.

- идентификатор типа хэндовера сеанса, определяющий один из четырех различных типов хэндовера, описанных выше.

Это сообщение "Запрос на установку линии радиосвязи" может быть реализовано в виде 3GPP RNSAP-сообщения "Запрос на установку линии радиосвязи", содержащего информационный элемент, констатирующий эти отношения между ID связывания (номером UDP порта) и WLAN MAC-адресом UT (240). Таким образом, сеанс однозначно идентифицируют в RNC2 231. Информационный элемент "Запрос на установку линии радиосвязи" представляет собой элемент, точно определяющий, какие радиоканалы должны быть установлены RNC2 (231), то есть RNC-кандидата, чтобы выполнить хэндовер. Обычно этот информационный элемент содержит любой идентификатор типа хэндовера сеанса и/или идентификатор типа хэндовера сигнализации управления, ассоциированный с сеансом, и/или идентификатор, идентифицирующий сеанс, причем идентификатор/идентификаторы определяют один из типов 1-4 хэндовера, описанных выше. Например, идентификатор типа хэндовера сеанса и идентификатор типа хэндовера сигнализации управления могут быть реализованы в виде выделенного поля размером N битов в подходящем поле данных 3GPP RNSAP-сообщения "Запрос на установку линии радиосвязи". Идентификатор сеанса может представлять собой альтернативный сетевой адрес UT 240, то есть его WLAN или MIP-адрес, но существуют другие возможности. Согласно изобретению важным является то, что эти идентификаторы, отдельно или в комбинации, определяют для RNC2 (231) один из четырех типов хэндовера, описанных выше. Таким образом, RNC2 231 может проверить и установить необходимые радиоресурсы, например 3GPP радиоканал трафика и/или (отдельный) 3GPP RRC радиоканал управления. В случае если сеанс должен быть маршрутизирован через AR 256, как описано ниже, идентификатор UT может представлять собой MIP/MIPSec-адрес UT 240. Адрес MIP представляет собой мобильный IP-адрес, используемый для мобильных приложений, а MIPSec-адрес представляет собой MIP-адрес, используемый в контексте IPSec-протокола, то есть MIPSec представляет собой MIP-адрес, обычно объединенный с идентификатором ассоциации безопасности (IPSec). Это сообщение "Запрос на установку линии радиосвязи" преимущественно также содержит информационный элемент, определяющий требуемый уровень QoS для требуемой линии/линий/каналов радиосвязи. Это делает доступным динамические QoS переговоры/оптимизацию между RNC1 230, RNC2 231 и UT 240, обеспечивая возможность для дальнейшей оптимизации MRRM функциональных возможностей сети с множеством RAT. Затем способ переходит на этап 6290.

На этапе 6290 RNC2 231 принимает/отклоняет запрошенный хэндовер RNC-сеанса, и в случае если RNC2 231 отклоняет (например, потому что не имеет свободных радиоресурсов) запрос (то есть запрошенный “Запрос на установку линии радисвязи”), способ останавливается на этапе 6290, а в случае если RNC2 231 признает, что запрошена установка линии радиосвязи, RNC2 231 подтверждает это в RNC1 230 обычным способом, то способ переходит на этап 6300.

На этапе 6293 MRRM-объект RNC1 формирует сообщение "Запрос на перемещение RNC" и посылает это сообщение в SGSN, проиллюстрированное этапом 21 передачи на фиг.7C, запрашивая SGSN переключить маршрутизацию сеанса из RNC1 230 на RNC2 231, возможно с "двойной маршрутизацией" и в RNC1 230, и в RNC2 231 в течение периода времени, которое может представлять собой заранее установленный фиксированный период времени или период времени, динамически управляемый RNC1 230. Это обеспечивает возможность предоставления мягкого хэндовера в сети с множеством RAT, что является важным преимуществом. Согласно изобретению сообщение "Запрос на перемещение RNC" содержит следующее:

- информационный элемент идентификатора типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Запрос на перемещение RNC",

- идентификатор, идентифицирующий RNC кандидата (231),

- сетевой адрес UT (240), как определено в соответствии с альтернативным протоколом сети доступа,

- туннельный идентификатор туннеля между RNC (230) и узлом поддержки передачи пакетных данных (220), через который в текущий момент времени туннелируется сеанс.

Идентичность SGSN 220 обычно ассоциирована с сеансом, например, сохраняется в таблице маршрутизации сеанса в RNC1 230. Затем способ переходит на этап 6300.

На этапе 6300 RNC1 230 посылает сообщение "Физическая переконфигурация канала" в UT 240 по UTRAN или WLAN-пути через узел-B 250 или AP1 265 обычным способом, как описано выше на этапе 6145. Этап 23 передачи иллюстрирует на фиг.7C случай, при котором сообщение "Физическая переконфигурация канала" посылают по UTRAN-пути. Цель этого сообщения заключается в том, чтобы проинструктировать UT 240 о том, чтобы он начал прислушиваться к пакетам сеанса, передаваемым по нисходящей линии связи, из AP2 266/узла-B 251. Как уже описывалось, это сообщение обычно реализуется при помощи RRC/RLC-протокола и посылается по BCCH в UT 240 через узел-B 250. Например, 3GPP-сообщение "Физическая переконфигурация канала" может использоваться путем добавления информационного элемента для того, чтобы идентифицировать узел/узлы радиодоступа AP1 265 и AP2 266, как определено согласно альтернативному протоколу сети доступа, например, WLAN MAC-адрес AP2 266 здесь также может использоваться в качестве информационного элемента (связанного с RNC1 230 при помощи сообщения "Кандидат для хэндовера"). Это сообщение также может содержать WLAN MAC-адрес RNC2 230 (если известен в RNC1, и в случае, если UT 240 не будет повторно использовать WLAN MAC-адрес RNC1 230 для того, чтобы посылать пакеты, передаваемые по восходящей линии связи, через AP2 265). Однако на данном этапе данное сообщение "Физическая переконфигурация канала" также может быть послано по WLAN-пути при помощи STAME/APME-протокола между UT 240 и AP1 265 и при помощи IAPP/LWAP-протокола между AP1 265 и RNC1 230 или в виде специализированного UDP/IP-пакета между UT 240 и RNC1 230, причем существует много возможностей. Затем способ переходит на этап 6310.

На этапе 6310 ассоциацию безопасности устанавливают между UT 240 и AP2 266, что проиллюстрировано этапом 24 передачи на фиг.7C, например, используя обычную стандартную EAP (расширяемый протокол аутентификации) аутентификацию в соответствии с IEEE 802.11 спецификацией безопасности. Затем способ переходит на этап 6320 в случае варианта осуществления, при котором между RNC1 230 и RNC2 231 существует Iur-интерфейс, и переходит на этап 6330 в случае варианта осуществления, при котором такой интерфейс не существует.

На этапе 6320 RNC1 230, действуя как SRNC, начинает маршрутизировать пакеты, передаваемые по нисходящей линии связи, в RNC2 231, действуя как DRNC, через установленный туннель между RNC. В одном из вариантов осуществления ROUTING-объект RNC1 маршрутизирует пакеты сеанса в RNC2 231, выполняя этапы, на которых:

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

- добавляют LLC-заголовки к исходным пользовательским пакетам данных IP-сеанса, передаваемым по нисходящей линии связи, преобразуя их в формат LLC, согласно указанному альтернативному протоколу сети доступа, с адресом исходной LLC-сети RNC1 (230),

- связывают указанный идентификатор сеанса с идентификатором туннеля, идентифицирующим меж-RNC GTP-U-туннель, то есть номер UDP порта, таким образом туннелируя указанные пакеты LLC-сеанса RNC-кандидата (231).

В одном из вариантов осуществления ROUTING-объект RNC1 маршрутизирует пакеты сеанса в RNC2 231, выполняя этапы, на которых:

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

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

В одном из вариантов осуществления, описанном ниже, в котором IP-сеть и AR 256 установлены между RNC2 231 и АP2 265, сообщение "Кандидат для хэндовера" содержит мобильный IP-адрес, MIP, или защищенный адрес MIP, MTPSec UT (240), наряду с IP-адресом маршрутизатора доступа, AR (256), ассоциированного с RNC-кандидатом (231). ROUTING-объект RNC1 маршрутизирует пакеты сеанса в RNC2 231, выполняя этапы, на которых:

- идентифицируют сеанс посредством MIP/MIPSec-адреса UT (240), связанного с сеансом (то есть сохраненного в таблице маршрутизации сеанса),

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

- инкапсулируют пакеты IP-сеанса исходного формата передачи посредством UDP/IP или TCP/IP с IP-адресом AR (265) в виде адреса назначения,

- инкапсулируют таким образом полученные UDP/IP или TCP/IP-пакеты сеанса с UDP/IP, формируя пакеты туннелирования, причем номер UDP порта пакетов туннелирования идентифицирует меж-RNC туннель для RNC-кандидата (231),

- связывают указанный идентификатор сеанса, TEID1, с номером UDP порта меж-RNC-туннеля, таким образом туннелируя инкапсулированные пакеты сеанса, передаваемые по нисходящей линии связи, в RNC-кандидат (231).

Преимущественно, пакеты сеанса маршрутизируют по альтернативному пути сети радиодоступа через второй порт (272) параллельно с маршрутизацией сеанса по меж-RNC-туннелю в RNC-кандидат, таким образом обеспечивая возможность для мягкого хэндовера, который является преимущественным, особенно в случае времязатратных процедур аутентификации между UT 240 и альтернативной сетью. Это проиллюстрировано этапами 25, 26 и 27 передачи на фиг.7C. Затем способ переходит на этап 6340.

На этапе 6330 SGSN 220 устанавливает новый GTP-U-туннель для сеанса через Iu-интерфейс между RNC2 231 и SGSN 220 и устанавливает RAB ID для этого GTP-U-туннеля, который передает в RNC2 231 обычным способом для PDP-контекста в пределах RNC хэндовера. Затем SGSN начинает маршрутизировать сеанс параллельно в RNC2 231 и RNC1 231, что проиллюстрировано этапами 28 и 29 передачи на фиг.7D, через их GTP-U-туннели, соответственно различающиеся соответствующими им TEID. Таким образом, этот вариант осуществления также обеспечивает возможность для мягкого хэндовера, который является преимущественным, особенно в случае времязатратных процедур аутентификации между UT 240 и альтернативной сетью. Затем способ переходит на этап 6340.

На этапе 6340 RNC2 231, действующий в качестве DRNC в случае, если он принимает пакеты сеанса по туннелю Iur-интерфейса из RNC1 230, и действующий в качестве SRNC в случае, если он принимает пакеты сеанса по туннелю Iu-интерфейса из SGSN 220, направляет эти пакеты сеанса, передаваемые по нисходящей линии связи, в UT 240 через AP2 266 или узел-B 251, в соответствии с типом хэндовера, указанным идентификатором типа хэндовера сеанса в сообщении "Запрос на установку линии радиосвязи", принятом из RNC1 230 (или SGSN 220). Более конкретно, в случае если пакеты сеанса должны быть маршрутизированы через AP2 266, объект маршрутизации RNC2 231 выполняет этап, на котором:

- ассоциирует с сеансом установленное логическое LLC-соединение, которое было установлено на этапе 6260, то есть путем обновления ее таблицы маршрутизации для сеанса с этим LLC-портом (277).

В одном из вариантов осуществления ROUTING-объект RNC2 231 выполняет этапы, на которых:

- принимает пакеты сеанса, передаваемые по нисходящей линии связи, по туннелю, идентифицируемому указанным номером порта туннеля,

- вырезает заголовки протокола туннелирования из принятых пакетов, передаваемых по нисходящей линии связи, таким образом получая пакеты сеанса, имеющие формат согласно альтернативному протоколу сети доступа, причем пакеты имеют исходный сетевой адрес RNC1 (230), как определено указанным альтернативным протоколом сети доступа,

- направляет таким образом полученные пакеты сеанса через порт (277), таким образом маршрутизируя пакеты в UT (240) через AP2 (266).

В одном из вариантов осуществления ROUTING-объект RNC2 231 выполняет этапы, на которых:

- принимает пакеты сеанса, передаваемые по нисходящей линии связи, по туннелю, идентифицируемому указанным номером порта туннеля,

- вырезает заголовки протокола туннелирования из принятых пакетов, таким образом получая пакеты сеанса, имеющие формат согласно альтернативному протоколу сети доступа, причем пакеты имеют исходный сетевой адрес RNC1 (230), как определено в соответствии с указанным альтернативным протоколом сети доступа,

- вырезает заголовки инкапсуляции таким образом полученных пакетов, причем заголовки инкапсуляции были добавлены RNC1 (230) при помощи альтернативного протокола сети доступа, таким образом преобразуя пакеты, передаваемые по нисходящей линии связи, в их исходный формат передачи,

- добавляет LLC-заголовки в пакеты сеанса исходного формата передачи, передаваемые по нисходящей линии связи, преобразуя их в LLC-формат согласно указанному альтернативному протоколу сети доступа с исходным сетевым адресом LLC RNC-кандидата (231).

- направляет таким образом сформированные пакеты LLC-сеанса через порт (277), таким образом маршрутизируя пакеты в UT (240) через AP2 (266).

В одном из вариантов осуществления, в котором сеть с множеством RAT содержит AR 256 и IP-сеть, установленную между RNC2 231 и AP2 266, и в котором сообщение "Кандидат для хэндовера" содержит мобильный IP-адрес, MIP, или безопасный адрес MIP, MIPSec, UT (240), наряду с IP-адресом маршрутизатора доступа, AR (256), ассоциированным с RNC-кандидатом (231), причем идентификатор UT-сообщения "Запрос на установку линии радиосвязи" представляет собой соответствующий MIP/MIPSec-адрес UT (240), и в котором меж-RNC-туннель представляет собой UDP/IP-туннель, ROUTING-объект RNC2 231 выполняет этапы, на которых:

- извлекает MIP/MIPSec UT (240) из указанного сообщения "Запрос на установку линии радиосвязи",

- ассоциирует номер порта туннеля с MIP/MIPSec UT (240) и с IP-адресом AR (256),

- принимает идентификацию сеанса посредством MIP/MIPSec-адреса UT (240), связанного с этим сеансом,

- обновляет таблицу маршрутизации сеанса с IP-адресом AR (256),

- принимает IP-инкапсулированные пакеты IP-сеанса, передаваемые по нисходящей линии связи, по меж-UDP/IP RNC-туннелю,

- вырезает заголовки UDP/IP-туннелирования из IP-инкапсулированных пакетов IP-сеанса, передаваемых по нисходящей линии связи, получая пакеты IP-сеанса, передаваемые по нисходящей линии связи, инкапсулированные с IP, причем IP-адрес инкапсуляции пакетов IP-сеанса представляет собой IP-адрес AR2 (256), и

- направляет пакеты IP-сеанса, передаваемые по нисходящей линии связи, инкапсулированные с IP-адресом AR (256), в порт (277), ассоциированный с AR (256), таким образом маршрутизируя пакеты IP-сеанса, передаваемые по нисходящей линии связи, в UT (240) через AR (256) и AP2 (266).

На этапе 6350 UT 240 принимает эти пакеты сеанса, передаваемые по нисходящей линии связи, из RNC2 231 через AP2 266/узел-B 251, через свой порт 242/241, в зависимости от типа хэндовера. Затем MRRM-объект UT 240 посылает сообщение “Подтверждение хэндовера” в RNC1 230 в виде ответа на прием этих пакетов сеанса, передаваемых по нисходящей линии связи, от RNC2 231. Цель этого сообщения заключается в том, чтобы информировать RNC1 230 о том, что с этого времени UT 240 активно ассоциирован с AP2 266/узлом-B 251 вместо AP1 265/узла-B 250, в зависимости от типа хэндовера. Как было заявлено, это сообщение содержит:

- идентификатор типа сообщения, идентифицирующий указанное сообщение, как являющееся сообщением "Подтверждение хэндовера",

- информационный элемент диссоциации и сетевой адрес точки радиодоступа, например, AP1 265 в случае хэндовера типа 4 или 3, с которым UT (240) больше не ассоциирован для маршрутизации сеанса, и

- информационный элемент “Подтверждение хэндовера” наряду с сетевым адресом целевой точки радиодоступа, например, AP2 (266) в случае хэндовера типа 4 или 3, с которой в настоящее время UT (240) ассоциирован для маршрутизации сеанса. Сообщение "Подтверждение хэндовера" может быть реализовано, например, посредством 3GPP RRC-сообщения "Отчет об измерении", в котором информация, которая указывает на AP1 (265) как на диссоциированную точку доступа, а на AP2 (266) - как на новую ассоциированную точку доступа, может содержаться в информационном элементе "Дополнительные измеренные результаты" и быть послано по UTRAN-пути (по BCCH) при помощи RLC/RRC-протоколов через, например, узел-B 250. Цель этого сообщения "Подтверждение хэндовера" заключается в том, чтобы информировать RNC1 230 о том, что с этого времени он должен маршрутизировать пакеты, передаваемые по нисходящей линии связи, только через RNC2 231, то есть отсутствует потребность в продолжении мягкого хэндовера. На данном этапе это сообщение "Подтверждение хэндовера" также может быть послано по WLAN-пути через AP1 265 или AP2 266 при помощи STAME/APME-протоколов между UT 240 и AP1/AP2 265/266 и при помощи IAPP/LWAP-протокола между АP1/АP2 265/266 и RNC1 230/RNC2 231 или в виде специализированного UDP/IP-пакета между UT 240 и RNC; существуют много возможностей. В случае если это сообщение посылают в RNC2 231, RNC2 231 обычно передает его в RNC1 230, что может представлять собой преимущественный способ минимизации всех радиопомех и таким образом увеличения общей емкости/пропускной способности сети. Более конкретно, IAPP-LEAVE.Notify-пакет, посланный из AP1 265 в RNC1, содержащий вышеупомянутую информацию, может преимущественно функционировать в виде такого сообщения "Подтверждение хэндовера". Затем AP1 265 посылает этот IAPP-LEAVE.Notify-пакет в RNC1 231, как только UT 240 диссоциирует с AP1 265. Этап 32 передачи на фиг.7C иллюстрирует случай, при котором это сообщение "Подтверждение хэндовера" посылают по WLAN-пути в RNC1 230. Таким образом, минимизируется полная сигнализация/помехи и увеличивается емкость сети. Согласно изобретению затем RNC1 230 блокирует маршрутизацию сеанса через AP1 265 в виде ответа на прием указанного сообщения "Подтверждение хэндовера". Затем способ переходит на этап 6360.

На этапе 6360 UT 240 начинает посылать пакеты сеанса, передаваемые по восходящей линии, через узел доступа, ассоциированный с RNC2 231, то есть AP2/узел-B 266/25, в виде ответа на прием этих пакетов, передаваемых по нисходящей линии связи, из RNC2 231 путем связывания идентификатора сеанса в UT 240, например 3GPP RB ID-сеанса, с, например, установленным WLAN RB ID, ассоциированным с AP2 266, в случае хэндовера типа 4 или 3. Затем способ переходит на этап 6370.

Таким образом, на этапе 6370 пакеты сеанса, передаваемые как по восходящей линии связи, так и по нисходящей линии связи, маршрутизируют через RNC2 231, например через AP2 266, что проиллюстрировано этапом 33 передачи на фиг.7C, и меж-RNC хэндовер завершается.

Даже несмотря на то, что выше был описан хэндовер сеанса с PDP-контекстом из UTRAN-пути маршрутизации на WLAN-путь маршрутизации, настоящее изобретение также применимо для хэндовера сеанса с PDP-контекстом или сеанса передачи данных из WLAN-пути маршрутизации на UTRAN-путь маршрутизации с незначительными модификациями, очевидными для специалиста в данной области техники. Например, в случае хэндовера из WLAN-пути маршрутизации на UTRAN-путь маршрутизации, например, если сеанс передачи данных сначала установлен через WLAN-путь маршрутизации, то сообщение о возможностях можно послать по WLAN-пути маршрутизации, и оно может содержать, например, WLAN RB ID, уникально идентифицирующий указанный сеанс передачи данных, и дополнительно содержать IMSI UT 240, позволяющий RNC1 230 установить альтернативные 3GPP RAB ID и 3GPP RB ID, соответствующие QoS требованиям WLAN RB ID и определяющие соответствующий сеанс передачи данных с UT 240 по UTRAN-пути, и так далее. Кроме того, изобретение может использоваться для одновременной маршрутизации PDP-пакетов или сеанса передачи данных как по WLAN-пути маршрутизации, так и по UTRAN-пути маршрутизации, не только для формирования мягкого хэндовера, но и для увеличения качества пропускной способности/трафика канала.

RNC1 230 инициирует хэндовер, и UT 240 переключает его путь маршрутизации, приняв первые PDP-пакеты, как описано выше, но существуют многие другие возможности. Например, хэндовер может инициировать UT 240 или другой MRRM-объект в сети, и RNC1/RNC2 230/231 может переключить путь маршрутизации после приема первых PDP пакетов, передаваемых по восходящей линии связи, из UT 240. UT/RNC 240/230 может принять решение о хэндовере независимо от RNC/UT 230/240 и независимо выполнить хэндовер и/или может сигнализировать решение о хэндовере в RNC/UT 230/240, например, при помощи RRC-сообщения для "синхронизации" эстафетной передачи с RNC1/RNC2/UT 230/231/240.

Теперь, возвращаясь к фиг.2, ниже более подробно описан вариант осуществления, в котором сеть содержит AR 256 и AR 255, показанный на фиг.2, со ссылкой на фиг.2, 5 и 7. В этом варианте осуществления WLAN-часть, содержащая AP1/AP2 265/266 и M-L2S1/М-L2S2 262/263, соединена с IP-сетью (не показана на фиг.2) посредством маршрутизаторов доступа AR1/AR2 255/256, то есть между RNC1/RNC2 230/231 и AR1/AR2 255/256 имеется промежуточная UDP/IP-сеть. Маршрутизаторы доступа соединены с DHCP (протоколом динамической конфигурации хоста)-сервером (не показано), который может быть интегрирован, например, в RNC1 230 или может быть отдельным сервером. Поскольку 3GPP UTRAN RNC1 230 и RNC2 231 имеют свои собственные IP-адреса и связаны посредством UDP/IP, можно считать, что AR2 256 соединены с RNC1 230, причем RNC2 231 просто действует как релейный UDP/IP-узел.

Сначала, со ссылкой на этапы 710-738 на фиг.7, будет описан хэндовер PDP-сеанса, в котором сеанс сначала маршрутизируют через RNC1 230 по UTRAN-пути через узел-B 250, в AR/WLАN части выполняется хэндовер сеанса, который далее маршрутизируют через AP1 265.

Ссылаясь на фиг.7A-C, способ согласно изобретению начинается на этапе 810, на котором устанавливают сеанс передачи данных с PDP-контекстом между UT 240 и GGSN 210, предоставляя возможность для сеанса передачи данных между UT 240 и, например, интернет-хостом или одноранговым узом, соединенным с Интернетом 280. Сеанс с PDP-контекстом устанавливают обычным способом, например, как описано выше.

На этапе 811 данные указанного сеанса с PDP-контекстом маршрутизируют по первому пути маршрутизации, то есть UTRAN-пути маршрутизации через узел-B 250 обычным способом, как описано выше.

На этапе 812 MRRM-объект RNC1 230 посылает свой альтернативный исходный сетевой адрес, NSA, то есть IP-адрес RNC1 230, в MRRM-объект UT 240, например, по нисходящей линии связи UTRАN-DCCH. В качестве альтернативы, на этапе 812 RNC не посылает свой NSA, вместо этого DHCP-серверу известен IP-адрес RNC1 230 (сохраненный заранее), и, например, в DHCP-сообщение подтверждения включен IP-адрес RNC1 230, как описано ниже на этапе 823.

На этапе 813 MRRM-объект UT 240 обновляет таблицу маршрутизации ROUTING-объекта UT путем ассоциации сеанса/сеансов с PDP-контекстом с принятым NSA, то есть в этом случае IP-адресом RNC1 230, как показано в табл.6, и создает альтернативный идентификатор маршрутизации для соответствующего сеанса передачи данных, то есть IP RB ID, и ассоциирует его с портом 242. IP RB ID ассоциирован с IP-адресом RNC1 230.

Таблица 6
PDP-сеанс	3GPP RB ID	3GPP RAB ID	NSA	IP RB ID	Приложение
Сеанс 1	RB ID 1	RAB ID 1	IP-адрес RNC	IP RB ID 1	Веб-браузинг
Сеанс 2	RB ID 2	RAB ID 2	IP-адрес RNC		Электронная почта
Сеанс N	RB ID N	RAB ID N	IP-адрес RNC		Мультимедийная загрузка

На этапе 820 MRRM-объект UT 240 детектирует WLAN (радиопередачи)-сигнал маяка из AP 665, и UT 240 устанавливает радиосоединение с WLAN через указанный второй порт (242). WLAN передает обновленные кадры в маршрутизатор доступа AR1 255, и таблицы переадресации WLAN и AR1 255 обновляются, соответствующим образом, обычным способом.

На этапе 823 UT 240 получает второй IP-адрес из DHCP-сервера дополнительно к своему уже назначенному адресу IP-сеанса с PDP-контекстом. Это требует, чтобы UT 240 имел установленного DHCP клиента. Назначение второго IP-адреса в UT 240 обычно выполняется следующим образом:

1. UT 240 выполняет радиопередачу сообщения об обнаружении DHCP в виде DHCP/UDP/IP-сообщения.

2. Сервер DHCP отвечает UT 240, посылая сообщение о предложении DHCP, которое содержит второй IP-адрес для UT 240 в виде DHCP/UDP/IP-сообщения. В случае если переданное сообщение об обнаружении достигает нескольких DHCP-серверов, различными DHCP-серверами может быть послано множество предложений DHCP. Второй IP-адрес обычно представляет собой IP-адрес, выделенный для мобильных приложений, то есть Ipm-адрес.

3. UT 240 выполняет радиопередачу сообщения запроса DHCP (то есть запроса для одного из предложенных IP-адресов от DHCP-сервера) в виде DHCP/UDP/IP-сообщения.

4. DHCP-сервер посылает сообщение о подтверждении DHCP (то есть подтверждает зарезервированный IP-адрес и конфигурацию для UT 240) в виде DHCP/UDP/IP-сообщения в UT 240, который отслеживает это подтверждение и сохраняет зарезервированный (второй) IP-адрес для дальнейшего использования. Этот второй IP-адрес направляется в UT RRC-приложение, которое ассоциирует этот второй IP-адрес с соответствующим сеансом/сеансами с PDP-контекстом. Необязательно сообщение подтверждения DHCP также может содержать IP-адрес RNC1 230, если оно известно DHCP-серверу.

На этапе 825 MRRM-объект UT 240 формирует и посылает сообщение об ассоциации в MRRM-объект RNC1 230. Сообщение об ассоциации содержит альтернативный адрес сети UT 240, то есть в этом случае второй IP-адрес, и также функционирует в виде сообщения о возможностях, как описано выше. В одном из вариантов осуществления сообщение об ассоциации дополнительно содержит идентификатор сеанса, уникально идентифицирующий сеанс передачи данных, например 3GPP RB ID 1 или 3GPP RAB ID 1, уникально идентифицирующий определенный сеанс передачи данных с PDP-контекстом, установленный на этапе 810. Таким образом, UT 240 может управлять таким сеансом/сеансами с PDP-контекстом среди набора активного сеанса/сеансов с PDP-контекстом, для которых может быть желательным хэндовер. Это может быть достигнуто предоставлением возможности UT 240 послать указанное сообщение об ассоциации по UTRAN-пути, использующему указанные 3GPP RB ID и 3GPP RAB ID так, чтобы RNC1 230 мог извлечь указанные 3GPP ID RB и 3GPP ID RAB, которые уникально идентифицируют определенный сеанс с PDP-контекстом. В качестве альтернативы, сообщение об ассоциации можно послать по пути WLAN-IP-сети в виде TCP/IP пакета, адресованного MRRM-объекту RNC1 230. DHCP-сервер посылает сообщение об ассоциации в RNC1 230, содержащее WLAN MAC-адрес UT 240 и второй IP-адрес. Это сообщение может быть выделенным сообщением, если IP-адрес RNC1 230 известен (заранее сохранен) DHCP-сервером, или может быть послан при помощи многоадресной рассылки.

На этапе 826 RNC 230 принимает указанное сообщение об ассоциации, посланное на этапе 825, и создает альтернативный идентификатор маршрутизации, в этом случае в виде идентичности определенного радиоканала IP-сети для определенного сеанса с PDP-контекстом, то есть IPN RB ID 1, как показано в табл.7 ниже, и ассоциирует этот IPN RB ID 1 с NA (сетевым адресом), то есть вторым IP-адресом UT 240, а также ассоциирует IPN RB ID 1 с портом 272. RNC1 230 ассоциирует указанный сеанс с PDP-контекстом (то есть соответствующий рассматриваемый сеанс) с указанным NA (вторым IP-адресом UT 240), указанным альтернативным идентификатором маршрутизации, то есть IPN RB ID 1, и портом 272, например, путем обновления его таблицы маршрутизации, как показано в табл.7. Аналогично, как для 3GPP ID RB и WLAN RB ID, IPN RB ID определяет соединение по пути IP-сеть-WLAN-сеть и содержит, например, аналогичные QoS требования, то есть требования относительно полосы пропускания, требование относительно максимальной задержки пакета, требования относительно BER, FER и так далее, в виде соответствующего 3GPP ID RB, для более низких уровней для реализации соединения между ROUTING-объектами RNC1 230 и UT 240.

Таблица 7
Сеанс	3GPP RB ID	3GPP RAB ID	UT	TEID	IPN RB ID	NA	Порт передачи данных	GTP-U
Сеанс 1	RB ID 1	RAB ID 1	UT1	TEID 1	IPN RB 1	Второй IP-адрес UT	272	GTP-U 1
Сеанс 2	RB ID 2	RAB ID 2	UT2	TEID 2				GTP-U 2
Сеанс N	RB ID N	RAB ID N	UTK	TEID N				GTP-U N

ROUTING-объект RNC1 230 продолжает маршрутизацию пользовательских данных сеанса с PDP-контекстом через UTRAN-радиоинтерфейс, то есть через порт 273, продолжая связывать TEID-сеанс с PDP-контекстом с UTRAN (3GPP) RAB ID и UTRAN (3GPP) RB ID. В одном из вариантов осуществления способ переходит затем на этап 827. В другом варианте осуществления способ пропускает этап 827 и переходит сразу на этап 830.

На этапе 827 RNC1 230 и UT 240 устанавливают обычное двунаправленное IPSec (защищенный IP) соединение согласно одному из вариантов осуществления, предоставляя возможность для выполнения безопасного шифрования и защиты аутентификации/целостности для пакетов, предназначенных для передачи по WLAN-пути IP-сети. Это требует, чтобы RNC1 230 и UT 240 дополнительно имели соответствующее установленное IPSec-приложение, и обычно выполняется посредством установки обычной так называемой ассоциации безопасности IPSec (SA) в каждом направлении между UT 240 и RNC1 230. После этого пакеты с PDP-контекстом могут передаваться безопасно по этим IPSec-соединениям. Полномочия ассоциации безопасности могут изменяться между UT 240 и RNC1 230 по защищенному (зашифрованному) установленному UTRAN (WCDMA) соединению. Затем способ переходит на этап 830.

На этапе 830 принимают решение о переключении маршрутизации указанного сеанса с PDP-контекстом из указанного пути сети сотовой радиосвязи (путь UTRAN) через узел-B 650 и порты 273 и 641 на указанный альтернативный путь сети передачи данных (путь WLAN-IP-сеть) через порты 272 и 642. Согласно изобретению это решение может быть принято UT 240 или RNC1 230 на основе различной RRM-информации. В одном из вариантов осуществления MRRM-объект RNC1 230 принимает RRM-сообщение, содержащее информацию относительно, например, силы сигнала, QoS, BER, FER, уровня помех, скорости UT 240, загрузки соты, качества радиоканала и так далее, относительно UTRAN-сети и/или WLAN-IP-сети из MRRM-объекта UT 240. Это сообщение может быть послано по UTRAN-пути маршрутизации, например DCCH, или по WLAN-IP-сети в виде TCP/IP-сообщения. MRRM-объект UT 240 выполняет измерения качества линии радиосвязи как для UTRAN-связи, так и для WLAN связи с тем, чтобы сформировать такое RRM-сообщение/сообщения или отчет об измерении. В качестве альтернативы, RRM-информация может быть собрана AP 665 или маршрутизатором доступа 6010 и передана в RNC1 230 в виде выделенного сообщения (например, в виде модифицированного IAPP-сообщения) в случае, если между AP и AR, и RNC1 230 существует для этой цели такое выделенное соединение на уровне управления, в качестве альтернативы AP посылает RRM-сообщения в альтернативную беспроводную сеть передачи данных (например, 802 WLAN-сеть уровня 2), которая передает их в IP-сеть через AR 6010, который, в свою очередь, передает их в RNC1 230. AR может послать RRM сообщения непосредственно в IP-сеть. RNC1 230 может постоянно прослушивать RRM-сообщения (например, прослушивать определенный адрес распределения IAPP для модифицированных IAPP RRM-сообщений), извлекать и отфильтровывать RRM-сообщение, относящееся к определенным сотам (то есть содержащим определенный WLAN ID-соты) и/или относящееся к определенным пользователям (например, содержащим MAC-адрес UT или IP-адрес UT), ассоциированный с RNC1 230. На этапе 830 RNC-MRRM-объект RNC1 230 может принять решение о хэндовере из UTRAN-пути маршрутизации на путь WLAN-IP-сети маршрутизации, например, если WLAN-IP-сеть в текущий момент времени предлагает лучший/более высокий уровень QoS, чем UTRAN, или если уровень загрузки трафика UTRAN-сети превышает определенное пороговое значение, или может принять решение о сохранении UTRAN-пути маршрутизации, например, из-за очень высокой скорости UT 240, но существует много возможностей. В альтернативном варианте осуществления UT MRRM-объект UT 240 принимает решение о переключении маршрутизации сеанса с PDP-контекстом на WLAN-путь маршрутизации, например, на основании указанных измеренных значений MRRM параметров. Важным является то, что изобретение предоставляет возможность для обеспечения MRRM функциональных возможностей в RNC1 230 и/или UT 240, предоставляя возможность, например, принятия решения о хэндовера с учетом эксплуатации радиоресурсов как указанной UTRAN, так и указанной WLAN-IP-сети. Таким образом, изобретение предоставляет возможность для разработки совершенно новых и более эффективных MRRM функциональных возможностей, поскольку RNC1 230 и/или UT 240 имеет доступ и к UTRAN, и к WLAN RRM-информации. В преимущественном варианте осуществления MRRM-объект RNC1 230 принимает решение о хэндовере. Необходимо отметить, что изобретение дает возможное преимущество сбора всей MRRM-информации в "правильном" узле, то есть в узле управления радиосетью, RNC1 230, в котором реализуются обычные UTRAN RRM-функции.

Согласно способу изобретения способ остается на этапе 830 до тех пор, пока не будет принято решение о хэндовере сеанса с PDP-контекстом на путь WLAN-IP-сети маршрутизации, и затем переходит на этап 831.

На этапе 831 в одном из вариантов осуществления RNC1 230 сначала выполняет хэндовер сеанса с PDP-контекстом, то есть указанного пути сети сотовой радиосвязи, на указанный альтернативный, то есть путь WLAN-IP-сети маршрутизации, то есть переключает передачу на уровне пользователя из UTRAN-пути на путь WLAN-IP-сети. Хэндовер выполняется ROUTING-объектом RNC1 230, который связывает идентификатор сеанса с PDP-контекстом, то есть в данном случае TEID 1, с альтернативной идентичностью радиоканала, то есть в этом случае IPN RB ID 1, вместо обычного 3GPP RB ID, табл.7, таким образом начиная маршрутизировать IP-пакеты PDP-сеанса, передаваемые по нисходящей линии связи, по пути маршрутизации WLAN-IP-сети через порт 272 вместо пути UTRAN через порт 273. Переключение передачи очень важно для IP-пакетов, передаваемых по нисходящей линии связи, принятых RNC1 230 из SGSN 220 по соответствующему GTP-U-туннелю. В обычной передаче на уровне пользователя RNC декапсулирует IP-пакеты из GTP-U PDU и инкапсулирует их с PDCP до передачи по UTRAN каналам. Изобретение позволяет бесшовное переключение передачи без потери данных при наличии ROUTING-объекта RNC1 230, выполняющего следующие этапы, на которых:

1. Принимают решение о том, что все IP-пакеты, передаваемые по нисходящей линии связи, которые уже были инкапсулированы и кешированы в виде PDCP пакетов перед меж-RAT (технология радиодоступа) хэндовером, будут передаваться в UT 240 по UTRAN-пути. Такие IP-пакеты могут быть кешированы в RNC1 230, поскольку они ждут своей передачи, или они уже были переданы в UT 240, но еще не были подтверждены. Пока RNC принимает IP-пакеты, передаваемые по восходящей линии связи, из UT 240 по его UTRAN-пути маршрутизации, RLC-объект RNC1 230 подтверждает прием пакетов, используя согласно изобретению UTRAN-путь (в случае, если используется режим, подтвержденный RLC).

2. В случае если RLC услуга подтверждения режима конфигурируется в PDP-контексте для передачи на уровне пользователя по UTRAN-пути, то между ROUTING-объектом UT 240 и RNC1 230 используется передача в обычном подтвержденном TCP/IP-режиме.

3. Все IP-пакеты, передаваемые по нисходящей линии связи, декапсулированные из GTP-U PDU после принятия решения о меж-RAT хэндовере на этапе 530, инкапсулируют в виде TCP/IP-пакетов ROATING-объекта со вторым IP-адресом UT 240 в качестве адреса назначения и IP-адресом RNC1 230 в качестве исходного адреса. Затем эти кадры посылают через порт 272 RNC1 230.

Затем созданные TCP/IP-пакеты, передаваемые по нисходящей линии связи, передают в порт 272 RNC1 230. Они представляют собой TCP/IP-пакеты ROUTING-объекта, то есть TCP заголовок определяет их, как являющиеся пакетами ROUTING-объекта, предназначенными для ROUTING-объекта UT 240, содержащие вложенные PDP IP-пакеты, передаваемые по нисходящей линии связи.

На этапе 832 IP-сеть и WLAN маршрутизируют эти IP-пакеты, передаваемые по нисходящей линии связи, в UT 240, поскольку их таблицы переадресации обновлены соответствующим образом, и передают их в UT 240.

На этапе 834 UT 240 переключает путь маршрутизации указанного сеанса с PDP-контекстом из UTRAN-пути маршрутизации на альтернативный путь WLAN-IP-сети маршрутизации после приема альтернативного исходного адреса сети RNC1 230, NSA, то есть в данном случае IP-адреса RNC1 230. ROUTING-объект UT 240 обновляет свою таблицу маршрутизации путем ассоциации идентификатора/идентификаторов сеанса с NSA RNC, то есть в данном случае IP-адресом RNC1 230, как показано ниже в табл.8.

Таблица 8
Сеанс	3GPP RB ID	3GPP RAB ID	NSAPI	NSA RNK	ID радиоканала IPN	Приложение
Сеанс 1	RB ID 1	RAB ID 1	NSAPI 1	IP-адрес RNC	IPN RB ID 1	Веббраузинг
Сеанс 2	RB ID 2	RAB ID 2	NSAPI 2			Электронной почты
Сеанс N	RB ID N	RAB ID N	NSAPI N			Мультимедийной загрузки

ROUTING-объект UT 240 декапсулирует принятые пакеты IP-PDP, передаваемые по нисходящей линии связи, из TCP/IP-пакетов. Затем UT 240 обновляет свою таблицу маршрутизации, то есть табл.8, соответствующим образом путем связывания соответствующего идентификатора сеанса с PDP-контекстом, то есть UTRAN RAB ID 1, с IPN RB ID 1 для передачи IP-пакета, передаваемого по восходящей линии связи, через порт 642 вместо UTRАN-порта 641. Таким образом, UT 240 заканчивает свою передачу по восходящей линии связи через свой UTRAN порт передачи 641 и начинает передавать последующие PDP IP-пакеты, передаваемые по восходящей линии связи, через порт 642 в виде TCP/IP-кадров в ROUTING-объект RNC1 230. Более конкретно, в одном из вариантов осуществления переключение передачи на уровне пользователя в UT 240 содержит следующие этапы, выполняемые ROUTING-объектом UT 240, на которых:

1. Так же, как это делалось RNC1 230 для IP-пакетов, передаваемых по нисходящей линии связи, все IP-пакеты, передаваемые по восходящей линии связи, которые уже были инкапсулированы и кешированы в виде PDCP пакетов в UT 240 перед переключением меж-RAT передачи, передают в RNC1 230 по UTRAN-пути, то есть используя назначенные UTRAN радиоканалы/каналы. Такие IP-пакеты могут быть кешированы, поскольку они ждут своей передачи, или они уже были переданы в RNC, но еще не подтверждены. Пока UT 240 принимает IP-пакеты, передаваемые по нисходящей линии связи, из RNC1 230 по его UTRAN-пути маршрутизации, RLC-объект UT подтверждает прием пакетов, тоже используя UTRAN-путь (в случае, если используется RLC подтвержденный режим).

2. Как указывалось в поле DSAP (пункт назначения) принятых TCR/IP-пакетов, извлеченная полезная нагрузка, то есть PDP IP-пакеты, передаваемые по нисходящей линии связи, должна быть направлена в вышележащий IP-уровень в UT.

3. После приема первого IP-пакета, передаваемого по нисходящей линии связи, через его порт 642, ROUTING-объект UT 240 прекращает инкапсулировать PDP IP-пакеты с PDCP и вместо этого инкапсулирует их в виде TCR/IP-кадров, используя второй IP-адрес UT 240 в качестве исходного адреса и IP-адрес RNC1 230 в качестве адреса назначения. Затем эти кадры посылают через порт 642.

На этапе 836 WLAN-IP-сеть передает эти пакеты в RNC1 230.

На этапе 838 ROUTING-объект RNC1 230 извлекает PDP IP-пакеты из принятых TCP/IP-пакетов, преобразует их в кадры обычных PDP IP-пакетов, инкапсулирует их и направляет в соответствующий GTP-U-объект для дальнейшего GTP-U-инкапсулирования и передачи по GTP-U-туннелю в направлении UMTS PS (переключенные пакеты)-домена. Идентификация конкретного GTP-U-объекта и туннеля осуществляется с использованием отношений один-к-одному между вторым IP-адресом UT (обозначенным как исходный адрес TCP/IP-пакетов) и TEID, установленным для рассматриваемого PDP-контекста, например, как показано в табл.7. Таким образом, на этапе 838 RNC1 230 завершает хэндовер сеанса с PDP-контекстом из UTRAM-пути маршрутизации по восходящей и нисходящей линиям связи на WLAN-путь маршрутизации.

Таким образом, на данном этапе PDP-сеанс маршрутизируют через AR1 255 и данные на уровне управления, ассоциированные с сеансом и/или (M)RRM-информацией, передают между UT 240 и RNC1 230 по UTRAN-пути через узел-B 250 при помощи 3GPP RRC/RLC-протоколов/сообщений и/или по пути WLAN/IP-сети через AR1 255 при помощи IAPP-протокола/сообщений или при помощи IEEE 802.11-протокола между UT 240 и AP1 265 и IAPP-протокола между AP1 265 и RNC1 230.

На этапе 840 UT 240 перемещается в зону покрытия AP2 266, ассоциированную с AR2 256 и RNC2 231, и ассоциируется с AP2 266, как описано выше. AP2 266 регистрирует WLAN MAC-адрес UT 240 в AR2 256, посылая обновленные кадры уровня 2 и/или IAPP-ADD.Notify-пакет в AR2 256, как описано выше, для регистрации WLAN MAC-адреса UT в RNC2 231. Затем AR 256 и UT 240 предпочтительно устанавливают ассоциацию безопасности, например, применяя обычную процедуру аутентификации EAP (расширенный протокол аутентификации) стандарта согласно IEEE 802.11 спецификации безопасности. Во время этой процедуры AR2 256 обычно передает свой IP-адрес в UT 240. Затем способ переходит на этап 850 в случае, если UT 240 назначают новый MIPSec-адрес, когда он "ассоциируется" с АR2 256, и переходит на этап 860 в случае, если UT 240 не назначают новый MIPSec-адрес, когда он "ассоциируется" с AR2 256. Это зависит от предварительной конфигурации сети/UT, и изобретение предоставляет решение, обеспечивающее преимущество гибкого функционирования как с "фиксированным", так и "динамическим” MIPSec-назначением.

На этапе 850 UT 240 выполняет новую процедуру назначения DHCP, как описано выше на этапе 823, и таким образом получает новый MIPSec (или MTP-адрес)-адрес. Во время этой процедуры AR2 256 также передает свой IP-адрес в UT 240, если он не был передан ранее.

На этапе 860 AR2 256 передает свой IP-адрес в UT 240, например, при помощи IAPP-протокола, если он не был передан ранее. Затем UT 240 посылает сообщение "Кандидат для хэндовера" в RNC1 230 или AR 256. Согласно изобретению это сообщение содержит (обновленный) MIP/MIPSec-адрес UT 240, который идентифицирует сеанс в RNC1 230, наряду с IP-адресом АR2 256. Это сообщение может быть послано по установленному MIP/MIPSec-соединению из UT 240 в RNC1 230 через AP1 265 и AR1 255 или в виде RRC-сообщения посредством RLC по UTRAN-пути через узел-B 250, через AR2 256 при помощи IAPP-протокола и UDP/IP между AR2 256 и RNC1 230. В случае если его посылают в AR2 256, это сообщение обычно также содержит IP-адрес RNC1 230. Затем AR2 256 обновляет соответствующим образом свои ассоциации связывания. ROUTING-объект соответствующим образом обновляет свою таблицу маршрутизации, ассоциируя сеанс с обновленным MIP/MIPSec-адресом UT 240 и IP-адресом AR2 256.

На этапе 870 MRRM-объект принимает решение о выполнении хэндовера меж-AR-RNC-сеанса, как описано выше, и посылает сообщение “Запрос на установку линии радиосвязи”, как описано выше, в RNC2 231. Затем RNC1 230 посылает сообщение "Переконфигурация физического канала" в UT 240, например, по UTRAN-пути через узел-B 250, как описано выше. После приема подтверждения/приема хэндовера из AR 256 RNC1 230 связывает идентификатор сеанса, TEID1, с IP RB ID, ассоциированным с UDP/IP-портом, ассоциированным с AR2 256, таким образом начиная маршрутизировать пакеты сеанса, передаваемые по нисходящей линии связи, в AR2 256 вместо AR1 255. Более конкретно, RNC1 230 выполняет следующие этапы, на которых:

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

- инкапсулирует пакеты IP-сеанса исходного формата передачи посредством UDP/IP или TCP/IP с IP-адресом AR2 (256) в качестве адреса назначения,

- инкапсулирует таким образом полученные UDP/IP или TCP/IP-пакеты сеанса с UDP/IP, формируя пакеты туннелирования, в которых номер UDP порта пакетов туннелирования идентифицирует меж-RNC-туннель для RNC-кандидата (231), установленного, как описано выше, и

- связывает указанный идентификатор сеанса с номером UDP порта меж-RNC-туннеля, таким образом туннелируя инкапсулированные пакеты сеанса, передаваемые по нисходящей линии связи, в RNC-кандидат (231), маршрутизируя эти пакеты через AR2 256 вместо AR 255.

На этапе 880 UT 240 принимает пакеты сеанса, передаваемые по нисходящей линии связи, и начинает посылать пакеты, передаваемые по восходящей линии связи, через AP2 266 вместо AP1 265. Затем UT 240 обычно посылает сообщение "Подтверждение хэндовера" в RNC1 230, например, через узел-B 250, как описано выше.

Таким образом, в случае динамического назначения MIP-адреса (S)RNC1 230 действует в качестве домашнего агента, в то время как UT 240 действует в качестве иностранного агента, тогда как в случае фиксированного назначения MIP-адреса (то есть UT хранит свой MIP-адрес во время всего сеанса) AR2 256 действует в качестве домашнего агента, а UT 240 - в качестве иностранного агента.

Следует отметить, что инкапсуляция IP-пакетов с GTP-U между RNC1 230 и SGSN 220, так же как между SGSN 220 и GGSN 210, остается неизменной на протяжении всего времени. Это выгодно для обеспечения непрерывного сеанса с удаленным интернет-хостом или одноранговым узлом.

Таким образом, UTRAN-радиоканал между UT 240 и RNC1 230 необязательно реализуется, даже если передача трафика по UTRAN-пути происходит не на уровне пользователя. Это выгодно, поскольку затем UTRAN-путь может использоваться для того, чтобы посылать MRRM-сообщения относительно UTRAN и/или альтернативной сети доступа, например WLAN или WLAN-IP-сети, на всем протяжении сеанса передачи данных. Кроме того, это облегчает бесшовный хэндовер сеанса из альтернативного пути маршрутизации назад на UTRAN-путь маршрутизации на более поздней стадии и позволяет эффективное гибкое управление перемещением, например, в случае обновления области местоположения для UTRAN и так далее.

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

Вышеописанный способ согласно изобретению и стеку/стекам протокола, описанным выше, обычно реализуется при помощи программного обеспечения, то есть компьютерных программ, хранящихся в запоминающих устройствах UT (240), RNC1 (230) и RNC2 231 и так далее, причем программное обеспечение реализует способ/протокол/протоколы при загрузке/работе в/на средстве обработки, например центральном процессоре, в UT (240) и RNC1 (230), RNC2 231 и так далее.

Программное обеспечение (компьютерная программа) согласно изобретению может храниться в читаемой компьютером среде различного типа, такой как, например, CD-ROM память, флэш-память и так далее, или может храниться на клиент-сервере, позволяя эффективное распределение и установку.

Принципы настоящего изобретения были описаны в вышеприведенных примерах вариантов осуществления или режимов работы, то есть в случае, когда L2-RN представляет собой WLAN. Однако, как уже было сказано, изобретение применимо для любой интегрированной сети сотовой радиосвязи и альтернативной сети радиодоступа уровня 2; возможны многие модификации и/или комбинации. Например, в случае, когда L2-сеть содержит WMAN, IEEE 802.16, AP1 265 может преобразовывать IEEE 802.3 кадры в 802.16 MAC кадры вместо 802.11 кадров. Сеть сотовой радиосвязи может представлять собой любую сеть сотовой радиосвязи, способную к установлению сеанса передачи данных, например UTRAN, UMTS-сеть, 2000 CDMA-сеть, IS-95-сеть, GPRS-сеть, D-AMPS-сеть и так далее. Возможны многочисленные модификации и/или комбинации. Различные этапы, описанные выше, не обязательно выполняются в том порядке, как они описаны выше. Поэтому изобретение не следует рассматривать как ограниченное конкретными вариантами осуществления, описанными выше, и следует учесть, что в этих вариантах осуществления специалистами в данной области техники могут быть сделаны изменения без отступления от объема настоящего изобретения, как определено прилагаемой формулой изобретения.

1. Способ выполнения хэндовера сеанса связи пользовательского терминала UT (240) в интегрированной сети с множеством технологий радиодоступа (RAT), причем указанный способ реализуется контроллером радиосети (RNC1) (230), установленным в указанной сети, при этом RNC1 (230), выполнен с возможностью маршрутизации указанного сеанса по первому пути сети радиодоступа через первый порт (273), согласно первому протоколу маршрутизации радиосети, путем связывания идентификатора сеанса, который идентифицирует указанный сеанс, с радиоканалом, определенным согласно указанному первому протоколу маршрутизации, причем указанный RNC1 (230) дополнительно выполнен с возможностью маршрутизации указанного сеанса по альтернативному пути сети радиодоступа через второй порт (272) путем связывания указанного идентификатора сеанса с идентификатором альтернативного канала, определенного согласно альтернативному протоколу сети доступа, при этом способ содержит следующие этапы, на которых:
принимают сообщение "Кандидат для хэндовера", содержащее информационный элемент идентификатора типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Кандидат для хэндовера", причем сообщение идентифицирует указанный сеанс, при этом сообщение дополнительно идентифицирует RNC-кандидата указанной сети, причем указанный RNC-кандидат является RNC-кандидатом для хэндовера указанного сеанса,
устанавливают идентичность указанного RNC путем рассмотрения указанного сообщения,
ассоциируют указанный сеанс связи с указанным RNC-кандидатом, идентифицированным на предыдущем этапе.

2. Способ по п.1, в котором указанное сообщение "Кандидат для хэндовера" содержит:
идентификатор пользовательского терминала UT ID, идентифицирующий указанный UT (240),
идентификатор точки доступа, АР2 ID, точки радиодоступа, АР2 (266), или идентификатор узла-В, Node-B ID, сигнал маяка которого детектируется указанным UT (240), причем указанный АР2 ID идентифицируется согласно указанному альтернативному протоколу сети радиодоступа, или мобильному IP-адресу, MIP, или защищенному MIP-адресу, MIPSеc, UT (240) наряду с IP-адресом маршрутизатора доступа, AR (256), ассоциированного с RNC-кандидатом (231), при этом этап установления идентичности указанного RNC-кандидата содержит этап, на котором:
проверяют сохраненную информацию, связывающую указанный АР2 ID/Node-B ID/IP-адрес AR (256) с идентичностью указанного RNC-кандидата (231),
причем этап ассоциации указанного сеанса связи с указанным RNC-кандидатом (231) содержит этап, на котором
обновляют таблицу маршрутизации для указанного сеанса, причем сеанс идентифицируется указанным UT ID, связанным с указанным идентификатором сеанса путем сохранения идентификатора, идентифицирующего указанный RNC-кандидат в указанной таблице маршрутизации.

3. Способ по п.2, в котором указанное сообщение "Кандидат для хэндовера" содержит сетевой адрес указанного RNC-кандидата (231) в качестве исходного адреса указанного сообщения, таким образом идентифицируя RNC-кандидата (231), причем указанное сообщение "Кандидат для хэндовера" получают через RNC-интерфейс, соединяющий указанный RNC1 (230) с указанным RNC-кандидатом.

4. Способ по п.2, в котором указанное сообщение "Кандидат для хэндовера" содержит сетевой адрес указанного RNC-кандидата (231), идентифицирующий RNC-кандидата (231), причем UT ID представляет собой альтернативный сетевой адрес указанного UT (240), и при этом АР2 ID представляет собой альтернативный сетевой адрес указанного АР2 (265), причем способ дополнительно содержит этап, на котором
принимают указанное сообщение "Кандидат для хэндовера" по первому пути сети радиодоступа или по альтернативному пути сети радиодоступа.

5. Способ по п.4, в котором указанный первый протокол маршрутизации сети представляет собой 3GPP-протокол, а альтернативный протокол сети доступа представляет собой IEEE 802-стандартный протокол или протокол мобильного IP, MIP или протокол защищенного мобильного IP, MIPSec, и в котором:
указанное сообщение "Кандидат для хэндовера" представляет собой RRC-сообщение, удовлетворяющее 3GPP-стандарту в случае, если указанное сообщение "Кандидат для хэндовера" принято по первому пути сети радиодоступа, и в котором
указанное сообщение "Кандидат для хэндовера" представляет собой UDP/IP-сообщение, удовлетворяющее IAPP-протоколу или LWAP-протоколу в случае, если указанное сообщение "Кандидат для хэндовера" принято по альтернативному пути сети радиодоступа.

6. Способ по любому из пп.1-5, дополнительно содержащий этапы, на которых:
маршрутизируют указанный сеанс по указанному альтернативному пути сети радиодоступа через указанный второй порт (272) и
сигнализируют данные на уровне управления и/или RRM-информацию, ассоциированную с указанным сеансом, в/из указанного UT (240) по указанному первому пути сети радиодоступа посредством указанного первого протокола маршрутизации радиосети, или
сигнализируют данные на уровне управления и/или RRM-информацию, ассоциированную с указанным сеансом в/из указанного UT (240) по указанному альтернативному пути сети радиодоступа посредством указанного альтернативного протокола маршрутизации сети доступа.

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

8. Способ по любому из пп.1-5, дополнительно содержащий этапы, на которых:
маршрутизируют указанный сеанс по указанному альтернативному пути сети радиодоступа через указанный второй порт (272) и
сигнализируют данные на уровне управления и/или RRM-информацию, ассоциированную с указанным сеансом, в UT (240) по указанному альтернативному пути сети радиодоступа.

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

10. Способ по пп.1-5, дополнительно содержащий этапы, на которых:
устанавливают, что указанный RNC-кандидат (231) не является RNC1 (230),
принимают решение о маршрутизации указанного сеанса связи через указанный RNC-кандидат,
устанавливают меж-RNС-туннельный канал через меж-RNС-интерфейс, соединяющий RNC1 (230) с указанным RNC-кандидатом.

11. Способ по п.10, дополнительно содержащий этапы, на которых
формируют сообщение "Запрос на установку линии радиосвязи", содержащее:
идентификатор типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Запрос на установку линии радиосвязи",
информационный элемент "Запрос на установку линии радиосвязи";
альтернативный сетевой адрес UT,
номер порта туннеля указанного меж-RNС-туннельного канала, и
посылают указанное сообщение "Запрос на установку линии радиосвязи" в указанный RNC-кандидат через меж-RNС-интерфейс, соединяющий RNC1 (230) с RNC-кандидатом.

12. Способ по п.11, в котором указанный информационный элемент "Запрос на установку линии радиосвязи" дополнительно содержит идентификатор типа хэндовера сеанса и/или идентификатор, идентифицирующий сигнализацию управления, ассоциированную с указанным сеансом, и/или идентификатор, идентифицирующий сеанс, причем указанный идентификатор/идентификаторы определяют один из следующих типов хэндовера:
(1) хэндовер сеанса и хэндовер на уровне управления из WLAN-пути, ассоциированного с API (265), на UTRAN-путь, ассоциированный с узлом-В (251) RNС2 (231),или
(2) хэндовер сигнализации на уровне управления из узла-В (250) радиодоступа, ассоциированного с RNC1 (230), к узлу-В-кандидату (251) радиодоступа, ассоциированному с RNC-кандидатом (230), причем хэндовер только сигнализации на уровне управления и/или RRM-информации, ассоциированной с сеансом и сигнализированной через указанный узел-В (250), должен выполняться к указанному узлу-В-кандидату (251), при этом указанная сигнализация реализуется посредством указанного первого протокола маршрутизации радиосети, или (3) хэндовер на уровне пользователя указанного сеанса из точки AP1 (265) радиодоступа, ассоциированной с RNC1 (230), в точку-кандидата АР2 (266) радиодоступа, ассоциированную с RNC-кандидатом (231), причем сеанс в текущий момент времени проводят через RNC1 (230) и через указанную точку AP1 (265) доступа, и он должен быть выполнен через RNC-кандидата (231) и через указанную точку-кандидата АР2 (266) доступа, при этом маршрутизация сеанса через указанные точки AP1 (265) и АР2 (266) доступа осуществляется посредством указанного альтернативного протокола маршрутизации сети доступа, или
(4) хэндовер на уровне пользователя или управления указанного сеанса из точки AP1 (265) радиодоступа, ассоциированной с RNC1 (230), в точку-кандидата АР2 (266) радиодоступа, ассоциированную с RNC-кандидатом (231), причем данные на уровне управления и/или RRM-информация, ассоциированная с сеансом, наряду с самим сеансом маршрутизируется в текущий момент времени через RNC1 (230) и через указанную точку AP1 (265) доступа, и должны быть маршрутизированы через RNC-кандидата (231) и через указанную точку-кандидата АР2 (266) доступа, при этом маршрутизация через указанные точки AP1 (265) и АР2 (266) доступа осуществляется посредством указанного альтернативного протокола маршрутизации сети доступа.

13. Способ по п.12, в котором указанное сообщение "Запрос на установку линии радиосвязи" дополнительно содержит
информационный элемент, определяющий требуемый уровень QoS для запрашиваемой линии/линий радиосвязи.

14. Способ по любому из пп.11-13, дополнительно содержащий этапы, на которых:
вырезают заголовки протокола из поступивших пользовательских пакетов данных IP-сеанса, передаваемых по нисходящей линии связи, таким образом преобразуя их в их исходный формат передачи,
добавляют LLC-заголовки к исходным пользовательским пакетам данных IP-сеанса, передаваемым по нисходящей линии связи, преобразуя их в формат LLC согласно указанному альтернативному протоколу сети доступа с адресом исходной LLC-сети RNC1 (230),
связывают указанный идентификатор сеанса с идентификатором туннеля, идентифицирующим меж-RNС-туннельный канал, таким образом выполняя туннелирование указанных LLC-пакетов сеанса в RNC-кандидат.

15. Способ по любому из пп.11-13, дополнительно содержащий этапы, на которых:
вырезают заголовки протокола из поступивших пользовательских данных IP-сеанса, передаваемых по нисходящей линии связи, таким образом преобразуя их в их исходный формат передачи,
связывают указанный идентификатор сеанса с идентификатором туннеля, идентифицирующим меж-RNС-туннельный канал, таким образом выполняя туннелирование указанных пользовательских данных сеанса исходного формата передачи в RNC-кандидат (231).

16. Способ по п.2 или любому из пп.11-13, в котором UT ID сообщения "Кандидат для хэндовера" представляет собой адрес мобильного IP, MIP или защищенный адрес MIP, MIPSec, UT; и в котором сообщение "Кандидат для хэндовера" содержит IP-адрес маршрутизатора доступа, AR (256), ассоциированный с RNC-кандидатом (231), причем способ дополнительно содержит этапы, на которых:
идентифицируют сеанс посредством MIP/MIPSec-адреса UT (240), связанного с сеансом,
обновляют таблицу маршрутизации сеанса при помощи IP-адреса AR (256),
вырезают заголовки протокола туннелирования из поступивших пользовательских пакетов данных IP-сеанса, передаваемых по нисходящей линии связи, таким образом преобразуя их в их исходный формат передачи,
инкапсулируют пакеты IP-сеанса исходного формата передачи посредством UDP/IP или TCP/IP с IP-адресом AR (256) в виде адреса назначения,
инкапсулируют таким образом полученные UDP/IP или ТСР/IР-пакеты сеанса с UDP/IP, формируя пакеты туннелирования, причем номер UDP порта пакетов туннелирования идентифицирует меж-RNС-туннель для RNC-кандидата (231), установленного как описано выше, и
связывают указанный идентификатор сеанса с номером UDP порта меж-RNC-туннеля, таким образом туннелируя инкапсулированные пакеты сеанса, передаваемые по нисходящей линии связи, в RNC-кандидат (231), и маршрутизируют пакеты через AR2 (256) вместо AR (255).

17. Способ по п.16, в котором RNC1 (230) маршрутизирует сеанс связи для RNC-кандидата по меж-RNС-туннелю, причем указанный способ дополнительно содержит этап, на котором:
маршрутизируют сеанс по альтернативному пути сети радиодоступа через второй порт (272) параллельно с маршрутизацией сеанса по меж-RNC-туннелю для RNC-кандидата.

18. Способ по п.17, дополнительно содержащий этапы, на которых
принимают сообщение "Подтверждение хэндовера" из UT (240), причем сообщение содержит:
идентификатор типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Подтверждения хэндовера",
информационный элемент диссоциации и сетевой адрес точки AP1 (265) радиодоступа, причем UT (240) больше не ассоциирован с AP1 (265), и
информационный элемент "Подтверждения хэндовера" наряду с сетевым адресом точки АР2 (266) радиодоступа, с которой в текущий момент времени ассоциирован UT (240),
причем сетевые адреса указанных AP1 (265) и АР2 (266) определяются согласно указанному альтернативному протоколу сети доступа, и при этом способ дополнительно содержит этап, на котором
блокируют маршрутизацию сеанса по альтернативному пути сети радиодоступа через второй порт (272) в виде ответа при приеме указанного сообщения "Подтверждение хэндовера".

19. Способ по любому из пп.1-5, дополнительно содержащий этапы, на которых:
принимают решение о маршрутизации сеанса через указанного RNC-кандидата, устанавливают, что сеанс не может быть маршрутизирован последовательно через RNC1 (230) и RNC-кандидата (231),
идентифицируют узел (220) поддержки передачи пакетных данных, соединенный и с RNC1 (230), и с RNC-кандидатом (231), и через узел (220) поддержки передачи пакетных данных которого выполняется маршрутизация сеанса в текущий момент времени,
формируют сообщение "Необходимое RNC-перемещение", содержащее:
информационный элемент "Идентификатор типа сообщения", идентифицирующий указанное сообщение как являющееся сообщением "Необходимое RNC-перемещение",
идентификатор, идентифицирующий RNC-кандидата (231),
сетевой адрес UT (240), как определено согласно альтернативному протоколу сети доступа,
туннельный идентификатор туннеля между RNC (230) и узлом (220) поддержки передачи пакетных данных, через который выполняется туннелирование сеанса в текущий момент времени, и
направляют указанное сообщение "Необходимое RNC-перемещение" в указанный узел (220) поддержки передачи пакетных данных, таким образом запрашивая для сеанса перемещение обслуживания RNC из указанного RNC1 (230) в указанный RNC-кандидата (231).

20. Способ по п.19, в котором этап принятия решения о маршрутизации сеанса через указанного RNC-кандидата (231) содержит следующие этапы, на которых:
принимают сообщение "Подтверждения хэндовера" из UТ (240), причем сообщение содержит:
информационный элемент идентификатора типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Подтверждения хэндовера",
информационный элемент диссоциации и сетевой адрес точки AP1 (265) радиодоступа, причем UT (240) больше не ассоциирован с AP1 (265), и
информационный элемент "Подтверждение хэндовера" наряду с сетевым адресом точки АР2 (266) радиодоступа, с которой UT (240) ассоциирован в текущий момент времени,
причем сетевые адреса указанных AP1 (265) и АР2 (266) определены согласно указанному альтернативному протоколу сети доступа, и при этом способ дополнительно содержит этап, на котором
отменяют альтернативный идентификатор канала, определяемый согласно альтернативному протоколу сети доступа, таким образом отменяя назначение радиоканала, ассоциированного с передачей сеанса по альтернативному пути сети радиодоступа, таким образом блокируя маршрутизацию сеанса по альтернативному пути сети радиодоступа в виде ответа на прием указанного сообщения "Подтверждение хэндовера".

21. Способ по п.20, в котором этап принятия решения о хэндовере сеанса через указанного RNC-кандидата дополнительно содержит следующие этапы, на которых:
собирают RRM-информацию относительно по меньшей мере точек AP1 (265) и АР2 (266) радиодоступа, чьи сигналы маяка в текущий момент времени детектируются UT (240), причем указанная RRM-информация сигнализируется по первому пути сети радиодоступа или по альтернативному пути сети радиодоступа,
принимают предварительное решение о хэндовере, основанное на указанной собранной RRM-информации, и
посылают сообщение "Физическая переконфигурация канала" в UT (240), содержащее идентификатор инструкций для хэндовера и альтернативный сетевой адрес АР2 (266), причем сообщение инструктирует UT (240) о маршрутизации сеанса через АР2 (266) вместо AP1 (265).

22. Способ по п.20 или 21, в котором этап сбора RRM-информации относительно по меньшей мере точек AP1 (265) и АР2 (266) радиодоступа, сигналы маяка которых в текущий момент времени детектируются UT (240), дополнительно содержит этап, на котором:
принимают сообщение-отчет об измерении управляющих радиоресурсов, RRC, по первому пути сети радиодоступа или по меж-RNС-интерфейсу, причем сообщение соответствует формату 3GPP RRC-стандарта и содержит информационный элемент "Дополнительные измеренные результаты", указывающий на АР2 (266) как на целевую точку доступа, или
принимает сообщение-отчет об измерении RRC, соответствующее стандартному формату RRC-сообщения согласно указанной альтернативной сети радиодоступа, причем указанное сообщение RRC содержит информационный элемент "Дополнительные измеренные результаты", указывающий на АР2 (266) как на целевую точку доступа.

23. Способ по любому из пп.1-5, в котором указанная сеть с множеством RAT представляет собой интегрированную 3GPP-UTRAN-IEEE 802-WLAN-сеть, указанный сеанс связи представляет собой 3GPP-сеанс с PDP-контекстом, указанный первый протокол маршрутизации радиосети представляет собой протокол 3GPP UTRAN-стандарта, указанный идентификатор сеанса представляет собой идентификатор конечной точки GTP-U-туннеля согласно протоколу 3GPP UTRAN-стандарта, TEID, UDP/IP-туннеля между RNC1 (230) и SGSN (220), указанный радиоканал согласно указанному первому протоколу маршрутизации представляет собой 3GPP RB ID, указанный альтернативный идентификатор канала представляет собой идентификатор WLAN радиоканала, WLAN RB ID, или идентификатор радиоканала мобильного IP, MIP RB ID, или идентификатор радиоканала защищенного мобильного IP, MIP/IPSec RB ID, указанный альтернативный протокол сети доступа представляет собой IEEE 802 WLAN-протокол, или IP/MIP/IPSec-протокол, или их комбинацию, указанный UT ID представляет собой WLAN МАС-адрес UT (240), или MIP-адрес UT (240), или MIPSec-адрес UT (240), указанный АР2 ID представляет собой WLAN МАС-адрес АР2 (266), указанный узел-В ID представляет собой 3GPP идентификатор, идентифицирующий узел-В (251), указанный второй сетевой адрес UT (240) представляет собой МТР или MTPSec-адрес, указанный идентификатор, идентифицирующий указанного RNC-кандидата, представляет собой IP-адрес или UTRAN МАС-адрес RNC-кандидата, указанный первый интерфейс, соединяющий указанный RNC1 (231) с указанным RNC-кандидатом (231), представляет собой 3GPP lur-интерфейс, указанный сетевой адрес указанного RNC-кандидата представляет собой UTRAN МАС-адрес или IP-адрес RNC-кандидата (231), и причем указанное сообщение "Запрос на установку линии радиосвязи" соответствует 3GPP-формату сообщения "Запрос на установку линии радиосвязи", и при этом сетевой адрес точек радиодоступа, AP1 (265), UT (240) и АР2 (266) представляют собой WLAN МАС-адреса API (265), UT (240) и АР2 (266) соответственно, указанный узел (220) поддержки пакетной передачи данных представляет собой 3GPP SGSN (220), причем формат сообщения "Запрошенное RNC-перемещение" соответствует 3GPP-формату сообщения «Запрошенное RNC-перемещение».

24. Читаемая компьютером среда, имеющая программное кодовое средство, которое, когда оно загружено в средство обработки RNC1 (230), устанавливается в сети с множеством RAT, причем RNC1 (230) выполнен с возможностью маршрутизировать указанный сеанс по первому пути сети радиодоступа через первый порт (273), согласно первому протоколу маршрутизации радиосети, путем связывания идентификатора сеанса, идентифицирующего указанный сеанс, с радиоканалом согласно указанному первому протоколу маршрутизации, при этом указанный RNC1 (230) дополнительно выполнен с возможностью маршрутизировать указанный сеанс по альтернативному пути сети радиодоступа через второй порт (272) путем связывания указанного идентификатора сеанса с альтернативным идентификатором канала, определенным согласно альтернативному протоколу сети доступа заставить указанное средство обработки выполнять по меньшей мере одну процедуру, реализуя способ по любому из пп.1-23.

25. Способ выполнения хэндовера сеанса связи пользовательского терминала UT (240) в интегрированной сети с множеством RAT, причем указанный способ осуществляется RNC-кандидатом (231), установленным в указанной сети, причем RNC-кандидат (231) является кандидатом для хэндовера сеанса, и при этом RNC-кандидат (231) выполнен с возможностью маршрутизировать сеанс по первому пути сети радиодоступа через первый порт (278) согласно первому протоколу маршрутизации радиосети путем связывания идентификатора сеанса, идентифицирующего указанный сеанс, с радиоканалом, определенным согласно указанному первому протоколу маршрутизации, причем указанный RNC-кандидат (231) дополнительно выполнен с возможностью маршрутизировать сеанс по альтернативному пути сети радиодоступа через второй порт (277) путем связывания идентификатор сеанса, идентифицирующий сеанс, с альтернативным идентификатором канала, определенным согласно альтернативному протоколу сети доступа, причем указанный способ содержит следующие этапы, на которых:
принимают сообщение "Запрос на установку линии радиосвязи" из соседнего RNC1 (230) в текущий момент времени маршрутизирующего сеанс, ассоциированный с UT,
извлекают из сообщения "Запрос на установку линии радиосвязи" номер туннельного порта меж-RNС-туннеля между RNC1 (230) и RNC-кандидатом (231),
извлекают из сообщения "Запрос на установку линии радиосвязи" идентификатор UT, идентифицирующий UT (240),
ассоциируют указанный номер туннельного порта с UT (240) и с сеансом, ассоциированным с UT (240),
извлекают идентификатор типа хэндовера сеанса указанного сообщения "Запрос на установку линии радиосвязи",
устанавливают канал радиотрафика для маршрутизации сеанса указанного UT (240) согласно указанному идентификатору типа хэндовера.

26. Способ по п.25, дополнительно содержащий этапы, на которых:
принимают сообщение "Кандидат для хэндовера", содержащее:
информационный элемент идентификатора типа сообщения, идентифицирующий указанное сообщение как являющееся сообщением "Кандидат для хэндовера", и
идентификатор точки доступа, АР2 ID, точки АР2 (266) радиодоступа или идентификатор узла-В, Node-B ID узла-В (251), сигнал маяка которого детектируется указанным UT (240), причем указанный АР2 ID определяется согласно указанному альтернативному протоколу сети радиодоступа или мобильному IP-адресу, MIP, или защищенному адресу MIP, MIPSec, UT (240) наряду с IP-адресом маршрутизатора AR (256) доступа, ассоциированного с RNC-кандидатом (231), причем сообщение "Кандидат для хэндовера" идентифицирует UT (240), и
устанавливает, что указанный UT (240) не имеет активного сеанса, маршрутизируемого через RNC-кандидата (231).

27. Способ по п.26, в котором указанное сообщение "Кандидат для хэндовера" принимают по меж-RNС-интерфейсу из RNC1 (230), маршрутизирующему сеанс в текущий момент времени, причем способ дополнительно содержит этапы, на которых:
узнают, что исходный сетевой адрес указанного сообщения "Кандидат для хэндовера" представляет собой сетевой адрес RNC1 (230), и делают вывод о том, что в текущий момент времени сеанс маршрутизируется через RNC1 (230),
устанавливают меж-RNС-туннель между RNC1 (230) и RNC-кандидатом (231).

28. Способ по п.26, дополнительно содержащий этапы на которых:
принимают указанное сообщение "Кандидат для хэндовера" из UT (240) по первому пути сети радиодоступа или по альтернативному пути сети радиодоступа,
направляют указанное сообщение "Кандидат для хэндовера" в соседние с ним RNC.

29. Способ по любому из пп.26-28, в котором идентификатор точки доступа представляет собой идентификатор соты узла доступа АР2 (266) указанного альтернативного пути сети радиодоступа, причем указанный элемент идентификатора типа хэндовера сеанса указывает, что сеанс должен быть маршрутизирован через АР2 (266), причем этап установки канала радиотрафика для UT (240) дополнительно содержит этапы, на которых:
устанавливают логическое LLC-соединение через порт (277) с UT (240) через АР2 (266), причем LLC-соединение устанавливают при помощи альтернативного протокола сети доступа,
ассоциируют сеанс с LLC-соединением.

30. Способ по п.29, дополнительно содержащий этапы, на которых:
принимают пакеты сеанса, передаваемые по нисходящей линии связи, по туннелю, идентифицируемому указанным номером туннельного порта,
вырезают заголовки протокола туннелирования из принятых пакетов, передаваемых по нисходящей линии, получая таким образом пакеты сеанса, имеющие формат согласно альтернативному протоколу сети доступа, причем пакеты имеют исходный сетевой адрес RNC1 (230) как определено указанным альтернативным протоколом сети доступа,
направляют полученные таким образом пакеты сеанса через порт (277), таким образом маршрутизируя пакеты в UT (240) через АР2 (266).

31. Способ по п.29, дополнительно содержащий этапы, на которых:
принимают пакеты сеанса, передаваемые по нисходящей линии связи, по туннелю, идентифицируемому указанным номером туннельного порта,
вырезают заголовки протокола туннелирования из принятых пакетов, получая таким образом пакеты сеанса, имеющие формат согласно альтернативному протоколу сети доступа, причем пакеты имеют исходный сетевой адрес RNC1 (230), как определено указанным альтернативным протоколом сети доступа,
вырезают заголовки инкапсуляции из полученных таким образом пакетов, причем заголовки инкапсуляции были добавлены RNC1 (230) при помощи альтернативного протокола сети доступа, таким образом преобразуя пакеты, передаваемые по нисходящей линии связи, в их исходный формат передачи,
добавляют LLC-заголовки к пакетам сеанса с исходным форматом передачи, передаваемым по нисходящей линии связи, преобразуя их в LLC-формат согласно указанному альтернативному протоколу сети доступа протокола с исходным LLC-сетевым адресом RNC-кандидата (231),
направляют сформированные таким образом LLC-пакеты сеанса через порт (277), таким образом маршрутизируя пакеты в UT (240) через АР2 (266).

32. Способ по любому из пп.26-28, в котором сообщение "Кандидат для хэндовера" содержит мобильный IP-адрес, MIP, или защищенный адрес MIP, MIPSec, UT (240) наряду с IP-адресом маршрутизатора AR (256) доступа, ассоциированный с RNC-кандидатом (23), причем идентификатор UT-сообщения "Запрос на установку линии радиосвязи" представляет собой соответствующий MIP/MIPSec-адрес UT (240), при этом меж-RNC-туннель представляет собой UDP/IP-туннель, причем способ дополнительно содержит этапы, на которых:
извлекают MIP/MIPSec UT (240) из указанного сообщения "Запрос на установку линии радиосвязи",
ассоциируют номер туннельного порта с MIP/MIPSec UT (240) и с IP-адресом AR (256),
принимают идентификацию сеанса при помощи MIP/MIPSec-адреса UT (240), связанного с сеансом,
обновляют таблицу маршрутизации сеанса с IP-адресом AR (256), принимают IP-инкапсулированные пакеты IP-сеанса, передаваемые по нисходящей линии связи, по RNC UDP/IP-туннелю,
вырезают UDP/IP-заголовки туннелирования из IP-инкапсулированных пакетов IP-сеанса, передаваемых по нисходящей линии связи, получая пакеты IP-сеанса, передаваемые по нисходящей линии связи, инкапсулированные с IP, причем IP-адрес инкапсуляции пакетов IP-сеанса представляет собой IP-адрес AR2 (256), и
направляют пакеты IP-сеанса, передаваемые по нисходящей линии связи, инкапсулированными с IP-адресом AR (256), в порт (277), ассоциированный с AR (256), таким образом маршрутизируя пакеты IP-сеанса, передаваемые по нисходящей линии связи, в UT (240) через AR (256) и АР2 (266).

33. Способ по любому из пп.25-28, в котором указанная сеть с множеством RAT представляет собой интегрированную 3GPP-UTRAN -IEEE 802-WLAN-ceть, указанный сеанс связи представляет собой 3GPP-сеанс с PDP-контекстом, указанный первый протокол маршрутизации радиосети представляет собой 3GРР-протокол UTRAN-стандарта, указанный идентификатор представляет собой идентификатор конечной точки GTP-U-туннеля согласно протоколу 3GPP UTRAN-стандарта, TEID, UDP/IP-туннеля между RNC1(230) и RNC-кандидатом (231), указанный радиоканал согласно указанному первому протоколу маршрутизации представляет собой 3GPP RB ID, указанный альтернативный идентификатор канала представляет собой идентификатор WLAN радиоканала, WLAN RB ID, или идентификатор радиоканала мобильного IP, MIP RB ID, или идентификатор радиоканала защищенного мобильного IP, MIP/IPSec RB ID, указанный альтернативный протокол сети доступа представляет собой IEEE 802 WLAN-протокол, или IP/MIP/IPSec-протокол, или их комбинацию, указанный UT ID представляет собой WLAN МАС-адрес UT (240), или MIP-адрес UT (240), или MIPSec-адрес UT (240), указанный АР2 ID представляет собой WLAN МАС-адрес АР2 (266), указанный Node-B ID представляет собой 3GPP идентификатор, идентифицирующий узел-В (251), указанный второй адрес сети UT (240) представляет собой MIP или MIPSec-адрес, причем указанное сообщение "Запрос на установку линии радиосвязи" соответствует 3GPP формату сообщения "Запрос на установку линии радиосвязи", при этом сетевой адрес точек радиодоступа AP1 (265), UT (240) и АР2 (266) представляет собой WLAN МАС-адреса AP1 (256), UT (240) и АР2 (266) соответственно.

34. Читаемая компьютером среда, хранящая программное кодовое средство, которое, если оно загружено в средство обработки RNC-кандидата (231), установленного в указанной сети, причем RNC-кандидат (231) представляет кандидата для хэндовера для сеанса, при этом RNC-кандидат (231) выполнен с возможностью маршрутизации сеанса по первому пути сети радиодоступа через первый порт (278), согласно первому протоколу маршрутизации радиосети, путем связывания идентификатора сеанса, идентифицирующего указанный сеанс, с радиоканалом, определенным согласно указанному первому протоколу маршрутизации, причем указанный RNC-кандидат (231) дополнительно выполнен с возможностью маршрутизации сеанса по альтернативному пути сети радиодоступа через второй порт (277) путем связывания идентификатора сеанса, идентифицирующего сеанс, с альтернативным идентификатором канала, определенным согласно альтернативному протоколу сети доступа, заставлять средство обработки выполнять по меньшей мере одну процедуру, реализуя способ согласно любому из пп.26-34.

35. Контроллер RNC1 (230) радиосети, который выполнен с возможностью маршрутизации по первому пути сети радиодоступа через первый порт (273) согласно первому протоколу маршрутизации радиосети путем связывания идентификатора сеанса, идентифицирующего указанный сеанс, с радиоканалом, определенным согласно указанному первому протоколу маршрутизации, причем указанный RNC1 (230) дополнительно выполнен с возможностью маршрутизировать по альтернативному пути сети радиодоступа через второй порт (272) путем связывания указанного идентификатора сеанса с альтернативным идентификатором канала, определенным согласно альтернативному протоколу сети доступа, причем указанный RNC содержит средство, реализующее способ по любому из пп.1-23.

36. Контроллер RNC1 (230) по п.35, в котором указанное средство содержит память данных со средством кодирования хранящейся программы, которое, если оно загружено в средство обработки указанного RNC1 (230), заставляет указанное средство обработки выполнять по меньшей мере одну процедуру, реализуя способ по любому из пп.1-23.

37. Контроллер радиосети RNC2 (231), выполненный с возможностью маршрутизировать сеанс по первому пути сети радиодоступа через первый порт (278), согласно первому протоколу маршрутизации радиосети, путем связывания идентификатора сеанса, идентифицирующего указанный сеанс, с радиоканалом, определенным согласно указанному первому протоколу маршрутизации, причем указанный RNC2 (231) дополнительно выполнен с возможностью маршрутизировать по альтернативному пути сети радиодоступа через второй порт (277) путем связывания идентификатора сеанса, идентифицирующего сеанс, с альтернативным идентификатором канала, определенным согласно альтернативному протоколу сети доступа, причем указанный RNC2 (231) содержит средство, реализующее способ согласно любому из пп.26-34.

38. Контроллер RNC2 (231) по п.37, в котором указанное средство содержит память данных со средством кодирования сохраненной программы, которое, если оно загружено в средство обработки указанного RNC1 (230), заставляет указанное средство обработки выполнять по меньшей мере одну процедуру, реализующее способ согласно любому из пп.26-34.