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

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

Иллюстрации

Показать все

Реферат

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

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Так как Институт инженеров по электротехнике и электронике (IEEE) 802.16 предусматривает высокие скорости осуществления доступа, форум по международной совместимости для микроволнового доступа (WiMAX) на основе IEEE 802.16 используется более и более широко. Сетевая архитектура WiMAX в предшествующем уровне техники включает в себя: мобильную станцию (MS), сеть служб доступа (ASN) и сеть служб возможности соединения (CSN). MS является мобильным абонентским терминалом, с помощью которого пользователь осуществляет доступ к сети WiMAX. ASN включает в себя базовую станцию (BS) и шлюз ASN (GW) и предусматривает терминал WiMAX с набором сетевых функций служб беспроводного доступа. BS и ASN GW включают в себя эти функциональные объекты: функцию физического уровня/функцию управления доступом к среде (PHY/MAC), функцию пути данных (DPF), аутентификатор, администратор потока служб (SFM) и внешний агент (FA). CSN адаптируется для предоставления служб IP-соединения (интернет-протокола) для WiMAX-терминала. AAA-сервер (аутентификация, авторизация и учет) в домашней CSN пользователя отвечает за аутентификацию и авторизацию пользователя.

SFM расположен в ASN и отвечает за создание, допуск, активацию, модификацию и удаление потоков служб. SFM составлен из функции управления допуском (ACF) и информации локальных ресурсов, коррелированной с ACF. ACF делает вывод, является ли новый поток служб приемлемым согласно существующим радиоресурсам и локальным ресурсам. Точное определение управления допуском предопределяется производителем в реализации. SFM обычно расположен в BS. Авторизатор потока служб (SFA) расположен в ASN. На этапе сетевого доступа, когда профиль качества обслуживания (QoS) пользователя загружается из AAA-сервера в SFA, SFA отвечает за оценку любого служебного запроса согласно профилю QoS. Для указанной ASN либо поставщика сетевого доступа (NAP) каждая MS имеет домашний SFA.

В настоящее время система связи WiMAX с множеством хостов включает в себя: мобильную станцию шлюза (G-MS), BS, NAP, ASN GW, поставщика сетевых служб (NSP) и CSN. G-MS соединяется с BS с помощью интерфейса WiMAX и хост осуществляет доступ к сети через G-MS. BS одного NAP соединяется с BS другого NAP через интерфейс R8; BS соединяется с ASN GW через интерфейс R6, интерфейс между ASN GW является интерфейсом R4, и ASN GW соединяется с CSN NSP с помощью интерфейса R3.

Способ для создания ISF в предшествующем уровне техники:

G-MS инициирует аутентификацию 802.lx для хоста и получает идентификатор сетевого доступа (NAI) хоста;

G-MS запускает HAAA-сервер (домашний сервер аутентификации, авторизации и учета) для осуществления аутентификации расширяемого протокола 802.lx аутентификации (EAP) для хоста, где аутентификация запускается с помощью сообщения запроса-доступа, сообщение запроса-доступа пересылается BS и ААА-прокси в HAAA-сервер, сообщение EAP_Id_Rsp инкапсулировано в сообщение запроса-доступа и посылается хостом, и сообщение EAP_Id_Rsp переносит NAI;

HAAA-сервер посылает сообщение принятия-доступа в G-MS, где сообщение принятия-доступа пересылается AAA-прокси и BS, и переносит сообщение успеха EAP (EAP-Success); и

G-MS извлекает сообщение принятия-доступа, чтобы получить сообщения успеха EAP (EAP-Success), и посылает его в хост.

Таким образом, аутентификация 802.lx для хоста завершается, и хост знает, что ему разрешено инициировать процесс адресации интернет-протокола или процессу регистрации мобильного IP (MIP).

Политика (PF), расположенная в CSN, посылает сообщения запроса резервирования ресурсов (RR-Req) в SFA и SFA пересылает сообщение в SFM.

