Способ и устройство для завершенной на мобильном телефоне связи короткими пакетами данных

Способ и устройство для завершенной на мобильном телефоне связи короткими пакетами данных

Иллюстрации

Показать все

Реферат

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

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

Уровень техники

Когда дейтаграмма протокола Интернет (IP), переносящая информацию, предназначенную для целевого устройства связи, отправляется из узлов обслуживания пакетных данных (PDSN) контроллеру базовой станции/функции управления пакетами (BSC/PCF), в то время как пакетный сеанс находится в ожидании, BSC/PCF необходимо определять, может ли быть информация отправлена в виде коротких пакетов данных (SDB). Один из алгоритмов должен использовать размер принимаемого информационного пакета в качестве критерия фильтрации. То есть когда принятый информационный пакет найден меньшим, чем заданный размер, информационный пакет может быть отправлен целевой мобильной станции в виде SDB по прямому общему каналу, например, не дожидаясь активации канала трафика. В ином случае канал трафика необходимо устанавливать перед отправкой информационного пакета. Этот алгоритм не может хорошо работать в услугах группового вызова, например, где клиенты и серверы отправляют сообщения, варьируемые по размеру, когда сеанс данных находится в ждущем состоянии. Однако не все эти сообщения являются критичными по времени и, следовательно, не имеют потребности быть отправленными в виде SDB. Некоторые большие сообщения может быть необходимо посылать в виде SDB, тогда как некоторые небольшие сообщения может быть необходимо доставлять после того, как канал трафика переустановлен. Использование большого размера пакета в качестве критерия фильтрации может инициировать отправку многих небольших сообщений в виде SDB и, следовательно, служит причиной значительной нагрузки на общий канал. С другой стороны, если использован небольшой размер пакета, то большие сообщения, которые являются критичными по времени, не могут быть немедленно отправлены в виде SDB.

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

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

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

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

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

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

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

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

Фиг.2 иллюстрирует IP-дейтаграмму, выполненную в виде кадра и инкапсулированную;

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

Фиг.4 иллюстрирует заголовочную часть для IP-дейтаграммы, показанной на Фиг.2;

Фиг.5 иллюстрирует поле типа обслуживания для заголовочной части, показанной на Фиг.4, согласно одному из вариантов осуществления;

Фиг.6 иллюстрирует поле типа обслуживания для заголовочной части, показанной на Фиг.4, согласно еще одному варианту осуществления;

Фиг.7 иллюстрирует поле типа обслуживания для заголовочной части, показанной на Фиг.4, согласно еще одному другому варианту осуществления;

Фиг.8 иллюстрирует альтернативную заголовочную часть для IP-дейтаграммы, показанной на Фиг.2;

Фиг.9 иллюстрирует структуру кадра для PPP-кадра, показанного на Фиг.2;

Фиг.10 иллюстрирует алгоритм анализа для PPP-кадра, показанного на Фиг.2;

Фиг.11 иллюстрирует алгоритм анализа для заголовочной части IP-дейтаграммы, показанной на Фиг.4 и Фиг.8; и

Фиг.12 иллюстрирует упрощенный алгоритм анализа.

Подробное описание

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

Фиг.1 иллюстрирует диаграмму последовательности операций вызова для доставки завершенных на мобильном устройстве коротких пакетов данных во время ожидающего сеанса пакетных данных. Во время состояния ожидания поддерживается сеанс двухточечного (от точки к точке) протокола передачи (PPP), но канал трафика деактивирован. Информация, поступающая на PDSN 102, например, в виде IP-дейтаграмм(ы), отправляется в BSC/PCF 104 на этапе (b). BSC/PCF 104 делает определение в отношении того, каким образом отправлять информацию, на этапе (c). На этапе (c) BSC/PCF 104 осуществляет анализ принятой информации. Если поле типа обслуживания (TOS) в заголовочной части принятой IP-дейтаграммы отмечено для SDB-доставки, то BSC/PCF 104 использует этапы от (d) до (g), чтобы доставлять информацию в виде SDB. Если BSC/PCF 104 определяет, что принятая информация должна быть отправлена в виде SDB, то BSC/PCF 104 сначала выполняет главный поисковый вызов, на этапе (d), чтобы локализовать целевую, мобильную станцию. Впоследствии информация отправляется в виде SDB по общему каналу, например, на мобильную станцию (MS) 106, на этапе (f). Целевая мобильная станция может быть идентифицирована в ответном сообщении на главный поисковый вызов мобильной станции, принятом на этапе (e). В ином случае, если BSC/PCF 104 определяет, что принятая информация не должна быть отправлена в виде SDB, то BSC/PCF 104 полагается на контроллер мобильной станции (MSC) 108, чтобы локализовать целевую мобильную станцию, например, через процедуру главного поискового вызова, повторно устанавливает канал трафика и затем отправляет информацию. Эта процедура не показана на диаграмме.

