БЫСТРОЕ УСТАНОВЛЕНИЕ СОЕДИНЕНИЯ ДЛЯ ДОСТУПА К СЕТИ Российский патент 2009 года по МПК H04L12/28 H04L29/06 

Настоящая Заявка на патент заявляет приоритет Предварительной заявки США № 60/592 470, озаглавленной "Method and Apparatus for Fast Packet Data Session Establishment", зарегистрированной 30 июля 2004 года и назначенной правопреемнику этой заявки, и таким образом явно содержится в данном документе посредством ссылки.

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

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

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

Глобальное взаимодействие сетей позволяет информации быть быстро доступной независимо от географических расстояний. Фиг. 1 показывает упрощенный схематический чертеж глобального соединения сетей, обычно именуемого как Интернет, обозначенный ссылкой с номером 20. Интернет 20 является, в сущности, многими сетями с разными уровнями иерархии, связанными вместе. Интернет 20 работает по IP (протоколу Интернета), опубликованному IETF (инженерной проблемной группой Интернет). Детали IP могут быть найдены в RFC (Запросы на комментарии) 791, опубликованные IETF.

Подсоединенными к Интернету 20 являются разные отдельные сети, иногда называемые LAN (локальные вычислительные сети) или WAN (глобальные вычислительные сети) в зависимости от размеров сети. Показанные на фиг. 1 являются некоторыми из таких сетей 22, 24 и 26.

В каждой из сетей 22, 24 и 26 могут быть разные части оборудования, соединенные с и во взаимодействии друг с другом. Примерами являются компьютеры, принтеры и серверы, если назвать только немногие, которые обычно называются узлами. Когда узел осуществляет связь за пределами своей собственной сети через Интернет 20, узлу должен быть назначен IP-адрес. Назначение IP-адреса может быть ручным или автоматическим. Ручное назначение IP-адреса может быть выполнено сетевым администратором, например. Более часто, IP-адрес назначается автоматически, например, выделенным сервером в LAN.

Возьмем пример для иллюстрации. Предположим, что узел 30 в сети 22 пытается отправить пакет данных другому узлу 34 в сети 24. Под управлением IP каждый пакет данных должен иметь адрес источника и адрес получателя. В этом случае адрес источника - это адрес узла 30 в сети 22. Адрес получателя - это адрес узла 34 в сети 24.

Очень часто требуются соединения узел-узел перед доступом к сети, такой как Интернет 20. Например, предположим, что узел 30 в сети 22 является портативным компьютером. Узел 30 портативного компьютера не имеет прямого доступа к сети 22. Тем не менее узел 30 портативного компьютера может связаться с NAS (сервером доступа к сети) 32 в сети 22 через некоторые другие средства, например, посредством коммутируемого вызова проводного модема через телефонную линию. В этом случае, узел 30 типично устанавливает сеанс PPP (протокол точка-точка) с NAS (сервером доступа к сети) 32 в сети 22. Передачи пакетов данных после того, как установлены между узлом 30 и сетью 22 или любыми другими сетями через Интернет 20, будут проходить через проводной модем и телефонную линию. Если модем передает и принимает сигналы последовательно и асинхронно через телефонную линию, пакеты данных, передаваемые по телефонной линии, также должны быть соответственно разбиты на кадры, чтобы удовлетворять требованиям последовательной и асинхронной модемной линии связи.

Приход беспроводных технологий позволяет узлам перемещаться из своей первоначально зарегистрированной сети в другую сеть. Например, обращаясь опять к фиг. 1, узел 30 вместо постоянно связанного проводом с сетью 22 может быть беспроводным устройством, таким как PDA (персональный цифровой помощник), сотовым телефоном или мобильным компьютером. Беспроводной узел 30 может передвигаться за границы своей домашней сети 22. Таким образом, узел 30 может передвигаться далеко от своей домашней сети 22 в чужую сеть 26. Чтобы получить доступ к сети 26 или быть соединенным с другими сетями через Интернет 20, узел 30 также типично устанавливает PPP-сеанс с NAS (сервером доступа к сети) 33 в сети 26. Связь между узлом 30 и NAS 33 в этом случае существует через радиоканал. С другой стороны, пакеты данных, передаваемые между узлом 30 и беспроводной сетью, также должны быть разбиты на кадры, чтобы умещаться в формат, который установлен во время PPP-сеанса между узлом 30 и NAS 33 через радиоканал.

Основная часть PPP описывается в RFC 1661 и 1662, опубликованных IETF. PPP является протоколом взаимодействия равноправных систем, в котором оба узла являются равноправными. То есть, никто не принимает на себя роль ни клиента, ни сервера. Каждая сторона может запросить действия или выполнить действия по отношению к другой. По существу, PPP является исследовательским и договаривающимся сеансом между узлами, во время которого узлы узнают о ресурсах друг друга в терминах возможностей и доступности и окончательно приближаются к тому, чтобы установить взаимно приемлемые варианты параметров, прежде какого-либо потока сетевого трафика.