SFM запускает BS для посылки сообщения запроса дополнения динамического служебного потока (DSA-Req) в G-MS и устанавливает соединение радиоинтерфейса для хоста согласно заранее установленной информации.

После приема сообщения DSA-Req G-MS возвращает сообщение ответа дополнения динамического служебного потока (DSA-Rsp) в BS.

BS запускает SFM для посылки сообщения ответа резервирования ресурсов (RR-Rsp) в SFA, и SFA пересылает сообщение в PF.

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

Способ для создания ISF в варианте осуществления настоящего изобретения включает в себя:

посылку запроса создания потока служб для запуска объекта создания ISF для создания ISF для хоста, где запрос создания потока служб переносит информацию о хосте; и

прием ответа о создании потока служб на запрос создания потока служб.

Компьютерный программный продукт предусматривается в варианте осуществления настоящего изобретения. Компьютерный программный продукт включает в себя коды компьютерной программы. При выполнении компьютером коды компьютерной программы заставляют компьютер осуществлять любой этап способа для создания ISF.

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

Устройство для создания ISF в варианте осуществления настоящего изобретения включает в себя:

блок посылки запроса, адаптированный для посылки запроса создания потока служб для запуска объекта создания ISF для создания ISF для хоста, где запрос создания потока служб переносит информацию о хосте; и

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

Система связи предусмотрена в варианте осуществления настоящего изобретения и включает в себя:

базовый SFA, приспособленный для: посылки первого RR-Req для создания ISF для хоста, где первый RR-Req переносит информацию о хосте; и приема первого RR-Rsp на первый RR-Req;

обслуживающая SFA, адаптированная для приема первого RR-Req и посылки запроса регистрации пути данных (PathRegReq) или второго RR-Req, где Path_Reg_Req или второй RR-Req переносит информацию о хосте; приема ответа о регистрации пути данных (PathRegRsp) на PathRegReq, или второй RR-Rsp на второй RR-Req, и посылает первый RR-Rsp на первый RR-Req; и

BS, адаптированная для приема PathRegReq либо второго RR-Req и посылки запроса дополнения динамического служебного потока (DSA-Req), либо запроса изменения динамического служебного потока (DSC-Req), где DSA-Req либо DSC-Req переносит информацию о хосте; приема ответа дополнения к динамическому служебному потоку (DSA-Rsp) либо ответа изменения динамического служебного потока (DSC-Rsp) в DSA-Req либо DSC-Req, и посылает Path_Reg_Rsp на Path_Reg_Req либо второй RR-Rsp на второй RR-Req; и

G-MS, адаптированная для создания ISF согласно информации о хосте после приема DSA-Req либо DSC-Req и посылки DSA-Rsp либо DSC-Rsp в DSA-Req либо DSC-Req.

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

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

Фиг.1 является блок-схемой последовательности операций способа для создания ISF в первом варианте осуществления настоящего изобретения;

Фиг.2 является блок-схемой последовательности операций способа для создания ISF во втором варианте осуществления настоящего изобретения;

Фиг.3 является блок-схемой сигнализации способа для создания ISF в третьем варианте осуществления настоящего изобретения;

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

Фиг.5 является структурой устройства для создания ISF в варианте осуществления настоящего изобретения;

Фиг.6 показывает структуру системы связи в первом варианте осуществления настоящего изобретения; и

Фиг.7 показывает структуру системы связи во втором и третьем вариантах осуществления настоящего изобретения.

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

Фиг.1 является блок-схемой последовательности операций способа для создания ISF в первом варианте осуществления настоящего изобретения. Способ включает в себя следующие этапы:

Этап 101: Послать запрос создания потока служб для запуска объекта создания ISF для создания ISF для хоста, где запрос создания потока служб переносит информацию о хосте.