В одном из вариантов осуществления сетевая сущность, такая как сервер 110 группового вызова, может предоставлять информацию, предназначенную для целевой MS 106, в виде IP-дейтаграммы. PDSN 102 инкапсулирует принятую IP-дейтаграмму перед отправкой в BSC/PCF 104. Фиг.2 иллюстрирует последовательность операций построения IP-дейтаграммы согласно одному из вариантов осуществления. IP-дейтаграмма 202 может включать в себя заголовочную часть и информационную часть. Если PDSN 102 является одноранговым PPP-устройством по отношению к MS, то PDSN 102 может инкапсулировать принятую IP-дейтаграмму 202 вовнутрь PPP-заголовка 204 и PPP-хвоста 206, формирующих PPP-кадр 208.

Согласно одному из вариантов осуществления, как описано в TIA/EIA/IS-2001, «Interoperability Specification (IOS) for cdma2000 Access Network Interfaces» («Спецификации совместимости (IOS) для сетевых интерфейсов доступа cdma2000»), от августа 2001 г., (IOSv4.1), перед отправкой информации в BSC/PCF 104, PDSN 102 добавляет заголовок 210 инкапсуляции групповой маршрутизации (GRE) и IP-заголовок 212 к принятому PPP-кадру 208, формируя GRE-пакет 214. GRE-пакет 214 обрабатывается как полезные данные IP и направляется в BSC/PCF 104, например, по каналу A10.

После приема GRE-пакетов 214 BSC/PCF 104 удаляет GRE-заголовок 210 и IP-заголовок 212 из принятого GRE-пакета 214 и может добавить подходящие заголовки перед отправкой информации по эфирному интерфейсу целевой MS 106. Как обсуждено выше, когда сеанс пакетных данных является ожидающим, BSC/PCF 104 необходимо проверять принятый PPP-кадр 208, чтобы определить, где начинается заголовочная часть IP-дейтаграммы 202, перед тем как начать анализ IP-дейтаграммы 202, как будет подробно обсуждено позже в настоящем патентном документе.

Возможно, что одинарный GRE-пакет 214 содержит неполный PPP-кадр или многочисленные PPP-кадры, как предписано в TIA/EIA/IS-835, «Wireless IP Network Standard» («Стандарт беспроводной IP-сети»), от 6 декабря 2001 года. В таких случаях стандарт предписывает, что поле порядкового номера, включенное в GRE-заголовок 210, может быть использовано, чтобы гарантировать последовательную доставку пакетов. В случае, если порядковый номер GRE-заголовка 210 разрешен, BSC/PCF 104 повторно упорядочивает принимаемые GRE-пакеты перед анализом PPP-кадра.

Фиг.3 - упрощенная структурная схема варианта осуществления BSC/PCF 304 и мобильной станции 306, которые допускают реализацию различных раскрытых вариантов осуществления. Для конкретной передачи данных голосовые данные, пакетные данные и/или сообщения могут быть обмениваемыми между BSC/PCF 304 и мобильной станцией 306 через эфирный интерфейс 308. Могут быть переданы различные типы сообщений, такие как сообщения, используемые, чтобы устанавливать сеанс связи между BSC/PCF 304 и мобильной станцией 306, сообщения регистрации и поискового вызова и сообщения, используемые, чтобы управлять передачей данных (например, управление мощностью, информация о скорости передачи данных, подтверждение и так далее). Некоторые из этих типов сообщений описаны более подробно ниже.

Для обратной линии связи на BSC/PCF 306 голосовые и/или пакетные данные (например, из источника 310 данных) и сообщения (например, из контроллера 330) предоставляются процессору 312 данных передачи (TX), который форматирует и кодирует данные и сообщения с помощью одной или более схем кодирования, чтобы генерировать кодированные данные. Каждая схема кодирования может включать в себя любое сочетание контроля с избыточным циклическим кодом (CRC), сверточного, быстрого и другого кодирования или никакого кодирования вообще. Голосовые данные, пакетные данные и сообщения могут быть закодированы с использованием разных схем, и разные типы сообщений могут быть закодированы по-разному.