Фиг. 2 показывает блок-схему последовательности примерного PPP-сеанса 34 связи, в котором узел 30 в сети 26 стремится установить канал связи (прим: соединение, канал связи - любой вид коммуникационного пути между двумя компьютерами (получателем и отправителем данных)) с NAS 32 для получения доступа к Интернету 20.

PPP имеет ряд компонентов протокола. В примерном PPP-сеансе, показанном на фиг. 2, PPP имеет LCP (протокол управления соединением) 36, CHAP (протокол аутентификации по методу "вызов-приветствие") 38 и IPCP (протокол конфигурации протокола Интернета) 40 в качестве компонентов.

Сначала, после завершения установления физического канала связи, то есть узел 30 и NAS 33 способны связаться друг с другом на аппаратном уровне, например, есть необходимость пройти через LCP 36. LCP 36 служит цели установления основного канала связи между узлом 30 и NAS 33. Во время LCP 36 узел 30 и NAS 33 обмениваются и обсуждают необходимые варианты параметров связи друг с другом. Варианты могут включать в себя максимальный размер пакета данных в канале связи, параметры, относящиеся к управлению качеством, используемую схему сжатия поля HDLC (высокоуровневый протокол управления каналом передачи данных) заголовка и готов ли равноправный участник сети быть аутентифицированным.

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

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

Как упомянуто ранее, PPP является протоколом взаимодействия равноправных систем. Либо узел 30, либо NAS 33 может быть запрашивающей стороной. То же самое считается истинным для роли отвечающей стороны. Все параметры с ассоциативно связанными вариантами должны быть обсуждены и отрегулированы таким образом, как описано выше. Может потребоваться несколько циклов согласования, как показано на фиг. 2. Общая схема согласования в своей основе является односторонним процессом. Если запрашивающая сторона определяет, что все необходимые параметры являются приемлемыми для отвечающей стороны, запрашивающая сторона отправляет финальное сообщение о подтверждении приема конфигурации отвечающей стороне. После того как обе стороны отправили сообщения подтверждения приема конфигурации, они затем переходят к фазе аутентификации.

Чтобы гарантировать, что стороны авторизованы, должна быть выполнена аутентификация. Одним способом выполнить аутентификацию является использовать другой PPP-компонент CHAP 38. Это типично NAS 33, который инициирует CHAP 38, чтобы проверить идентичность узла 30. Во время CHAP 38 NAS 33 отправляет сообщение, называемое сообщением вызова, узлу 30. Под управлением CHAP существует совместно используемый секрет, который используется вместе с сообщением вызова, который используется, чтобы вычислить ответное сообщение с использованием предварительно согласованного алгоритма. Узел 30 затем отправляет ответное сообщение, сгенерированное секретным алгоритмом, к NAS 33. NAS 33 после этого сравнивает принятое ответное сообщение с сообщением, вычисленным самим NAS 33. Если сравнение указывает совпадение, узлу 30 говорится перейти к CHAP 38, в котором NAS 33 отправляет сообщение об успехе CHAP узлу 30. Иначе сервером NAS 33 отправляется сообщение о неудаче CHAP.

Альтернативно, вместо CHAP 38 аутентификация может быть выполнена посредством прохождения через PAP (протокол аутентификации по паролю). В PAP узел просто отправляет NAS 33 имя пользователя и пароль для проверки. Если подтверждено, узлу 30 говорится перейти к PAP.

Если узлу 30 нужен IP-доступ, информация, относящаяся к IP, опять должна быть передана и согласована. Например, среди прочего узлу 30 может быть необходимо иметь назначение IP-адреса для того, чтобы получить доступ к Интернет 20 (фиг. 1) в соответствии с IP. Чтобы достичь этой цели, начинается согласование и обмен вариантов параметров по IPCP 40. В примерном PPP-сеансе 34 узел 30 первоначально запрашивает IP-адрес 0.0.0.0 у NAS 33. В ответ NAS 33 отправляет сообщение об отсутствии подтверждения приема конфигурации, предлагая узлу 30 использовать IP-адрес a.b.c.d. Если принято, узел 30 подтверждает использование IP-адреса a.b.c.d, отправляя NAS 33 другое сообщение для подтверждения приема.

В конечном счете, когда узел 30 согласовывает все параметры, обсужденные во время IPCP 40, узел 30 отправляет сообщение о подтверждении приема к NAS 33. Впоследствии передаются пользовательские данные сеанса доступа к сети. IP-пакеты данных сетевого трафика инкапсулируются в PPP-кадры с параметрами и согласовываются во время LCP 36 ранее.

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

Как может быть видно на фиг. 2 и описано выше, в самом деле существует ряд сообщений, передаваемых между узлом 30 и NAS 33 во время PPP-сеанса 34. По существу, затрачивается значительная продолжительность времени. Это особенно верно, если PPP-сеанс 34 согласовывается по медленному каналу связи с высокой латентностью данных.

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

Сущность изобретения

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

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

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

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

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

Краткое описание чертежей

