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

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

Иллюстрации

Показать все

Реферат

Испрашивание приоритета

В настоящей заявке на патент испрашивается приоритет в соответствии с предварительной заявкой США № 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 пользоват