Кодированные данные затем предоставлены модулятору (MOD) 314 и дополнительно обработаны (например, маскированы, сжаты по спектру короткими PN-последовательностями и скремблированы большой PN-последовательностью, назначенными пользовательскому терминалу). Модулированные данные затем предоставлены устройству передатчика (TMTR) 316 и приведены в желаемое состояние (например, конвертированы в один или более аналоговых сигналов, усилены, отфильтрованы и квадратурно модулированы), чтобы генерировать сигнал обратной линии связи. Сигнал обратной линии связи направляется через антенный переключатель 318 (D) и передается через антенну 320 в BCF/PCF 304.

На BCF/PCF 304 сигнал обратной линии связи принимается антенной 350, направляется через антенный переключатель 352 и предоставляется блоку приемника (RCVR) 354. BSC/PCF 304 может принимать информацию регистрации и информацию статуса, например информацию о локализации мобильной станции, от мобильной станции 306. Блок приемника 354 приводит в нужное состояние (например, фильтрует, усиливает, преобразует с понижением частоты и оцифровывает) принятый сигнал и предоставляет выборки. Демодулятор (DEMOD) 356 принимает и обрабатывает (например, устраняет сжатие, удаляет маскирование и демодулирует пилот-сигнал) выборки, чтобы предоставить восстановленные символы. Демодулятор 356 может реализовать многоотводный (рейк) приемник, который обрабатывает многочисленные варианты принимаемого сигнала и генерирует комбинированные символы. Устройство 358 обработки данных приема (RX) затем декодирует символы, чтобы восстановить данные и сообщения, переданные по обратной линии связи. Восстановленные голосовые/пакетные данные предоставлены приемнику данных 360, и восстановленные сообщения могут быть предоставлены контроллеру 370. Контроллер 370 может включать в себя команды для поискового вызова группы мобильных станций, которые могут быть основаны на подвижности мобильных станций. Обработка посредством демодулятора 356 и устройства 358 обработки RX-данных являются комплементарными по отношению к таким же, выполненным на базовой станции 306. Демодулятор 356 и устройство 358 обработки RX-данных могут дополнительно управляться, чтобы обрабатывать многочисленные сигналы передачи, принятые через многочисленные каналы, например обратный основной канал (R-FCH) и обратный дополнительный канал (R-SCH). Также сигналы передачи могут быть одновременно от многочисленных мобильных станций, каждая из которых может быть передающей по обратному основному каналу, обратному дополнительному каналу или по обоим.

В прямой линии связи на BSC/PCF 304 голосовые и/или пакетные данные (например, из источника 362 данных) и сообщения (например, от контроллера 370) обрабатываются (например, форматируются и кодируются) устройством 364 обработки данных приема (TX), дополнительно обрабатываются (например, маскируются и сжимаются по спектру) модулятором (MOD) 366 и приводятся в нужное состояние (например, конвертируются в аналоговые сигналы, усиливаются, фильтруются и квадратурно модулируются) блоком 368 (TMTR) приемника, чтобы сгенерировать сигнал прямой линии связи. Сигнал прямой линии связи направляется через антенный переключатель 352 и передается через антенну 350 в BSC/PCF 306. Сигналы прямой линии связи включают в себя сигналы поискового вызова.

На BSC/PCF 306 сигнал прямой линии связи принимается антенной 220, направляется через антенный переключатель 318 и предоставляется блоку 322 приемника. Блок 322 приемника приводит в нужное состояние (например, преобразует с понижением частоты, фильтрует, усиливает, квадратурно модулирует и оцифровывает) принятый сигнал и предоставляет выборки. Выборки обрабатываются (например, устраняется сжатие, удаляется маскирование и демодулируется пилот-сигнал) демодулятором 324, чтобы предоставить символы, а символы дополнительно обрабатываются (например, декодируются и проверяются) устройством 326 обработки данных приема, чтобы восстановить данные и сообщения, переданные по прямой линии связи. Восстановленные данные предоставляются приемнику 328 данных, а восстановленные сообщения могут быть предоставлены контроллеру 330. Контроллер 330 может включать в себя команды для BSC/PCF 306, которые могут быть основаны на подвижности мобильной станции.

Биты типа обслуживания (TOS) IP