Фиг. 1 - схематический чертеж глобального соединения сетей.

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

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

Фиг. 4 - схематический чертеж, показывающий стек протоколов в иерархическом порядке.

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

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

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

Фиг. 8 - соответствующая блок-схема для схемы последовательности соединения на фиг. 7.

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

Фиг. 10 - соответствующая блок-схема для схемы последовательности соединения на фиг. 9.

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

Фиг. 12 - схема последовательности соединения сеанса связи на фиг. 1, осуществленного с дополнительными типами сообщений.

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

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

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

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

Фиг. 3 показывает упрощенный схематический чертеж узлов, затронутых в примерном варианте осуществления изобретения. Общая система связи обозначается ссылкой с номером 42. В этом варианте осуществления система 42 связи включает в себя сеть 48, соединенную с базовой сетью 50, которая может быть интранетом или Интернетом. В сети 48 располагается NAS (сервер доступа к сети), который служит в качестве шлюза между сетью 48 и любым узлом, который стремится получить доступ к сети. В системе 42 предполагается, что существует такой узел 44, который ищет доступ либо к сети 48, либо к другим сетям (не показаны) через базовую сеть 50. Узел 44 связывается с NAS 46 через канал 45 связи.

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

В этом варианте осуществления предполагается, что канал 45 связи является радиоинтерфейсом. Узел 44 является мобильным устройством, которое связывается с NAS 46 беспроводным образом. Сеть 48 поддерживает беспроводные технологии, такие как стандарты cdma2000, как изложено TIA/EIA (Ассоциацией изготовителей средств связи/ассоциацией электронной промышленности). NAS 46 в этом случае является PDSN (узлом обслуживания передачи пакетных данных), соединенным с RAN (сеть радиодоступа), которая осуществляет связь с узлом 44 через RF (радиочастотные) сигналы по радиоканалу 45. PDSN и RAN известны в данной области техники и не показаны на фиг. 3 по соображениям ясности и краткости.

Перед описанием операционных деталей системы 42 связи он поможет объяснить сначала различные типы протоколов с разными уровнями иерархии и их взаимными отношениями.

В области сетевых коммуникаций протоколы располагаются в иерархии в соответствии с OSI-моделью (взаимодействие открытых систем), как изложено ISO (Международной организацией по стандартизации) и ITU-T (Сектором по стандартизации Международного союза электросвязи). Целью является облегчить взаимодействие оборудования от разных поставщиков. То есть, каждый уровень иерархии протоколов имеет свои собственные спецификации. По существу, пока спецификации отдельного уровня иерархии удовлетворяются, гарантируется, что разработки продуктов на этом уровне должны быть совместимы с другими продуктами на других уровнях.

Предполагается, что система 42 на фиг. 3 поддерживает IP (протокол Интернета). Фиг. 4 схематически показывает стек протоколов в иерархическом порядке, обычно именуемый как "стек протоколов", и в общем обозначаемый ссылкой с номером 52. Стек 52 IP-протоколов структурирован в соответствии с IETF (инженерная проблемная группа Интернет) моделью, которая похожа, но не точно такая же, что и модель OSI. В соответствии с IETF-моделью стек 52 протоколов IP имеет пять уровней, начиная с уровня 1 до уровня 5. Таким образом, пакет данных, отправленный узлом, таким как узел 44 или 46, показанный на фиг. 3, должен быть обработан стеком 52 протоколов. Стек протоколов 52 создается в узле в форме программного или аппаратного обеспечения или их комбинации. Также пакет данных, принятый тем же узлом, должен быть обработан стеком 52 протоколов, но в обратном порядке.

Возьмем пример для иллюстрации. Предполагается, что пакет данных обрабатывается для того, чтобы быть отправленным из узла, такого как узел 44 или 46 (фиг. 3), пакет данных сначала создается в соответствии с одним из протоколов на уровне приложений, т. е. уровне 5. Уровень 5 включает в себя HTTP (протокол передачи гипертекста), SMTP (простой протокол пересылки электронной почты), FTP (протокол передачи файлов) и RTP (транспортный протокол реального времени). Дополнительно предполагается, что пакет данных является продуктом VoIP (передача голоса по протоколу Интернет) сеанса. Пакет данных таким образом должен быть отформатирован в соответствии с RTP на уровне 5.

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

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

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

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

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

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

Самый нижний уровень стека 52 протокола на фиг. 4 - это физический уровень, уровень 1, который имеет дело с физическим осуществлением передачи пакета данных. Например, если канал 45 связи (фиг. 3) является традиционным проводным каналом связи, физический уровень, уровень 1, имеет отношение к аппаратной схеме в обоих узлах 44 и 46 (фиг. 3), возбуждающей сигналы через провода, которые составляют канал 45 связи. Если канал 45 связи представлен радиоинтерфейсом, физический уровень, уровень 1, относится к воздушному пространству и аппаратной схеме в обоих узлах 44 и 46 (фиг. 3), принимающей и передающей сигналы по воздушному пространству.