В этом варианте осуществления это может быть базовый SFA, который посылает запрос создания потока служб для инициирования создания ISF для хоста; информация о хосте может включать в себя ID хоста и/или параметры для создания ISF. Таким образом, объект создания ISF, который создает ISF, может определять хост, в соответствии с которым должен быть создан ISF, и параметры, которым необходимо соответствовать созданной ISF.

Этап 102: Принимать ответ о создании потока служб на запрос создания потока служб.

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

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

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

Этап 201: базовый SFA принимает указание принятия-доступа от HAAA-сервера, который указывает разрешение на доступ к хосту.

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

Этап 202: базовый SFA уведомляет хост об успехе аутентификации.

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

В этом варианте осуществления успех авторизации хоста может уведомляться с помощью этих этапов: базовый SFA посылает сообщение завершения ретрансляции аутентификации EAP (AR_EAP_Complete) в BS, и сообщение об успехе EAP (EAP-Success) заключается в сообщение AR_EAP_Complete. Сообщение успеха EAP переносит информацию об успехе аутентификации хоста. BS посылает сообщение ответа управления ключами секретности (PKM) в G-MS, и сообщение об успехе EAP заключается в сообщении ответа PKM. G-MS посылает расширяемый протокол аутентификации по LAN (EAPoL)-пакетное сообщение в хост, сообщение об успехе EAP заключается в пакетное сообщение EAPoL.

Этап 203: базовый SFA посылает запрос создания потока служб для инициирования создания ISF для хоста.

Запрос создания потока служб переносит информацию о хосте. Информация о хосте включает в себя ID хоста и/или параметры для создания ISF. Таким образом, объект, который создает ISF, знает о хосте, соответствующем ISF, который необходимо создать, и параметры, которым необходимо соответствовать ISF. Параметры могут быть получены от HAAA-сервера.

Этап 204: базовый SFA принимает ответ о создании потока служб на запрос создания потока служб.

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

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

Следует отметить, что в этом варианте осуществления этап 202 может происходить до или после этапа 203, этап 202 и этап 203 происходят после этапа 201. Предпочтительно, чтобы этап 202 происходил после этапа 204. В этом случае хост может получать уведомление об успехе аутентификации одновременно с получением уведомления о завершении создания ISF для хоста для осуществления доступа к сети, хост может определять, когда инициировать процесс адресации интернет-протокола или процесс регистрации MIP, и эффективность обработки системы улучшается.

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

Фиг.3 является блок-схемой сигнализации способа для создания ISF во втором варианте осуществления настоящего изобретения. Способ включает в себя следующие этапы:

Этап 301: G-MS оканчивает осуществления доступа к сети.

Этот процесс освещен в предшествующем уровне техники и не описан подробно в данном документе.

Этап 302: Хост осуществляет доступ к G-MS и инициирует процесс аутентификации.

В этом варианте осуществления хост может инициировать аутентификацию с помощью начального сообщения расширяемого протокола аутентификации по сети LAN (EAPoL) либо с помощью других сообщений.

Этап 303: Осуществляют процесс аутентификации хоста пользователя. В этом процессе базовый SFA хоста знает о G-MS ID и ID аутентификатора G-MS и коррелирует их с контекстом хоста. Кроме того, на этом этапе хост может также осуществлять аутентификацию сетевого входа устройства.

Этап 304: После успешной аутентификации хоста HAAA-сервер посылает сообщения принятия-доступа в аутентификатор, которое указывает успешную аутентификацию в хосте.

В этом варианте осуществления аутентификатор может быть граничным с базовый SFA. Сообщение принятия-доступа переносит информацию о безопасности и профиль QoS хоста. Профиль QoS хоста включает в себя информацию о создании ISF и/или предварительно обеспеченного потока служб (PPSF) для хоста. Тем не менее, аутентификатор и базовый SFA могут также быть двумя независимыми физическими объектами.

