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

Изобретение относится к беспроводной связи, а именно к способам и устройствам для создания первоначального потока служб (ISF). Техническим результатом является более полное использование системных ресурсов. Технический результат достигается тем, что способ для создания первоначального потока служб (ISF) содержит этапы, на которых: посылают запрос создания потока служб для запуска объекта создания ISF для создания ISF для хоста согласно информации о хосте, причем запрос создания потока служб переносит упомянутую информацию о хосте, и принимают ответ о создании потока служб на запрос создания потока служб. 3 н. и 16 з.п. ф-лы, 7 ил.

 

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

Настоящее изобретение относится к технологиям беспроводной связи и, в частности, к способу, устройству и системе связи для создания первоначального потока служб (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 соответствует специфичному хосту, и системные ресурсы полностью используются. После того как хост проходит аутентификацию, аутентификатор не уведомляет об успехе аутентификации в хост немедленно, но сначала создает ISF для хоста. После завершения создания этого ISF аутентификатор уведомляет об успехе аутентификации и о завершении создания ISF в хост. Следовательно, хост может определять, когда инициировать процесс обращения к интернет-протоколу или процесс регистрации MIP, и эффективность обработки системы улучшается.

Как показано на фиг.7, система связи, предусмотренная в третьем варианте осуществления настоящего изобретения, включает в себя:

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

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

обслуживающий 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-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 соответствует специфичному хосту, и системные ресурсы полностью используются.

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

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

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

Запоминающая среда может быть постоянным запоминающим устройством (ROM), магнитным диском либо CD-ROM.

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

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

2. Способ для создания ISF по п.1, в котором до посылки запроса о создании потока служб способ дополнительно содержит этап, на котором:
принимают индикацию принятия-доступа разрешения доступа хоста от НААА-сервера (домашний сервер аутентификации, авторизации и учета).

3. Способ для создания ISF по п.2, в котором после приема индикации принятия-доступа разрешения доступа хоста от НААА-сервера способ дополнительно содержит этап, на котором:
уведомляют об успехе аутентификации в хост.

4. Способ для создания ISF по п.3, в котором уведомление об успехе аутентификации содержит этапы, на которых:
посылают сообщение завершения ретрансляции аутентификации ЕАР (AR_EAP_Complete) в базовую станцию (BS), при этом EAP-Success-сообщение инкапсулировано в AR_ЕАР_Complete-сообщение, причем EAP-Success-сообщение содержит информацию об успехе аутентификации хоста;
посылают с помощью BS сообщение ответа управления ключами секретности (PKM-Rsp) в мобильную станцию шлюза (G-MS), при этом EAP-Success-сообщение инкапсулировано в PKM-Rsp-сообщение; и
посылают с помощью G-MS расширяемый протокол аутентификации с помощью пакетного сообщения локальной вычислительной сети (EAPoL-Packet) в хост, при этом EAP-Success-сообщение инкапсулировано в EAPoL-Packet-сообщение.

5. Способ для создания ISF по п.3, в котором после приема ответа создания потока служб на запрос создания потока служб способ дополнительно содержит этап, на котором:
создают ISF и уведомляют хост о завершении создания ISF.

6. Способ для создания ISF по п.5, в котором уведомление хоста о завершении создания ISF содержит этапы, на которых:
уведомляют хост о завершении создания ISF с помощью EAP-Success-сообщения; или
с помощью переноса информации о ISF в EAP-Success-сообщении.

7. Способ для создания ISF по любому из пп.1-6, при этом объектом создания ISF является G-MS, и посылка запроса создания потока служб для запуска объекта создания ISF для создания ISF содержит этапы, на которых:
посылают первый запрос резервирования ресурсов (RR-Req) в авторизатор потока служб (SFA), при этом первый RR-Req переносит информацию о хосте;
посылают с помощью обслуживающего SFA запрос регистрации пути данных (Path_Reg_Req) или второй RR-Req в BS, при этом Path_Reg_Req или второй RR-Req переносят информацию о хосте;
посылают с помощью BS запрос дополнения динамического служебного потока (DSA-Req) или запрос изменения динамического служебного потока (DSC-Req) в G-MS, при этом DSA-Req или DSC-Req переносят информацию о хосте;
устанавливают с помощью G-MS ISF согласно информации о хосте после приема DSA-Req или DSC-Req, и посылают ответ дополнения динамического служебного потока (DSA-Rsp) или ответ изменения динамического служебного потока (DSC-Rsp) в ответ на DSA-Req или DSC-Req;
посылают с помощью BS ответ регистрации пути данных (Path_Reg_Rsp) на Path_Reg_Req или второй ответ резервирования ресурсов (RR-Rsp) на второй RR-Req, в обслуживающий SFA; и
посылают с помощью обслуживающего SFA первый RR-Rsp на первый RR-Req.

8. Способ для создания ISF по п.7, в котором:
первый RR-Req и первый RR-Rsp дополнительно переносят информацию о хосте и информацию о G-MS.

9. Способ для создания ISF по п.8, в котором:
первый RR-Req и первый RR-Rsp переносят упомянутую информацию о хосте и дополнительно переносят информацию тип-длина-значение (TLV) G-MS; или
первый RR-Req и первый RR-Rsp переносят информацию о G-MS и дополнительно переносят информацию TLV хоста.

10. Способ для создания ISF по п.8, в котором:
Path_Reg_Req и Path_Reg_Rsp содержат информацию о хосте и информацию о G-MS; или
второй RR-Req и второй RR-Rsp содержат информацию о хосте и информацию о G-MS.

11. Способ для создания ISF по п.10, в котором:
Path_Reg_Req является сообщением запроса регистрации пути данных и Path_Reg_Rsp является сообщением ответа регистрации пути данных; либо второй RR-Req является вторым сообщением запроса резервирования ресурсов, и второй RR-Rsp является вторым сообщением ответа резервирования ресурсов;
заголовок сообщения Path_Reg_Req и заголовок сообщения Path_Reg_Rsp либо заголовок сообщения второго RR-Req и заголовок сообщения RR-Rsp переносят информацию о хосте и дополнительно переносят TLV информацию G-MS; или
заголовок сообщения Path_Reg_Req и заголовок сообщения Path_Reg_Rsp или заголовок сообщения второго RR-Req и заголовок сообщения RR-Rsp переносят информацию о G-MS и дополнительно переносят TLV информацию хоста.

12. Способ для создания ISF по п.7, в котором:
DSA-Req является сообщением запроса дополнения динамического служебного потока и DSC-Req является сообщением запроса изменения динамического служебного потока; и зарезервированное поле DSA-Req- или DSC-Req-сообщения переносят информацию о хосте; или поле имени класса глобальной службы DSA-Req- или DSC-Req-сообщения переносит информацию о хосте; или если подуровень сходимости Ethernet (Eth-CS) используют как подуровень сходимости (CS), адрес управления доступом к среде (MAC) в TLV классификатора в DSA-Req- или DSC-Req-сообщении используют для индикации информации о хосте.

13. Устройство для создания первоначального потока служб (ISF), содержащее:
блок посылки запроса, адаптированный для посылки запроса создания потока служб для запуска объекта создания ISF для создания ISF для хоста согласно информации о хосте, причем запрос создания потока служб переносит упомянутую информацию о хосте; и
блок приема ответа, адаптированный для приема ответа создания потока служб на запрос создания потока служб.

14. Устройство для создания ISF по п.13, дополнительно содержащее:
блок приема индикации, адаптированный для приема индикации принятия-доступа разрешения доступа к хосту от домашнего сервера аутентификации, авторизации и учета (НААА-сервера), причем блок посылки запроса дополнительно адаптирован для посылки запроса создания потока служб после того, как блок приема указания принимает индикацию принятия-доступа.

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

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

17. Система связи, содержащая:
базовый авторизатор потока служб (SFA), адаптированный для: посылки первого запроса резервирования ресурсов (RR-Req) для создания первоначального потока служб (ISF) для хоста, при этом первый RR-Req переносит информацию о хосте; и приема первого ответа резервирования ресурсов (RR-Rsp) на первый RR-Req;
обслуживающий SFA, адаптированный для: приема первого 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), адаптированная для: приема 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), адаптированная для: создания ISF согласно информации о хосте после приема DSA-Req либо DSC-Req и посылки DSA-Rsp либо DSC-Rsp на DSA-Req либо DSC-Req.