Что касается пакета данных, принятого узлом, таким как узел 44 и 46 (фиг. 3), пакет данных должен быть обработан таким же стеком 52 протоколов, но в обратном порядке, то есть от уровня 1 к уровню 5.

Теперь ссылка возвращается к фиг. 3. В этом примере предполагается, что узел 44 стремится получить доступ к сети через NAS 46. Перед каким-либо обменом сообщениями физический канал 45 связи должен быть готов передавать сигналы. Выражаясь иначе, физический уровень, уровень 1 узлов 44 и 45, должен физически присутствовать и быть установленным.

В этом варианте осуществления, как упоминалось ранее, канал 45 связи является радиоинтерфейсом, а беспроводной технологией, поддерживаемой сетью 48, является cdma2000. Физический уровень имеет дело с беспроводной схемой в узле 44 и RAN в NAS 46. RAN может включать в себя, по меньшей мере, один BSC (контроллер базовой станции) и множество BS (базовых станций). RAN, BSC и BS не показаны на фиг. 3.

В соответствии с этим вариантом осуществления после того, как физический уровень, уровень 1, установлен, то есть оба узла 44 и 46 обнаружили взаимное физическое присутствие друг друга, NAS 46 немедленно отправляет первое сообщение узлу 44.

Фиг. 5 является блок-схемой, показывающей последовательность передачи сообщений между узлом 44 и NAS 46. Общий поток процесса обозначается ссылкой с номером 54.

Первое сообщение называется сообщением синхронизации и обозначается ссылкой с номером 56. Сообщение 56 синхронизации включает в себя все возможные варианты аутентификации для узла 44, чтобы выбрать из них. Варианты могут включать в себя сообщение вызова по CHAP (протоколу аутентификации по методу "вызов-приветствие") и запрос пароля и имени пользователя, требуемых протоколом PAP (протоколом аутентификации по паролю). В сообщение 56 синхронизации также должны быть включены отличные от CHAP и PAP другие протоколы аутентификации, которые определены и поддерживаются в PPP.

После приема сообщения 56 синхронизации узел 44 отвечает сообщением 58 запроса, как показано на фиг. 5.

В сообщение 58 запроса узел 44 включает необходимую информацию аутентификации в ответ на запросы, как изложено в сообщении 56 синхронизации. Кроме того, узел 44 также включает в сообщение 58 запроса все варианты параметров, необходимые для установления канала связи узла 44 для последующего доступа к сети через NAS 46. Не делается различие, относятся ли параметры с ассоциативно связанными вариантами к конфигурации канала связи, аутентификации или контролю доступа к сети. То есть, вместо классификации параметров согласно функциям компонентов протокола, таких как LCP (протокол управления каналом связи), CHAP (протокол аутентификации по методу "вызов-приветствие") и IPCP (протокол управления протоколом Интернета), как описано ранее по отношению к PPP, в сообщении 58 запроса этого варианта осуществления все параметры с вариантами включаются независимо от функций. Более конкретно, параметры с вариантами в сообщении 58 запроса могут включать в себя ответ на сообщение вызова, или имя пользователя и пароль, если применимо, параметры конфигурации канала 45 связи, такие как размер дейтаграммы и схему сжатия поля HDLC-заголовка (высокоуровневый протокол управления каналом передачи данных), так же как и все параметры для доступа к сети, такие как IP-адрес, конфигурацию DNS (доменная система имен) и протокол сжатия IP-заголовка, если применимо, и так далее.

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

Соответственно, как показано на фиг. 5, NAS 46 отвечает сообщением 60 ответа после приема сообщения 58 запроса. В сообщении 60 ответа NAS 46 выбирает варианты из различных альтернатив. Сообщение 60 ответа включает в себя выбранные варианты параметров с их ассоциативно связанными значениями конфигурации. Очень часто сообщение 60 ответа является последним сообщением, необходимым перед началом сетевого трафика от узла 44.

В отличие от способов других протоколов, таких как PPP-протокол точка-точка, описанный ранее, в соответствии с этим вариантом осуществления нет необходимости в каких-либо сообщениях подтверждения, чтобы подтверждать прием или не подтверждать прием. По существу, в ответ на любое сообщение, будь это сообщение 56 синхронизации, сообщение 58 запроса или сообщение 60 ответа, ни Ack-, ни Nak-сообщения не нужны. Отвечающий узел просто переходит к следующему этапу. Отсутствие ответа на любой отдельный запрошенный элемент подразумевает, что такой элемент недоступен или не поддерживается.

Возвращаясь назад к фиг. 5, после приема сообщения 60 ответа, если варианты, выбранные посредством NAS 46, удовлетворяют определенному пороговому значению, например, все выбранные варианты позволяют узлу 44 установить канал связи для доступа к сети, узел 44 переходит прямо к передаче пользовательских данных 62 к NAS 46. Опять же сообщение подтверждения приема не отправляется узлом 44.

По окончании доступа к сети либо узел 44, либо NAS 46 может отправить сообщение 64 запроса завершения другому, который после этого отвечает обратно сообщением 66 подтверждения завершения и заканчивает сеанс связи.