Этап 305: Аутентификатор запускает базовый SFA для посылки первого сообщения RR-Req в обслуживающий SFA, таким образом запуская обслуживающий SFA хоста для создания ISF для хоста.

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

Информация хоста, например ID хоста, вводится в заголовок сообщения RR-Req-сообщения, и соответствующая информация хоста и информация ISF хоста вводятся в «тип-длина-значение» (TLV) информацию MS существующего RR-Req-сообщения. Кроме того, соответствующее G-MS ID TLV может быть добавлено в RR-Req-сообщение для указания G-MS, которая обслуживает хост. Таблица 1 показывает G-MS ID TLV, предусмотренное в варианте осуществления настоящего изобретения.

Таблица 1
Тип	102
Длина, измеряемая в байтах	6
Значение	48-битовый G-MS MAC-адрес
Описание	Уникальный G-MS ID, который может быть G-MS МАС-адресом

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

G-MS ID является вводом в заголовок сообщения RR-Req-сообщения, и соответствующая информация хоста и ISF-информация хоста (а именно соответствующее Info TLV хоста) добавляются в MS Info TLV существующего RR-Req-сообщения. Info TLV хоста включает в себя ID TLV хоста. Таблица 2 показывает ID TLV хоста, предусмотренного в варианте осуществления настоящего изобретения.

Таблица 2
Тип	Необходимо определить (TBD)
Длина, измеряемая в байтах	6
Значение	48-bit МАС-адрес хоста
Описание	Уникальный ID хоста, который может быть МАС-адресом хоста

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

Этап 306: Обслуживающий SFA посылает сообщение PathRegReq или второе RR-Req-сообщение в DPF на BS. Создание ISF происходит в то же самое время установления пути данных.

Конкретно, сообщение PathRegReq либо сообщение RR-Req посылается в DPF, расположенную в BS.

Кроме того, расширение сообщения Path_Reg_Req может происходить в момент расширения RR-Req-сообщения. Способ для расширения сообщения PathRegReq в варианте осуществления настоящего изобретения описан ниже:

ID хоста является вводом в заголовок сообщения Path_Reg_Req-сообщения соответствующей информации хоста и ISF-информация хоста является вводом в MS Info TLV в существующее Path_Reg_Req-сообщение, и соответствующее G-MS ID TLV добавляется в сообщение. G-MS ID TLV, предусмотренное в варианте осуществления настоящего изобретения, показано в таблице 1 выше.

Аналогично расширению RR-Req-сообщения другой способ расширения Path_Reg_Req-сообщения предусматривается в варианте осуществления настоящего изобретения, как описано ниже:

G-MS ID является вводом в заголовок сообщения Path_Reg_Req-сообщения, и соответствующая информация хоста и ISF-информация хоста добавляются к MS Info TLV в существующем Path_Reg_Req-сообщении, а именно соответствующее Info TLV хоста добавляется в сообщение. Info TLV хоста включает в себя ID TLV хоста. ID TLV хоста, предусмотренное в варианте осуществления настоящего изобретения, показано на таблице 2 выше.

Этап 307: BS посылает DSA-Req либо DSC-Req-сообщение (DSA-Req-сообщение) DSA-Req-сообщение и так далее и совместно называемое DSx-Req-сообщение) и создает однонаправленный канал ISF по радиоинтерфейсу.

Более точно, SFM, расположенный в BS, посылает DSA-Req-сообщение для создания нового соединения радиоинтерфейса для хоста или посылает DSC-Req-сообщение для выделения заранее установленного соединения радиоинтерфейса с хостом либо посылает другое аналогичное функциональное сообщение.

Когда существуют множественные хосты, DSA-Req либо DSC-Req-сообщение может расширяться так, чтобы G-MS могло бы сообщаться о хосте, специфичном для ISF.

Способ указания хоста, специфичного для ISF в варианте осуществления настоящего изобретения, описан ниже:

Зарезервированное поле в DSA-Req либо DSC-Req-сообщении переносит информацию хоста, например MAC-адрес хоста.

Альтернативно, 6-байтовое поле названия класса глобальной службы в DSA-Req или DSC-Req-сообщение переносит информацию хоста, например ID хоста.

Если подуровень сходимости (CS) является подуровнем сходимости Ethernet (Eth-CS), так как Eth-CS использует MAC-адрес, как правило, классификации, и MAC-адрес является ID хоста, G-MS может использовать MAC-адрес в классификаторе непосредственно для идентификации хоста, специфичного для сигнализации.

DSA-Req или DSC-Req-сообщение передается по первичному идентификатору соединения (CID) G-MS. Следовательно, G-MS может обнаруживать первичный CID для определения, что сообщение посылается BS в G-MS, не является необходимым для DSA-Req либо DSC-Req-сообщения переносить соответствующий G-MS ID, и на исходные параметры сообщения не воздействуют переносом G-MS ID. Так как никакой G-MS ID не нужно переносить, ресурсы радиоинтерфейса экономятся.

Этап 308: После приема DSA-Req либо DSC-Req-сообщения G-MS устанавливает ISF для хоста и возвращает a DSA-Rsp либо DSC-Rsp-сообщение.

Этап 309: После приема DSA-Rsp либо DSC-Rsp-сообщения BS возвращает Path_Reg_Rsp-сообщение либо второе RR-Rsp-сообщение в обслуживающий SFA.

Если Path_Reg_Req-сообщение расширяется, Path_Reg_Rsp-сообщение может, соответственно, расширяться. Способ расширения является аналогичным расширению Path_Reg_Req-сообщения.

Этап 310: После приема Path_Reg_Rsp-сообщения обслуживающая SFA посылает первое RR-Rsp-сообщение в базовый SFA.

Если RR-Req-сообщение расширяется, RR-Rsp-сообщение может соответственно расширяться. Способ расширения является аналогичным расширению RR-Req-сообщения.

Этап 311: После приема первого RR-Rsp-сообщения базовый SFA посылает сообщение подтверждения приема резервирования ресурсов (RR_Ack) в обслуживающий SFA, указывающий, что первое RR-Rsp-сообщение принимается.

Этап 312: После приема Path_Reg_Rsp-сообщения обслуживающий SFA возвращает сообщение подтверждения приема регистрации пути данных (Path_Reg_Ack) в BS.

Этап 313: После осведомленности завершения создания ISF базовый SFA запускает аутентификатор для посылки AR_EAP_Complete-сообщения в BS.

EAP-Success-сообщение инкапсулировано в сообщение AR_EAP_Complete.

Следует отметить, что этап 311 может происходить до либо после этапа 313.

Этап 314: После приема AR_EAP_Complete-сообщения BS инкапсулирует EAP-Success-сообщение в AR_EAP_Complete-сообщение как сообщение ответа управления ключами секретности версии 2 (PKMv2-Rsp) и посылает PKMv2-Rsp-сообщение в G-MS.

Этап 315: После приема PKMv2-Rsp-сообщения G-MS начинает соответствующее управление доступом и посылает EAPoL-пакетное сообщение (EAPoL-Packet) в хост, указывая завершение авторизации хоста.

EAP-Success-сообщение инкапсулировано в сообщение EAPoL-Packet. Дополнительно, соответствующая ISF-информация может переноситься в сообщении EAP-Success, так чтобы хост знал о параметрах QoS ISF хоста.

После приема EAPoL-Packet-сообщения хост знает о том, что аутентификация завершена и создается ISF, и он готов инициировать процесс адресации интернет-протокола либо процесс регистрации MIP.

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

Фиг.4 является блок-схемой сигнализации способа для создания ISF в третьем варианте осуществления настоящего изобретения. Способ включает в себя следующие этапы:

Этап 401: G-MS оканчивает осуществления доступа к сети.