Фиг.4 иллюстрирует заголовочную часть для IP-дейтаграммы 202, показанной на Фиг.2, согласно одному из вариантов осуществления, например, версии 4 IP (IPv4). Поле 402 типа обслуживания (TOS) IP является вторым байтом в пределах заголовочной части IP-дейтаграммы 202. Существует три широко распространенных соответствия TOS-битов определению обслуживания для IPv4. Первое соответствие определено в RFC (Запросах на комментарии проблемной группы проектирования Интернет) 791, «Internet protocol» («Протокол Интернет»), от сентября 1981 г. В этом RFC поле TOS имеет пять подполей, как показано на Фиг.5. Три бита «старшинства» задают старшинство IP-дейтаграммы значениями со значениями, расположенными в диапазоне от нуля (обычное старшинство) до семи (контроль сети), предоставляя возможность отправителям указывать важность каждой IP-дейтаграммы. Следующими тремя битами являются «D», «T» и «R». Эти биты могут быть использованы, чтобы задавать тип транспортировки IP-дейтаграммы. Последние два бита являются зарезервированными битами. В одном из вариантов осуществления сервер 110 группового вызова использует один или оба из зарезервированных битов в поле TOS IP-дейтаграммы, чтобы обозначать, что инфраструктура беспроводной связи, как показано на Фиг.3, например, должна отправлять IP-дейтаграмму целевой мобильной станции в виде SDM-сообщений.

Фиг.6 иллюстрирует еще одно соответствие битов TOS для определения обслуживания, как определено в RFC 1439, «Type of Service in the Internet Protocol Suite» («Тип обслуживания в наборе протоколов Интернет»), от июня 1999 г. Несмотря на то, что этот RFC обновляет определение в RFC 791, многие печатные материалы и реализации до сих пор ссылаются на оригинальное определение в RFC 791. В RFC 1439 подполе старшинства является тем же самым, что и то, которое определено в RFC 791. Следующие четыре бита рассматриваются в качестве битов типа обслуживания (TOS), а последний бит - в качестве бита, который должен быть нулевым (MBZ) битом. RFC 1439 переопределяет биты «D», «T», «R» в качестве 4-битного поля TOS. RFC 1439 предписывает, что создатель дейтаграммы устанавливает последний бит в нуль, за исключением участия в эксперименте протокола Интернет, который осуществляет использование последнего бита. Поэтому это оставляет только последний бит в качестве неиспользуемого бита. В одном из вариантов осуществления сервер 110 группового вызова использует зарезервированный бит в поле TOS, чтобы обозначать, что инфраструктура беспроводной связи, как показано на Фиг.3, например, должна отправлять IP-дейтаграмму целевой мобильной станции в виде SDM-сообщений.

Фиг.7 иллюстрирует третье определение обслуживания, определенное дифференциальной структурой обслуживания проблемной группы проектирования Интернета (IETF), как описано в RFC 2474, «Definition of Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers» («Определение поля дифференцированных услуг (поля DS) в заголовках IPv4 и IPv6»), от декабря 1998 г. Это определение использует 6 бит указания кода дифференциального обслуживания (DSCP), чтобы указать интерпретацию поведения на каждом участке передачи (PHB) для IP-дейтаграммы. Последние два бита являются зарезервированными битами. В одном из вариантов осуществления сервер 110 группового вызова использует один или оба из зарезервированных битов в поле TOS, чтобы обозначать, что инфраструктура беспроводной связи, которая показана на Фиг.3, например, должна отправлять IP-дейтаграмму целевой мобильной станции в виде SDM-сообщений.

Фиг.8 иллюстрирует заголовочную часть для IP-дейтаграммы 202 (Фиг.2) для версии 6 IP (IPv6) согласно RFC 2460, «Internet Protocol, Version 6 (IPv6) Specification» («Протокол Интернет, Спецификация версии 6 (IPv6)»), от декабря 1998 г. Класс 802 трафика является однобайтным полем, которое непосредственно продолжает 4-битное поле 804 версии, как показано на Фиг.8. RFC 2460 остается открытым в выражении того, какие 8 бит класса 802 трафика используются. Однако имеют место активные усилия IETF адаптировать определение обслуживания для IPv6 подобно определению обслуживания IPv4.

Возвращаясь к Фиг.6, задано, что первые 7 бит заголовочной части IPv4 могут быть использованы для соответствия определения обслуживания, последний бит может быть использован, чтобы указывать, что принимаемая информация на BSC/PCF 104 должна быть отправлена целевой MS 106 в виде SDB-сообщений. RFC 1812, «Requirements for IP Version 4 Routers» («Требования для маршрутизаторов версии 4 IP»), от июня 1995 г., накладывает требования на маршрутизаторы IPv4 не отбрасывать пакеты, если ненулевые значения использованы в зарезервированном бите(ах). Существующие RFC не предписывают, каким образом другие новые протоколы могут использовать зарезервированные биты, поэтому для BSC/PCF 104 является возможным принимать IP-дейтаграммы во время ожидающего сеанса пакета данных, которые содержат зарезервированный бит(ы), отмеченный иначе, чем нулем. В дополнение, нет требований RFC, указывающих, как маршрутизаторы IPv6 должны интерпретировать последний бит из 8-битного поля класса трафика в заголовке IPv6.