В менее часто встречающихся обстоятельствах может быть недостаточно вариантов конфигурации в сообщении 58 запроса для NAS 46 для того, чтобы установить канал связи для доступа к сети, которого добивается узел 44. То есть, варианты, выбранные посредством NAS 46, в сообщении 60 ответа могут быть недостаточными, чтобы удовлетворить пороговому значению для узла 44, чтобы установить канал связи для доступа к сети. NAS 46, однако, отправляет сообщение 58 ответа только с принятыми вариантами, а непринятые варианты пропускаются. Снова, нет необходимости в Nak-сообщении. Как упомянуто ранее, предложенные варианты, включенные в состав сообщения 58 запроса, но пропущенные в сообщении 60 ответа, косвенным образом указывают отсутствие поддержки пропущенных вариантов. В этом случае NAS 46 не может установить сетевой трафик и ожидает, пока узел 44 не отправит новое сообщение запроса.

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

Общий процесс 54 также показан в блок-схеме на фиг. 6.

Процесс установления соединения согласно изобретению также конфигурируется, чтобы иметь возможности обработки отказа для других протоколов связи. В этом варианте осуществления, если процесс 54 соединения, показанный на фиг. 5 и 6, не поддерживается либо в узле 44, либо в NAS 46 (фиг. 3), традиционный PPP задействуется в качестве протокола перехода на аварийный режим, чтобы продолжить процесс соединения, приводящий к возможному доступу к сети, которого добивается узел 44.

По существу, могут быть две возможности, соответственно описанные ниже в данном документе.

Первый сценарий возникает, когда узел 44 поддерживает процесс 54 соединения, а NAS 46 - нет. Ссылка теперь направлена на фиг. 7 в соединении с фиг. 3. Фиг. 7 является блок-схемой, которая показывает последовательность передачи сообщений между узлом 44 и NAS 46 в этом сценарии. Общий поток сообщений обозначен ссылкой с номером 68. Так как предполагается, что узел 44 поддерживает процесс 54 соединения, при установлении физического уровня, уровня 1, между узлами 44 и 46 узел 44 ожидает сообщение 56 синхронизации. Однако NAS 46 не имеет сообщения 56 синхронизации, чтобы отправить, потому что также предполагается, что NAS 46 не поддерживает процесс 54 соединения. Вместо этого NAS 46 отправляет сообщение 70 запроса конфигурации LCP по протоколу PPP узлу 44.

После приема сообщения 70 запроса конфигурации LCP узел 44 немедленно узнает, что NAS 46 не поддерживает процесс 54 соединения, и быстро принимает действия, чтобы связаться с NAS 46 через традиционный PPP. Конкретно, в ответ на сообщение 70 запроса конфигурации LCP узел 44 отправляет сообщение 72 подтверждения приема конфигурации LCP, как показано на фиг. 7. Альтернативно, узел может отправить сообщение о отсутствии подтверждения приема конфигурации, если предложенные варианты LCP в сообщении 70 запроса конфигурации являются нежелательными, таким же образом, подобным традиционному PPP.

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

Перерыв в процессе, по существу, похож на процесс 34, показанный на фиг. 2. То есть, после успешного соединения трафик 74 данных устанавливается между узлом 44 и NAS 46. По окончании доступа к сети либо узел 44, либо NAS 46 может отправить сообщение 76 запроса завершения другому, который после этого отвечает обратно сообщением 78 подтверждения завершения и завершает сеанс 68 связи.

Соответствующая блок-схема процесса 68 показана на фиг. 8. Этапы традиционного PPP не показаны на фиг. 8 ради краткости.

Второй сценарий происходит, когда NAS 46 поддерживает процесс 54 соединения, а узел 44 - нет. Ссылка теперь направлена на фиг. 9 в соединении с фиг. 3. Фиг. 9 является блок-схемой, показывающей последовательность передачи сообщений между узлом 44 и NAS 46 в этом сценарии. Полный поток сообщений обозначается ссылкой с номером 70. Так как предполагается, что NAS 46 поддерживает процесс 54 соединения, после установки физического уровня, уровня 1, между узлами 44 и 46 NAS 46 немедленно отправляет сообщение 56 синхронизации узлу 44. Так как также предполагается, что узел 44 не поддерживает процесс 54 соединения, после приема сообщения 56 синхронизации узел 44 не распознает сообщение 56 синхронизации. Как упомянуто ранее и будет дополнительно объяснено ниже, узел 44 может отличить PPP-сообщение от неPPP-сообщения. Таким образом, с нераспознанным сообщением 56 синхронизации узел 44 отбрасывает нераспознанное сообщение 56 синхронизации, используя стандартные PPP-процедуры. Вместо этого узел 44 отправляет сообщение 72 запроса конфигурации LCP по физическому каналу связи, установленному между узлом 44 и NAS 46.