Этап 402: хост осуществляет доступ к G-MS и инициирует процесс аутентификации с помощью сообщения начала EAPoL (EAPoL-Start).

Этап 403: Осуществляется процесс аутентификации хоста пользователя. В этом процессе базовый SFA хоста знает о G-MS ID и ID аутентификатора G-MS и коррелирует их с контекстом хоста. Дополнительно, на этом этапе устройства, которые осуществляют доступ к сети с помощью хоста, могут быть аутентифицированы.

Этап 404: После успешной аутентификации хоста HAAA-сервер посылает сообщение принятия-доступа в аутентификатор, которое указывает успешную аутентификацию хоста.

В этом варианте осуществления аутентификатор может быть граничным с базовым SFA. Сообщение принятие-доступ переносит информацию о безопасности и профиль QoS хоста. Профиль QoS хоста включает в себя информацию о создании ISF и PPSF для хоста. Тем не менее, аутентификатор и базовый SFA могут также быть двумя независимыми физическими объектами.

Этап 405: Аутентификатор посылает сообщение AR_EAP_Complete в BS.

EAP-Success-сообщение инкапсулировано в сообщение AR_EAP_Complete.

Этап 406: После приема сообщения AR_EAP_Complete BS инкапсулирует EAP-Success-сообщение в сообщение AR_EAP_Complete как PKMv2-Rsp-сообщение и посылает PKMv2-Rsp-сообщение в G-MS.

Этап 407: После приема PKMv2-Rsp-сообщения G-MS начинает соответствующее управление доступом и посылает EAPoL-Packet-сообщение в хост, указывая завершение авторизации хоста.

Этап 408: После посылки AR_EAP_Complete-сообщения аутентификатор запускает базовый SFA для посылки первого RR-Req-сообщения в обслуживающий SFA, таким образом запуская обслуживающий SFA хоста для создания ISF для хоста.

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

Информация хоста, например ID хоста, является вводом в заголовок сообщения RR-Req-сообщения, и соответствующая информация хоста и информация ISF хоста являются вводом в MS Info TLV существующего RR-Req-сообщения. Кроме того, соответствующее G-MS ID TLV может быть добавлено в RR-Req-сообщение для указания G-MS, которая обслуживает хост. G-MS ID TLV, предусмотренное в этом варианте осуществления, показано в таблице 1 выше.

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

G-MS ID является вводом в заголовок сообщения PR-Req-сообщения, и соответствующая информация хоста и ISF-информация хоста добавляются к MS Info TLV в существующем RR-Req-сообщении, а именно соответствующее Info TLV хоста добавляется в сообщение. Info TLV хоста включает в себя ID TLV хоста. ID TLV хоста, предусмотренное в варианте осуществления настоящего изобретения, показано в таблице 2 выше.

Этап 409: Обслуживающий SFA посылает сообщение Path_Reg_Req или второе RR-Req-сообщение в DPF на BS. Создание ISF происходит в то же самое время установления пути данных.

Конкретно, сообщение PathRegReq либо второе сообщение RR-Req посылается в SFM, расположенный в BS.

Кроме того, расширение сообщения Path_Reg_Req может происходить в момент расширения RR-Req-сообщения. Способ для расширения сообщения Path_Reg_Req в варианте осуществления настоящего изобретения описан ниже:

ID хоста является вводом в заголовок сообщения Path_Reg_Req-сообщения, соответствующая информация хоста и ISF-информация хоста являются вводом в MS Info TLV в существующее Path_Reg_Req-сообщение, и соответствующее G-MS ID TLV добавляется в сообщение. G-MS ID TLV, предусмотренное в варианте осуществления настоящего изобретения, показано в таблице 1 выше.

Аналогично расширению RR-Req-сообщения другой способ расширения Path_Reg_Req-сообщения предусматривается в варианте осуществления настоящего изобретения, как описано ниже:

