Поддержка передачи обслуживания для сетей, имеющих разные протоколы установления канала связи
Изобретение относится к системам связи. Технический результат заключается в повышении надежности процесса передачи обслуживания. В системе связи, в которой перемещающийся узел, для которого требуется обеспечить доступ к сети среди разных сетей, которые воплощены с разными протоколами уровня сетевого интерфейса, установлены схемы передачи обслуживания, благодаря использованию которых узел может свободно перемещаться из одной сети в другую с уменьшенным уровнем прерывания доступа к сети. Перед и в самом начале передачи обслуживания узел принимает указание на передачу обслуживания. Это указание может быть воплощено в различных формах, таких как сигнальное сообщение, обозначающее изменение SID (системная идентификация), NID (идентификация сети) или PZID (идентификация области пакета). В качестве альтернативы, указание может быть в форме информации, непосредственно включенной в пакет данных, переданный в перемещающийся узел перед передачей узла. В другом альтернативном варианте указание может быть воплощено как различимые структуры сообщения, передаваемые в узел, в которых разные структуры сообщения могут быть переданы разными сетями, поддерживающими разные протоколы уровня сетевого интерфейса. 6 н. и 30 з.п. ф-лы, 16 ил.
Испрашивание приоритета
В настоящей заявке на патент испрашивается приоритет в соответствии с предварительной заявкой США № 60/614215 под названием "A Method and Apparatus for Handoff Support Fast Link Establishment Protocol", поданной 28 сентября 2004 г., права на которую принадлежат заявителю данной заявки и специально приведенной здесь в качестве ссылочного материала.
УРОВЕНЬ ТЕХНИКИ
Область техники, к которой относится изобретение
Настоящее изобретение, в общем, относится к пакетной передаче данных, более конкретно к поддержке передачи обслуживания для сетей с разными протоколами установления канала связи, выполнение которой часто требуется перед какой-либо пакетной передачей данных по сетям.
Описание предшествующего уровня техники
Глобальное взаимное соединение сетей позволяет обеспечить быстрый доступ к информации, независимо от географических расстояний. На фиг.1 показана упрощенная схема глобального соединения сетей, обычно называемого сетью Интернет, обозначенной ссылочной позицией 20. Интернет 20, по существу, представляет собой множество сетей с разными уровнями иерархии, соединенных вместе. Интернет 20 работает в соответствии с IP (протокол Интернет), который был опубликован IETF (Целевая группа инженерной поддержки Интернет). Подробное описание протокола IP можно найти в RFC (Запрос комментария) 791, опубликованном IETF.
К сети Интернет 20 подключены различные отдельные сети, иногда называемые ЛВС (локальные вычислительные сети, LAN) или ГВС (глобальные вычислительные сети, WAN) в зависимости от размеров сети. На фиг.1 показаны некоторые из таких сетей 22, 24, 26 и 28.
В пределах каждой из сетей 22, 24, 26 и 28 могут быть подключены различные части оборудования, соединенные и связанные друг с другом. Примеры такого оборудования представляют собой компьютеры, принтеры и серверы, помимо прочего, которые обычно называются узлами. Когда узел при обмене данными выходит за пределы собственной сети через Интернет 20, этому узлу должен быть назначен IP адрес. Назначение IP адреса может выполняться вручную или автоматически. Назначение IP адреса вручную может быть выполнено, например, сетевым администратором. Более часто, IP адрес назначают автоматически, например, с помощью выделенного сервера в ЛВС или ГВС.
Рассмотрим пример для иллюстрации. Предположим, узел 30 в сети 22 пытается передать пакет данных в другой узел 37 в сети 24. В соответствии с протоколом IP, каждый пакет данных должен иметь адрес источника и адрес назначения. В этом случае адрес источника представляет собой адрес узла 30 в сети 22. Адрес назначения представляет собой адрес узла 37 в сети 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 в чужую сеть 28. Для обеспечения доступа к сети 28 или для подключения к другим сетям через Интернет 20 узел 30 также обычно устанавливает сеанс PPP с NAS 33 сети 28. Обмен данных между узлом 30 и NAS 33 в этом случае выполняется через беспроводной канал связи. И снова, пакеты данных, обмен которыми выполняется через беспроводной канал связи, также должны быть разделены на фреймы для соответствия формату, согласованному во время сеанса PPP между узлом 30 и NAS 33.
Основная часть PPP описана в RFC 1661 и 1662, опубликованных IETF. PPP, по существу, представляет собой сеанс проверки и согласования между узлами, причем во время этого сеанса узлы определяют ресурсы друг друга в смысле пропускной способности и доступности и, в результате, согласуют набор взаимоприемлемых параметров до передачи сетевого трафика. Поскольку сеанс PPP часто должен быть установлен до получения доступа к сети, PPP иногда называют "протоколом уровня сетевого интерфейса". Однако также обычно используют другие аналогичные термины, включая "протокол установления канала связи" и "протокол уровня 2". Ниже термины "протокол уровня сетевого интерфейса", "протокол установления канала связи" и "протокол уровня 2" используются взаимозаменяемо.
На фиг.2 показана схема последовательности операций примера сеанса 34 передачи данных PPP, в котором узел 30 в сети 28 пытается установить канал связи с NAS 33 для получения доступа к Интернет 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.
С другой стороны, если параметр распознается, но вариант выбора, связанный с параметром, не является приемлемым, отвечающая сторона передает обратно сообщение Configure Nak (конфигурация не подтверждена). Запрашивающая сторона снова может либо прекратить сеанс PPP, или передать другое сообщение запроса конфигурации с другим вариантом выбора для того же параметра.
Все параметры с соответствующими вариантами выбора должны быть согласованы и установлены так, как описано выше. Может потребоваться несколько циклов согласования, как показано на фиг.2. Если запрашивающая сторона определяет, что все необходимые параметры являются приемлемыми для отвечающей стороны, запрашивающая сторона передает конечное сообщение Configure Ack (подтверждение конфигурации) запрашивающей стороне. После того как обе стороны передадут сообщения подтверждения конфигурации, они затем переходят к фазе аутентификации.
Для удостоверения того, что обе стороны являются ауторизованными, должна быть выполнена аутентификация. Один из способов выполнения аутентификации состоит в использовании компонента 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 Success (CHAP успешно пройден) в узел 30. В противном случае сообщение CHAP Failure (CHAP не пройден) будет передано NAS 33.
В качестве альтернативы, вместо CHAP 38 аутентификация может быть выполнена путем прохода через PAP (ПАП, протокол аутентификации пароля). При использовании PAP узел 30 просто передает в NAS 33 имя пользователя и пароль для проверки. В случае успешной проверки говорят, что узел 30 прошел PAP.
Если узлу 30 требуется доступ к IP, снова требуется произвести обмен и согласование информации, относящейся к IP. Например, помимо прочего, может потребоваться назначить узлу 30 IP адрес для доступа к Интернет 20 (фиг.1) в соответствии с IP. С этой целью начинается согласование и обмен вариантами выбора параметров в соответствии с IPCP 40. В примере сеанса 34 PPP узел 30 первоначально запрашивает IP адрес 0.0.0.0 в NAS 33. В ответ NAS 33 передает сообщение Configure Nak (не подтверждения конфигурации), что предполагает, что узел 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 во время сеанса 34 PPP требуется произвести обмен достаточно большим количеством сообщений. На это уходит значительный период времени. В особенности это справедливо в случае, когда сеанс 34 PPP согласуют по медленному каналу передачи данных с большой задержкой при передаче данных.
Для ускорения процесса первоначального установления канала связи между узлом 30 и NAS 33 были предложены разные протоколы, помимо PPP. Пример таких протоколов описан в заявке № 11/193068 на патент США под названием "Fast Link Establishment for Network Access", поданной 28 июля 2005 г. (далее заявка на патент "'068"). Заявка на патент '068, права на которую принадлежат заявителю настоящей заявки, специально приведена здесь полностью в качестве ссылочного материала. Ниже любой протокол установления канала связи, который не является протоколом PPP, называется не-PPP.
Однако в системе связи, в которой некоторые сети поддерживают не-PPP, в то время как другие не поддерживают такой протокол, возникают проблемы. Эти проблемы могут быть дополнительно осложнены, когда мобильные узлы перемещаются по разным сетям с разными протоколами установления канала связи.
Для иллюстрации рассмотрим другой пример. Рассмотрим снова фиг.1. Предположим, что узел 30 после перемещения в сеть 28 устанавливает канал связи с NAS 33 через сеанс не-PPP. После этого выполняется обмен данными пользователя между узлом 30 и NAS 33. Кроме того, предположим, что в ходе передачи данных пользователя узел 30 перемещается в другую сеть, такую как сеть 26. Если сеть 26 аналогична сети 28 в любом аспекте, в отношении физического воплощения и протокола, включая в себя воплощение протокола уровня сетевого интерфейса, может быть разработана упрощенная схема передачи обслуживания. После перехода на территорию сети 26, сеть 28 может передать обязанности по обработке данных в сеть 26, которая затем принимает на себя функции пакетного обмена данными, ранее выполнявшиеся сетью 28.
Однако сети 28 и 26 часто имеют разные воплощения в отношении аппаратных средств и уровня канала связи. Например, предположим, что сеть 28 поддерживает не только PPP, но также и другой не-PPP в качестве протоколов уровня сетевого интерфейса. С другой стороны, сеть 26 поддерживает только PPP в качестве протокола уровня сетевого интерфейса и не поддерживает другие протоколы. После перемещения в сеть 26 из сети 28 и для продолжения доступа к сети узел 30 должен вначале установить другой сеанс протокола уровня сетевого интерфейса с NAS 35 в сети 26 так, чтобы обмен пакетными данными, установленный после этого, соответствовал физическому каналу связи, установленному между узлом 30 и NAS 35 в сети 26. Если узел 30 не адаптирован к запуску без перерыва обычного PPP, требуемого в сети 26, узел 30 будет полностью отключен от сетевого доступа.
В соответствии с этим, существует потребность в обеспечении надежного процесса передачи обслуживания для перемещающихся узлов, для которых требуется обеспечить сетевой доступ в разных сетях, поддерживающих разные протоколы уровня сетевого интерфейса.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
В системе связи с множеством сетей узел, которому требуется обеспечить доступ к сети в системе передачи данных, должен пройти через процесс передачи обслуживания при перемещении из одной сети в другую. Особые проблемы возникают, когда разные сети выполнены с использованием разных протоколов уровня сетевого интерфейса. В соответствии с примерным вариантом выполнения изобретения устанавливают схемы передачи обслуживания, используя которые узел может перемещаться из одной сети в другую с меньшим количеством перерывов доступа к сети. Перед передачей обслуживания узел принимает указание на передачу обслуживания. Это указание может принимать форму смены SID (СИД, системная идентификация), NID (ИДС, идентификация сети), или PZID (ИДЗП, идентификация зоны пакета), или их комбинации. В качестве альтернативы, указание может быть непосредственно включено в пакет данных, передаваемый в узел во время передачи обслуживания. В качестве другой альтернативы, указание может быть выполнено в форме структур сообщения, передаваемых в узел, в котором другие структуры сообщения передают с использованием других сетей, поддерживающих другие протоколы уровня сетевого интерфейса.
В соответствии с одним аспектом изобретения раскрыт способ, в котором узел, для которого требуется установить доступ к сети, проходит через способ, который включает в себя этапы установления первого протокола уровня сетевого интерфейса с обслуживающим узлом, приема указания на передачу обслуживания и установление второго протокола уровня сетевого интерфейса с целевым узлом.
В соответствии с другим аспектом изобретения раскрыто устройство, воплощенное с использованием аппаратных средств, для выполнения этапов упомянутого выше раскрытого способа.
В соответствии с еще одним аспектом изобретения раскрыт считываемый компьютером носитель информации, на котором содержатся считаемые компьютером инструкции для выполнения этапов упомянутого выше раскрытого способа.
Эти и другие свойства и преимущества будут очевидны для специалиста в данной области техники из следующего подробного описания, которое следует рассматривать совместно с прилагаемыми чертежами, на которых одинаковыми ссылочными позициями обозначены одинаковые части.
Краткое описание чертежей
На фиг.1 показана схема глобального соединения сетей;
на фиг.2 показана схема последовательности связи или сеанса связи для обычного протокола уровня сетевого интерфейса;
на фиг.3 показана схема узлов и сетей, используемая в общем варианте выполнения изобретения;
на фиг.4 показана схема узлов и сетей, используемая в примерном варианте выполнения изобретения, в котором поддерживаются беспроводные технологии;
на фиг.5 показана схема, представляющая стек протоколов в иерархическом порядке;
на фиг.6 показана схема последовательности связи сеанса связи для примерного протокола уровня сетевого интерфейса, который отличается от обычного протокола уровня сетевого интерфейса, показанного на фиг.2;
на фиг.7 показана схема последовательности связи, представляющая этапы, используемые в соответствии с первой схемой передачи обслуживания, используемой в примерном варианте выполнения изобретения;
на фиг.8 показана блок-схема последовательности операций схемы передачи обслуживания для схемы последовательности связи, показанной на фиг.7;
на фиг.9 показана схема последовательности связи, представляющая этапы, используемые в соответствии со второй схемой передачи обслуживания, используемой в примерном варианте выполнения изобретения;
на фиг.10 показана схема формата фрейма данных, используемого в протоколах уровня сетевого интерфейса по фиг.2 и 6;
на фиг.11 показана блок-схема последовательности операций схемы передачи обслуживания в схеме последовательности связи, представленной на фиг.9;
на фиг.11A показана блок-схема последовательности операций варианта схемы передачи обслуживания для схемы последовательности связи, показанной на фиг.7;
на фиг.12 показана схема последовательности связи, представляющая этапы, используемые в соответствии с третьей схемой передачи обслуживания, используемой в примерном варианте выполнения изобретения;
на фиг.13 показана блок-схема последовательности операций схемы передачи обслуживания для схемы последовательности связи, представленной на фиг.12;
на фиг.14 показана схема части узла, которому требуется установить доступ к сети в соответствии с примерным вариантом выполнения;
на фиг.15 показана схема последовательности связи, представляющая используемые этапы, в которых передача обслуживания в целевую сеть происходит в ходе установления сеанса по протоколу уровня сетевого интерфейса в обслуживающей сети; и
на фиг.16 показана блок-схема последовательности операций процесса передачи обслуживания, иллюстрируемого в схеме последовательности связи, представленной на фиг.15.
ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
Следующее описание представлено для того, чтобы позволить любому специалисту в данной области техники использовать изобретение. Подробности приведены в следующем описании с целью пояснения. Следует понимать, что специалист в данной области техники мог бы понять, что это изобретение можно использовать на практике без использования этих конкретных деталей. В других случаях хорошо известные структуры и процессы не описаны подробно с тем, чтобы не загромождать описание изобретения ненужными деталями. Таким образом, настоящее изобретение не следует ограничивать представленными вариантами выполнения, но оно должно соответствовать самому широкому объему, соответствующему раскрытым здесь его принципам и свойствам.
На фиг.3 показана упрощенная схема узлов и сетей, используемых в обобщенном варианте выполнения изобретения. Система связи в целом обозначена ссылочной позицией 42 и включает в себя сети 45 и 47, соединенные с базовой сетью 49. Базовая сеть 49 может представлять собой интранет или Интернет. К базовой сети 49 могут быть подключены другие сети, но они не показаны на фиг.3 для ясности и краткости изложения.
В сетях 45 и 47 расположены соответственно NAS (серверы сетевого доступа) 51 и 53, которые, в свою очередь, выполняют функцию шлюзов для любых узлов, для которых требуется доступ к сети. Предположим, что в системе 42 имеется такой узел 55, которому требуется доступ к сети 45 или другим сетям через базовую сеть 49. Узел 55 не имеет непосредственного доступа к сети 45, но может связываться с NAS 51 через канал 57 передачи данных. Установки связи между узлом 55 и NAS 51 выполняются через процесс, называемый "установлением канала связи".
Предположим, что узел 55 не замкнут в своей исходной сети, такой как сеть 45, но может перемещаться в другие сети, такие как сеть 47.
В этом случае, когда узел 55 покидает сеть 45 и перемещается в сеть 47, для получения доступа к сети узел 55, аналогично, должен установить другой сеанс установления канала связи с NAS 53 в сети 47 через еще один канал передачи данных.
Канал 57 связи между NAS 51 и узлом 55 может представлять собой канал связи, который может иметь разные формы. Например, канал 57 связи может представлять собой кабельный канал связи, такой как обычное телефонное проводное соединение, канал связи по коаксиальному кабелю или канал связи по оптическому кабелю, помимо прочих. Кроме того, канал 57 связи может также представлять собой беспроводной канал связи, такой как радиоинтерфейс, по которому можно передавать, например, электромагнитные или акустические сигналы.
На фиг.4 представлен более конкретный вариант воплощения системы 42 связи, которая поддерживает беспроводные технологии. В этом случае вся система, в общем, обозначена ссылочной позицией 44. Беспроводная связь между узлами может осуществляться через каналы связи в форме радиоинтерфейса, такого как каналы 58 и 90 радиоинтерфейса, показанные на фиг.4. В данном варианте выполнения, с целью краткости и ясности изложения, сеть 44 представлена как сеть, поддерживающая технологии беспроводной связи, такие как стандарты cdma2000, установленные 3GPP2 (Проект 2 партнерства по разработке системы связи третьего поколения), который представляет собой консорциум нескольких международных органов в области стандартизации, включая TIA/EIA (Ассоциация телекоммуникационной промышленности/Ассоциация отраслей электронной промышленности) Соединенных Штатов Америки.
В системе 44 узел 56, который может перемещаться в другие сети, может быть выполнен в разных формах, таких как КПК (карманный персональный компьютер), переносный компьютер или сотовый телефон, помимо прочих.
В сетях 46 воплощены PDSN (УОПД, узлы обслуживания пакетных данных) 60, которые выполняют функцию NAS 52. Узел 58 связывается с PDSN 60 через RAN (СРД, сеть радиодоступа), которая, в общем, обозначена ссылочной позицией 62. RAN 62 включает в себя BSC/PCF (контроллер базовой станции/функция управления пакетными данными) 64, подключенный к множеству BS (БС, базовых станций) 65A-65N.
Аналогично, в сети 48 расположены другие PDSN (узлы обслуживания пакетных данных) 66, которые выполняют функцию другого NAS 54. Любой узел, которому требуется получить доступ к сети, связывается с PDSN 66 через другой RAN 68. RAN 68 включает в себя BSC/PCF 70, подключенный к множеству BS 72A-72M.
Сети 46 и 48 могут обрабатывать пакеты данных, в которых передают голосовую информацию или данные. Подробное описание архитектуры сетей 46 и 48, обладающих возможностью беспроводной связи, можно найти в документе, опубликованном 3GPP2, под названием "Interoperability Specification (IOS) for CDMA 2000 Access Network Interfaces", TIA-2001-D, Feb. 2005.
Перед подробным описанием работы системы 42 связи полезно вначале пояснить общую обработку пакета данных во время передачи пакета данных через различные уровни протоколов с разной иерархией и их взаимозависимости.
В области сетевой связи для протоколов установлена иерархия в соответствии с моделью OSI (взаимодействие открытых систем), представленной ISO (ИСО, Международная организация по стандартизации) и в ITU-T (Международный союз электросвязи - сектор стандартов в области телекоммуникаций). Цель состоит в обеспечении взаимной работоспособности оборудования, поставляемого разными поставщиками. Таким образом, каждый уровень иерархии протокола имеет свою собственную спецификацию. При этом, если только удовлетворяются спецификации на определенном уровне иерархии, обеспечивается совместимость при разработке продуктов на этом уровне с другими продуктами на других уровнях.
Предположим, что система 44, показанная на фиг.4, поддерживает IP (протокол Интернет). На фиг.5 схематично представлен стек протоколов в иерархическом порядке, обычно называемым "стеком протокола", и который, в общем, обозначен ссылочной позицией 74. Стек 74 протокола IP имеет структуру, соответствующую модели IETF (Целевая группа инженерной поддержки Интернет), которая аналогична, но не является точно такой же, как модель OSI. В соответствии с моделью IETF, стек 74 протокола IP имеет пять уровней, начиная с уровня 1 до уровня 5. Таким образом, пакет данных, передаваемый одним узлом, таким как один из узлов 56, 60 и 66, как показано на фиг.4, должен быть обработан через стек 74 протокола. Стек 74 протокола построен в узле в форме программных или аппаратных средств, или с использованием их комбинации. Аналогично, пакет данных, принимаемый тем же узлом, должен быть обработан с использованием того же стека 74 протокола, но в обратном порядке.
Для иллюстрации рассмотрим пример. Предположим, что пакет данных обрабатывают для передачи обслуживания, например, узла 56 (фиг.4), при этом пакет данных вначале формируют в соответствии с одним из протоколов на прикладном уровне, то есть уровне 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, например, с добавлением адресов источника и назначения пакета данных.
Следует отметить, что для краткости на фиг.5 показан только IP на уровне 3. На уровне 3 имеются другие протоколы, которые выполняют вспомогательные функции в отношении протокола IP. Например, ICMP (протокол управляющих сообщений сети Интернет), который предназначен для передачи сообщений об ошибке для пакетов данных, которые не могут быть доставлены.
После этого пакет данных должен быть разбит на фреймы так, чтобы он соответствовал применяемому протоколу на уровне канала связи, уровне 2. PPP (протокол канала связи с непосредственным соединением), описанный выше, классифицирован как протокол уровня 2. Как указано выше, существуют другие не-PPP протоколы, используемые сетями для замены PPP в качестве протокола уровня сетевого интерфейса.
Самый нижний уровень стека 74 протокола на фиг.5 представляет собой физический уровень, уровень 1, который работает с физическим воплощением передачи пакета данных. Например, на фиг.3, если уровень 57 связи представляет собой обычное проводное соединение, физический уровень, уровень 1, относится к аппаратным средствам обоих узлов 55 и 51, и передает сигналы через электрические провода, которые составляют канал 57 связи. В качестве другого примера, как показано на фиг.4, канал 58 связи представляет собой радиоинтерфейс, при этом физический уровень, уровень 1, относится к эфирному пространству и к аппаратным цепям RAN 62, передающим сигналы через эфирное пространство.
Рассмотрим снова фиг.4. При приеме пакета данных примерным узлом 56 такой пакет данных должен быть обработан с использованием того же стека 72 протокола (фиг.5), но в обратном порядке, то есть от уровня 1 до уровня 5.
Предположим в этом примере, что узел 56 первоначально должен получить доступ к сети через PDSN 60. Далее предположим, что узел 56 не имеет непосредственного доступа к сети 46.
Обычно узел 56 может начать процесс доступа к сети путем установления вначале сеанса PPP с PDSN 60. Однако, как пояснялось выше, для упрощения процесса установления связи перед получением доступа к сети были предложены другие протоколы уровня сетевого интерфейса. Один из таких протоколов описан в патентной заявке '068, также упомянутой выше.
В следующем описании, для упрощения пояснений, протокол, раскрытый в патентной заявке '068, представлен совместно с описанием работы примерного варианта выполнения. Однако следует отметить, что практика изобретения не нуждается в таком ограничении и не должна быть ограничена таким образом. При этом вполне могут быть применимы другие протоколы уровня сетевого интерфейса, кроме протокола, описанного в патентной заявке '068.
Возвращаясь снова к фиг.4, перед обменом сообщениями, физический канал 58 связи должен быть готов к передаче сигналов. Другими словами, физический уровень, уровень 1, узла 56 и BS 65A должен, прежде всего, физически присутствовать и должен быть установлен.
После того как физический уровень будет установлен, то есть после того как узел 56 и PDSN 60 детектируют взаимное физическое присутствие друг друга через RAN 62, PDSN 60 немедленно передает первое сообщение в узел 56.
На фиг.6 показана блок-схема последовательности операций, представляющая последовательность передачи сообщений между узлом 56 и PDSN 60. Обработка потока, в общем, обозначена ссылочной позицией 75. Обработка 75 потока описана подробно в заявке '068, но вкратце приведена ниже.
PDSN 60 принимает сетевой доступ только от авторизованных узлов. Первое сообщение передает PDSN 60, которое называется сообщением синхронизации, которое обозначено ссылочной позицией 76. Сообщение 76 синхронизации включает в себя все возможные варианты аутентификации, выбор среди которых осуществляется узлом 56. Эти варианты выбора могут содержать сообщение запрос в соответствии с CHAP (протокол взаимной аутентификации) и запрос на получение пароля и имени пользователя, требуемых PAP (протокол аутентификации по паролю), и любых других применимых протоколов аутентификации.
После получения сообщения 76 синхронизации узел 56 отвечает сообщением 78 запроса, как показано на фиг.6.
В сообщение 78 запроса узел 56 включает необходимую информацию аутентификации в ответ на запросы, представленные в сообщении 76 синхронизации. Кроме того, узел 56 также включает в сообщение 78 запроса все возможные варианты выбора параметра, необходимые для установления канала связи для узла 56, для последующего доступа к сети через PDSN 60. При этом не имеет значения, будут ли параметры с соответствующими вариантами выбора относиться к конфигурации канала связи аутентификации или управлению доступом к сети. Таким образом, вместо классификации параметров в соответствии с функциями компонентов протокола, такими как LCP (протокол управления каналом), CHAP (протокол взаимной аутентификации) и IPCP (протокол управления протоколом Интернет), как описано выше относительно PPP, в сообщении 78 запроса, все параметры с вариантами выбора включены независимо от функций. Более конкретно, параметры с вариантами выбора в сообщении 78 запроса могут включать в себя ответ на сообщение-запрос, или имя пользователя и пароль, если применимо, параметры конфигурации канала связи для канала связи 58, такие как размер датаграммы и схема сжатия поля заголовка HDLC (высокоуровневое управление каналом передачи данных), а также параметры для сетевого доступа, такие как IP адрес, конфигурация DNS (доменная система именования), и протокол сжатия заголовка IP, если применимо, и т.д.
Сообщение 78 запроса, в принципе, отформатировано с использованием преднамеренной избыточности в отношении вариантов выбора, что позволяет PDSN 60 выбирать варианты, которые поддерживаются обоими узлами 56 и 60, что позволяет обоим узлам 56 и 60 быстро заканчивать общий процесс установления канала связи на уровне 2 канала. Среди множества вариантов выбора PDSN 60 может избирательно выбирать параметры с ассоциированными вариантами выбора, которые очевидно поддерживаются с целью повышения шанса успешного установления канала связи, сокращая, таким образом, общее время поддержания канала связи.
В ответ на сообщение 78 запроса, как показано на фиг.6, PDSN 60 передает сообщение 80 ответ. В сообщении 80 ответа, PDSN 60 выбирает варианты выбора из различных вариантов выбора. Сообщение 80 ответ включает в себя выбранные варианты параметра с ассоциированными с ними значениями конфигурации. Очень часто сообщение 80 ответ представляет собой последнее сообщение, требуемое до начала передачи сетевого трафика в форме данных 82 пользователя узлом 56. Во время окончания доступа к сети один из узла 56 или PDSN 60 может отправить сообщение 84 запрос на прекращение в другой узел, который после этого отвечает сообщением 86 подтверждения окончания и завершает сеанс связи.
Как можно видеть, в отличие от других протоколов, таких как протокол PPP, описанных выше, процесс 75 установления канала связи включает, по существу, меньшее количество сообщений, обмен которыми производится до начала передачи данных 82 пользователя. В соответствии с этим, установление канала связи на уровне канала связи, то есть на уровне 2, в результате, может быть выполнено быстрее.
Предположим в этом примере, что в ходе обмена данными 82 пользователя с PDSN 60 в сети 46 узел 56 начинает перемещаться в другую сеть, такую как сеть 48. Путь перемещения обозначен ссылочной позицией 88, как показано на фиг.4.
В соответствии с этим сценарием узел 56, в принципе, проходит через процесс, в общем, называемый "передачей обслуживания". Более конкретно, узел 56 переключает сторону связи с PDSN 60 через RAN 62 в сети 46 на PDSN 66 через RAN 68 в сети 48. В соответствии с данным вариантом выполнения, перед передачей обслуживания узел 56 вначале должен получить указание на передачу обслуживания. Указания на передачу обслуживания могут быть выражены в различных формах, воплощенных в разных схемах.
На фиг.7 показана одна такая схема, в общем, обозначенная ссылочной позицией 92. Рассмотрим фиг.7 совместно с фиг.4.
Перед передачей обслуживания предположим, что узел 56 вначале выполняет сеанс 94 связи не-PPP с PDSN 60 через RAN 62 до получения какого-либо доступа к сети. Сеанс 94 может представлять собой процесс 75 установления канала связи, как показано и описано на фиг.6. Сеанс 94 установления канала связи не-PPP продолжается, например, в периоды времени t1-t4.
Следует отметить, что в середине сеанса установления канала связи не-PPP в период времени t2, PDSN 60 передает сообщение 96 запроса на конфигурирование LCP, которое представляет собой сообщение PPP. Причина этого состоит в том, что PDSN 60 первоначально не имеет информации о том, поддерживает ли узел 56 обычный PPP или не-PPP. Для повышения шанса связи с узлом 56 передают как сообщение 76 синхронизации в соответствии с процессом 75 установления канала связи (фиг.6), так и сообщение 96 запроса на конфигурирование LCP в соответствии с PPP. В этом случае узел 56 поддерживает процесс 75 установления канала связи. При этом сеанс 94 протокола уровня сетевого интерфейса выполняется в соответствии с процессом 75 установления канала связи.
После успешного установления сеанса 94 протокола уровня сетевого интерфейса может быть произведен обмен данными 82 пользователя в период времени t5. Предположим, что в этот момент времени узел 56 начинает перемещаться из сети 46 в направлении сети 48.
В соответствии со стандартами cdma2000, сети, обладающие возможностью беспроводной передачи данных, такие как сети 46 и 48, постоянно передают сообщения в режиме широковещательной передачи для обозначения своей идентичности. Сообщение широковещательной передачи может быть выполнено в форме "Сообщения системного параметра" и/или иногда в форме "Сообщения расширенного системного параметра", выполняемого по F-BCCH (Канал управления прямой широковещательной передачей), который представляет собой один из каналов управления прямой передачей в сети. При этом узел, такой как узел 56, всегда может определить свое местоположение, детектируя сообщения широковещательной передачи из сетей.
В сообщении системного параметра, помимо прочего, содержится SID (системная идентификация) и NID (идентификация сети). SID представляет собой число, которое назначено определенному оператору беспроводной связи в сети, такой как сеть 46 или 48. С другой стороны, NID представляет собой номер, который уникально идентифицирует конкретную сеть в системе передачи данных, такой как система 44.
В сообщение расширенного системного параметра включена PZID (идентификация пакетной зоны), которая идентифицирует область зоны обслуживания PCF, такую как BSC/PCF 64 или 70, как показано на фиг.4. Если система передачи данных, такая как система 44, поддерживает HRPD (ВСПП, высокоскоростную пакетную передачу данных), обычно известную как 1xEV-DO, которая представляет собой технологию беспроводной передачи данных, основанную на CDMA (МДКР, многостанционный доступ с кодовым разделением каналов), в маске подсети ID сектора может присутствовать ID (идентификация) подсети вместо PZID в другом сообщении широковещательной передачи, называемом "сообщением параметра сектора".
Рассмотрим теперь фиг.4 и 7, предположим, что когда узел 56 достигает территории сети 48, узел 56 принимает сообщение широковещательной передачи из сети 48. Из сообщения широковещательной передачи, помимо прочего, получают новый NID. Новый NID отличается от предыдущего его аналога. При изменении NID узел 56 знает, что он переместился в другую сеть. Предположим, в данном случае, что сеть 48 не поддерживает какой-либо из не-PPP в качестве своего протокола уровня 2. При этом PDSN 66 в сети 48 передает сообщение 98 запроса на конфигурирование LCP. Узел 56 отвечает в этот раз на сообщение 98 запрос на конфигурирование LCP. Причина этого состоит в том, что узел 56 может обоснованно предположить о своем входе в новую сеть на основе изменения NID, хотя было принято сообщение не-PPP, такое как сообщение 76 синхронизации. Вместо этого было принято сообщение 98 запроса на конфигурирование LCP, которое представляло собой сообщение PPP. Узел 56 сразу определяет, что сеть, в которую он прибыл, такая как сеть 48, не поддерживает какой-либо необычный протокол уровня 2. Узел 56, таким образом, быстро ориентируется в отношении согласования с PDSN 66 через сеанс 100 согласования PPP в период времени t8. В случае успешного согласования, после этого, в момент времени t9, выполняется передача данных 102 пользователя, как показано на фиг.7.
Следует отметить, что узел 56 отвечает на сообщение 98 запроса на конфигурирование LCP из сети 48 в период времени t7, но не на сообщение 96 запроса на конфигурирование LCP из сети 46 в период времени t2. Как указано выше, это происходит из-за того, что узел 56 получил информацию об изменении SID, NID или PZID в момент времени t6 перед моментом времени t7.
После успешного выполнения сеанса 100 согласования PPP может быть установлена передача данных 102 пользователя. По окончании передачи данных 102 пользователя узел 30 или NAS 33 может передать сообщение 104 запроса на прекращение в другой узел, который после этого отвечает сообщением 106 подтверждения прекращения в периоды времени t10 и t11 соответственно и заканчивает сеанс 92 связи.
Соответствующие этапы первой схемы передачи обслуживания в соответствии с данным вариантом выполнения представлены в блок-схеме последовательности операций, показанной на фиг.8.
На фиг.9 показана вторая схема, в общем, обозначенная ссылочной позицией 108. Теперь рассматривается фиг.4 совместно с фиг.9. Как и в предыдущем примере, узел 56 вначале проходит через сеанс 94 протокола связи перед получением доступа к сети через обслуживающий PDSN 60. И снова, для обеспечения лучшего шанса подключения узла 56, сообщение 96 запроса на конфигурирование LCP также передается PDSN 60 в период времени t2 во время сеанса 94, как описано выше. После успешного выполнения сеанса 94 протокола уровня сетевого интерфейса не-PPP, выполняется обмен данными 82 пользователя в период t4 времени, как показано на фиг.9. И снова предположим, что в середине передачи данных 82 пользователя узел 56 начинает перемещаться из сети 46 в направлении сети 48. В этом примере узел 56 принимает указание на передачу обслуживания, причем это указание отличается от указания в предыдущем примере.
В частности, когда узел 56 достигает территории сети 48, узел 56 принимает другое сообщение 110 запроса на конфигурирование LCP, в период t5 времени, как показано на фиг.9. В это время узел 56 может отличить место происхождения сообщения 110 запроса на конфигурирование LCP в период времени t5 от сообщения 96 запроса на конфигурирование LCP в период времени t2 на основе разных ID (ИД, идентификаций) сообщения в сообщениях 110 и 96, как описано ниже.
В этот переходный момент полезно сделать отступление для пояснения формата фрейма данных сообщения PPP.
На фиг.10 представлен формат фрейма данных, имеющий HDLC (высокоуровневое управление каналом передачи данных) - как фрейм, используемый в PPP.
Шаблон фрейма для пакета данных, в общем, обозначен ссылочной позицией 112 и представляет собой, в принципе, шаблон пакета в соответствии со спецификацией RFC 1662 для PPP. Более конкретно, фрейм 112 данных включает в себя поле 114 флага, поле 116 адреса, поле 118 управления, поле 120 номера протокола, поле 122 данных и поле 124 FCS (ПКФ, последовательность контроля фрейма).
Для обеспечения обратной совместимости с PPP, большинство протоколов уровня сетевого интерфейса, предназначенные для замены PPP, также сконструированы с форматом фрейма, более или менее похожим на формат 112 фрейма для PPP. Например, в протоколе 75 канала связи, раскрытом в патентной заявке '068, показанной на фиг.6, используется формат фрейма, аналогичный формату фрейма PPP.
Рассмотрим теперь фиг.10.
Поле 114 флага имеет длину один байт и обозначает начало фрейма пакета данных. Поле 114 флага всегда имеет шестнадцатеричное значение 7E, и это значение является тем же значением, которое используется в процессе 54 канала связи и PPP, в соответствии с требованиями RFC 1662.
Поле 116 адреса также представляет собой поле длиной один байт и в нем всегда установлено шестнадцатеричное значение FF, также в соответствии с RFC 1662.
Поле 118 управления имеет длину один байт и является фиксированным и имеет шестнадцатеричное значение 03, в соответствии с требованиями RFC 1662.
В поле 120 номера протокола, значение поля обозначает, что собой представляет пакет 112 данных. Область 120 номера протокола имеет длину два байта. Например, как определено в RFC 1661 и 1662, каждое из сообщений LCP, такое как сообщение запроса на конфигурирование LCP (фиг.2), имеет шестнадцатеричное значение C021. Для того чтобы можно было отличать одно сообщение PPP от другого сообщения, такого как сообщение запроса на конфигурирование LCP, и сообщение не подтверждения конфигурации LCP (фиг.2), разные ИД сообщения включены в поле 122 данных, как поясняется ниже. Что касается других протоколов канала связи, разработанных для замены PPP, таких как протокол 75, раскрытый в заявке '068, представленный на фиг.6, в них используются другие номера 120 протокола, для того чтобы можно было отличить их от других сообщений PPP. Например, в процессе 75 установления канала связи, показанном на фиг.6, сообщение 76 синхронизации, сообщение 78 запроса или сообщение 80 ответа, используемые в процессе 75 установления канала связи (фиг.6) имеют уникальное значение протокола, отличающееся от любого из значений протокола, используемых в PPP. Это позволяет легко различать, является ли пакет 112 данных пакетом PPP или пакетом не-PPP.
Поле 122 данных имеет длину в диапазоне от нуля до большего количества байт полезной информации, чем содержит либо информация данных или управления. Например, если значение в поле 120 номера протокола имеет значение, которое обозначает, что пакет 112 данных представляет собой сообщение 96 или 110 запроса на конфигурирование LCP (фиг.9), поле 122 данных включает в себя все существенные варианты выбора параметров связи при установлении канала 58 или 90 связи соответственно. В качестве другого примера, если значение в поле 120 номера протокола имеет значение, которое обозначает, что пакет 112 данных представляет собой данные 82 или 100 пользователя (фиг.9), пакет данных IP, генерируемый из уровня 3, будет полностью инкапсулирован в поле 122 данных.
Поле 124 FCS имеет длину в диапазоне от двух до четырех байт и содержит коды, такие как CRC (ЦИК, циклический избыточный код) фрейма 112, предназначенный для обеспечения основной защиты от ошибок во время передачи.
Снова рассмотрим фиг.9. Как указано выше, поле 122 данных включает в себя ИД сообщения, называемый "кодом" в соответствии с RFC 1661, который позволяет отличить один тип сообщения PPP от другого, например, позволяет различать сообщение запроса на конфигурирование LCP и сообщение подтверждения конфигурирования LCP (фиг.2). Другое отличие можно также обеспечить в ИД сообщения в пределах одного типа сообщения, например, путем присоединения вспомогательного ИД, называемого "идентификатором" в RFC 1661. Например, сообщение 96 запроса на конфигурирование LCP и сообщение LCP 110 запроса на конфигурирование LCP в процессе 108, показанном на фиг.9, может быть сформировано с разными кодами, или в качестве альтернативы, с одинаковым кодом, но разными идентификаторами, характерными для сетей. При этом сети 48 и 46 могут быть разработаны так, что они будут передавать разные сообщения 96 и 110 конфигурирования LCP соответственно путем включения разных кодов или идентификаторов, внедренных в поле 122 данных пакета 112 данных (фиг.10). Следовательно, в данном примере, когда узел 56 перемещается из сети 46 в сеть 48, благодаря распознаванию сообщения запроса на конфигурирование LCP, идентификатор которого отличается от идентификатора в сети 48, узел 56 знает, что он находится на территории сети 48.
Находясь в сети 48, узел 56 не принимает сообщение не-PPP, но вместо этого принимает сообщение 110 запроса на конфигурирование LCP, которое представляет собой сообщение PPP и которое имеет другой идентификатор, отличающийся от идентификатора сообщения 96 запроса на конфигурирование LCP, при этом узел 56 определяет, что сеть 48 не поддерживает какой-либо протокол не-PPP в качестве своего протокола установления канала связи. Узел 56 быстро ориентируется и отвечает на сообщение 110 запроса на конфигурирование LCP. После этого выполняется согласование 100 PPP, как показано на фиг.9. Остальная часть процесса 108, по существу, аналогична процессу 92, представленному со ссылкой фиг.7 и описанному выше, и больше не повторяется.
Соответствующие этапы второй схемы передачи обслуживания в соответствии с данным вариантом выполнения представлены в блок-схеме последовательности операций, показанной на фиг.11.
В качестве альтернативы, пакет идентификации версии/пропускной способности может быть вставлен в поле 122 данных пакета 112 данных. В соответствии со стандартом cdma2000, объявленным 3GPP2, пакет идентификации версии/пропускной способности может быть включен, как определено в документе 3GPP2, под названием "Wireless IP Network Standard", TIA-835D. Пакет идентификации версии/пропускной способности, в принципе представляет собой пакет, специфичный для поставщика, как можно видеть по его названию, который идентифицирует соответствующую информацию определенного поставщика узла, такого как узел 56 или PDSN 60 или 66, показанный на фиг.4. Вначале, во время фазы LCP сеанса PPP, выполняют обмен пакетами идентификации версии/пропускной способности. Цель этого обмена пакетами идентификации версии/пропускной способности состоит в том, чтобы исключить ненужные этапы согласования во время сеанса PPP в отношении не поддерживаемых свойств каждым из узлов, после того как проводящие согласование узлы указывают свои версии и пропускные способности на раннем этапе в процессе согласования.
В качестве примера, предположим, что узел 56 на фиг.9 в период времени t2 принимает сообщение 96 запрос на конфигурирование LCP с пакетом идентификации версии/пропускной способности, который не исключает использование какого-либо из не-PPP, при этом узел 56 в период времени t3, таким образом, не переходит непосредственно к использованию PPP для установления канала связи. Вместо этого, узел 56 продолжает процесс 94 установления канала связи не-PPP в период времени t3. С другой стороны, если узел 56 в период времени t5 принимает сообщение 110 запроса на конфигурирование LCP с пакетом идентификации версии/пропускной способности, имеющим информацию, которая позволяет использовать только PPP, тогда узел 56 мгновенно ориентируется и проводит согласование с целевым узлом 66 через PPP в период времени t6.
В качестве альтернативы, отдельный пакет идентификации версии/пропускной способности может быть передан перед сообщением 96 или 110 запроса на конфигурирование LCP. Таким образом, например, в период времени t5, два сообщения могут быть переданы целевым PDSN 66. Первое сообщение представляет собой пакет идентификации версии/пропускной способности с информацией, специфичной для поставщика, включенной в поле 122 данных пакета 112 данных (фиг.10), как описано выше. Второе сообщение может представлять собой обычное сообщение запроса на конфигурирование LCP, такое как первое сообщение запроса на конфигурирование LCP, во время фазы 36 согласования LCP сеанса 34 PPP, как показано на фиг.2.
Соответствующие этапы схемы передачи обслуживания, описанные непосредственно выше, представлены в блок-схеме последовательности операций, показанной на фиг.11A.
На фиг.12 показана еще одна схема передачи обслуживания, в общем, обозначенная ссылочной позицией 130. Рассмотрим теперь фиг.12 совместно с фиг.4. Как и в предыдущей схеме, находясь в сети 46, узел 56 должен пройти через сеанс 94 установления канала связи с PDSN 60 перед получением доступа к сети. И снова, для обеспечения лучшего шанса подключения узла 56, сообщение 96 запроса на конфигурирование LCP также передается обслуживающим PDSN 60 в сети 46 в период времени t2 во время сеанса 94, как также пояснялось выше. Следует отметить, что в это время сообщение 96 запроса на конфигурирование LCP передают во время передачи других сообщений не-PPP в сеансе 94 установления канала связи. После успешного выполнения сеанса 94 протокола уровня сетевого интерфейса не-PPP, выполняют обмен данными 82 пользователя в период времени t4, аналогично тому, как было описано выше и представлено на фиг.12. И снова предположим, что в середине обмена данными 82 пользователя узел 56 начинает перемещаться из сети 46 в направлении сети 48.
Когда узел 56 достигает территории сети 48, в это время узел 56 принимает множество сообщений 132A-132N запроса на конфигурирование LCP, в период времени t7, как показано на фиг.12. В этом примере узел 56 может отличать место происхождения сообщения 96 запроса на конфигурирование LCP из сети 46 в период времени t2 от сообщения 132A-132N запроса на конфигурирование LCP из сети 48 в период времени t7, на основе структуры передачи сообщения. Более конкретно, в период времени t2 узел 56 принимает одно сообщение 96 конфигурирования LCP во время передачи других сообщений не-PPP в сеансе 94 установления канала связи. В отличие от этого, в период времени t7 узел 56 принимает множество сообщений 132A-132N конфигурирования LCP.
Таким образом, основываясь на структуре приема сообщений запроса на конфигурирование LCP, узел 56 определяет, поддерживает ли сетевой узел 56 в настоящее время протокол не-PPP или нет. Например, узел 56 может быть запрограммирован так, что он будет отвечать только на второе последовательное сообщение запроса на конфигурирование LCP. Таким образом, в этом случае в период времени t2, когда узел 56 принимает сообщение 96 запроса на конфигурирование LCP, узел 56 ожидает поступления следующего сообщения. Если следующее поступившее сообщение не представляет собой повторение сообщение 96 запроса на конфигурирование LCP, узел 56 определяет, что сеть 46 поддерживает другие протоколы не-PPP, кроме PPP, и просто игнорирует сообщение 96 запроса на конфигурирование LCP в период времени t2, и продолжает сеанс 94 канала связи не-PPP, как описано выше.
С другой стороны, если узел 56 принимает больше, чем одно последовательное сообщение 132A-132N запроса на конфигурирование LCP, например, во время периода времени t7, узлы 56 знают, что сеть, передающая сообщения, сеть 48 в данном случае, поддерживает только PPP и не поддерживает другие протоколы уровня сетевого интерфейса. Узел 56 немедленно переходит на связь с целевым PDSN 66 через RAN 68 в сети 48, используя протокол PPP, как показано на фиг.12. Остальная часть процесса 130, по существу, аналогична процессам 92 и 108, показанным соответственно на фиг.7 и фиг.9, описанным выше, и, таким образом, больше не повторяется.
Следует отметить, что количество сообщений 132A-132N запроса на конфигурирование LCP, на которые отвечает узел 56, должно быть конфигурируемым. Например, вместо начала согласования 100 PPP с целевым PDSN 66, после второго сообщения 132B запроса на конфигурирование LCP, как описано в приведенном выше примере, узел 56 вполне может начать согласование 100 PPP, после i-го сообщения 132i запроса на конфигурирование LCP, где i находится в диапазоне от 2 до N, причем N представляет собой целое число, больше 2.
Соответствующие этапы третьей схемы передачи обслуживания в соответствии с данным вариантом выполнения показаны в блок-схеме последовательности операций, представленной на фиг.13.
На фиг.14 схематично представлена часть воплощения аппаратных средств устройства, такого как узел 56, представленный на фиг.4, обозначенного ссылочной позицией 140 в соответствии с примерным вариантом выполнения изобретения. Устройство 140 может быть построено и может быть внедрено в различных формах, например в виде переносного компьютера, КПК или сотового телефона, помимо прочих вариантов.
Устройство 140 содержит центральную шину 142 передачи данных, соединяющую несколько схем вместе. Схемы включают в себя ЦПУ (центральное процессорное устройство) или контроллер 144, схему 146 приемника, схему 148 передатчика и модуль 150 памяти.
Если устройство 140 представляет собой часть устройства беспроводной связи, схемы 146 и 148 приема и передачи могут быть подключены к РЧ (радиочастотной) схеме, но это не показано на чертеже. Схема 146 приема обрабатывает и помещает в буфер принимаемые сигналы перед передачей их в шину 142 передачи данных. С другой стороны, схема 148 передачи обрабатывает и помещает в буфер данные из шины 142 передачи данных перед передачей их из устройства 140. ЦПУ/контроллер 144 выполняет функцию управления данными в шине 142 передачи данных и, кроме того, выполняет функцию общей обработки данных, включающей в себя выполнение содержания инструкций в модуле 140 памяти.
Вместо использования отдельных компоновок, как показано на фиг.14, в качестве альтернативы, схема 148 передатчика и схема 146 приемника может представлять собой часть ЦПУ/контроллера 144.
Модуль 150 памяти включает в себя набор инструкций, в общем, обозначенный ссылочной позицией 152. В данном варианте выполнения инструкции включают в себя, помимо прочего, такие участки, как функция 154 стека протокола, клиент 156 установления канала связи, функция 158 передачи обслуживания канала связи и функция 160 PPP. Функция 154 стека протокола обеспечивает работу стека протокола, аналогичного стеку 74, как показано и описано выше со ссылкой на фиг.5. Клиент 156 установления канала связи включает в себя наборы инструкций, предназначенные для установления одного или более процессов канала связи, кроме процесса канала связи PPP, таких как процесс 94, как показано на фиг.7, 9 и 12, описанных выше. Функция 160 PPP включает в себя наборы инструкций, обеспечивающих возможность выполнения устройством 140 процесса PPP. Функция 158 передачи обслуживания канала связи включает в себя наборы инструкций, предназначенных для выполнения процесса передачи обслуживания, такого как процесс 92, 108 и 130, описанных и показанных на соответствующих чертежах на фиг.7-13. Функция 160 PPP может использоваться независимо для сети, которая поддерживает процесс канала связи PPP или не-PPP, или в качестве отступления, в случае, когда сеть не поддерживает процессы канала связи в соответствии с другими не-PPP, как также описано выше.
В данном варианте выполнения модуль 150 памяти представляет собой схему ОЗУ (оперативное запоминающее устройство). Примеры участков 154, 156, 158 и 160 инструкций представляют собой программные процедуры или модули. Модуль 150 памяти может быть связан с другой схемой памяти (не показана), которая может быть энергозависимого или энергонезависимого типа. В качестве альтернативы, модуль 150 памяти может быть построен на основе других типов схемы, таких как EEPROM (ЭСППЗУ, электрически стираемое программируемое постоянное запоминающее устройство), EPROM (СППЗУ, стираемое программируемое постоянное запоминающее устройство), ПЗУ (постоянное запоминающее устройство), ASIC (специализированная интегральная микросхема), магнитный диск, оптический диск и другие устройства, хорошо известные в данной области техники.
Кроме того, следует отметить, что процессы 92, 108 и 130, как описано выше и представлено на фиг.7-13, 15 и 16, также могут быть кодированы в виде инструкций, считываемых компьютером, записанных на любом считываемом компьютером носителе информации, известном в данной области техники. В данном описании и приложенной формуле изобретения термин "носитель информации, считываемый компьютером" относится к любому носителю информации, который участвует в предоставлении инструкций для любого процессора, такого как ЦПУ/контроллер 144, показанного и описанного на фиг.14, для их выполнения. Такой носитель информации может быть носителем типа накопителя и может быть выполнен в форме энергозависимого или энергонезависимого носителя информации, как также описано выше, например, при описании модуля 150 памяти, со ссылкой на фиг.14. Такой носитель информации также может быть носителем передающего типа и может включать в себя коаксиальный кабель, медный провод, оптический кабель и радиоинтерфейс, по которому передают акустические или электромагнитные волны и который позволяет передавать сигналы, считываемые машинами или компьютерами.
Наконец, как описано в варианте выполнения, процедуры передачи обслуживания представлены как выполняемые в ходе обмена данными 82 пользователя (например, см. фиг.7, 9 и 12). Однако это условие не является обязательным. Возможно также выполнять процедуру передачи обслуживания, когда узел 56 находится в процессе установления сеанса 94 протокола уровня сетевого интерфейса. На фиг.15 показан такой сценарий, в котором выделен процесс 92 установления канала связи, как показано и описано на фиг.7, и некоторые соответствующие этапы повторяются с целью иллюстрации. Как показано на чертеже, в период t4 времени, перед окончанием процесса 94 установления канала связи, узел 56 находится в процессе перемещения в сеть 48 и дополнительно определяет изменение SID, NID, PZID или ID подсети в период времени t4. При этом узел 56 не обязательно может принимать сообщение 80 ответа из PDSN 60 в сети 46 во время перемещения. Однако когда узел 56 принимает сообщение 98 запроса на конфигурирование LCP в период времени t5, узел 56 определяет, что он находится на территории сети 48 и может немедленно начать процесс 100 согласования PPP аналогично тому, как описано выше. Кроме того, это же справедливо для процессов 108 и 130, представленных и описанных на фиг.9 и 12 соответственно. Таким образом, процесс передачи обслуживания в соответствии с примерным вариантом выполнения изобретения необязательно должен происходить только во время обмена данными пользователя. Кроме того, система 44 была описана как поддерживающая стандарты cdma2000. Другие стандарты также, очевидно, могут быть применены. Пример других стандартов представляет собой WCDMA (широкополосный многостанционный доступ с кодовым разделением каналов), объявленный 3GPP (Проект партнерства по разработке системы связи третьего поколения). Кроме того, в примерном варианте выполнения протокол уровня 3 описан как протокол IP. IP может иметь другую версию, такую как IPv4 (протокол Интернет версии 4) и IPv6 (протокол Интернет версии 6). Кроме того, следует отметить, что в равной степени применимы другие протоколы уровня 3. Например, протокол уровня 3 может представлять собой IPX (Протокол межсетевого пакетного обмена), Apple-Talk и разные другие сетевые протоколы других версий. Кроме того, любые логические блоки, схемы и этапы алгоритма, описанные совместно с вариантом выполнения, могут быть воплощены в виде аппаратных средств, программных средств, встроенного программного обеспечения или их комбинаций. Для специалиста в данной области техники будет понятно, что эти и другие изменения в форме и деталях могут быть выполнены без отхода от объема и сущности изобретения.
1. Способ передачи обслуживания мобильного узла от обслуживающего узла в целевой узел в системе связи, содержащий получение доступа к упомянутому обслуживающему узлу через первый протокол уровня сетевого интерфейса;
получение указания на упомянутую передачу обслуживания; и
получение доступа к упомянутому целевому узлу через второй протокол уровня сетевого интерфейса,
причем получение доступа включает в себя отправку мобильным узлом набора
вариантов параметров для аутентификации, конфигурации канала связи и доступа к сети в одном сообщении запроса.
2. Способ по п.1, в котором упомянутое получение упомянутого указания включает в себя прием сообщения, имеющего идентификацию, идентифицирующую упомянутый целевой узел.
3. Способ по п.1, в котором упомянутое получение упомянутого указания включает в себя прием пакета данных, имеющего идентификацию сообщения в поле данных упомянутого пакета данных, идентифицирующую упомянутый целевой узел.
4. Способ по п.1, в котором упомянутое получение упомянутого указания включает в себя прием пакета данных, имеющего пакет идентификации версии/пропускной способности в поле данных упомянутого пакета данных, идентифицирующий упомянутый целевой узел.
5. Способ по п.1, в котором упомянутое получение упомянутого указания включает в себя прием множества сообщений запроса упомянутого второго протокола уровня сетевого интерфейса из упомянутого целевого узла.
6. Способ по п.1, дополнительно включающий в себя обмен данными пользователя с упомянутым обслуживающим узлом после упомянутого получения доступа к упомянутому обслуживающему узлу, в котором упомянутое указание на упомянутую передачу обслуживания принимают в ходе упомянутого обмена упомянутых данных пользователя.
7. Устройство по п.1, в котором упомянутое указание на упомянутую передачу обслуживания принимают в ходе получения доступа к упомянутому обслуживающему узлу через упомянутый первый протокол уровня сетевого интерфейса.
8. Способ передачи обслуживания мобильного узла из первого узла во второй узел в системе связи, которая поддерживает IP (протокол Интернет), причем способ содержит получение доступа к упомянутому первому узлу через протокол уровня сетевого интерфейса, который не является РРР (протоколом канала связи с непосредственным соединением), получение указания на упомянутую передачу обслуживания и получение доступа к упомянутому второму узлу через упомянутый РРР, причем получение доступа включает в себя отправку мобильным узлом набора вариантов параметров для аутентификации, конфигурации канала связи и доступа к сети в одном сообщении запроса.
9. Способ по п.8, в котором упомянутое получение упомянутого указания включает в себя прием сообщения, имеющего идентификацию сообщения, идентифицирующую упомянутый второй узел, причем упомянутую идентификацию сообщения выбирают из группы, состоящей из NID (идентификация сети), SID (системная идентификация), PZID (идентификация зоны пакета) и ИД подсети (идентификация подсети), ассоциированных с упомянутым вторым узлом.
10. Способ по п.8, в котором упомянутое получение упомянутого указания включает в себя прием пакета данных, имеющего код или идентификатор, включенный в поле данных упомянутого пакета данных, идентифицирующий упомянутый второй узел.
11. Способ по п.8, в котором упомянутое получение упомянутого указания включает в себя прием пакета данных, имеющего пакет идентификации версии/пропускной способности, включенной в поле данных упомянутого пакета данных, идентифицирующий упомянутый второй узел.
12. Способ по п.8, в котором упомянутое получение упомянутого указания включает в себя прием множества сообщений запроса на конфигурирование LCP (протокол управления каналом) упомянутого РРР из упомянутого второго узла.
13. Устройство связи в системе связи, содержащее
средство получения доступа к обслуживающему узлу в упомянутой системе связи через первый протокол уровня сетевого интерфейса;
средство приема указания на передачу обслуживания; средство для получения доступа к целевому узлу через второй протокол уровня сетевого интерфейса, причем получение доступа включает в себя отправку устройством набора вариантов параметров для аутентификации, конфигурации канала связи и доступа к сети в одном сообщении запроса.
14. Устройство по п.13, в котором упомянутое указание включает в себя идентификацию в сообщении, идентифицирующую упомянутый целевой узел.
15. Устройство по п.13, в котором упомянутое указание включает в себя идентификацию сообщения в поле данных пакета данных, идентифицирующую упомянутый целевой узел.
16. Устройство по п.13, в котором упомянутое указание включает в себя пакет идентификации версии/пропускной способности в поле данных пакета данных, идентифицирующий упомянутый целевой узел.
17. Устройство по п.13, в котором упомянутое указание включает в себя множество сообщений запроса упомянутого второго протокола уровня сетевого интерфейса из упомянутого целевого узла.
18. Устройство связи в системе связи, которое поддерживает IP (протокол Интернет), содержащее средство получения доступа к первому узлу через протокол уровня сетевого интерфейса, который не является РРР (протоколом канала связи с непосредственным соединением); средство получения указания на передачу обслуживания; средство получения доступа ко второму узлу через упомянутый РРР, причем получение доступа включает в себя отправку устройством набора вариантов параметров для аутентификации, конфигурации канала связи и доступа к сети в одном сообщении запроса.
19. Устройство по п.18, в котором упомянутое указание включает в себя сообщение, имеющее идентификацию сообщения, идентифицирующую упомянутый второй узел, причем упомянутую идентификацию сообщения выбирают из группы, состоящей из NID (идентификация сети), SID (системная идентификация), PZID (идентификация зоны пакета) и ИД подсети (идентификация подсети), ассоциированных с упомянутым вторым узлом.
20. Устройство по п.18, в котором упомянутое указание включает в себя пакет данных, имеющий код или идентификатор, включенный в поле данных упомянутого пакета данных, идентифицирующий упомянутый второй узел.
21. Устройство по п.18, в котором упомянутое указание включает в себя пакет данных, имеющий пакет идентификации версии/пропускной способности, включенный в поле данных упомянутого пакета данных, идентифицирующий упомянутый второй узел.
22. Устройство по п.18, в котором упомянутое указание включает в себя множество сообщений запроса на конфигурирование LCP (протокол управления каналом) упомянутого РРР из упомянутого второго узла.
23. Устройство связи в системе связи, содержащее
модуль памяти, включающий в себя инструкции, считываемые компьютером, предназначенные для получения доступа к обслуживающему узлу упомянутой системы связи через первый протокол уровня сетевого интерфейса, получения указания на передачу обслуживания и получения доступа к целевому узлу упомянутой системы связи через второй протокол уровня сетевого интерфейса; и
схему процессора, соединенную с упомянутым модулем памяти для обработки упомянутых инструкций, считываемых компьютером, причем получение доступа включает в себя отправку устройством набора вариантов параметров для аутентификации, конфигурации канала связи и доступа к сети в одном сообщении запроса.
24. Устройство по п.23, в котором упомянутое указание включает в себя сообщение, имеющее идентификацию, идентифицирующую упомянутый целевой узел.
25. Устройство по п.23, в котором упомянутое указание включает в себя пакет данных, имеющий идентификацию сообщения в поле данных упомянутого пакета данных, идентифицирующую упомянутый целевой узел.
26. Устройство по п.23, в котором упомянутое указание включает в себя пакет данных, имеющий пакет идентификации версии/пропускной способности в поле данных упомянутого пакета данных, идентифицирующий упомянутый целевой узел.
27. Устройство по п.23, в котором упомянутое указание включает в себя множество сообщений запроса упомянутого второго протокола уровня сетевого интерфейса из упомянутого целевого узла.
28. Устройство по п.23, в котором упомянутый модуль памяти дополнительно включает в себя инструкции, считываемые компьютером, для обмена данными пользователя с упомянутым обслуживающим узлом после упомянутого получения доступа к упомянутому обслуживающему узлу и начала упомянутой передачи обслуживания при получении упомянутого указания во время обмена упомянутыми данными пользователя.
29. Устройство по п.23, в котором упомянутый модуль памяти дополнительно включает в себя считываемые компьютером инструкции, предназначенные для начала упомянутой передачи обслуживания, в то время как упомянутое указание принимают во время упомянутого доступа к упомянутому обслуживающему узлу через упомянутый первый протокол уровня сетевого интерфейса.
30. Устройство по п.23, в котором модуль памяти дополнительно включает в себя считываемые компьютером инструкции, предоставляющие набор вариантов выбора параметра, для аутентификации, конфигурирования канала связи и доступа к сети, в сообщении запроса, во время упомянутого получения доступа к упомянутому обслуживающему узлу.
31. Устройство связи в системе связи, которое поддерживает IP (протокол Интернет), содержащее
модуль памяти, включающий в себя считываемые компьютером инструкции, предназначенные для получения доступа к первому узлу через протокол уровня сетевого интерфейса, который не является РРР (протоколом канала связи с непосредственным соединением), получения указания на передачу обслуживания и получения доступа ко второму узлу через упомянутый РРР и схему процессора, соединенную с упомянутым модулем памяти, для обработки упомянутых считываемых компьютером инструкций, причем получение доступа включает в себя отправку устройством набора вариантов параметров для аутентификации, конфигурации канала связи и доступа к сети в одном сообщении запроса.
32. Устройство по п.31, в котором модуль памяти дополнительно включает в себя считываемые компьютером инструкции, предназначенные для предоставления упомянутому второму узлу набора вариантов выбора параметра для аутентификации, конфигурирования канала связи и доступа к сети, в сообщении запроса, поступившем во время упомянутого получения доступа.
33. Устройство по п.31, в котором упомянутое указание включает в себя сообщение, имеющее идентификацию сообщения, идентифицирующую упомянутый второй узел, причем упомянутую идентификацию сообщения выбирают из группы, состоящей из NID (идентификация сети), SID (системная идентификация), PZID (идентификация зоны пакета) и ИД подсети (идентификация подсети), ассоциированных с упомянутым вторым узлом.
34. Устройство по п.31, в котором упомянутое указание включает в себя пакет данных, имеющий код или идентификатор, включенный в поле данных упомянутого пакета данных, идентифицирующий упомянутый второй узел.
35. Устройство по п.31, в котором упомянутое указание включает в себя пакет данных, имеющий пакет идентификации версии/пропускной способности, включенный в поле данных упомянутого пакета данных, идентифицирующий упомянутый второй узел.
36. Устройство по п.31, в котором упомянутое указание включает в себя множество сообщений запроса на конфигурирование LCP (протокол управления каналом) упомянутого РРР из упомянутого второго узла.