18. Система связи по п.17, дополнительно содержащая:
домашний сервер аутентификации, авторизации и учета (НААА-сервер), адаптированный для: аутентификации хоста и посылки индикации принятия-доступа разрешения доступа к хосту после успешной аутентификации, при этом:
базовый SFA дополнительно адаптирован для: приема индикации принятия-доступа, посылки первого RR-Req после приема индикации принятия-доступа и посылки сообщения завершения ретрансляции аутентификации ЕАР (AR_EAP_Complete) после приема первого RR-Rsp, при этом сообщение AR_EAP_Complete переносит информацию об успехе аутентификации хоста и завершении создания ISF;
BS дополнительно адаптирована для посылки сообщения ответа управления ключами секретности (PKM-Rsp) после приема сообщения AR_EAP_Complete, при этом EAP-Success-сообщение инкапсулировано в PKM-Rsp-сообщение;
G-MS дополнительно адаптирована для посылки расширяемого протокола аутентификации с помощью пакетного сообщения локальной вычислительной сети (EAPoL-Packet) после приема PKM-Rsp-сообщения, в котором EAP-Success-сообщение инкапсулировано в EAPoL-Packet-сообщение; и
хост адаптирован для приема EAPoL-Packet-сообщения.

19. Система связи по п.18, дополнительно содержащая:
домашний сервер аутентификации, авторизации и учета (НААА-сервер), адаптированный для: аутентификации хоста и посылки индикации принятия-доступа разрешения доступа к хосту после успешной аутентификации, при этом:
базовый SFA дополнительно адаптирован для: приема индикации принятия-доступа, посылки первого RR-Req после приема индикации принятия-доступа и посылки сообщения завершения ретрансляции аутентификации ЕАР (AR_EAP_Complete) после приема индикации принятия-доступа, при этом сообщение AR_EAP_Complete переносит информацию об успехе аутентификации хоста;
BS дополнительно адаптирована для посылки сообщения ответа управления ключами секретности (PKM-Rsp) после приема сообщения AR_EAP_Complete, при этом EAP-Success-сообщение инкапсулировано в PKM-Rsp-сообщение;
G-MS дополнительно адаптирована для посылки расширяемого протокола аутентификации с помощью пакетного сообщения локальной вычислительной сети (EAPoL-Packet) после приема PKM-Rsp-сообщения, в котором EAP-Success-сообщение инкапсулировано в EAPoL-Packet-сообщение; и
хост адаптирован для приема EAPoL-Packet-сообщения.