G-MS ID является вводом в заголовок сообщения Path_Reg_Req-сообщения, соответствующая информация хоста и ISF-информация хоста добавляются в MS Info TLV в существующее Path_Reg_Req-сообщение, а именно соответствующее Info TLV хоста добавляется в сообщение. Info TLV хоста включает в себя ID TLV хоста. ID TLV хоста, предусмотренное в варианте осуществления настоящего изобретения, показано в таблице 2 выше.

Этап 410: BS посылает DSA-Req или DSC-Req-сообщение и создает однонаправленный канал ISF по радиоинтерфейсу.

Конкретно, SFM, расположенный в BS, посылает DSA-Req-сообщение для создания нового соединения радиоинтерфейса для хоста или посылает DSC-Req-сообщение для выделения заранее установленного соединения радиоинтерфейса с хостом либо посылает другое DSx-Req-сообщение.

DSA-Req или DSC-Req-сообщение может быть расширено так, чтобы G-MS знало о хосте, специфичном для ISF.

Способ указания хоста, специфичного для ISF в варианте осуществления настоящего изобретения, описан ниже:

Зарезервированное поле в DSA-Req либо DSC-Req-сообщении переносит информацию хоста, например MAC-адрес хоста.

Альтернативно, 6-байтовое поле названия класса глобальной службы в DSA-Req или DSC-Req-сообщение переносит информацию хоста, например ID хоста.

Если CS является подуровнем Eth-CS, так как Eth-CS использует MAC-адрес, как правило, классификации и MAC-адрес является ID хоста, G-MS может использовать MAC-адрес в классификаторе непосредственно для идентификации хоста, специфичного для сигнализации.

DSA-Req или DSC-Req-сообщение передается по первичному CID G-MS. Следовательно, G-MS может обнаруживать первичный CID для определения, что сообщение посылается BS в G-MS, не является необходимым для DSA-Req либо DSC-Req-сообщения переносить соответствующий G-MS ID и на исходные параметры сообщения не воздействуют переносом G-MS ID. Так как никакой G-MS ID не нужно переносить, ресурсы радиоинтерфейса экономятся.

Этап 411: После приема DSA-Req либо DSC-Req-сообщения G-MS устанавливает ISF для хоста и возвращает a DSA-Rsp либо DSC-Rsp-сообщение.

Этап 412: После приема DSA-Rsp либо DSC-Rsp-сообщения BS возвращает Path_Reg_Rsp-сообщение либо второе RR-Rsp-сообщение в обслуживающий SFA.

Если Path_Reg_Req-сообщение расширяется, Path_Reg_Rsp-сообщение может, соответственно, расширяться. Способ расширения является аналогичным расширению Path_Reg_Req-сообщения.

Этап 413: После приема Path_Reg_Rsp-сообщения обслуживающий SFA посылает первое RR-Rsp-сообщение в базовый SFA.

Если RR-Req-сообщение расширяется, RR-Rsp-сообщение может соответственно расширяться. Способ расширения является аналогичным расширению RR-Req-сообщения.

Этап 414: После приема первого RR-Rsp-сообщения базовый SFA посылает первое RR_Ack-сообщение в обслуживающий SFA.

Этап 415: После приема Path_Reg_Rsp-сообщения обслуживающий SFA возвращает Path_Reg_Ack-сообщение в BS.

Следует отметить, что этап 413 может происходить до либо после этапа 415.

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

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

Фиг.5 показывает структуру устройства для создания ISF в варианте осуществления настоящего изобретения. Устройство включает в себя:

блок 501 посылки запроса, адаптированный для посылки запроса создания потока служб для запуска объекта создания ISF для создания ISF для хоста, где запрос создания потока служб переносит информацию о хосте; и

блок 502 приема ответа, адаптированный для приема ответа создания потока служб на запрос создания потока служб.

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

Устройство для создания ISF в этом варианте осуществления может служить как SFA в системе связи.