Далее в этом документе термин «поле TOS IP» использован, чтобы указывать и на поле 402 TOS IPv4, и на поле 802 класса трафика IPv6, в зависимости от схемы адресации, находящейся в рассмотрении. Согласно одному из вариантов осуществления серверы группового вызова осуществляют использование неиспользуемого бита(ов) поля TOS в качестве механизма для указания SDB-доставки. Например, для сообщения, которое необходимо отправить в виде SDB, серверы группового вызова могут устанавливать последний бит поля TOS IP в значение 0x01.

Протокол двухточечного соединения

Как отмечено выше, GRE-пакет 214 (Фиг.2) может содержать в себе многочисленные PPP-кадры или неполный PPP-кадр. BSC/PCF 104 извлекает GRE-заголовок 210 и IP-заголовок 212 из принятого GRE-пакета 214, повторно упаковывает информацию в виде кадров протокола линии радиосвязи (RLP) и передает RLP-кадры по эфирному интерфейсу целевой мобильной станции 106. Для того чтобы BSC/PCF 104 анализировать поле TOS IP, BSC/PCF 104 обнаруживает начало и окончание PPP-кадра 208. В этом разделе мы изучаем структуру PPP-кадра и идентифицируем поля, которые могут быть введены в обращение во время фазы контроля связи, как предписано в TIA/EIA/IS-835, «PPP in HDLC-like Framing» («Стандарт беспроводной IP-сети»), от 6 декабря 2001 г. Большее количество подробностей о PPP можно найти в RFC 1661, «The Point-to-Point Protocol (PPP)» («Протокол двухточечного соединения (PPP»), от июля 1994 г.

Фиг.9 иллюстрирует высокоуровневую структуру кадра управления каналом передачи данных (HDLC) для PPP-кадра 208, согласно RFC 1662, «PPP in HDLC-like Framing» («PPP в HDLC-подобной структуре»), от июня 1994 г. Поля с 902 по 908 относятся к PPP-заголовку 204 PPP-кадра 208, а поле 912 указывает ссылкой на IP-дейтаграмму 202 PPP-кадра 208, а поле 912 указывает ссылкой на PPP-хвост 206 PPP-кадра 208. Первое поле 902 является ограничителем «7E», чтобы обозначать начало и/или окончание PPP-кадра 208. Ограничитель продолжается HDLC-кадрами 904, 906, 908.

Согласно RFC 1662, адресное поле 904 может быть установлено в октет 0xFF, а поле управления 906 может быть установлено в октет 0x03. Информационное поле HDLC содержит в себе поле 908 протокола и IP-дейтаграмму (полезные данные PPP) 910. Для IP-обслуживания поле 908 протокола включает в себя два октета со значением 0x0021, продолженные IP-дейтаграммой 910. Последнее поле HDLC-пакета является проверочной последовательностью кадра (FCS) 912, которая может включать в себя два или четыре октета. Каждый PPP-кадр начинается последовательностью разделителя кадра, и одна последовательность разделителя кадра может быть использована между двумя кадрами. Две следующих друг за другом последовательности разделителя кадра составляют пустой кадр. Концевая последовательность разделителя кадра на Фиг.9 не показана.

Согласно одному из вариантов осуществления протокол управления соединением (каналом связи) (LCP) вводит в обращение модификации к стандартной HDLC-подобной структуре кадра, которая была описана выше. Одноранговые PPP-устройства могут договориться сократить поле 904 адреса и поле 906 управления. Если сокращение разрешено, то два октета исключаются. В дополнение, одноранговые PPP-устройства могут договориться сократить поле 908 протокола до одного байта, например 0x21. Еще одним договорным параметром является количество бит для контроля избыточным циклическим кодом (CRC) в поле 912 FCS. Одноранговые PPP-устройства могут договориться на 16-битный CRC или 32-битный CRC.

PPP может выполнять подстановку битов перед тем, как передается информация, чтобы достигнуть прозрачности для символов управления. Управляющий октет пропуска может быть выбран, чтобы быть 0x7D. Как минимум, RFC 1662 требует реализации, чтобы пропустить последовательность разделителя, например, 0x7E, и управляющие октеты пропуска, 0x7D. После вычисления FCS передатчик проверяет полный кадр между двумя последовательностями ограничителя и выполняет пропуск последовательности разделителя. Значения между 0x00 и 0x1F (включительно) плюс значения 0x7D и 0x7E могут быть пропущены передатчиком при отправке PPP-кадра.

Таблица символов асинхронного управления (ACCM) является необязательным элементом LPC, содержащим четырехоктетную битовую таблицу, которая разрешает (бит установлен) или запрещает (бит сброшен) пропуски символа для управляющих символов ASCII-32 (32-разрядного Американского стандартного кода обмена информацией) в диапазоне от 0x00 до 0x1F. К примеру, первый октет значения ACCM содержит биты для управляющих символов от 0x19 до 0x1F, с MSB (самым старшим битом), указывающим 0x1F, и LSB (самым младшим битом), указывающим 0x18. Второй октет содержит биты для символов от 0x10 до 0x17 и так далее. Значение 0xFFFFFFFF указывает, что все управляющие символы пропущены, согласно «PPP Design, Implementation, and Debugging», Carlson, James, Addison-Wesley, 2002 («Замысел, реализация, и наладка PPP», Карлсон Джеймс, Эдисон-Уэсли, 2002 г.). Значение ACCM 0x00000000 указывает, что ни один ASCII-символ со значениями между 0x00 и 0x1F не был пропущен. Каждая последовательность ограничителя, управляющий октет обхода, и любой октет, который отмечен в ACCM отправки, замещается управляющим октетом обхода, например, 0x7D, продолженным исходным октетом, подвергнутым операции ИСКЛЮЧАЮЩЕГО ИЛИ (операции XOR) с октетом 0x20.

Для операций и простого IP, и мобильного IP, TIA/EIA/IS-835, "Wireless IP Network Standard" («Стандарт беспроводной IP-сети»), от 6 декабря 2001 г., предписывает обход управления и для мобильного устройства и для PSDN. Для PSDN стандарт требует от PDSN вводить в обращение соответствие управляющих символов с минимальным количеством пропущенных символов посредством представления значения 0x00000000 ACCM. С другой стороны, стандарт рекомендует, что если MS вводит в обращение соответствие управляющих символов, то она должна стремиться к минимальному количеству обходов посредством ввода в обращение ACCM 0x00000000. Поэтому возможно, чтобы BSC/PCF 104 принимала PPP-кадры от PDSN 102, где не только последовательность ограничителя, но также и символы из 0x00 и 0x1F пропущены.

Когда BSC/PCF 104 не является одноранговым PPP-устройством PDSN, BSC/PCF 104 может не быть осведомленным в отношении того, какие LCP-параметры, например поле 906 управления, поле 904 адреса и поле 908 протокола, введены в обращение между MS 106 и PDSN 102. Поэтому, за исключением определения PPP-структуры, BSC/PCF 104 определяет, какие поля сокращены, и являются ли какие-либо символы обойденными, чтобы идентифицировать начало заголовочной части IP-дейтаграммы 202, для того чтобы разобрать биты TOS IP. В следующем разделе описан алгоритм, который BSC/PCF 104 использует, чтобы анализировать PPP-кадр.

Алгоритм анализа PPP-кадра

Как отмечено выше, GRE-пакет 214, поступающий на BSC/PCF 104, может содержать в себе многочисленные PPP-кадры, или неполные кадры, которые требуют от BSC/PCF 104 анализировать поток пакетных данных во время состояния ожидания, чтобы определять последовательность ограничителя PPP-кадра. Алгоритм, который BSC/PCF 104 использует, чтобы анализировать поток информации, чтобы определять начало заголовочной части IP-дейтаграммы 202, показан на Фиг.10.

Если алгоритм обнаруживает нераспознаваемую последовательность символов, то алгоритм переходит к началу следующего PPP-кадра, поскольку он не может узнать, где PPP-кадр 204 начинается. Это событие может происходить как результат непригодной PPP-реализации, или когда существуют одна или более ошибок в потоке данных. Алгоритм последовательно проверяет наличие последовательности ограничителя «0x7E» до тех пор, пока не найдет непустой PPP-кадр. Более точно, после нахождения первого ограничителя 0x7E на этапе 1002 следующий байт проверяется на ограничитель 0x7E на этапе 1004. Если последующий байт содержит в себе еще один ограничитель 0x7E, означающий, что PPP-кадр после анализа является пустым, последовательность операций продолжается проверкой последующего байта на этапе 1006. Однако если байт, следующий за байтом, содержащим первый ограничитель 0x7E, не содержит в себе ограничитель 0x7E, означающий, что обнаружен непустой PPP-кадр, то последовательность операций осуществляет проверку до поля 904 адреса на этапе 1008.

В одном из вариантов осуществления поле 904 адреса и поле 906 управления могут быть сокращенными и впредь отсутствующими. В дополнение поле 908 протокола также может быть сокращено, так что может быть представлен только его второй байт, имеющий значение 0xFF. В таких случаях, согласно RFC 1662, второй байт двухоктетного поля 908 протокола не должен быть установлен в 0xFF, чтобы избежать того, чтобы он был ошибочно воспринят в качестве поля 904 адреса, имеющего значение 0xFF.

Продолжая проверку на этапе 1008 и отыскивая 0xFF, соответствующее полю 904 адреса, BSC/PCF 104 проверяет на этапе 1010, содержит ли в себе следующий байт 0x03, соответствующее полю 906 управления. Если на этапе 1010 определено, что следующий байт не содержит 0x03, то BSC/PCF 104 проверяет, явилось ли результатом договоренности при введении в обращение ACCM для поля управления значение 0x03. После введения в обращение ACCM BSC/PCF 104 сначала отправляет байт обхода управления, например, 0x7D и затем байт, содержащий в себе результат исключающего «или» (XOR) байта исходной информации, которая должна быть отправлена, например 0x03 с 0x20.

На этапе 1012 BSC/PCF 104 осуществляет проверку на существование байта 0x7D первым, и если установлено, то проверяет на существование 0x23, которое является результатом 0x03, подвергнутого операции XOR с 0x20 на этапе 1014. Если 0x7D и 0x23 не найдены, означая, что никакое поле 906 управления не обнаружено, то последовательность операций осуществляет проверку на начало нового PPP-кадра на этапе 1016 и 1018, подобно этапу 1002 и 1004, описанным выше. Должно быть отмечено, что если результатом на этапе 1008 является «нет», то поле 904 адреса сокращено и, таким образом, не представлено.

Если на этапе 1010 или на этапе 1014 результатом является «да», означающее, что обнаружено значение 0x03, соответствующее полю 906 управления, непосредственно или через введение в обращение ACCM, то последовательность операций осуществляет проверку по следующим байтам на наличие 0x00, соответствующего первому байту поля 908 протокола. BSC/PCF 104 может сначала проверить, должен ли был результат ввода в обращение отправить поле 908 протокола через ACCM. На этапе 1020, если байт 0x7D не найден, означая, что поле 908 протокола не собираются отправлять через ввод в обращение ACCM, то BSC/PCF 104 затем проверяет, на этапе 1022, содержит ли в себе последующий байт 0x00, соответствующий первому байту поля 908 протокола.

После того как BSC/PCF 104находит 0x00, соответствующий первому байту поля 908 протокола, на этапе 1022 BSC/PCF 104 проверяет, должен ли результат ввода в обращение был отправить второй байт поля 908 протокола через ввод в обращение ACCM. На этапах 1024, если байт 0x7D не найден, означая, что поле 908 протокола не собираются отправлять посредством ввода в обращение ACCM, то BSC/PCF 104 затем проверяет на этапе 1026, содержит ли в себе следующий байт 0x21, соответствующее второму байту поля 908 протокола. Если 0x21 найдено на этапе 1026, сопровождающее 0x00, найденное на этапе 1022, последовательность операций заканчивается на этапе 1028 для анализа заголовочной части IP-дейтаграммы 910, как будет описано далее в настоящем патентном документе.

На этапах 1024, если найден байт 0x7D, означающий, что поле 908 протокола собираются отправлять через ввод в обращение ACCM, то BSC/PCF затем проверяет на этапе 1030, содержит ли в себе следующий байт 0x01, который является вторым байтом поля 908 протокола, например 0x21, подвергнутое операции XOR с 0x20, согласно вводу в обращение ACCM. Если байт 0x01 найден на этапе 1030 сопровождающим 0x00, найденный на этапе 1022, то последовательность операций заканчивается на этапе 1028 для анализа заголовочной части IP-дейтаграммы 910.

Возвращаясь снова к этапу 1020, отыскивающему первый байт поля 908 протокола, например, 0x00, если BCF/PCF 104 находит 0x7D, то последующий байт проверяется на 0x20, которое является первым байтом поля 908 протокола, например 0x00, подвергнутый операции XOR с 0x20 на этапе 1032. Если результатом на этапе 1032 является «да», означающее, что 0x00 найден в первом байте поля 908 протокола, то последовательность операций продолжается на этапе 1024, отыскивая наличие второго байта поля 908 протокола, например, 0x21, как подробно обсуждено выше.

На этапе 1032, если байт, сопровождающий байт, содержащий 0x7D, не содержит в себе значение, соответствующее первому байту поля 908 протокола, например, 0x00, то BSC/PCF 102 определяет на этапе 1034, содержит ли байт в себе 0x00, который является вторым байтом поля 908 протокола, например 0x21, подвергнутое операции XOR с 0x20. Если результатом является «да», то последовательность операций завершается на этапе 1028. Если результат проверки поля 908 протокола завершается, при не нахождении второго байта поля 908 протокола, например, 0x21 последовательность операций заканчивается на этапе 1016, отыскивая следующий PPP-кадр.

Должно быть отмечено, что если результатом на этапе 1022 является «нет», означающее, что первый байт поля 908 протокола не найден, то это поле сокращается. Таким образом, только присутствие его второго байта, например, 0x21 проверяется на этапе 1036.

Алгоритм анализа IP-дейтаграммы

Как только алгоритм анализа PPP-кадра достиг состояния 1028 «Анализировать IP-дейтаграмму», указывающего, что алгоритм успешно обнаружил начало IP-дейтаграммы 910, то BSC/PCF 104 затем использует алгоритм согласно одному из вариантов осуществления, который показан на Фиг.11, чтобы анализировать заголовочную часть 400 (Фиг.4) или 800 (Фиг.8) IP-дейтаграммы 910, чтобы обнаружить, представлена ли SDB-метка. В одном из вариантов осуществления алгоритм анализа предполагает, что четыре байта 32-х битной заголовочной части 400 и 800 переданы в следующем порядке: биты 0-7 сначала, биты 8-15, биты 16-23 и биты 24-31 в конце. Это упорядочивание названо байтовым упорядочиванием по старшинству, которое является байтовым упорядочиванием, используемым во всех двоичных целых в TCP/IP-заголовках, пока они пересекают сеть. Это упорядочивание также называют сетевым байтовым порядком. Если BSC/PCF 104 хранит двоичные целые в других форматах, таких как байтовое упорядочивание по меньшинству, то BSC/PCF 104преобразует значения заголовка в сетевой байтовый порядок перед запуском алгоритма или производит соответствующее отображение, с тем чтобы алгоритм исполнялся должным образом.

Поле 402 TOS IPv4 (Фиг.4) и класс 802 трафика IPv6 (Фиг.8) начинаются с 4-битного поля версии. 4-битное поле версии содержит в себе номер версии IP. Для версий IPv4 и IPv6 номером версии являются 0x04 и 0x06 соответственно. Для определения номера версии алгоритм, показанный на Фиг.11, проверяет, передан ли первый байт заголовочной части IP-дейтаграммы 910 согласно вводу в обращение ACCM или вообще непосредственно. Если найдено, что первый байт заголовочной части содержит 0x7D, на этапе 1102, означающее, что первый байт заголовочной части введен в обращение согласно ACCM, то алгоритм затем производит операцию XOR последующего байта с 0x20 на этапе 1104, чтобы скомпенсировать функцию XOR с 0x20, следовательно, восстанавливая первоначальное значение.

На этапе 1106 первоначальное содержимое первого байта IP-заголовка, принятого из этапа 1102, или результат, принятый из этапа 1104 с целью вычленения, подвергаются операции AND с 0xF0, чтобы прочитать первые четыре бита заголовочной части. На этапе 1108 результат этапа 1106 проверяется на 0x60, чтобы определить, указывают ли первые четыре бита заголовочной части, что номером версии является IPv6.

Если результат этапа 1108 указывает, что версией является IPv6, то последовательность операций продолжается на этапах 1110, 1112, 1114 и 1116, чтобы определить, установлен ли пятый бит класса 802 трафика (Фиг.8), указывая SDB-метку. Если результат этапа 1116 указывает, что бит SDB установлен, то последовательность операций завершается на этапе 1118.

Продолжаясь с этапа 1120, если результат указывает, что номером версии заголовочной части является IPv4, последовательность операций продолжается на этапах 1122, 1124, 1126 и 1128, чтобы определить, установлен ли восьмой бит поля 402 TOS (Фиг.4), указывая SDB-метку. Если результат этапа 1128 указывает, что бит SDB установлен, то последовательность операций заканчивается на этапе 1118.

Как только SDB-метка найдена, BSC/PCF 104 обнаруживает следующую последовательность ограничителя, чтобы найти конец PPP-кадра, находящегося в проверке. Более чем две IP-дейтаграммы, где первая IP-дейтаграмма содержит SDB-метку, могут быть инкапсулированы в пределах одиночного PPP-кадра, поступившего на BSC/PCF 104. В дополнение, IP-дейтаграмма с SDB-меткой может превышать о