Если NAS 46 принимает сообщение 72 запроса конфигурации LCP или PPP-отклонение сообщения 56 синхронизации, NAS 46 немедленно отменяет все функции, относящиеся к процессу 54 соединения (фиг. 5 и 6), и идет через традиционный PPP-процесс 34, как показано на фиг. 2 и описано ранее.

После успешного соединения может произойти обмен трафиком 74 данных между узлом 44 и NAS 46. По окончании доступа к сети либо узел 44, либо NAS 46 может отправить сообщение 76 запроса завершения другому, который после этого отвечает обратно сообщением 78 подтверждения завершения и завершает сеанс 70 связи.

Фиг. 10 показывает соответствующую блок-схему процесса 70. Этапы традиционного PPP не показаны на фиг. 10 по соображениям краткости и ясности.

Фиг. 11 показывает формат кадра данных, используемого в потоке процесса 54 (фиг. 5). Шаблон кадра для пакета данных процесса 54 обозначается ссылкой с номером 80. По существу, шаблон 80 похож на соответствующий шаблон пакета данных, используемый PPP, как изложено в RFC 1662. В частности, кадр 80 данных включает в себя поле 82 флага, поле 84 адреса, управляющее поле 86, поле 88 номера протокола, поле 90 данных и поле 92 FCS (контрольная последовательность кадра).

Поле 82 флага имеет однобайтную длину и указывает начало кадра пакета данных. Поле 82 флага всегда принимает шестнадцатиричное значение 7E и является таким же значением, используемым для процесса 54 соединения и PPP, как требуется по RFC 1662.

Поле 84 адреса также имеет однобайтную длину и всегда устанавливается в шестнадцатиричное значение, равное FF, как также изложено в RFC 1662.

Управляющее поле 86 имеет однобайтную длину и фиксировано с шестнадцатиричным значением, равным 03, как также описано в RFC 1662.

В поле 88 номера протокола значение в этом поле указывает, что пакет 80 данных присутствует. Поле 88 номера протокола является двухбайтным по длине. Например, как определено в RFC 1661 и 1662, каждое из LCP-сообщений, таких как сообщение 70 запроса конфигурации, имеет шестнадцатиричное значение, равное C021. В этом варианте осуществления каждое из сообщений, таких как сообщение 56 синхронизации, сообщение 58 запроса или сообщение 60 ответа, используемых в процессе 54 соединения (фиг. 5), имеет уникальное значение протокола, отличное от любого из значений протокола, используемых в PPP. По существу, легко может быть распознано, является ли пакет 80 данных PPP-пакетом или неPPP-пакетом.

Поле 90 данных имеет длину, которая изменяется от нуля до более байт, полезной нагрузки, которая содержит либо данные, либо управляющую информацию. Например, если значение в поле 88 номера протокола со значением, которое указывает, что пакет 80 данных - это сообщение 58 запроса, поле данных включает в себя всю информацию, относящуюся к вариантам параметров, как упомянуто выше. В качестве другого примера, если значение в поле 88 номера протокола имеет значение, которое указывает, что пакет 80 данных является пользовательскими данными 62 (фиг. 5), IP-пакет данных, сгенерированный на уровне 3, полностью инкапсулируется в поле 90 данных.

FCS-поле 92 изменяется от двух до четырех байт по длине и содержит коды, такие как CRC (циклический избыточный код), для кадра 80, чтобы предоставить основную защиту против ошибок во время передачи.

В дополнение к сообщению 56 синхронизации, сообщению 58 запроса, сообщению 60 ответа, запросу 64 завершения и сообщению подтверждения завершения, как упомянуто выше (например, см. фиг. 5), другие типы сообщений могут также быть осуществлены в процессе 54 установления канала связи. Фиг. 12 показывает несколько примеров.

Ссылка теперь направлена на фиг. 3 в соединении с фиг. 12. Например, после продленного периода бездействующей связи, обозначенного ссылкой с номером 94 на фиг. 12, либо узел 44, либо NAS 46 может отправить сообщение 96 эхо-запроса другой стороне, чтобы осведомиться о состоянии стороны или канала 45 связи. Например, если не существует физического канала связи, установленного для канала 45 связи из-за сбоя питания, отправляющая сторона не примет ответ на сообщение 45 эхо-запроса. Соответственно, отправляющая сторона может захотеть завершить сеанс 54 связи. С другой стороны, если канал 45 связи еще физически действующий, принимающая сторона может ответить на сообщение 96 эхо-запроса, отравляя сообщение 98 эхо-ответа. Отправляющая сторона может после этого отказаться от решения завершить сеанс 54 связи. Продолжительность периода 94 времени может быть предварительно определена.

Между обменами пользовательскими данными 62 NAS 46 может отправить сообщение 98 аутентификации узлу 44, запрашивающее информацию для дальнейшей аутентификации. Например, во время обычного трафика данных узел 44 может нуждаться в доступе к важной информации, к которой могут получить доступ только некоторые пользователи. По существу, NAS 46 может отправить сообщение 99 аутентификации узлу 44 для дальнейшей аутентификации. В дополнение к протоколам аутентификации, таким как PAP и CHAP, как упомянуто выше, также могут использоваться другие более сложные схемы протоколов, известные в данной области техники. Примером может быть EAP (расширенный протокол аутентификации), применяющий внешний сервер, такой как AAA (аутентификация, авторизация и учет) сервер, расположенный либо внутри, либо за пределами сети 48, для аутентификации.