Устройство для создания ISF в этом варианте осуществления может дополнительно включать в себя:

блок приема указания, адаптированный к приему указания принятия-доступа, которое указывает разрешение доступа к хосту от HAAA-сервера, где в этом случае блок 501 посылки запроса адаптируется для посылки запроса создания потока служб после указания, что блок приема принимает указание принятия-доступа.

Устройство для создания ISF в этом варианте осуществления может дополнительно включать в себя:

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

Устройство для создания ISF в этом варианте осуществления может дополнительно включать в себя:

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

Первый модуль уведомления и второй модуль уведомления могут быть интегрированы вместе.

Система связи предусмотрена в варианте осуществления настоящего изобретения. Фиг.6 показывает структуру системы связи в первом варианте осуществления настоящего изобретения. Система включает в себя:

базовый SFA 601, приспособленный для посылки первого RR-Req для создания ISF для хоста, где первый RR-Req переносит информацию о хосте; и приема первого RR-Rsp на первый RR-Req;

обслуживающая SFA 602, адаптированная для приема первого RR-Req и посылки Path_Reg_Req или второго RR-Req, где Path_Reg_Req или второй RR-Req переносит информацию о хосте; приема Path_Reg_Rsp на Path_Reg_Req, или второй RR-Rsp на второй RR-Req, и посылает первый RR-Rsp на первый RR-Req;

BS 603, адаптированная для приема Path_Reg_Req или второго RR-Req и посылки DSA-Req или DSC-Req, где DSA-Req или DSC-Req переносит информацию о хосте; приема DSA-Rsp или DSC-Rsp в DSA-Req или DSC-Req и посылки Path_Reg_Rsp на Path_Reg_Req или второго RR-Rsp на второй RR-Req; и

G-MS 604, адаптированная для создания ISF согласно информации о хосте после приема DSA-Req либо DSC-Req и посылки DSA-Rsp либо DSC-Rsp в DSA-Req либо DSC-Req.

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

Фиг.7 показывает структуру системы связи во втором варианте осуществления настоящего изобретения. Система связи включает в себя:

HAAA-сервер 701, приспособленный для аутентификации хоста и посылки указания принятия-доступа разрешения доступа хоста после того, как следует аутентификация;

базовый SFA 702, адаптированный для посылки первого RR-Req для создания ISF для хоста после приема указания принятия-доступа, где первый RR-Req переносит информацию о хосте; приема первого RR-Rsp для первого RR-Req и посылки AR_EAP_Complete-сообщения после приема первого RR-Rsp-сообщения, где AR_EAP_Complete-сообщение переносит информацию об успехе аутентификации хоста и завершении создания ISF;

обслуживающий SFA 703, адаптированный для приема первого RR-Req и посылки Path_Reg_Req или второго RR-Req; приема Path_Reg_Rsp на Path_Reg_Req или второго RR-Rsp на второй RR-Req и посылки первого RR-Rsp на первый RR-Req;

BS 704, приспособленную для приема Path_Reg_Req или второго RR-Req и второго DSA-Req или DSC-Req; приема DSA-Rsp или DSC-Rsp в DSA-Req или DSC-Req и посылки Path_Reg_Rsp на Path_Reg_Req или второй RR-Rsp на второй RR-Req и посылки сообщения ответа PKM (PKM-Rsp) после приема AR_EAP_Complete-сообщения, где EAP-Success-сообщение инкапсулировано в PKM-Rsp-сообщение; и

G-MS 705, приспособленную для создания ISF согласно информации о хосте после приема DSA-Req или DSC-Req и посылки DSA-Rsp или DSC-Rsp в DSA-Req или DSC-Req и посылки EAPoL-Packet-сообщения после приема PKM-Rsp-сообщения, где EAP-Success-сообщение инкапсулировано в EAPoL-Packet-сообщение; и

хост 706, адаптированный для приема EAPoL-Packet-сообщения.

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