УПРАВЛЕНИЕ ТРАФИКОМ В СИСТЕМЕ СВЯЗИ, ИМЕЮЩЕЙ РАЗНОРОДНЫЕ КАНАЛЫ CDMA
TRAFFIC CONTROL IN COMMUNICATION SYSTEM WITH HETEROGENEOUS CDMA LINKS

Испрашивание приоритета согласно §119 35 U.S.C.
По настоящей Заявке на патент испрашивается приоритет Предварительной заявки № 60/506290, озаглавленной "Managing Traffic in Communications System Having Dissimilar CDMA Channels", поданной 25 сентября 2003 года и переуступленной правообладателю этой заявки, и таким образом явно включена в данный документ посредством ссылки.
Область техники, к которой относится изобретение
Настоящее изобретение относится к управлению трафиком в системах передачи данных, в которых представлены разнородные каналы CDMA (множественного доступа с кодовым разделением каналов). Более конкретно, изобретение относится к управлению трафиком в системах связи, в которых представлен асинхронный канал CDMA "произвольного доступа" (без резервирования) с меньшей пропускной способностью наряду с ортогональным "ориентированным на резервирование" каналом CDMA с большей пропускной способностью.
Описание предшествующего уровня техники
В системах на основе множественного доступа с временным разделением каналов (TDMA) доступная полоса пропускания делится на элементарные временные интервалы (слоты). Слоты дополнительно подразделяются на две общие категории: временные интервалы с произвольным доступом (RATS) и временные интервалы с резервированием (RETS).
RATS назначаются как конкурентные слоты, когда различное находящееся у заказчика оборудование (CPE) состязается за ресурсы. Основанные на ALOHA протоколы разрешения конкуренции типично используются в отношении RATS для того, чтобы разрешать коллизии между находящимся у заказчика оборудованием (CPE). CPE отправляют небольшой пакет по RATS для того, чтобы запросить полосу пропускания по RETS. В зависимости от системы небольшие пакеты могут передаваться по RATS, но большая часть трафика отправляется по RETS посредством изначального запроса полосы пропускания.
Системы TDMA имеют два основных недостатка: большая задержка доступа и меньшая эффективность использования полосы пропускания. Поскольку запрос должен быть отправлен по RATS до получения резервирования, вводится длительная задержка. Слоты RATS должны обрабатываться при очень низкой нагрузке по трафику во избежание чрезмерных коллизий и задержки. Это приводит к меньшей эффективности использования полосы пропускания системами TDMA.
Следовательно, в данной области техники существует потребность в методике, которая обеспечивает более короткую задержку доступа и более высокую эффективность использования полосы пропускания. С этой целью применяется множественный доступ с кодовым разделением каналов (CDMA). В целом, было установлено (Bhargava et al, "Digital Communications by Satellite", John Wiley & Sons, New York, 1981, см., в частности, главу 9), что CDMA дает возможность пользователям работать на одной и той же номинальной частоте, при этом требуя минимальной частотной или временной координации между пользователями.
Появились различные подходы к реализации CDMA. Т.е. в CDMA каналы, которые являются разнородными в некоторых отношениях, такие как асинхронный множественный доступ с кодовым разделением каналов (ACDMA, см. стандарт TTA/EIA/IS95) и ортогональный множественный доступ с кодовым разделением каналов (OCDMA), обеспечивали гибкость при проектировании систем связи. Тем не менее, с возможностью объединять несколько разнородных типов каналов в одну систему связи приходит требование эффективно управлять трафиком в разнородных каналах. Например, существует потребность оптимизировать использование разнородных каналов для того, чтобы максимизировать общую пропускную способность системы одновременно с надлежащим распределением полосы пропускания между конкурирующими терминалами. Тем не менее, сложность подходов на разнородных CDMA затруднила оптимальное управление трафиком.
Следовательно, в данной области техники существует потребность обеспечить структуру эффективного управления трафиком в сетях связи с различными каналами, особенно разнородными каналами CDMA.
Сущность изобретения
В системе связи на базе множественного доступа с кодовым разделением каналов (CDMA), включающей в себя один или более терминалов (таких как находящееся у заказчика оборудование, CPE), которые обмениваются данными с узлом (таким как Интернет-шлюз) посредством, например, по меньшей мере, канала произвольного доступа (RACH) и ориентированного на резервирование канала (RESCH), предусмотрены различные схемы управления трафиком связи между каналами. Решения в отношении канала, по которому данный терминал может выполнять передачу, может быть основано на множестве критериев. Решением может быть выбор из двух альтернатив, как то, передает ли терминал по RACH или по RESCH; альтернативно, более разнообразные решения могут включать в себя обновление до более скоростных каналов RESCH или понижение до более медленных каналов RESCH. Решения при управлении трафиком, например, при оперативных сеансах Web-просмотра (браузинга) пользователями могут включать в себя интеллектуальное определение того, занят ли терминал. Схемы управления трафиком предоставляют управление доступом к среде (MAC), т.е. особенно полезны, например, в ответной линии спутниковой сети связи, которая включает в себя разнородные каналы CDMA (ортогональный множественный доступ с кодовым разделением каналов (OCDMA) в RESCH и асинхронный множественный доступ с кодовым разделением каналов (ACDMA) в RACH).
Перечень фигур чертежей
Более полное понимание описанных вариантов осуществления достигается посредством ссылок на последующее подробное описание, рассматриваемое вместе с прилагаемыми чертежами, на которых аналогичные ссылочные номера указывают на идентичные или соответствующие элементы по всему описанию и на которых:
Фиг.1 - схематичное представление возможного контекста способа управления трафиком, в котором ответная линия (RL) сети связи, включающей в себя сеть спутниковой связи, имеет трафик, которым следует управлять.
Фиг.2 - блок-схема последовательности операций первого варианта осуществления способа управления трафиком, в котором терминал выполняет передачу исключительно по каналу произвольного доступа.
Фиг.3 - блок-схема последовательности операций второго варианта осуществления способа управления трафиком, в котором терминал может передавать данные по ориентированному на резервирование каналу после отправки запроса на резервирование полосы пропускания и предоставления разрешения по этому запросу, при этом разрешение по запросу на резервирование полосы пропускания предоставляется, если статистика трафика (например, размер пакетов или средняя скорость передачи данных за интервал времени) превышает порог, или если содержимое трафика (например, типы пакетов) удовлетворяет определенному критерию.
Фиг.4 - блок-схема последовательности операций третьего варианта осуществления способа управления трафиком, в котором статистика по трафику связи терминала или его содержимое отслеживается, и терминалу предоставляется возможность передавать данные по "всегда активному" подканалу ориентированного на резервирование канала, когда отслеживаемый трафик показывает, что терминал "занят" (активно используется пользователем).
Фиг.5A и 5B - блок-схемы последовательности операций четвертого варианта осуществления способа управления трафиком, в котором отслеживается "Q-состояние" терминала (величина, на которую загружен выходной буфер терминал) для того, чтобы определить, должен ли его трафик переноситься каналом произвольного доступа или ориентированным на резервирование каналом, и если трафик должен переноситься ориентированным на резервирование каналом (фиг. 5B), то более длинный (или более короткий, или той же длины) код Уолша назначается каналу, с тем чтобы терминал далее передавал данные по более медленному (или более быстрому, или такой же скорости) каналу.
Фиг.6 - блок-схема последовательности операций пятого варианта осуществления способа управления трафиком, в котором отслеживается предыстория "Q-состояния" терминала (величины, на которую загружен выходной буфер терминал) для того, чтобы определить, следует ли предоставить или аннулировать разрешение терминалу передавать данные по "всегда активному" подканалу, ориентированному на резервирование канала.
Подробное описание изобретения
При описании вариантов осуществления, проиллюстрированных на чертежах, для понимания используется специальная терминология. Тем не менее, изобретение не предназначено быть ограниченным выбранной специальной терминологией, и следует понимать, что каждый конкретный элемент включает в себя все технические эквиваленты, которые работают аналогичным способом для того, чтобы достичь аналогичной цели.
Более того, признаки и процедуры, реализации которых хорошо известны специалистам в данной области техники, пропущены для краткости. Например, инициирование и завершение программных циклов, передача параметров из одной части сети в другую, необходимых для того, чтобы выполнять свои функции, и т.п. находятся в пределах компетенции специалистов в данной области техники, а следовательно, какое-либо их подробное представление может быть опущено.
Дополнительно, различные аспекты, признаки и варианты осуществления системы обмена данными могут быть описаны как процесс, который может быть проиллюстрирован блок-схемой последовательности операций, блок-схемой, структурной схемой или скелетной схемой. Хотя блок-схема последовательности операций может описывать операции как последовательный процесс, многие операции могут выполняться параллельно или одновременно, либо в порядке, отличном от описанного. Операции, не необходимые или не требуемые для конкретной реализации, могут быть опущены. Процесс может соответствовать способу, функции, процедуре, программному обеспечению, вспомогательной процедуре, подпрограмме или любому сочетанию вышеперечисленного.
Варианты осуществления структур управления трафиком могут ссылаться на находящееся у заказчика оборудование (CPE) и на шлюзы между сетями наземной и спутниковой связи. Тем не менее, следует понимать, что структуры управления трафиком применяются, в общем, в широком смысле к терминалам, рабочим станциям, персональным вычислительным машинам и т.п.; кроме того, структуры управления трафиком применяются, в общем, в широком смысле к маршрутизаторам, коммутаторам, прокси-серверам (серверам-посредникам), узлам и т.п. Более того, такие функции, как функции управления, которые описаны как реализуемые или исполняемые в конкретном месте сети, также могут выполняться в других подходящих местах сети.
Варианты осуществления систем связи могут ссылаться на каналы произвольного доступа (такие как заданные в TIA/EIA/IS95) или ориентированные на резервирование каналы (такие как раскрытые в Патентной заявке US 10/428953, поданной 1 мая 2003 и озаглавленной "Orthogonal Code Division Multiple Access On Return Link Of Satellite Links"). Эти каналы являются просто примерными типами каналов; системы управления трафиком могут быть применены к другим типам каналов.
Различным терминам, которые используются в этом описании, должна быть дана самая широкая разумная их интерпретация при использовании в интерпретировании формулы изобретения.
Вкратце, может быть предусмотрено, по меньшей мере, три типа каналов. Каналы подходят для использования в ответной линии (RL) вариантов осуществления сети связи, раскрытой в данном описании, сетях, которые могут включать в себя сеть спутниковой связи. Эти три типа каналов включают в себя:
- Канал произвольного доступа (RACH) использует способ управления без резервирования, разрешающий произвольный доступ к передающей среде, и применяет методики ACDMA (асинхронного множественного доступа с кодовым разделением сигналов). RACH, таким образом, предоставляет доступ в "произвольные" (незапланированные) моменты времени, но за счет общей скорости передачи данных.
- Канал с резервированием (RESCH) использует ориентированный на резервирование способ управления, разрешающий доступ к среде на основе ограниченного числа кодов (кодов Уолша), которые назначаются, например, шлюзом соответствующим терминалам, с тем чтобы шлюз мог надежно отличать терминалы. Коды являются взаимно ортогональными, обеспечивая, что передачи данных от различных терминалов не мешают друг другу. RESCH, таким образом, использует OCDMA (ортогональный множественный доступ с кодовым разделением сигналов) и является более эффективным, чем RACH, в отношении общей скорости передачи данных, но за счет гибкости, предоставляемой возможностью произвольного (незапланированного) доступа в RACH. В некоторых вариантах осуществления RESCH может включать в себя подканал, называемый "всегда активным" каналом.
- Канал контроля работоспособности (HCH) относится к каналу обратной связи между CPE и шлюзом и, таким образом, является второстепенным в отношении управления трафиком между RACH и RESCH.
Управление трафиком по RACH и RESCH может осуществляться согласно описанным в данном документе принципам. Сначала описаны базовые характеристики одной неограничительной реализации каналов.
RACH.
Канал RACH основан на асинхронном множественном доступе с кодовым разделением аналов (ACDMA), и абонентские терминалы могут передавать данные по RACH в любое время, когда у них есть данные для передачи, без необходимости заранее резервировать полосу пропускания. В соответствии с принципами CDMA терминалы кодируют свои данные с расширением спектра с помощью длинных псевдослучайных (PN, псевдошумовых) кодов. Ряд PN-кодов доступен для использования терминалами, при этом каждый PN-код задает соответствующий канал произвольного доступа. Различные PN-коды, соответствующие различным каналам RACH, могут передаваться на одной несущей частоте. Канал RACH, описанный в данном документе и используемый в одном варианте осуществления, имеет структуру, описанную в стандарте TIA/EIA/IS95.
Терминал может произвольно выбирать из пула PN-кодов и использовать выбранный PN-код для кодирования своих данных с расширением спектра. Альтернативно, узел, такой как шлюз, может назначать терминалу код для использования. В любом случае каждая передача данных по RACH начинается с преамбулы для того, чтобы дать возможность шлюзу или другому узлу выполнить синхронизацию и распознать начало передачи от терминала.
RACH может быть использован, в первую очередь, для начальной регистрации при включении питания, для отправки пакетов в начале потока данных, когда терминал (находящееся у заказчика оборудование, CPE) неактивен в течение определенного периода времени и ему не назначена полоса пропускания по RESCH, и для отправки небольших пачек коротких пакетов, как описано ниже. Полоса пропускания в RESCH может быть зарезервирована для терминалов на основе требований терминалов по полосе пропускания и доступной полосы пропускания RESCH. HCH используется терминалами для обеспечения обратной связи по отношению уровня сигнала к совокупному уровню шумов и помех (SINR) шлюзу и в качестве опорного сигнала для измерений интенсивности сигналов RL шлюзом.
-4
Методика множественного доступа, используемая в RACH, - это асинхронный CDMA. Терминалы (находящееся у заказчика оборудование, CPE) кодируют свои данные с расширением спектра помощью одного из ряда псевдослучайных (PN) кодов. Управление мощностью каждого терминала осуществляется по RACH, так чтобы его принимаемое SINR было выше определенного порога, например, для того, чтобы достичь низкой (к примеру, <10) частоты ошибок по пакетам (PER). Пропускная способность RACH, количество PN-кодов, требуемых для того, чтобы поддерживать PER вследствие коллизий по коду ниже допустимого уровня, управление мощностью и управление перегрузкой в RACH может быть реализовано специалистами в данной области техники и, по существу, не представляет важности для управления трафиком и поэтому не представлено более подробно в данном документе. Процедуры, используемые для того, чтобы определять то, какие пакеты передаются по RACH и какие пакеты передаются по RESCH, являются темой дальнейшего описания.
RESCH.
Физическая структура канала, используемого для того, чтобы поддерживать RESCH, - это ортогональный CDMA (OCDMA). Можно подумать о подходе TDMA с помощью кодов Уолша длиной 1. Полоса пропускания канала OCDMA делится согласно множественным ортогональным кодам Уолша различной длины. В зависимости от требования терминала по скорости передачи данных в ответной линии, в OCDMA терминалу назначается ортогональный код Уолша конкретной длины. Полоса пропускания (заданная назначенным кодом Уолша) выделяется терминалу в течение конкретного интервала времени. Конкретные подобности каналов физического уровня и механизмов, которые могут использоваться для того, чтобы достичь ортогональности между сигналами терминалов, принимаемыми в шлюзе, могут быть реализованы специалистами в данной области техники и, таким образом, по сути не важны для управления трафиком.
HCH.
-4
Канал контроля работоспособности (HCH) - это канал ответной линии (RL), который используется терминалами для того, чтобы отправлять информацию обратной связи шлюзу относительно SINR, достигнутого в терминале. В одном варианте осуществления терминал передает индекс максимальной скорости передачи данных, которую терминал может декодировать с низкой (к примеру, <10) частотой ошибок по TCP-пакетам (PER). Шлюз также использует сигнал, принимаемый от терминала по HCH, для того, чтобы оценивать интенсивность принимаемых сигналов (RSS) от терминала. RL RSS используется для того, чтобы осуществлять управление мощностью каналов с фиксированной скоростью по RACH, а также определять максимальную скорость передачи данных, достижимую в управляемых по скорости каналах на RESCH для заданного уровня мощности передачи. Каждому терминалу назначается полоса пропускания по HCH.
Далее приведено описание процедур управления доступом к передающей среде (MAC), которые могут быть использованы для того, чтобы управлять и направлять передаваемые сигналы и пользовательские данные по RACH и RESCH. Предусмотрено разнообразие таких процедур MAC.
Как правило, когда терминал имеет данные для передачи, но не имеет какого-либо выделения полосы пропускания по RESCH, терминал начинает поток данных посредством простой передачи своих пакетов по RACH. После приема пакетов терминала по RACH шлюз определяет, что терминал инициировал поток данных, после чего шлюз должен принять решение о том, следует ли или нет выделять полосу пропускания терминалу по RESCH.
Большая часть последующего описания посвящена схемам управления полосой пропускания (и косвенно, схемам управления доступа к среде (MAC)) для трафика HTTP (протокол передачи гипертекста). В трафике HTTP приложение Web-просмотра терминала, подключенного к ответной линии, переносит сообщения GET и подтверждения приема. Предусмотрен ряд подходов к переносу трафика линии ответной связи, генерируемого потоком HTTP.
На фиг.1 в качестве неограничивающего примера проиллюстрирован контекст способа управления трафиком, в котором ответная линия (RL) сети связи, включающей в себя сеть спутниковой связи, имеет трафик, которым следует управлять. На фиг.1 различные терминалы (находящееся у заказчика оборудование, CPE) 110, 120, ... связаны посредством соответствующих спутниковых антенн 111, 121, ... со спутником 100 и, таким образом, с узлом (таким как Интернет-шлюз) 150 посредством своей спутниковой антенны 151.
Прямая линия связи (FL) 130 означает направление связи от узла к любому из терминалов. Наоборот, обратная линия связи (RL, иногда называется ответной линией связи) 140 означает направление связи от любого из терминалов к узлу. RL может быть реализована с помощью сочетания вышеописанных методик OCDMA и ACDMA.
CPE (терминалы) могут отличаться по структуре и работе, как и шлюз (узлы). Как правило, терминалы и узлы имеют оборудование связи, работающее согласно взаимно совместимым протоколам связи, таким как TCP/IP и HTTP, дающее возможность терминального доступа к Интернету посредством узла. Узел и терминалы включают в себя соответствующие процессоры, сконфигурированные для того, чтобы выполнять описанные в данном документе аналитические функции. Узел при реализации Интернет-шлюза также включает в себя прокси-сервер для того, чтобы дать возможность узлам доступа в Интернет.
Специалисты в данной области техники должны понимать, что полоса пропускания спутника и узла должна быть распределена между терминалами. Управление трафиком особенно сложное, например, когда управляемый трафик - это трафик TCP/IP-HTTP оперативных сеансов Web-просмотра пользователями. Такой трафик должен проходить трассы к и от спутников, трассы, которые вводят значительные задержки по времени. Подходы к управлению трафиком, изложенные в этом описании, особенно пригодны для использования в ответной линии связи (RL) таких систем, как показанная на фиг.1, из-за требования мультиплексирования "много-к-одному" в RL; тем не менее, RL на фиг.1 - это только один вариант применения подходов.
Как правило, раскрытые подходы включают в себя стратегическое управление тем, каким из множества терминалов 110, 120, ... предоставляется больше доступной полосы пропускания, в данном примере к спутнику 100 и узлу 150, при этом с целью доступной полосы пропускания. Примеры таких подходов включают в себя линию связи, имеющую управление доступом к среде (MAC), управляющее доступом к вышеописанным каналам RACH и RESCH.
Первый вариант осуществления (фиг.2).
В первом варианте осуществления весь трафик передается по RACH. Преимущество передачи по RACH заключается в том, что пакеты могут быть отправлены сразу после того, как они сгенерированы, и нет дополнительной задержки запроса на резервирование.
Согласно фиг.2 блок-схема последовательности операций иллюстрирует этапы примерной реализации первого варианта осуществления. Этап 200 представляет начало процесса, за которым следует этап 210, который указывает передачу данных по каналу произвольного доступа. Этап 220 представляет окончание процесса, когда передача данных завершена.
Недостатки передачи только по RACH включают в себя низкую эффективность использования полосы пропускания и низкую скорость передачи данных.
Второй вариант осуществления (фиг.3).
Второй подход к управлению трафиком обратной линии описан со ссылкой на трафик HTTP. Разумеется, следует принимать во внимание, что варианты осуществления не обязательно должны быть ограничены вариантами осуществления с трафиком HTTP; другие типы услуг также могут обрабатываться аналогично.
Во втором подходе анализируются характеристики трафика от данного терминала (CPE). Характеристики трафика, которые анализируются, могут включать в себя статистику трафика, такую как размер пакетов или средняя скорость передачи данных, измеренная за некоторый период времени) или содержимое трафика (например, тип пакета). На основе проанализированных характеристик трафика трафик далее передается по каналу произвольного доступа (RACH) или по ориентированному на резервирование каналу (RESCH).
В одном примере терминал отправляет меньшие пакеты (например, подтверждения приема TCP) по RACH. Тем не менее, когда терминалу требуется отправить пакеты длины, большей чем определенный пороговый размер, терминал запрашивает полосу пропускания по RESCH. Чтобы, таким образом, запросить полосу пропускания по RESCH, терминал отправляет пакет запроса на резервирование по RACH.
На фиг.3 блок-схема последовательности операций показывает этапы примерной реализации второго варианта осуществления, при этом этап 300 указывает начало процесса.
Этап 302 иллюстрирует анализ трафика данных, относящегося к данному терминалу. Например, анализируется статистика трафика, такая как размер пакетов или средняя скорость передачи данных за заданный период времени. Альтернативно, анализируется содержимое трафика, такое как тип пакетов или другой критерий. В одном варианте осуществления предварительный анализ выполняется в терминале, но в других вариантах осуществления этот анализ выполняется в узле.
Этап 310 иллюстрирует решение, основанное на анализе статистики трафика или содержимого трафика от этапа 302. Если проанализированная статистика трафика находится ниже порога или содержимое трафика не удовлетворяет данному критерию или критериям, управление передается этапу 330, который указывает, что терминал выполняет передачу по RACH. Тем не менее, если проанализированный трафик соответствует или превышает порог или содержимое трафика удовлетворяет данному критерию или критериям, управление передается этапу 320.
Этап 320 иллюстрирует то, что терминал отправляет запрос на резервирование полосы пропускания, в одной реализации по RACH. Следующий этап 322 указывает, что узел (шлюз) обрабатывает запрос терминала и на основе доступной полосы пропускания удовлетворяет запрос терминала. Чтобы передать удовлетворение запроса, узел отправляет код резервирования полосы пропускания терминалу, как проиллюстрировано на этапе 324. Далее этап 326 иллюстрирует то, что терминал выполняет передачу по RESCH.
Этапы 320, 322, 324 представлены пунктирными линиями для того, чтобы подчеркнуть, что описанная реализация включает в себя процесс запроса и предоставления, который выполняется между терминалом (CPE) и узлом (шлюзом); тем не менее, эта последовательность запроса-предоставления - не единственная, предлагаемая для того, чтобы терминал осуществлял передачу по RESCH. Второй вариант осуществления добавляет задержку на двустороннее прохождение в каждую передачу по RL, что увеличивает время ответа по страницам для приложений HTTP. Тем не менее, второй вариант осуществления имеет большую эффективность использования полосы пропускания, чем просто при отправке всех данных по RACH, как применяется в первом варианте осуществления.
После этапов 330 и 326 управление передается обратно аналитическому этапу 302. Таким образом, анализ статистики трафика или содержимого трафика и последующее определение того, передает ли терминал по RACH или по RESCH, может проводиться постоянно.
Третий вариант осуществления (фиг.4).
Третий подход основан частично на распознавании того, что трафик, генерируемый в обратной линии (RL) посредством, например, потока данных HTTP, является пакетным и имеет низкое требование по скорости передачи данных, когда используется сжатие. Поэтому третий подход к управлению трафика включает в себя назначение потока данных подканалу с низкой скоростью передачи данных ориентированного на резервирование канала (RESCH) без необходимости терминалу проходить через процесс явного запроса на резервирование. В этом описании этот подканал с низкой скоростью передачи данных упоминается как "всегда активный" канал и он "активен" (выделен конкретному терминалу) на, по меньшей мере, период времени транзакции ответа на запрос по страницам.
Преимущественно, подход "всегда активного" канала устраняет задержку запроса на резервирование, которая существенна (около 0,5 секунды) в геостационарной спутниковой системе. Недостаток подхода "всегда активного" канала заключается в том, что вследствие пакетирования HTTP-трафика канал не всегда используется в течение времени, когда он выделен и "активен". Тем не менее, поскольку только часть пользователей, которым назначен "всегда активный" канал, фактически выполняет передачу, передающим терминалам разрешено отправлять данные при большей мощности и более высоком уровне кодирования/модуляции. Это приводит к более высокой эффективности использования полосы пропускания, когда терминал выполняет передачу, большей эффективности, которая является частичной компенсацией терминалам, которые не полностью используют выделенные им полосы пропускания, тем самым достигая общего (статистического) выигрыша от мультиплексирования. Как упоминалось выше, необязательно ограничивать этот подход трафиком HTTP; подход может быть использован также с другими типами услуг.
Один подход к принятию решения о том, следует ли или нет назначать "всегда активный" канал потоку, описан далее. Этот подход описывается со ссылкой на трафик HTTP как неограничивающий пример: конкретно, трафик, когда пользователь выполняет серфинг в Интернете с помощью традиционного Web-обозревателя. Тем не менее, следует понимать, что трафик может быть отличным от HTTP.
Вкратце, шлюз пытается определить, когда пользователь фактически в данном терминале, на основе анализа трафика, ассоциированного с этим терминалом. Предположительно, трафик осуществляется по RACH, и код Уолша не был назначен, который должен предоставить терминалу разрешение использовать более быстрый RESCH. Если шлюз определяет, что пользователь активно использует данный терминал (т.е. то, "занят" ли терминал), то шлюз назначает этому терминалу код Уолша, который дает ему разрешение использовать подканал RESCH. В одном варианте осуществления выделенный подканал - это "всегда активный" подканал, скорость передачи данных по которому ниже, чем большая часть другого трафика по RESCH.
Шлюз непрерывно отслеживает трафик, ассоциированный с терминалом, с намерением сохранения "всегда активного" канала в течение всего Web-сеанса пользователя. Когда объем трафика в активном канале падает ниже определенного уровня активности, шлюз заключает, что пользователь больше не использует активно терминал и аннулирует разрешение терминалу использовать "всегда активный" канал. Кроме того, когда характер трафика канала показывает, что отправляется только "фоновый" трафик HTTP, шлюз заключает, что пользователь больше не использует активно терминал и отзывает разрешение CPE использовать "всегда активный" канал.
Таким образом, непрерывный мониторинг и результирующее назначение и отзыв "всегда активных" подканалов в RESCH шлюзом повышает общее (статистическое) использование полосы пропускания, выделяемой "всегда активным" каналам для множества терминалов.
Решение выделять "всегда активный" канал потоку данных может быть инициировано терминалом или шлюзом. Если терминал запрашивает "всегда активный" канал, он может отправить запрос по RACH или "совместить" запрос с другими пакетами RACH. Прежде чем поток HTTP обозначается надлежащим для "всегда активного" канала, его первые несколько пакетов могут быть переданы по RACH для того, чтобы избежать задержки на резервирование. В любом случае шлюз окончательно предоставляет полосу пропускания.
Пропускная способность (в бит/с) "всегда активного" канала может быть задана как объем данных, который передает терминал, поделенное на продолжительность времени, когда терминал имеет выделение пропускной способности. Фактическая эффективность использования полосы пропускания терминалов по "всегда активному" каналу задается как его пропускная способность, деленная на величину полосы пропускания, выделенную терминалу, т.е. бит в секунду на Гц, фактически передаваемые.
Идеально, шлюз должен выделять "всегда активный" канал терминалу после обнаружения потока данных от терминала по RL, если он ожидает, что эффективность использования полосы пропускания "всегда активного" канала больше, чем эффективность использования полосы пропускания RACH. В одном примере пропускная способность канала RESCH номинально составляет около 1,5 бит/с/Гц (4,5 Мбит/с по RL-каналу в 3 МГц), тогда как этот показатель RACH составляет около 0,3 бит/с/Гц. Поэтому в идеальном варианте можно захотеть выполнять передачу по "всегда активному" каналу.
Тем не менее, как описано выше, не все терминалы, которые имеют выделение "всегда активного" канала, фактически используют соответствующие назначенные полосы пропускания. Поэтому можно выполнять передачу при большей мощности по "всегда активному" каналу и использовать большую степень кодирования/модуляции, чем номинально используется в RESCH. Средняя и пиковая мощность передачи всех терминалов, выполняющих передачу по "всегда активным" каналам, должна быть ниже допустимых уровней, разрешенных лимитом по интерференции с соседним спутником.
Различные подходы могут применяться при определении того, должен ли "всегда активный" канал быть назначен терминалу, например:
- подход параметрического обнаружения потоков на основе характеристик трафика потока данных; или
- основанный на контексте механизм обнаружения потоков.
Параметрический подход использует характеристики трафика потока для того, чтобы прогнозировать, будет или нет поток генерировать достаточно трафика для того, чтобы достичь достаточно высокой фактической эффективности использования полосы пропускания для того, чтобы подтвердить назначение "всегда активного" канала. При этом подходе базовая идея состоит в том, чтобы воздерживаться от назначения "всегда активных" каналов потокам, которые имеют небольшое количество байт и малую длительность. Этот подход позволяет назначать "всегда активный" канал потоку, если количество пакетов и/или число байт, принимаемых в шлюзе от терминала в течение определенного интервала времени, превышает определенные пороги. Ограничение на число пакетов в данном интервале измерений предназначено для того, чтобы не допустить назначения "всегда активных" каналов потокам, которые имеют небольшую длительность и включают в себя транзакции, такие как DNS-поиски.
Трудность с неназначением "всегда активного" канала потоку, если количество пакетов от потока ниже определенного порога, заключается в том, что даже HTTP-поток начинается с одного сообщения GET. В этом случае "всегда активный" канал не должен быть назначен потоку HTTP до тех пор, пока не поступит ответ на первое сообщение GET и не сгенерирует ряд сообщений GET. Последующие сообщения GET либо не должны направляться по RACH, либо будут испытывать полусекундную задержку на резервирование. Чтобы быстрее обнаруживать потоки HTTP, подход может вызывать поток, если количество отправленных байт превышает порог или количество отправленных пакетов превышает порог.
Критерий прерывания также предусмотрен для того, чтобы отключать "всегда включенный" канал, когда поток завершается.
Параметрический механизм отключает "всегда активный" канал, когда поток неактивен в течение более чем заданного времени "ожидания" после последнего пакета потока. Важный параметр в этом подходе - какой длительности должно быть время "ожидания".
Подход с длительным ожиданием (много минут) предназначен для того, чтобы обеспечивать то, что "всегда активный" канал доступен пользователю в течение сеанса Web-просмотра. Другими словами, длительное время ожидания обеспечивает, что "всегда активный" канал не исключается в ходе "периода зависания". Преимущество длительного ожидания заключается в том, что когда пользователь запрашивает новую страницу, нет начальной задержки для запроса "всегда активного" канала. Разумеется, при длительных ожиданиях теряется полоса пропускания в периоды зависания, и "всегда активные" каналы могут назначаться многим CPE, чьи вычислительные машины всегда выполняют такие процессы, как простое периодическое обновление узла.
В модели с коротким ожиданием "всегда активный" канал исключается после краткосрочного интервала после последнего пакета потока. Модель с коротким ожиданием повышает эффективность использования полосы пропускания, но увеличивает количество повторных назначений кода Уолша. Короткий период ожидания выбирается достаточно длительным для того, чтобы обеспечить, что "всегда активный" канал не исключается до того, как полностью принят ответ на запрос поискового вызова, но может быть достаточно коротким для того, чтобы "всегда активный" канал разблокировался в течение периода зависания.
Первые несколько пакетов нового потока (например, запрос по странице) передаются по RACH для того, чтобы избежать задержки на резервирование. Этот подход добавляет трафик в RACH, но при помощи сжатия значительно уменьшает размер пакетов, например, сообщения GET, и дополнительная нагрузка на RACH небольшая. Поэтому посредством отправки начала потока по RACH устраняются задержки, связанные с резервированием.
Хотя количество повторных назначений кода Уолша в модели с коротким ожиданием значительно больше, чем в модели с длительным ожиданием, требуемое время обработки и передачи сигналов для того, чтобы установить и разорвать "всегда активные" каналы, не должно быть "узким местом". Причина заключается в том, что в схемах TDMA выделение полосы пропускания выполняется более динамично, чем для "всегда активных" каналов. По-видимому, каждое сообщение GET потребует отдельного резервирования, что приведет к большим задержкам, а также большому числу транзакций запроса/предоставления резервирования. Поэтому количество назначений по "всегда активным" каналам с коротким временем ожидания должен быть менее зависимо от количества резервирований канала, которое требует система с RL TDMA.
Другой подход к принятию решения о том, должен ли или нет "всегда активный" канал быть назначен потоку, основан на контексте (как упоминалось выше).
В неограничивающем примере, использующем HTTP-прокси, шлюз распознает, что приложение HTTP запущено и, следовательно, может определить, что должен быть назначен "всегда активный" канал. Даже скорость передачи данных по "всегда активному" каналу может быть определена на основе другой контекстной информации, такой как Web-узел, который посещается. Поскольку скорость передачи данных "всегда активного" канала может зависеть от того, как страница кэшируется клиентским прокси, предусмотрен обмен данными между прокси и шлюзом, касающийся "ожидаемого" объема RL-трафика для потока. Аналогично, шлюз может распознать на основе содержимого пакетов, что ответ на запрос поискового вызова завершен, и "всегда активный" канал может быть отключен.
Фактическая эффективность использования полосы пропускания контекстного назначения "всегда активных" каналов выше, чем при параметрическом подходе, поскольку время ожидания может быть уменьшено практически до нуля.
В контекстном обнаружении потоков обнаружение потоков фактически является дополнительной функцией прокси. Другими словами, трафик Web-просмотра, генерируемый Web-обозревателями, обнаруживается, если пользователь использует прокси. Назначение "всегда активного" канала этим пользователем является дополнительной функцией усовершенствований прокси. Разумеется, контекстное обнаружение потоков может быть применено к типам трафика, отличным от HTTP.
На фиг.4 блок-схема последовательности операций показывает этапы примерной реализации третьего варианта осуществления, при этом этап 400 иллюстрирует начало процесса.
Этап 410 иллюстрирует этап анализа статистики трафика или содержимого трафика, который может быть во многом таким же, что и на этапе 302 (фиг.3). Следовательно, его подробное описание не приводится повторно.
Этап 420 иллюстрирует решение о том, "занят" ли или нет терминал. Определение "занятости" зависит от конкретной реализации сети, особенно от используемого протокола. Терминал может считаться "занятым", если считается, что пользователь активно участвует во взаимодействии с терминалом способом, который приводит к обмену данными по линии связи в объеме или типа, превышающего значение для простого "фонового" обмена данными.
Например, если терминал обменивается данными с Web-узлами Интернета по TCP/IP и HTTP (см. фиг.1), определение того, занят ли или нет терминал, может включать в себя анализ того, отправляет ли или нет терминал активно запросы на загрузку Web-страницы. Если запросы на Web-страницы активно отправляются и Web-страницы фактически загружаются таким образом, что, вероятнее всего, это является сеансом интерактивного Web-просмотра, терминал считается занятым и управление передается этапу 440. Тем не менее, если осуществляется только минимальный "фоновый" обмен данными, такой как минимальный трафик, требуемый для того, чтобы поддерживать TCP-сеанс, при отсутствии взаимодействия пользователя в течение заранее определенного периода времени, то терминал считается незанятым, и управление переходит к этапу 430.
Этап 430 иллюстрирует, что если терминал считается незанятым, назначение всех кодов Уолша для "всегда активного" подканала, ориентированного на резервирование подканала, отменяется (они аннулируются). Если ни одного кода Уолша уже не назначено терминалу, на этапе 430 не выполняют никакого действия. Аннулирование кода Уолша передается терминалу, который затем выполняет передачу по RACH, как указано на этапе 432.
Наоборот, этап 440 иллюстрирует, что если терминал считается занятым, код Уолша для "всегда активного" подканала, ориентированного на резервирование подканала, назначается. Если код Уолша до этого назначен терминалу, то на этапе 440 не выполняют никакого действия, и предыдущее назначение кода Уолша остается в силе. Любое новое назначение кода Уолша передается терминалу, который затем выполняет передачу по RESCH, как указано на этапе 442.
После этапов 432 и 442 управление передается обратно аналитическому этапу 410. Таким образом, анализ статистики трафика или содержимого трафика и последующее определение того, занят ли или нет терминал и передает ли терминал по RACH или по RESCH, может проводиться постоянно.
Четвертый вариант осуществления (фиг.5A, 5B).
В четвертом подходе терминал первоначально передает пакеты по RACH. Каждый пакет содержит "Q-состояние" терминала. При этом "Q-состояние" означает объем данных, находящихся в выходном буфере терминала (очереди). Значением Q-состояния может быть, например, количество байт, которое остается в очереди на передачу терминала на момент передачи первого бита Q-состояния. Q-состояние может быть включено в передаваемые пакеты множеством способов. Например, Q-состояние может быть прикреплено в конец каждого MAC-пакета, причем прикрепление может выполняться посредством передающей ASIC (специализированной интегральной схемы).
На основе Q-состояния, принятого от терминала, шлюз может решить назначить канал резервирования терминалу. В этом случае узел (шлюз) сообщает терминалу о назначенном коде Уолша и времени канала резервирования, назначенном ему.
В то время, когда терминал передает данные по каналу резервирования, терминал продолжает передавать свое Q-состояние. Узел может принять решение на основе значения Q-состояния, отправленного терминалом, либо обновить код Уолша канала резервирования терминала на более короткий код Уолша (канал с более высокой скоростью), чтобы увеличить продолжительность текущего канала, либо назначить более длинный код Уолша (канал с более низкой скоростью передачи данных).
Согласно фиг.5A, 5B, блок-схема последовательности операций иллюстрирует этапы примерной реализации четвертого варианта осуществления, при этом этап 500 иллюстрирует начало процесса.
Этап 510 иллюстрирует передачу терминалом своей загрузки выходного буфера (Q-состояния) по RACH. Этап 520 иллюстрирует решение о том, соответствует ли или превышает ли Q-состояние заданный порог Q-состояния или нет. Если Q-состояние меньше порога, управление переходит к этапу 530, который иллюстрирует, что терминал выполняет передачу по RACH.
Тем не менее, если Q-состояние соответствует или превышает порог, управление передается этапу 540, который иллюстрирует назначение узлом терминалу кода Уолша для "всегда активного" подканала в ориентированном на резервирование канале. Этап 542 иллюстрирует результирующую передачу терминала по "всегда активному" подканалу, ориентированному на резервирование канала. Этап 544, как правило, показывает обработку, которая осуществляется, когда терминал выполняет передачу по ориентированному на резервирование каналу. Этап 544 подробнее описан ниже со ссылкой на фиг.5B.
Когда терминал больше не выполняет передачу по RESCH (или по его "всегда активному" подканалу), управление передается от этапа 544 к 530, иллюстрируя, что терминал выполняет передачу по RACH после того, как он больше не выполняет передачу по RESCH или его подканалу.
После этапа 530 управление передается обратно этапу 510. Таким образом, мониторинг Q-состояния терминала и последующее определение того, подтверждает или нет загрузка выходной очереди терминала назначение кода Уолша, разрешающего терминалу выполнять передачу по каналу резервирования, может выполняться постоянно.
На фиг.5B подробнее представлены сведения по обработке канала резервирования (фиг.5A, этап 544).
Этап 550 иллюстрирует передачу терминалом своей загрузки выходного буфера (Q-состояния) по RESCH. Передача Q-состояния по RESCH отличается от передачи Q-состояния по на этапе 510.
Этап 552 иллюстрирует анализ предыстории последних Q-состояний узла. Предпочтительно, этот анализ выполняется в узле (шлюзе), но использование этого места необязательно. В любом случае, на основе одного или более последних Q-состояний принимается решение, касающееся того, должен ли терминалу быть назначен один из нескольких возможных каналов:
- вообще без ориентированного на резервирование канала передачи, но по каналу произвольного доступа (этап 560 и возврат к фиг.5A),
- ориентированный на резервирование канал передачи с меньшей скоростью (этапы 570, 572),
- ориентированный на резервирование канал передачи с той же скоростью (этап 580), или
- ориентированный на резервирование канал передачи с большей скоростью (этапы 590, 592).
Если предыстория Q-состояний указывает, что загрузка выходного буфера терминала уменьшается до значения ниже порога или соответствует другим критериям, делается вывод о том, что тенденция терминала - в значительной степени не полностью использовать RESCH, и, следовательно, код Уолша терминала аннулируется на этапе 560. Узел сообщает об аннулировании кода Уолша терминалу, и управление переходит от этапа 560 обратно к этапу 530 (фиг.5A), что означает передачу данных по RACH.
Если предыстория Q-состояний указывает, что загрузка выходного буфера терминала уменьшается ниже другого порога или соответствует другим критериям, делается вывод о том, что тенденция терминала - в незначительной степени не полностью использовать текущий RESCH. Следовательно, текущий код Уолша терминала заменяется на более длинный код Уолша на этапе 570. Узел сообщает об изменении кода Уолша терминалу, и управление переходит к этапу 572, на котором указывают, что терминал передает данные по новому RESCH, который имеет меньшую скорость передачи, чем скорость ранее назначенного RESCH.
Если предыстория Q-состояний показывает, что загрузка выходного буфера терминала примерно стабильна или соответствует другим критериям, делается вывод о том, что терминал корректно использует текущий RESCH. Следовательно, текущий код Уолша терминала остается неизменным и в силе. Управление переходит непосредственно к этапу 580, на котором указывают, что терминал передает данные по тому же каналу RESCH, по которому он передавал (или, по меньшей мере, по каналу RESCH, который имеет такую же скорость передачи данных).
Наконец, если предыстория Q-состояний указывает, что загрузка выходного буфера терминала увеличивается выше данного порога или соответствует другим критериям, делается вывод о том, что тенденция терминала - чрезмерно использовать текущий RESCH. Следовательно, текущий код Уолша терминала заменяется на более короткий код Уолша на этапе 590. Узел сообщает об изменении кода Уолша терминалу, и управление переходит к этапу 592, на котором указывают, что терминал передает данные по новому RESCH, который имеет большую скорость передачи данных, чем скорость ранее назначенного RESCH.
В любом случае, после любого из этапов 572, 580, 592 управление передается обратно этапу 550 для передачи последующих Q-состояний. Таким образом, анализ очереди выходного буфера терминала и последующее определение того, подтверждает ли или нет предыстория Q-состояний терминала использование RESCH с другой скоростью или даже RACH, может выполняться постоянно.
Использование предыстории множества Q-состояний "усредняет" все неинформативные значения Q-состояний или краткосрочные аномалии в загрузке выходного буфера терминала. Этот подход уменьшает число раз, когда терминал без необходимости переключается между передачей по RACH и RESCH (фиг.5A в сравнении с фиг.5B). Дополнительно, этот подход дает возможность сложным аналитическим методикам быть использованным для принятия решений о величине полосы пропускания, которую подтверждают Q-состояния данного терминала.
Конкретная реализация четвертого варианта осуществления описана далее, при этом:
- "CPE" (находящееся у заказчика оборудование) соответствует "терминалу", представленному в этом описании,
- "шлюз" соответствует "узлу", представленному в этом описании,
- "RACH" соответствует каналу произвольного доступа (без резервирования),
- "RESCH" (канал резервирования) соответствует ориентированному на резервирование каналу,
- "RL" (ответная линия связи, иногда обратная линия связи) соответствует части сети связи, в которой RACH, RESCH и, возможно, другие каналы могут быть обнаружены (см. пример на фиг.1), и
- "FL" (прямая линия) - это линия, отправляющая данные по сети в направлении, противоположном RL (см. пример на фиг.1).
Планировщик в CPE определяет, направляются ли пакеты CPE, предназначенные шлюзу, по RACH или по RESCH. Когда первоначальная передача CPE начинается, она осуществляется по RACH. Тем не менее, далее, когда создается очередь передачи RL CPE, шлюзу может потребоваться выделить канал резервирования (короткий код Уолша на канале OCDMA) для того, чтобы ускорить процесс загрузки, соответствующий текущему переносу данных. CPE периодически сообщает информацию о Q-состоянии RL шлюзу посредством прикрепления этой информации к каждому MAC-пакету, передаваемому шлюзу. Шлюз на основе порога глубины очереди RL определяет то, превышает ли текущее сообщенное Q-состояние RL порог, который ему требуется для того, чтобы выполнить резервирование для CPE. Это обосновано тем, что должно отнимать меньше времени для того, чтобы опустошить загрузку созданной очереди с помощью более высокой скорости резервирования, чем оставаться с неизменной скоростью, чтобы установить загрузку. Затем шлюз должен определить, какую скорость (короткий код Уолша) и на какой период времени назначить для резервирования CPE. Скорость определяется посредством оптимальной скорости из доступного пула коротких кодов Уолша. Затем шлюз определяет, может ли мощность, требуемая для передачи на этой скорости, поддерживаться CPE (т.е. она не превышает максимальной мощности передачи усилителя мощности (PA) в CPE). В противном случае, наиболее оптимальная скорость выбирается так, чтобы мощность передачи, требуемая в CPE, не превышала максимальной мощности PA, и выполняется резервирование (назначение короткого кода Уолша) для CPE.
Шлюз продолжает отслеживать информацию о Q-состояния от CPE с момента времени, когда он назначил резервирование для CPE. Если последующие обновления Q-состояния являются неуменьшающими, то текущее резервирование может быть продлено после окончания текущего периода резервирования. Поскольку текущее резервирование выделено на основе исходной информации о Q-состоянии, CPE должен быть предоставлен продленный период резервирования на основе текущего более высокого значения Q-состояния для того, чтобы установить размер очереди. Типичный пример варианта применения, в котором продленные периоды резервирования могут предоставляться, - это случай выгрузки по FTP. В этом случае последующие обновления Q-состояния выполняются при более высоких значениях размера очереди RL, и шлюз должен увеличивать период резервирования до тех пор, пока вся нагрузка не будет исключена из очереди RL.
Кроме того, если шлюз обнаруживает, что в настоящее время нет доступных кодов Уолша, то в случае, когда CPE подпадает под условие получения резервирования (посредством информации о своем Q-состоянии), он обрабатывает эту ситуацию, как описано далее в сценарии перегрузки по коротким кодам Уолша.
Предполагается, что шлюз централизованно координирует назначение/отмену назначения короткого кода Уолша. Подробности этого и сигнализация, требуемая для назначения/отмены назначения короткого кода Уолша, описаны ниже.
Переменные состояния, хранимые в CPE и в шлюзе
И CPE, и шлюз поддерживают состояние соединения посредством ряда переменных состояния. Шлюз хранит некоторые из этих переменных состояния по каждому CPE, т.е. для всех CPE, которые в настоящее время зарегистрированы и являются частью системы. Это следующие переменные состояния:
CurrentState
- - означает текущее состояние передачи по RL, т.е. идет ли она по RACH или по RESCH. На основе этого CPE планирует, что пакет должен быть отправлен по RACH или по RESCH.
QueueSize
QueueSize
CPE
CPE
-  - означает текущий размер очереди передачи (в битах) в CPE, сообщенный поступившим MAC-пакетом от CPE.  означает размер очереди RL MAC, за исключением размера поступившего MAC-пакета.
QueueSize
Gw
-  - означает текущий размер очереди передачи (в битах), хранимый в шлюзе, сразу перед поступлением нового MAC-пакета от CPE.
QueueDepthThreshold
-  - означает порог размера очереди передачи (в битах), за пределами которого CPE подпадает под резервирование.
CurrentRate
-  - означает текущую скорость передачи данных, на которой данный CPE передает пакеты шлюзу (в битах в секунду) по RL. Шлюз хранит эту переменную по каждому CPE.
CurrentTime
-  - означает текущее время CDMA в шлюзе.
RTT
-  - означает время двустороннего прохождения по геостационарной линии связи (в секундах). Только один экземпляр этой переменной хранится в шлюзе.
- GuardTime
- равно наибольшей разности в задержке на распространение в FL, которая может быть понесена любыми двумя CPE в луче. Шлюз хранит только один экземпляр этой переменной.
ResvTime
-  - равно времени резервирования для резервирования по короткому коду Уолша, назначенному CPE шлюзом. Шлюз хранит экземпляр этой переменной по каждому CPE.
- StartResvTime
CurrentTime
StartResvTime
CurrentTime + 1/2 RTT + GuardTime
GuardTime
1/2RTT
StartResvTime
- означает время начала канала резервирования по короткому коду Уолша в шлюзе. Для резервирования, которое определено в , значение  равно в шлюзе (когда резервирование начинается в CPE). Шлюз предоставляет разрешение на период  в течение средней задержки на распространение в FL, равное  для того, чтобы обеспечить, что все CPE в луче могут слышать сообщение резервирования и начинать свое резервирование в момент .
- EndResvTime
StartResvTime + ResvTime.
- означает окончание времени резервирования по короткому коду Уолша для CPE. Оно равно
Процедура передачи в CPE
CPE прикрепляет информацию о Q-состоянии к каждому пакету данных, отправляемому в шлюз.
Процедура приема в CPE
CPE принимает сигнализирующие пакеты от шлюза, обозначая резервирование по короткому коду Уолша или завершение текущего резервирования.
CurrentState
StartResvTime
EndResvTime
CurrentState
Если имеется новое резервирование по короткому коду Уолша, то CPE задает  значение, равное RESCH, в начале , и резервирование продолжается до . После того, как резервирование завершается,  снова присваивается значение RACH для того, чтобы обозначить, что дальнейшие передачи выполняются по RACH вместо RESCH.
CurrentState
Если CPE принимает сигнал с указанием завершения текущего резервирования, он присваивает  значение RACH с момента завершения, указанного в сигнальном сообщении.
Требования к шлюзу
В этом разделе описаны процедуры в шлюзе для определения того, при каком пороге CPE подпадает под то, чтобы получить резервирование по короткому коду Уолша, процедуры назначения/отмены назначения короткого кода Уолша для CPE, процедуры продления текущего сеанса резервирования. Описан общий алгоритм резервирования в шлюзе.
Процедура приема в шлюзе
OueueSize
CurrentState
CPE
Шлюз принимает MAC-пакет от CPE, считывает поле Q-состояния и обновляет переменную  значением принятого Q-состояния. Если CPE не имеет резервирования (т.е. его равно RACH), то шлюз должен сначала определить то, подпадает ли CPE под резервирование по короткому коду Уолша.
Новая процедура резервирования в шлюзе
Критерий порога глубины очереди RL для определения того, подпадает ли поток без текущего резервирования под резервирование, задается следующим уравнением.
QueueSize
> QueueDepthThreshold = (RTT + GuardTime) * CurrentRate
CPE
(определение порога глубины очереди RL)
Краткое описание вышеприведенного уравнения дается ниже. Резервирование выполняется только в том случае, если время, требуемое для того, чтобы сбросить нагрузку в очереди передачи RL посредством предоставления резервирования, меньше времени, требуемого для того, чтобы сбросить очередь RL при текущей скорости передачи, т.е.:
(RTT/2+ RTT/2+GuardTime),
RTT/2
RTT/2
GuardTime
RTT + GuardTime).
Левая сторона (LHS) неравенства имеет член который представляет собой полную задержку на двустороннее прохождение, после которой начинается резервирование в CPE. - это средняя задержка на распространение в RL, после который MAC-пакет, проходящий к резервированию, достигает шлюза, и шлюз делает резервирование, а + учитывает задержку на распространение в FL + защитный интервал, до которого начинается резервирование в CPE. Второй член в LHS - это общее время обслуживания при новой более высокой скорости передачи данных (обратите внимание, что он учитывает очередь RL, сброшенную при старой скорости передачи данных в течение периода Правая сторона (RHS) неравенства - это общее время на обслуживание для того, чтобы обслуживать очередь RL при текущей скорости обслуживания.
P
P
P
P
Rate
Rate
ResvTime
required
required
max
max
WC
WC
Пул коротких кодов Уолша в шлюзе разбивается на различные пулы W8, W16, W32, W64, W128 и W256 коротких кодов Уолша. Из списка доступных коротких кодов Уолша шлюз выбирает короткий код Уолша с максимальной скоростью передачи данных, так чтобы удовлетворялись определенные ограничения. Во-первых, скорость должна быть такой, чтобы общая мощность, распространяемая от всех CPE соседним спутникам, находилась в рамках заданных ограничений Федеральной комиссии связи США (FCC). После того, как короткий код Уолша выбран на основе вышеуказанных критериев, шлюз определяет, может ли мощность (), требуемая для скорости передачи данных, поддерживаться CPE (т.е.  < , где  - это максимальная допустимая мощность передачи PA). Если эта скорость поддерживается, то ей присваивается значение . В противном случае, шлюз определяет, какая может быть следующая поддерживаемая оптимальная скорость, и ей присваивается значение . Время резервирования вычисляется следующим образом:
(Определение времени резервирования для квалифицирования потока)
StartResvTime = CurrentTime + 1/2RTT + GuardTime
EndResvTime = StartResvTime + ResvTime
QueueSize
QueueSize
GW
CPE
Резервирование начинается с  и продолжается до . Шлюз также обновляет переменную состояния  до .
StartResvTime
EndResvTime
Информация о резервировании по короткому коду Уолша (короткий код Уолша, , ) передается от шлюза к CPE посредством сигнального сообщения. Шлюз отправляет это сообщение CPE по каналу управления FL.
Алгоритм назначения нового резервирования для CPE
(QueueSize
)
CPE
Шлюз принимает информацию о Q-состоянии от CPE
CurrentTime
Он обновляет , когда информация о Q-состоянии принята
If (если) (CPE в данный момент не принимает резервирование)
// Проверка критериев порога резервирования
(QueueSize
> (RTT + GuardTime)*CurrentRate)
CPE
if
// Проверка того, доступен ли какой-либо короткий код Уолша
CurrentTime > EndResvTime
if (для, по меньшей мере, одного короткого кода Уолша)
Rate
wc
1. Выбрать короткий код Уолша с максимальной скоростью передачи данных, разрешенной пулом свободных кодов Уолша и другими ограничениями, и CPE может поддерживать требуемую мощность передачи. Пусть скорость задается посредством
ResvTime
2. Вычислить время резервирования, :
ResvTime,
StartResvTime
CurrentTime + Ѕ RTT + Guard Time
EndResvTime
StartResvTime
ResvTime.
3. Назначить короткий код Уолша CPE для начиная с = и до = +
4. Передать резервирование для CPE посредством сигнального сообщения.
endif
endif
endif
(Алгоритм выделения резервирования новому потоку)
Продление резервирования для потоков с текущим резервированием
QueueSize
CPE
Период резервирования, который первоначально определен шлюзом, может быть недостаточным в случае, если CPE предоставляет последующие отчеты о Q-состоянии с увеличением  (т.е. очередь передачи CPE растет). В таком случае шлюз определяет, подпадает ли CPE под то, чтобы получить продление текущего резервирования, и если так, на сколько должно быть продлено резервирование.
CurrentTime
EndResvTime.
EndResvTime)
EndResvTime
CurrentTime < EndResvTime
(1/2RTT + GuardTime) - (Transmission
Reception
Processing Delay)
QueueSize
deltaQueue
(QueueSize
- QueueSize
+ CurrentReceivedPacketSize)
deltaQueue/Rate
EndResvTime - EndResvTime + deltaQueue/Rate
QueueSize
QueueSize
EndResvTime)
CPE
CPE
GW
WC
WC
GW
CPE
Шлюз сначала определяет то, больше ли текущее системное время , чем Если так, это подразумевает, что CPE не может получить продление своего текущего резервирования (поскольку его текущее резервирование истекло в , но должен пройти через следующий процесс резервирования. Далее он проверяет, достаточно ли времени для сообщения продления резервирования для того, чтобы достичь CPE до того, как истекает его текущее резервирование в , т.е. - + + . Если нет, шлюз не может продлять резервирование для CPE. Если текущее резервирование не истекло, шлюз определяет пошаговое увеличение/уменьшение  с момента последнего отчета о Q-состоянии. Т.е. шлюз определяет = . Если есть увеличение, то он вычисляет увеличение в резервировании как . Шлюз обновляет , а также обновляет  до . После этого шлюз отправляет информацию о пошаговом резервировании (короткий код Уолша, CPE посредством сигнального сообщения. Шлюз отправляет это сообщение CPE по каналу управления FL.
Алгоритм продления текущего резервирования для CPE
(QueueSize
)
CPE
Шлюз принимает информацию о Q-состоянии от CPE
(резервирование не может быть продлено согласно вышеупомянутым критериям)
if
deltaQueue = QueueSize
-QueueSize
Current ReceivedPacketSize
CPE
GW
+
(deltaQueue > 0)
if
IncrementResv = deltaQueue/Rate
WC
IncrementResv
Передать в CPE посредством сигнального сообщения
EndResvTime - EndResvTime + IncrementResv
Обновить
QueueSize
= QueueSize
GW
CPE
Обновить
endif
endif
(Алгоритм продления резервирования для потоков с резервированием)
Изменение скорости передачи данных, соответствующей резервированию (текущая скорость передачи данных, соответствующая резервированию не поддерживается в CPE)
P
P
desired
max
В течение периода резервирования CPE шлюз постоянно отслеживает, находится ли мощность в CPE, требуемая для того, чтобы передавать данные на текущей скорости передачи данных (), в рамках максимальной мощности передачи PA (). Если этот критерий удовлетворяется, CPE разрешается продолжить передачу на текущей скорости. Если этот критерий не удовлетворяется (вследствие изменения условий канала, таких как замирание при дожде), шлюз заново вычисляет максимальную скорость, которая может быть разрешена, на основе своих таблиц скоростей.
Шлюз отключает текущее резервирование для CPE и передает новое резервирование для CPE посредством нового сообщения резервирования с новой скоростью по каналу управления FL.
Повторное назначение короткого кода Уолша новому резервированию, процедура перегрузки в шлюзе
CurrentTime > EndResvTime
CurrentTime > EndResvTime - 1/2RTT
GuardTime
CurrentTime + 1/2RTT
GuardTime,
EndResvTime + 2*GuardTime
EndResvTime
2*GuardTime
1/2RTT + GuardTime (GuardTime << 1/2RTT)
Предположим, поток CPE подпадает для резервирования. Шлюз проверяет, для любого короткого кода Уолша, в данный момент рассматриваемого. Более агрессивный подход может заключаться в том, чтобы проверять + для любого короткого кода Уолша, в данный момент рассматриваемого. Это означает, что решение о резервировании может быть принято шлюзом для повторного использования короткого кода Уолша до того, как текущее резервирование с помощью того же короткого кода Уолша в CPE истекает. Это более эффективно, поскольку новое резервирование начинается только с + что гарантированно > , а предшествующее резервирование завершается в  и, таким образом, нет несоответствий в выделении резервирования. Это также повышает эффективность назначения резервирования, поскольку короткий код Уолша не используется в течение интервала , что является гораздо меньшей перегрузкой по сравнению с потерей периода времени между повторными назначениями посредством вышеописанного умеренного подхода.
CurrentTime > EndResvTime - 1/2RTT +
Из двух вышеприведенных проектных вариантов применяется более эффективный подход, т.е. проверка GuardTime выполняется шлюзом. Если так, то резервирование доступно, и шлюз выделяет резервирование. В противном случае, если нет доступного резервирования (условие перегрузки по короткому коду Уолша), шлюз запрещает резервирование для CPE (т.е. не действует в соответствии с информацией о Q-состоянии и не предоставляет резервирование).
Требования по сигнализации для назначения/отмены назначения резервирования в шлюзе
EndResvTime
EndResvTime
EndResvTime
Шлюз управляет и координирует назначения и отмену назначения резервирования по короткому коду Уолша для CPE. Алгоритмом резервирования предполагается, что назначение короткого кода Уолша отменяется по истечении текущего периода резервирования (), и CPE не сигнализирует шлюзу о том, что он разорвал резервирование по короткому коду Уолша. Обратите внимание, что может не быть исходным периодом резервирования, который назначен CPE, а обновленным после нескольких продлений резервирования. Для каждого нового назначения резервирования и возможных последующих продлений периодов резервирования для CPE шлюз явно уведомляет CPE посредством сигнального сообщения, которое отправляется по каналу управления FL.
Алгоритм CPE
(QueueSize
)
CPE
CPE отправляет информацию о Q-состоянии в пакетах данных, предназначенных для шлюза
Алгоритм шлюза
(QueueSize
)
CPE
Шлюз принимает информацию о Q-состоянии от CPE
CurrentTime
Он обновляет , когда информация о Q-состоянии принята
if (CPE в данный момент не принимает резервирование)
// Проверка критериев порога резервирования
QueueSize
>
RTT + GuardTime
* CurrentRate
CPE
if (() )
// Проверка того, доступен ли какой-либо короткий код Уолша
CurrentTime > EndResvTime
1/2RTT + GuardTime
if (-  для, по меньшей мере, 1 короткого кода Уолша)
Rate
wc
1. Выбрать короткий код Уолша с максимальной скоростью передачи данных, разрешенной пулом свободных кодов Уолша и другими ограничениями, и CPE может поддерживать требуемую мощность передачи. Пусть скорость задается посредством
ResvTime
2. Вычислить время резервирования, :
ResvTime,
StartResvTime
CurrentTime + 1/2RTT + Guard Time
EndResvTime
StartResvTime
ResvTime.
3. Назначить короткий код Уолша CPE для начиная с = и до = +
4. Сообщить CPE о резервировании посредством сигнального сообщения,
else (иначе)
В настоящее время нет доступного короткого кода Уолша, шлюз запрещает резервирование для CPE.
endif
endif
else // CPE в данный момент принимает резервирование
// Проверка того, требуется ли CPE продление резервирования
deltaQueue = QueueSize
- QueueSize
Current ReceivedPacketSize
CPE
GW
+
(deltaQueue > 0
if и резервирование может быть продлено)
IncrementResv = deltaQueue/Rate
WC
IncrementResv
Передать в CPE посредством сигнального сообщения
EndResvTime - EndResvTime + IncrementResv
Обновить
endif
QueueSize
- QueueSize
GW
CPE
Обновить
//Шлюз определяет, что текущая скорость резервирования не может поддерживаться вследствие превышения мощностью передачи, требуемой в CPE, максимальной мощности передачи PA. Вместо этого уведомляется о более низкой скорости передачи данных, которая может поддерживаться
if (новое резервирование требуется)
ResvTime
1. Заново вычислить на основе нового назначения короткого кода Уолша.
ResvTime,
StartResvTime
CurrentTime + 1/2RTT + Guard Time
EndResvTime
StartResvTime
ResvTime.
2. Назначить короткий код Уолша CPE для начиная с = и до = +
3. Передать новое резервирование для CPE и одновременно отключить старое резервирование для CPE посредством сигнального сообщения.
endif
endif
Пятый вариант осуществления (фиг.6).
Некоторые из принципов четвертого варианта осуществления также могут быть использованы в связи с "всегда активным" подканалом канала, описанного со ссылкой на третий вариант осуществления. Шлюз может принять решение о том, "занят" ли терминал, на основе Q-состояния терминала и обновить терминал для того, чтобы использовать "всегда активный" подканал ориентированного на резервирование канала все время, пока он занят.
На фиг.6 блок-схема последовательности операций иллюстрирует этапы примерной реализации пятого варианта осуществления, при этом этап 600 иллюстрирует начало процесса.
Этап 610 иллюстрирует передачу терминалом узлу (шлюзу) Q-состояния терминала (загрузки выходного буфера). Эта передача осуществляется либо по RACH (при условии, что терминал в данный момент не имеет разрешения для того, чтобы передавать по RESCH), либо по RESCH (при условии, что терминал в данный момент имеет разрешение для того, чтобы передавать по RESCH).
Этап 620 иллюстрирует решение о том, "занят" ли или нет терминал. Определение "занятости" зависит от конкретной реализации сети, особенно от используемого протокола. Терминал может считаться "занятым", если считается, что пользователь активно участвует во взаимодействии с терминалом способом, который приводит к обмену данными по линии связи в объеме или типа, превышающего значение для простого "фонового" обмена данными. Этап 620, в сущности, такой же, что и этап 420 (фиг.4), и его подробное описание не приводится повторно.
Этап 630 иллюстрирует, что если терминал считается незанятым, назначение всех кодов Уолша для "всегда активного" подканала, ориентированного на резервирование подканала, отменяется (они аннулируются). Если ни одного кода Уолша не назначено до этого терминалу, этап 630 не выполняет никакого действия. Об аннулировании кода Уолша сообщается терминалу, который затем выполняет передачу по RACH, как указано на этапе 632.
Наоборот, этап 640 иллюстрирует, что если терминал считается занятым, код Уолша для "всегда активного" подканала, ориентированного на резервирование подканала, назначается терминалу. Если код Уолша до этого назначен терминалу, то этап 640 не выполняет никакого действия, и предыдущее назначение кода Уолша остается в силе. Любое новое назначение кода Уолша сообщается терминалу, который затем выполняет передачу по RESCH, как указано на этапе 642.
После этапов 632 и 642 управление передается обратно аналитическому этапу 610. Таким образом, анализ загрузки выходного буфера терминала и последующее определение того, занят ли или нет терминал и передает ли терминал по RACH или по RESCH, может проводиться постоянно.
Кроме того, для описанных в данном документе способов предусмотрены компьютерные программные продукты (такие как носители данных), хранящие программные инструкции для исполнения в вычислительной системе, имеющей, по меньшей мере, одно устройство обработки данных, инструкции которого, когда исполняются вычислительной системой, предписывают вычислительной системе выполнять описанные в данном документе способы.
Дополнительно предусмотрены системы для выполнения описанных в данном документе способов, причем эти системы включают в себя, по меньшей мере, одно из терминала (или находящегося у заказчика оборудования) и узла (такого как шлюз). Терминалы и узлы (или шлюзы) и т.п. могут быть легко реализованы специалистами в данной области техники. Как правило, эти элементы могут быть реализованы как какие-либо соответствующие вычислительные машины, использующие технологию, о которой известно специалистам в данной области техники, что она подходит для выполняемых функций. Терминал или узел может быть реализован с помощью традиционной вычислительной машины (компьютера) общего назначения, запрограммированной согласно вышеописанным принципам, как должно быть очевидно специалистам в области вычислительной техники. Соответствующее программное обеспечение может легко быть подготовлено программистами обычной квалификации на основе принципов настоящего изобретения, как должно быть очевидно специалистам в области вычислительной техники. Могут быть выбраны другие подходящие языки программирования, работающие с другими доступными операционными системами.
Вычислительные машины общего назначения могут реализовывать вышеописанные способы, при этом корпус вычислительной машины может содержать ЦП (центральный процессор), память, такую как ДОЗУ (динамическое оперативное запоминающее устройство), ПЗУ (постоянное запоминающее устройство), СППЗУ (стираемое программируемое постоянное запоминающее устройство), ЭСППЗУ (электрически стираемое программируемое постоянное запоминающее устройство), СОЗУ (статическое оперативное запоминающее устройство), СДОЗУ (синхронное динамическое оперативное запоминающее устройство) и флэш-ОЗУ, а также другие логические устройства специального назначения, такие как ASIC (специализированные интегрированные схемы), или конфигурируемые логические устройства, такие как GAL (типовая матричная логика) и программируемые матричные БИС (программируемые пользователем матричные БИС).
Каждая вычислительная машина также может включать в себя множество устройств ввода (например, клавиатуру, микрофон и мышь) и контроллер дисплея для управления монитором. Помимо этого, вычислительная машина может включать в себя дисковод для гибких дисков; другие съемные носители (например, компакт-диск, лента и сменные магнитооптические носители); и жесткий диск или другие фиксированные накопители на носителях с высокой плотностью, подключенные с помощью соответствующей шины устройства, такой как шина SCSI (системный интерфейс малых ЭВМ), усовершенствованная шина IDE (встроенный интерфейс накопителей) или шина Ultra DMA (прямой доступ к памяти). Вычислительная машина также может включать в себя устройство считывания компакт-дисков, устройство чтения-записи компакт-дисков или накопитель с автоматической сменой компакт-дисков, который может быть подключен к такой же шине устройства или другой шине устройства.
Как указано выше, система включает в себя, по меньшей мере, один машиночитаемый носитель. Примеры машиночитаемых носителей включают в себя компакт-диски, жесткие диски, гибкие диски, ленту, магнитооптические диски, ППЗУ (например, СППЗУ, ЭСППЗУ, флэш-СППЗУ), ДОЗУ, СОЗУ, СДОЗУ.
Программное обеспечение для управления аппаратными средствами вычислительной машины и предоставления возможности вычислительной машине взаимодействовать с пользователем, чтобы выполнять вышеописанные функции, сохраняется на любом или сочетании машиночитаемых носителей. Такое программное обеспечение может включать в себя, но не только, пользовательские приложения, драйверы устройств, операционные системы, средства разработчиков и т.п.
Эти машиночитаемые носители дополнительно включают в себя компьютерный программный продукт, включающий в себя машиноисполняемый код или машиноисполняемые инструкции, которые при выполнении предписывают вычислительной машине выполнять вышеописанные способы. Кодом вычислительной машины может быть любой интерпретируемый или исполняемый код, в том числе, но не только, сценарии, интерпретаторы, динамические подключаемые библиотеки, Java-классы, законченные исполняемые программы и т.п.
Специалистам в данной области техники из вышеописанного должно быть очевидно, что предусмотрено множество способов, систем, вычислительных программ на носителях записи и т.п.
Например, на основе фиг.3 в системе связи множественного доступа с кодовым разделением каналов (CDMA), включающей в себя множество терминалов, которые обмениваются данными с узлом посредством, по меньшей мере, канала произвольного доступа и ориентированного на резервирование канала, предусмотрен способ управления трафиком в канале произвольного доступа и ориентированном на резервирование канале. Способ включает в себя сравнение с, по меньшей мере, одним критерием, характеристик трафика, в котором передаются данные от данного терминала. Если характеристики трафика удовлетворяют этому, по меньшей мере, одному критерию, способ включает в себя отправку запроса на резервирование полосы пропускания; обработку запроса на резервирование полосы пропускания и разрешение по нему; передачу разрешения по запросу на резервирование полосы пропускания заданному терминалу; и предписание заданному терминалу передавать данные по ориентированному на резервирование каналу. Если характеристики трафика не удовлетворяют упомянутому, по меньшей мере, одному критерию, способ включает в себя предписание заданному терминалу передавать данные по каналу произвольного доступа.
Канал произвольного доступа может быть сконфигурирован так, чтобы разрешать терминалам передавать данные по каналу произвольного доступа в моменты времени, которые не были до этого назначены, а ориентированный на резервирование канал может передавать данные на более высокой общей скорости передачи данных, чем канал произвольного доступа.
Терминалами может быть находящееся у заказчика оборудование (CPE), а узлом может быть шлюз, связывающий множество CPE с Интернетом посредством сети спутниковой связи.
Данный терминал может передавать запрос на резервирование полосы пропускания, узел может обрабатывать и предоставлять разрешение по запросу на резервирование полосы пропускания, и предоставление разрешения по запросу на резервирование полосы пропускания передается от узла данному терминалу.
Канал произвольного доступа может передавать данные на основе асинхронного множественного доступа с кодовым разделением каналов (ACDMA), а ориентированный на резервирование канал может передавать данные на основе ортогонального множественного доступа с кодовым разделением каналов (OCDMA).
Упомянутый, по меньшей мере, один критерий может включать в себя пороговый размер пакета, а этап сравнения может включать в себя сравнение порогового размера пакета с размером пакета, который характеризует пакеты, в которых данные должны передаваться от заданного терминала.
Упомянутый, по меньшей мере, один критерий может включать в себя пороговую скорость передачи данных, а этап сравнения может включать в себя сравнение пороговой скорости передачи данных со средней скоростью передачи данных, вычисленной за временной интервал, которая характеризует пакеты, в которых данные должны передаваться от заданного терминала.
Упомянутый, по меньшей мере, один критерий может включать в себя указание типа пакета, а этап сравнения может включать в себя сравнение указания типа пакета с типами пакетов, которые характеризуют пакеты, в которых данные должны передаваться от заданного терминала.
В качестве еще одного примера, на основе фиг.4 в системе связи множественного доступа с кодовым разделением каналов (CDMA), включающей в себя множество терминалов, которые обмениваются данными с узлом посредством, по меньшей мере, канала произвольного доступа и ориентированного на резервирование канала, предусмотрен способ управления трафиком в канале произвольного доступа и ориентированном на резервирование канале. Способ включает в себя a) сравнение с, по меньшей мере, одним критерием характеристик трафика, в котором данные передаются от заданного терминала для получения результата исследования, и b) определение на основе результата исследования того, находится ли этот заданный терминал в занятом состоянии. Если определено, что заданный терминал находится в занятом состоянии, способ включает в себя назначение заданному терминалу кода, обозначающего ориентированный на резервирование подканал; и предписание заданному терминалу передавать данные по ориентированному на резервирование подканалу. Но если определено, что заданный терминал не находится в занятом состоянии, способ включает в себя предписание заданному терминалу передавать данные по каналу произвольного доступа.
Этап назначения кода может включать в себя назначение кода Уолша заданному терминалу.
Канал произвольного доступа может быть сконфигурирован так, чтобы разрешать терминалам передавать данные по каналу произвольного доступа в моменты времени, которые не были до этого назначены, а ориентированный на резервирование канал может передавать данные на более высокой общей скорости передачи данных, чем канал произвольного доступа.
Терминалами может быть находящееся у заказчика оборудование (CPE), а узлом может быть шлюз, связывающий множество CPE с Интернетом посредством сети спутниковой связи.
Канал произвольного доступа может передавать данные на основе асинхронного множественного доступа с кодовым разделением каналов (ACDMA), а ориентированный на резервирование канал может передавать данные на основе ортогонального множественного доступа с кодовым разделением каналов (OCDMA).
Упомянутый, по меньшей мере, один критерий может включать в себя пороговый размер пакета, а этап сравнения может включать в себя сравнение порогового размера пакета с размером пакета, который характеризует пакеты, в которых данные должны передаваться от заданного терминала.
Упомянутый, по меньшей мере, один критерий может включать в себя пороговую скорость передачи данных, а этап сравнения может включать в себя сравнение пороговой скорости передачи данных со средней скоростью передачи данных, вычисленной за временной интервал, которая характеризует пакеты, в которых данные должны передаваться от заданного терминала.
Упомянутый, по меньшей мере, один критерий может включать в себя указание типа пакета, а этап сравнения может включать в себя сравнение указания типа пакета с типами пакетов, которые характеризуют пакеты, в которых данные должны передаваться от заданного терминала.
В качестве еще одного примера, на основе фиг.5A в системе связи множественного доступа с кодовым разделением каналов (CDMA), включающей в себя множество терминалов, которые обмениваются данными с узлом посредством, по меньшей мере, канала произвольного доступа и ориентированного на резервирование канала, предусмотрен способ управления трафиком в канале произвольного доступа и ориентированном на резервирование канале. Способ включает в себя анализ степени загрузки выходного буфера заданного терминала для получения Q-состояния, и сравнение порога с Q-состоянием заданного терминала. Если Q-состояние больше порога, способ включает в себя назначение заданному терминалу кода, обозначающего ориентированный на резервирование подканал; и предписание заданному терминалу передавать данные по ориентированному на резервирование подканалу. Если Q-состояние меньше порога, способ включает в себя предписание заданному терминалу передавать данные по каналу произвольного доступа.
Способ может дополнительно включать в себя передачу Q-состояния по каналу произвольного доступа.
Канал произвольного доступа может быть сконфигурирован так, чтобы разрешать терминалам передавать данные по каналу произвольного доступа в моменты времени, которые не были до этого назначены, а ориентированный на резервирование канал может передавать данные на более высокой общей скорости передачи данных, чем канал произвольного доступа.
Терминалами может быть находящееся у заказчика оборудование (CPE), а узлом может быть шлюз, связывающий множество CPE с Интернетом посредством сети спутниковой связи.
Канал произвольного доступа может передавать данные на основе асинхронного множественного доступа с кодовым разделением каналов (ACDMA), а ориентированный на резервирование канал может передавать данные на основе ортогонального множественного доступа с кодовым разделением каналов (OCDMA).
На основе фиг.5B способ может дополнительно включать в себя, после предписания заданному терминалу передавать данные по ориентированному на резервирование подканалу, анализ предыстории, по меньшей мере, одного Q-состояния заданного терминала для получения результата анализу предыстории Q-состояния; и на основе, по меньшей мере, частично результата анализа предыстории Q-состояния, выбор и выполнение этапа из группы, включающей в себя: (i) назначение заданному терминалу первого кода, обозначающего более быстрый ориентированный на резервирование подканал, работающий на более высокой скорости передачи данных, чем текущая скорость передачи данных; (ii) назначение заданному терминалу второго кода, обозначающего ориентированный на резервирование подканал той же скорости, работающий на той же скорости передачи данных, что и текущая скорость передачи данных; (iii) назначение заданному терминалу третьего кода, обозначающего более медленный ориентированный на резервирование подканал, работающий на менее высокой скорости передачи данных, чем текущая скорость передачи данных; или (iv) аннулирование на заданном терминале любого кода, обозначающего какой-либо ориентированный на резервирование подканал.
Первый, второй и третий коды могут быть последовательно большими кодами Уолша, обозначающими соответствующие ориентированные на резервирование подканалы, работающие на соответствующих последовательно меньших скоростях передачи данных.
Способ может дополнительно включать в себя передачу Q-состояния по ориентированному на резервирование каналу.
Канал произвольного доступа может быть сконфигурирован так, чтобы разрешать терминалам передавать данные по каналу произвольного доступа в моменты времени, которые не были до этого назначены, а ориентированный на резервирование канал может передавать данные на более высокой общей скорости передачи данных, чем канал произвольного доступа.
Терминалами может быть находящееся у заказчика оборудование (CPE), а узлом может быть шлюз, связывающий множество CPE с Интернетом посредством сети спутниковой связи.
Канал произвольного доступа может передавать данные на основе асинхронного множественного доступа с кодовым разделением каналов (ACDMA), а ориентированный на резервирование канал может передавать данные на основе ортогонального множественного доступа с кодовым разделением каналов (OCDMA).
В качестве дополнительного примера, на основе фиг.6 в системе связи множественного доступа с кодовым разделением каналов (CDMA), включающей в себя множество терминалов, которые обмениваются данными с узлом посредством, по меньшей мере, канала произвольного доступа и ориентированного на резервирование канала, предусмотрен способ управления трафиком в канале произвольного доступа и ориентированном на резервирование канале. Способ включает в себя анализ степени загрузки выходного буфера заданного терминала для получения Q-состояния и определение на основе, по меньшей мере частично, Q-состояния того, находится ли этот заданный терминал в занятом состоянии. Если определено, что заданный терминал находится в занятом состоянии, способ включает в себя назначение заданному терминалу кода, обозначающего ориентированный на резервирование подканал; и предписание заданному терминалу передавать данные по ориентированному на резервирование подканалу. Но если определено, что заданный терминал не находится в занятом состоянии, предписание заданному терминалу передавать данные по каналу произвольного доступа.
Кодом может быть код Уолша, обозначающий ориентированный на резервирование канал.
Канал произвольного доступа может быть сконфигурирован так, чтобы разрешать терминалам передавать данные по каналу произвольного доступа в моменты времени, которые не были до этого назначены, а ориентированный на резервирование канал может передавать данные на более высокой общей скорости передачи данных, чем канал произвольного доступа.
Терминалами может быть находящееся у заказчика оборудование (CPE), а узлом может быть шлюз, связывающий множество CPE с Интернетом посредством сети спутниковой связи.
Канал произвольного доступа может передавать данные на основе асинхронного множественного доступа с кодовым разделением каналов (ACDMA), а ориентированный на резервирование канал может передавать данные на основе ортогонального множественного доступа с кодовым разделением каналов (OCDMA).
Компьютерные программные продукты предусмотрены для хранения программных инструкций для исполнения в компьютерной системе, имеющей, по меньшей мере, одно устройство обработки данных, инструкции которого, когда исполняются компьютерной системой, предписывают компьютерной системе выполнять вышеописанные способы.
Предусмотрены компьютерные системы, которые сконфигурированы так, чтобы выполнять вышеописанные способы.
Предшествующие варианты осуществления являются просто примерами и не должны рассматриваться как ограничивающие изобретение. Настоящие принципы могут легко применяться к другим типам устройств. Описание вариантов осуществления предназначено быть иллюстративным и не ограничивать объем, определяемый формулой изобретения. Множество альтернатив, модификаций и вариаций должно быть очевидно специалистам в данной области техники.
Множество модификаций и вариаций настоящего изобретения возможны в свете вышеизложенных принципов. Например, конкретная реализация программного обеспечения, терминалов и узлов функции управления трафиком может отличаться без отступления от объема изобретения. Разумеется, конкретная аппаратная или программная реализация изобретения может отличаться без отступления от объема настоящего изобретения. Поэтому следует понимать, что в рамках объема, определенного формулой изобретения и ее эквивалентами, изобретение может быть использовано на практике иными способами, чем конкретно описанные в данном документе.