Фиг. 13 схематически показывает часть аппаратного осуществления устройства, такого как узел 44, показанный на фиг. 3, обозначенного ссылкой с номером 100, в соответствии с примерным вариантом осуществления изобретения. Устройство 100 может быть построено и интегрировано в различные формы, такие как портативный компьютер, PDA (персональный цифровой секретарь) или сотовый телефон, например.

Устройство 100 содержит центральную шину 102 данных, связывающую несколько схем вместе. Схемы включают в себя CPU (центральный процессор) или контроллер 104, схему 106 приема, схему 108 передачи и модуль 110 памяти.

Если устройство 100 является беспроводным устройством, схемы 106 и 108 приема и передачи могут быть соединены с RF-схемой (радиочастотной), но не показанной на чертеже. Схема 106 приема обрабатывает и буферизует принятые сигналы перед отправкой на шину 102 данных. С другой стороны, схема 108 передачи обрабатывает и буферизует данные от шины 102 данных перед отправкой из устройства 100. CPU/контроллер 104 выполняет функцию управления данными шины 102 данных и дополнительно функцию общей обработки данных, включающей в себя выполнение управляющего содержимого модуля 110 памяти.

Вместо отдельно размещенного, как показано на фиг. 13, в качестве альтернативы, схема 108 передачи и схема 106 приема могут быть частями CPU/контроллера 104.

Модуль 110 памяти включает в себя набор инструкций, обычно обозначаемых ссылкой с номером 112. В этом варианте осуществления инструкции включают в себя, среди прочего, части, такие как функция 114 стека протоколов, клиент 116 установления канала связи, PPP-функция 118. Функция 114 стека протоколов запускает стек протоколов, подобный стеку 52, как показано и описано на фиг. 4 ранее. Клиент 116 установления канала связи включает в себя наборы инструкций в соответствии с процессом, таким как процессы, описанные на фиг. 5-10, приведенных выше. PPP-функция 118 включает в себя наборы инструкций для того, чтобы дать возможность устройству 102 выполнить PPP-процесс. PPP-функция 118 может использоваться независимо или при переходе на аварийный режим из клиента 116 установления канала связи, как также описано ранее.

В этом варианте осуществления модулем 110 памяти является схема RAM (оперативное запоминающее устройство). Примерные части 114, 116 и 118 инструкций являются программными процедурами или модулями. Модуль 110 памяти может быть соединен с другой схемой памяти (не показана), которая может быть либо энергозависимого, либо энергонезависимого типа. Как альтернатива, модуль 110 памяти может быть сделан из других типов схем, таких как EEPROM (электрически стираемое программируемое постоянное запоминающее устройство), EPROM (электрически программируемое постоянное запоминающее устройство), ROM (постоянное запоминающее устройство), ASIC (специализированная интегральная микросхема), магнитный диск, оптический диск и другие, хорошо известные в данной области техники.

Фиг. 14 схематически показывает часть аппаратного осуществления другого устройства, такого как NAS 46, показанного на фиг. 3, в соответствии с изобретением и обозначается ссылкой с номером 120. Устройство 120 содержит центральную шину 122 данных связывающую несколько схем вместе. Схемы включают в себя CPU (центральный процессор) или контроллер 124, схему 126 приемника, схему 128 передатчика и модуль 130 памяти.

Схемы 126 и 128 приема и передачи могут быть соединены с сетевой шиной данных (не показана), с которой соединено устройство 120. Схема 126 приема обрабатывает и буферизует принятые сигналы от сетевой шины данных (не показана) перед маршрутизацией к внутренней шине 122 данных. Схема 128 передачи обрабатывает и буферизует данные от шины 122 данных перед отправкой из устройства 120. CPU/контроллер 124 выполняет работу по управлению данными шины 122 данных и функцию общей обработки данных, включающей в себя выполнение управляющего содержимого модуля 130 памяти.

Опять же, вместо отдельно размещенного, как показано на фиг. 14, схема 128 передачи и схема 126 приема могут быть частями CPU/контроллера 124.

Модуль 130 памяти включает в себя набор инструкций, в общем, обозначенных ссылкой с номером 134. В этом варианте осуществления инструкции включают в себя части, среди прочего, функции 136 стека протоколов, сервера 138 установления соединения, PPP-функцию 130. Функция 136 стека протоколов запускает стек протоколов, подобный стеку 52, как показано и описано на фиг. 4 ранее. Сервер 138 установления соединения включает в себя наборы инструкций в соответствии с процессом, таким как процессы, описанные на фиг. 5-10, и как описано выше. PPP-функция 140 включает в себя наборы инструкций, позволяющие устройству 120 выполнить PPP-процесс. PPP-функция 140 может выполняться независимо или в качестве перехода на аварийный режим из сервера 138 установления соединения, как также описано ранее.

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

Также должно быть отмечено, что процессы 54, 68 и 70, как описано и показано на фиг. 5-10, могут также быть сохранены и передаваться на любом машиночитаемом носителе, известном в данной области техники. В этой спецификации и приложенной формуле изобретения термин "машиночитаемый носитель" ссылается на любой носитель, который участвует в предоставлении инструкций CPU/контроллеру 104 и 124, соответственно показанным и описанным на фиг. 12 и 13, для выполнения. Такой машиночитаемый носитель, если он имеет тип хранилища, может принимать форму энергозависимого или энергонезависимого носителя данных, подобного типам схем для модулей 110 и 130 памяти, как также описано ранее. Такой машиночитаемый носитель, если он передающего типа, может включать в себя коаксиальный кабель, металлический провод, оптический кабель или радиоинтерфейс, передающий звуковые или электромагнитные волны, способные передавать сигналы, читаемые машинами или компьютерами, например.

В заключение описанный в варианте осуществления протокол уровня 3 описывается как IP. IP может быть разных версий, таких как IPv4 (протокол Интернета версии 4) и IPv6 (протокол Интернета версии 6). Кроме того, должно быть отмечено, что протоколы уровня 3 являются одинаково применимыми. Например, протоколом уровня 3 может быть IPX (протокол межсетевого обмена пакетами), Apple-Talk и различные другие сетевые протоколы разных версий. Кроме того, в примерном варианте осуществления узел 44 изображается как мобильное устройство, связывающееся с NAS 46 беспроводным образом. Должно быть оценено, что узел 60 очень хорошо может быть стационарным. Кроме того, не требуется, чтобы канал 45 связи был радиоканалом. Вместо этого канал 45 связи может быть проводным каналом связи. Кроме того, любые логические блоки, схемы и этапы алгоритма, описанные вместе с вариантом осуществления, могут быть выполнены в аппаратных, программных, аппаратно-программных средствах или их комбинациях. Специалистам в данной области техники будет понятно, что эти и другие изменения в форме и деталях могут быть сделаны здесь без отступления от цели и духа изобретения.

Изобретение относится к передачам пакетов данных. Техническим результатом является создание быстрого и эффективного способа установления первоначальных каналов связи перед любыми следующими уровнями графика данных. Для этого сеанс связи между узлом, пытающимся осуществить доступ к сети, и NAS (сервером доступа к сети) устанавливается посредством наличия только нескольких обменов сообщениями. После обнаружения физического канала связи между узлом и NAS NAS немедленно отправляет сообщение запроса аутентификации узлу. В ответ узел отправляет сообщение запроса, которое включает в себя все варианты параметров, в дополнение к ответу на сообщение запроса аутентификации, для конфигурации канала связи и управления доступом к сети. NAS затем отбирает и выбирает варианты параметров и отправляет назад узлу выбранные варианты в сообщении ответа. Если выбранные варианты в ответном сообщении удовлетворяют пороговой величине, узел просто передает пользовательские данные для доступа к сети через NAS. 16 н. и 31 з.п. ф-лы, 14 ил.

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

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

отправляют упомянутое сообщение от устройства связи упомянутому узлу доступа к сети;

принимают от упомянутого узла доступа к сети второе сообщение, которое касается авторизации упомянутого набора вариантов параметров упомянутого первого сообщения; и

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

устанавливают физический канал связи с упомянутым узлом доступа к сети;

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

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

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

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

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

отправляют от устройства связи упомянутому узлу второе сообщение, которое касается авторизации упомянутого набора вариантов параметров.

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

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

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

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

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

средство для приема от упомянутого узла доступа к сети второго сообщения, которое касается авторизации упомянутого набора вариантов параметров упомянутого первого сообщения; и

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

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

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

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

средство для отправки упомянутого сообщения запроса упомянутому узлу доступа к сети через упомянутый физический канал связи;

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

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

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

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

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

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

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

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

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

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

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

схему процессора, соединенную с упомянутым модулем памяти для обработки упомянутых машиночитаемых инструкций.

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

схему процессора, соединенную с упомянутым модулем памяти для обработки упомянутых машиночитаемых инструкций.

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

схему процессора, соединенную с упомянутым модулем памяти для обработки упомянутых машиночитаемых инструкций.

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

схему процессора, соединенную с упомянутым модулем памяти для обработки упомянутых машиночитаемых инструкций.

предоставления в устройстве связи в сети набора вариантов параметров для аутентификации, конфигурации канала связи и доступа к сети в сообщении для сеанса связи перед доступом к сети; и

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

установления физического канала связи с упомянутым узлом доступа к сети;

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

отправки упомянутого сообщения запроса упомянутому узлу доступа к сети через упомянутый физический канал связи;

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

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

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

отправки от устройства связи упомянутому узлу второго сообщения, которое касается авторизации упомянутого набора вариантов параметров.

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

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

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

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