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

Заявлены средство и способ адаптивного управления задержкой для распределения ресурсов с различными требованиями к качеству обслуживания (QoS). Техническим результатом является создание адаптивного управления задержкой для планирования передач в системе связи. Для этого планировщик прямой линии связи (FL) подготавливает экземпляры передачи посредством обработки очередей ожидающих данных в соответствии с классом приоритета, таким как «наилучшее усилие» (BE) и «срочная пересылка» (EF). Биты данных из многих очередей вставляются в экземпляр передачи. Различные метрики используются для формирования набора кандидатов для передачи и последующего выбора и создания следующего экземпляра передачи на основании набора кандидатов. 2 н. и 2 з.п. ф-лы, 15 ил., 1 табл.

 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

В системе с коммутацией пакетов, или системе с совместно используемыми пакетными данными, может использоваться услуга передачи речи поверх протокола Интернет (VoIP), чтобы эмулировать (имитировать) передачу речи с коммутацией пакетов. VoIP обычно является чувствительным к задержке приложением или услугой, и, следовательно, используются механизмы качества обслуживания (КО, QoS), чтобы удовлетворять ограничениям задержки на доставку пакета. Другие услуги и типы передач также имеют различные требования к задержке или цели (целевые установки), чтобы обеспечивать QoS. Соответственно, имеется необходимость в адаптивном управлении задержкой для планирования передач в системе связи.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1A - система беспроводной связи.

Фиг. 1B - система беспроводной связи с поддержкой высокоскоростной передачи данных.

Фиг. 2 - блок-схема сети доступа (СД, AN) в системе беспроводной связи.

Фиг. 3 - схема последовательности операций алгоритма планирования для передач в системе беспроводной связи.

Фиг. 4 - иллюстрация классификации планировщиков передачи пакетных данных.

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

Фиг. 6 - иллюстрация поведения планировщика при наличии пользователей только срочной пересылки (EF) при типе одиночного трафика.

Фиг. 7 - иллюстрация вычисления сжатого многочлена c(z) полезной нагрузки на основании многочлена p(z) полезной нагрузки.

Фиг. 8 - иллюстрация планировщика в соответствии с одним вариантом осуществления.

Фиг. 9 - иллюстрация части планировщика по Фиг. 8 в соответствии с одним вариантом осуществления.

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

Фиг. 11 - иллюстрация части алгоритма планирования по Фиг. 10 в соответствии с одним вариантом осуществления.

Фиг. 12 - иллюстрация части алгоритма планирования по Фиг. 10 в соответствии с одним вариантом осуществления.

Фиг. 13 - иллюстрация части алгоритма планирования по Фиг. 10 в соответствии с одним вариантом осуществления.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

Нижеследующее обсуждение относится к алгоритму планирования, предназначенному для прямой линии связи (FL), для системы, поддерживающей действие стандарта 1xEV-DO, то есть поддерживающей технические условия стандарта IS-856. В одном варианте осуществления алгоритм планирования пользуется преимуществом различных многопользовательских пакетов и коротких пакетов, чтобы выполнять требования качества QoS для различных приложений, пытаясь при этом максимизировать емкость (пропускную способность) FL. Алгоритм планирования также обеспечивает механизмы назначения приоритетов различным приложениям. Такое назначение приоритета может быть основано на типе потока данных приложения, конкретных требованиях QoS или других характеристиках потока. В одном варианте осуществления потоки планируются для передачи по FL на основании чувствительности приложения к задержке. В одном аспекте потоки различаются на основании чувствительности к задержке в сопоставлении с чувствительностью к пропускной способности. Тогда как нижеследующее обсуждение рассматривает средства и способы планирования в виде осуществленных в контексте редакции Revision A технического описания 1xEV-DO, средства и способы планирования являются дополнительно применимыми к альтернативным системам, в частности принципы применимы к системам, в которых пользователи являются совместимыми с заданным подмножеством подтипов, как определено в описании стандарта IS-856, конкретно "cdma2000 High Rate Packet Data Air Interface Specification" (Описание радио-интерфейса высокоскоростных пакетных данных для системы МДКР cdma2000), в документе Проекта 2 партнерства систем связи 3-го поколения (3GPP2) C.S0024 Ver. 4.0, октябрь 2002.

В нижеследующем описании термины, такие как "пользователь Rev-A " или "совместимый с Rev-A пользователь", будут использоваться для ссылки на терминал доступа (ТД, AT) с поддержкой подтипов протокола уровня канала доступа к среде передачи (КДС, MAC (Medium Access Channel)) и физического уровня, определенных в IS-S56, конкретно в документе "cdma2000 High Rate Packet Data Air Interface Specification" 3GPP2 C.S0024-A, Версия 1.0, март 2004. В частности, пользователь Rev-A поддерживает расширенный протокол MAC для прямого информационного канала. Термины, такие как "пользователи Rel-0", используются для ссылки на AT, поддерживающие подтипы протокола уровня MAC и физического уровня, определенные в IS-856, но которые не поддерживают более новые подтипы, определенные в редакции Revision A.

В системе беспроводной связи с использованием схемы множественного доступа с кодовым разделением каналов (МДКР, CDMA) один способ планирования выделяет каждому из устройств абонента все кодовые каналы в намеченные временные интервалы на основе временного мультиплексирования. Центральный узел связи, такой как базовая станция (БС, BS), обеспечивает реализацию связываемой с абонентом уникальной частоты несущей или кода канала, чтобы предоставлять возможность монопольного взаимодействия с абонентом. Схемы множественного доступа с временным разделением каналов (МДВР, TDMA) также могут быть осуществлены в системах наземных линий связи, использующих физическое переключение контактных реле или коммутацию пакетов (пакетную коммутацию). Система CDMA может быть спроектирована, чтобы поддерживать один или несколько стандартов, таких как: (1) " TIA/EIA/IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" (Стандарт IS-95-B Ассоциации промышленности средств связи/Ассоциации электронной промышленности совместимости «мобильная станция-базовая станция» для двухрежимной широкополосной системы сотовой связи с расширением спектра), который упоминается в документе как стандарт IS-95; (2) стандарт, предложенный консорциумом, именуемым «Проект партнерства систем связи 3-го поколения», упоминаемым в документе как 3GPP и реализованным в наборе документов, включающим в состав документы с порядковыми номерами 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, и 3G TS 25.214, 3G TS 25.302, упоминаемыми в документе как стандарт W-CDMA (широкополосный МДКР); 3) стандарт, предложенный консорциумом, именуемым «Проект 2 партнерства систем связи 3-го поколения», упоминаемым в документе как 3GPP2, и TR-45.5, упоминаемым в документе как стандарт cdma2000, прежде именованным IS-2000 MC, или (4) некоторый другой стандарт беспроводной связи.

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

Фиг. 1A используется в качестве примера системы 100 связи, поддерживающей множество пользователей и способной осуществлять по меньшей мере некоторые аспекты и исполнения изобретения. Может использоваться любой из множества алгоритмов и способов, чтобы планировать передачи в системе 100. Система 100 обеспечивает связь для множества сотовых ячеек 102A-102G, каждая из которых обслуживается соответствующей базовой станцией 104A-104G соответственно. В примерном варианте осуществления некоторые из базовых станций 104 имеют многие приемные антенны, а другие имеют только одну приемную антенну. Подобным образом некоторые из базовых станций 104 имеют многие передающие антенны, а другие имеют одиночную передающую антенну. Не имеется ограничений на комбинации из передающих антенны и приемных антенн. Следовательно, для базовой станции 104 является возможным иметь многие передающие антенны и одиночную приемную антенну или иметь многие приемные антенны и одиночную передающую антенну, или иметь и одиночные, и многие передающие и приемные антенны.

Возрастающий спрос на беспроводную передачу данных и расширение услуг, доступных через технологию беспроводной связи, привело к развитию специальных услуг передачи данных. Одна такая услуга именуется «высокоскоростной передачей данных» (ВПД, HDR). Примерная услуга HDR, предложенная в документе "EIA/TIA-ISS56 cdma2000 High Rate Packet Data Air Interface Specification" (Техническое описание радио-интерфейса высокоскоростной передачи пакетных данных), именуется "техническим описанием HDR". Услуга HDR является обычно «наложением» на систему речевой связи, которое обеспечивает эффективный способ передачи пакетов данных в системе беспроводной связи. Если объем передаваемых данных и количество передач увеличиваются, доступная для радиопередач ограниченная полоса частот становится критическим ресурсом.

На Фиг. 1B иллюстрируется структурная эталонная модель для системы 120 связи с наличием сети 122 доступа (СД, AN), взаимодействующей с терминалом 126 доступа (ТД, AT) через радио-интерфейс 124. В одном варианте осуществления система 10 является системой множественного доступа с кодовым разделением каналов (МДКР, CDMA), системой с наличием «наложенной» системы высокоскоростной передачи данных, HDR, такой как задает стандарт HDR. AN 122 взаимодействует с AT 126, а так же как с любыми другими AT в пределах системы 120 (не показано), посредством радио-интерфейса 124. AN 122 включает в себя многие секторы, причем каждый сектор обеспечивает по меньшей мере один канал. Канал определен в виде набора линий связи для передач между AN 122 и многими AT в рамках заданного назначения частот. Канал состоит из прямой линии связи (ПЛС, FL) для передач от AN 122 в AT 126 и обратной линии связи (ОЛС, RL) для передач от AT 126 в AN 122.

Для передач данных AN 122 принимает от AT 126 запрос данных. Запрос данных указывает скорость передачи, на которой должны посылаться данные, длительность передаваемого пакета данных и сектор, из которого должны посылаться данные. AT 126 определяет скорость передачи на основании качества канала между AN 122 и AT 126. В одном варианте осуществления качество канала определяется согласно отношению (Н/П, C/I) мощности несущей к уровню помехи. Альтернативные варианты осуществления могут использовать другие метрики, соответствующие качеству канала. AT 126 поставляет запросы передач данных путем посылки сообщения «управление скоростью передачи» (УСП, DRC) через особый канал, именуемый как «канал DRC». Сообщение DRC включает в себя порцию скорости передачи данных и порцию сектора. Порция скорости передачи данных указывает запрошенную скорость передачи для AN 122, чтобы посылать данные, и порция сектора указывает сектор, из которого AN 122 должен посылать данные. Информация и о скорости передачи данных, и о секторе обычно требуется, чтобы обрабатывать передачу данных. Порция скорости передачи данных именуется «значение DRC», и порция сектора именуется «покрытие DRC» (маскирование). Значение DRC является сообщением, посылаемым на AN 122 через радио-интерфейс 124. В одном варианте осуществления каждое значение DRC соответствует скорости передачи данных в Кбит/с (килобит в секунду), имеющей связанный размер пакета в соответствии с заранее установленным заданием значений DRC. Задание включает в себя значение DRC, указывающее нулевую скорость передачи данных. На практике, нулевая скорость передачи данных указывает AN 122, что AT 126 не является способным принимать данные. В некоторой ситуации, например, качество канала является недостаточным, чтобы AT 126 принимал данные безошибочно.

В ходе действия AT 126 непрерывно осуществляет мониторинг (текущий контроль) качества канала, чтобы вычислять скорость передачи данных, на которой AT 126 способен принимать следующую передачу пакета данных. AT 126 затем формирует соответствующее значение DRC; значение DRC передается на AN 122, чтобы запросить передачу данных. Следует отметить, что обычно передачи данных разделяются на пакеты. Время, требуемое для передачи пакета данных, является функцией примененной скорости передачи данных.

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

Один пример системы связи, поддерживающей передачи HDR и приспособленной для планирования передач многим пользователям, проиллюстрирован на Фиг. 2. Фиг. 2 подробно описывается ниже в документе, причем конкретно базовая станция 820 и контроллер 810 базовой станции сопрягаются с интерфейсом 806 сети с коммутацией пакетов. Контроллер 810 базовой станции включает в себя планировщик 812 канала, чтобы осуществлять алгоритм планирования для передач в системе 800. Планировщик 812 канала определяет длительность интервала обслуживания, в течение которого данные должны быть переданы на любую конкретную удаленную станцию, на основании связанной мгновенной скорости удаленной станции для приема данных (как указано в последнем по времени принятом сигнале DRC). Интервал обслуживания может не быть непрерывным во времени, а может происходить один раз каждые n временных интервалов (слотов). В соответствии с одним вариантом осуществления, первая порция пакета передается в течение первого временного интервала в первый раз (первично), и вторая порция передается на 4 временных интервала позже в последующий раз. Также любые последующие порции пакета передаются во многих временных интервалах, имеющих сходную протяженность в 4 временных интервала, то есть отстоящих друг от друга на 4 временных интервала. В соответствии с вариантом осуществления, мгновенная скорость для приема данных Ri определяет длительность Li интервала обслуживания, связанную с конкретной очередью данных.

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

Контроллер 810 базовой станции сопрягается с интерфейсом 806 сети с коммутацией пакетов, с коммутируемой телефонной сетью 808 общего пользования (КТСОП, PSTN) и базовыми станциями в системе связи (на Фиг. 3 для простоты показывается только одна базовая станция 820). Контроллер 810 базовой станции координирует взаимодействие между удаленными станциями в системе связи и другими пользователями, соединенными с интерфейсом 806 сети с коммутацией пакетов и PSTN 808. PSTN 808 сопрягается с пользователями через стандартную телефонную сеть (не показано на Фиг. 3).

Контроллер 810 базовой станции содержит много селекторных элементов 816, хотя для простоты только один показан на Фиг. 2. Каждый селекторный элемент 816 выделяется для управления взаимодействием (передачей информации) между одной или несколькими базовыми станциями 820 и одной удаленной станцией (не показано). Если селекторный элемент 816 не был выделен данной удаленной станции, процессор 818 управления вызовом информируется о необходимости послать сообщение удаленной станции. Процессор 818 управления вызовом затем предписывает базовой станции 820 послать сообщение удаленной станции.

Источник 802 данных содержит объем данных, который должен быть передан на заданную удаленную станцию. Источник 802 данных поставляет данные на интерфейс 806 сети с коммутацией пакетов. Интерфейс 806 сети с коммутацией пакетов принимает данные и маршрутизирует данные на селекторный элемент 816. Селекторный элемент 816 затем передает данные на каждую базовую станцию 820 во взаимодействии с целевой удаленной станцией. В примерном варианте осуществления каждая базовая станция 820 поддерживает очередь 830 данных, которая хранит данные, подлежащие передаче на удаленную станцию.

Данные передаются на канальный элемент 826 в виде пакетов данных из очереди 830 данных. В примерном варианте осуществления, на прямой линии связи "пакет данных" относится к количеству данных, которым является максимально 1024 битов, и количеству данных, подлежащих передаче на удаленную станцию-получатель в пределах заранее установленного "временного интервала" (≈1,667 мс). Для каждого пакета данных канальный элемент 826 вставляет необходимые управляющие поля. В примерном варианте осуществления канальный элемент 826 выполняет контроль циклическим избыточным кодом (циклический избыточный код, ЦИК, CRC), кодируя пакет данных и управляющие поля, и вставляет набор кодовых концевых комбинаций битов. Пакет данных, управляющие поля, биты CRC контроля по четности и кодовая концевая комбинация битов составляют отформатированный пакет. В примерном варианте осуществления канальный элемент 826 затем кодирует отформатированный пакет и перемежает (или переупорядочивает) символы внутри кодированного пакета. В примерном варианте осуществления перемеженный пакет маскируется (покрывается) с помощью кода Уолша и расширяется с помощью коротких кодов PNI (псевдошумовой синфазной последовательности) и PNQ (псевдошумовой квадратурной последовательности). Расширенные данные подаются на блок 828 радиочастоты (РЧ, RF), который квадратурно модулирует, фильтрует и усиливает сигнал. Сигнал прямой линии связи передается по эфиру через антенну на прямую линию связи.

На удаленной станции сигнал прямой линии связи принимается посредством антенны и направляется на приемник. Приемник фильтрует, усиливает, квадратурно демодулирует и квантует сигнал. Оцифрованный сигнал подается на демодулятор (DEMOD), где его сжимают (осуществляют обратное расширение) с помощью коротких кодов PNI и PNQ последовательностей и демаскируют с помощью покрытия Уолша. Демодулированные данные поставляются на декодер, который выполняет инверсию функций обработки сигнала, выполненных на базовой станции 820, конкретно обратное перемежение, декодирование и функции проверки CRC. Декодированные данные подаются на приемник данных.

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

Сигнал DRC, передаваемый каждой удаленной станцией, проходит через канал обратной связи и принимается на базовой станции 820 через приемную антенну, соединенную с блоком 828 RF. В примерном варианте осуществления информация DRC демодулируется в канальном элементе 826 и поставляется на планировщик 812 канала, расположенный в контроллере 810 базовой станции, или планировщик 832 канала, расположенный в базовой станции 820. В первом примерном варианте осуществления планировщик 832 канала расположен в базовой станции 820. В альтернативном варианте осуществления планировщик 812 канала расположен в контроллере 810 базовой станции и соединен с селекторными элементами 816 внутри контроллера 810 базовой станции.

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

Планирование передачи в системе с коммутацией пакетов в соответствии с одним вариантом осуществления составляет баланс объема нагрузки в зависимости от задержки пользователя. Потоки приложений передаются в виде дейтаграмм, которые являются независимыми автономными сообщениями, посылаемыми по сети. Поступление дейтаграммы, время поступления и содержимое обычно не гарантируются. Дейтаграммы, связанные с одним и тем же потоком приложения, могут передаваться одному и тому же пользователю по различным маршрутам. Дейтаграммы повторно собирают в приемнике. Сквозная задержка в системе с коммутацией пакетов не является фиксированной, и, следовательно, планировщик может использовать такую разность в задержке и регулировать задержку для различных пользователей, чтобы повысить емкость. Например, планировщик может уменьшить задержку, на практике испытываемую пользователями, запрашивающими данные с наличием низких предельных значений задержки и/или пределов изменения задержки. Такие приложения включают в себя, но не являются ограниченными таковыми, VoIP, видео, и т.д. Передачи могут иметь конкретный класс (уровень) качества обслуживания (ККО, GoS) или требование(я) QoS. Взаимодействие для типа VoIP, например, требует, чтобы пакеты поступали с наличием заданного времени ожидания или в пределах допустимого времени задержки. Следовательно, может быть желательным назначать приоритеты таким взаимодействиям или приложениям с наличием требования более низкого времени ожидания или другого описания(ий) GoS. Мультимедийная конференцсвязь, потоковое видео, просмотр сети Интернет, передачи по протоколу передачи файлов, каждое имеет конкретные требования GoS.

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

PF=f(задержка),

причем f() является функцией, и PF затем определяется на основании требования к задержке для данного пользователя или данного приложения, предназначенного для пользователя. PF вычисляется для каждой дейтаграммы в каждой очереди; различные PF сравниваются, чтобы идентифицировать экземпляры потока с более высоким приоритетом. Передача информации с коммутацией пакетов позволяет, чтобы планирование включало в состав адаптивное управление задержкой, поскольку сквозная задержка для данной передачи не является фиксированной. Это является отличием от передачи с коммутацией каналов, в которой сквозная задержка является фиксированной.

Следует отметить, что нижеследующее обсуждение рассматривает систему cdma2000, поддерживающую услуги высокоскоростной передачи пакетных данных (ВППД, HRPD), как описано в IS-856. Эта система используется в качестве примера. Настоящее изобретение является применимым к другим системам, в которых пользователей выбирают для обслуживания в соответствии с алгоритмом планирования.

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

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

ГЛОССАРИЙ

Сеть доступа (СД, AN) - сетевое оборудование, обеспечивающее связность данных между сетью сотовой связи и сетью передачи данных с коммутацией пакетов (обычно Интернет) и несколькими AT. AN в системе HRPD является эквивалентом базовой станции в системе сотовой связи.

Терминал доступа (ТД, AT) - устройство, обеспечивающее связность данных для пользователя. AT в системе HRPD соответствует мобильной станции в системе сотовой связи. AT может быть соединенным с вычислительным устройством, таким как портативный персональный компьютер, или может быть автономным устройством данных, таким как персональный цифровой ассистент (ПЦА, PDA).

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

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

Автоматический запрос (АЗПП, ARQ) повторной передачи - механизм, посредством которого передатчик инициирует повторную передачу данных на основании появления или непоявления (отсутствия) события.

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

Пакетирование (σ) - мера разбиения на пакеты или плотности и зависимости от времени для пакетов в потоке приложения.

«Наилучшее усилие» (лучшее возможное) (BE) - потоки приложений, которые в общем имеют относительно большой объем данных для приема по радио-интерфейсу, но свойство трафика таково, что могут допускаться относительно большие задержки, но частота потери данных должна быть сверхмалой.

Управление скоростью передачи данных (DRC) - механизм, посредством которого AT передает запрашиваемую скорость данных на AN.

Недостающие биты (defbits) - количество битов, соответствующих недостающим пакетам.

DelayBound (предельное значение задержки) - заданная длительность времени, допускаемого для передачи пакета данных от AN на AT.

«Срочная пересылка» (EF) - потоки приложений обычно имеют малые объемы трафика, который поступает из Интернета на сеть доступа, однако, свойство трафика таково, что пакеты данных должны быть доставлены пользователю в пределах некоторого относительно малого значения DelayBound, с надлежащей частотой потери данных.

Прямая линия связи (FL) - канал передачи данных от AN в AT.

Пакет заголовка линии (HOL) - первый пакет в очереди.

Высокоскоростная передача пакетных данных (HRPD) - услуга передачи данных, осуществляющая передачу пакетных данных с высокой скоростью передачи. Называется также высокоскоростной передачей данных (HDR) и описывается в стандарте IS-856, озаглавленном "cdma2000 High Rate Packet Data Air Interface Specification" (Техническое описание радио-интерфейса высокоскоростной передачи пакетных данных для cdma2000).

Флуктуация - разброс во времени между принимаемыми последовательными пакетами.

Предельное значение флуктуации - ограничение на флуктуацию для данного потока приложения.

Протокол экспертной группы по вопросам движущегося изображения (MPEG) для передачи мультимедийных материалов.

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

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

Обратная линия связи (ОЛС, RL) - канал передачи от AT в AN.

Очередь передачи - очередь передачи, хранящая потоки приложений для данной базовой приемопередающей станции (BTS, БППС).

Многие беспроводные передачи информации пользуются преимуществом протокола (IP) Интернет, чтобы для обработки пакетных данных воспользоваться преимуществом различного поведения (Per Hop Behavior, PHB) на каждом участке связи (пошаговом обслуживании) и различной маршрутизации. В целом, Интернет составлен из множества сетей, созданных на основании различных технологий канального уровня, которые основываются на IP для возможности взаимодействия. IP предлагает услугу сетевого уровня без установления соединения, которая подвергается потере пакетов и задержке, которые возрастают с нагрузкой сети. Основная модель доставки по IP именуется «наилучшее усилие» (BE). Однако некоторые приложения могут требовать лучшего обслуживания, чем простое обслуживание BE. Например, приложения мультимедиа могут указывать установленную полосу частот, низкую задержку и небольшую флуктуацию. Другим типом приоритета является режим пересылки, именуемый «пересылка с подтверждением» (гарантированная пересылка) (AF), который гарантирует уровень пропускной способности.

Имеются различные аспекты в управлении QoS. Некоторыми рассматриваемыми вопросами управления QoS являются распределение полосы частот и гарантируемая полоса частот поверх совместно используемой среды передачи, известной так же, как широковещательные сети, например сеть Ethernet или беспроводная локальная вычислительная сеть (ЛВС, LAN). Наряду с этим возрастает требование включать поддержку возможностей беспроводной связи в портативные ЭВМ и другие вычислительные устройства. Однако сети беспроводной связи являются ограниченными по полосе частот, и таким образом резервирование объема ресурсов и оптимизация становятся критическими рассматриваемыми вопросами.

На Фиг. 3 иллюстрируется способ планирования, который назначает приоритеты передачам на основании класса качества обслуживания (ККС, GoS) или требований QoS. В AN данные для передачи хранятся в блоке запоминающего устройства, приспособленном для хранения очередей данных, соответствующих поступающим потокам приложений. Очередь хранится для каждого экземпляра потока приложения. В соответствии с настоящим изобретением поток приложения разделяется на экземпляры, причем каждый экземпляр является октетом данных. Следовательно, поток приложения может иметь, и обычно будет иметь, многие очереди, связанные с ним. Каждая очередь тогда имеет связанный тип приоритета QoS и/или GoS, определяемый требованиями передачи и приема. Например, тип приоритета может быть основан на требовании к сквозной задержке или на некоторых других критериях качества. Следует отметить, данная передача может попадать в один из многих типов приоритетов GoS. Например, некоторые услуги дают возможность, чтобы пакеты данных передавались индивидуально и затем повторно собирались (объединялись) в приемнике в более позднее время без потери непрерывности (последовательности пакетов), то есть тип приоритета «BE». Напротив, приложения, разработанные, чтобы предоставлять пользователю практику работы в реальном масштабе времени, например VoIP, имеют более высокоприоритетный тип и именуются как тип приоритета «срочная пересылка» (EF). Тип EF приоритета включает в себя приложения, имеющие ограничения предельного значения задержки и разброса задержки. В настоящем примере планировщик отдает предпочтение EF-передачам (с типом приоритета EF). Тип приоритета для QoS или GoS также может обозначаться как класс QoS. Кроме того, каждая очередь имеет связанную с ней чувствительность. Например, поток EF-приложения является обычно чувствительным к задержке, означая, что передача потока EF-приложения имеет требования к задержке, которые должны быть удовлетворены. Во многих случаях, если требования к задержке не удовлетворяются, данные отвергаются и не передаются. Напротив, поток BE-приложения является обычно чувствительным к пропускной способности, означая, что передача потока BE-приложения имеет целевые требования к пропускной способности, но не обязательно имеет строгие требования к задержке для потока EF-приложения.

На Фиг. 3 иллюстрируется способ 200 планирования, осуществляющий адаптивное управление задержкой в соответствии с одним вариантом осуществления. Внутри AN планировщик осуществляет алгоритм планирования, обеспечивающий передачи многим пользователям пакетных данных с высокой скоростью. Планировщик проверяет очередь данных, чтобы определить для данных тип GoS. В блок-ромбе 202 принятия решения, если какие-либо данные имеют заданный тип приоритета GoS, то есть тип приоритета, задающий более конкретные требования чем BE, то процесс переходит на этап 204, чтобы найти в очереди самые «старые» (ранние) данные самого высокоприоритетного типа. Как используется в документе, более высокий тип приоритета относится к типу приоритета GoS, задаваемому более строгим описанием. Например, один тип приоритета может указывать предельное значение задержки, тогда как другой может указывать предельное значение флуктуации. В этом случае тип приоритета, указывающий предельное значение задержки, считается более высокоприоритетным и, таким образом, рассматривается первым.

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

Например, когда EF-данные находятся в очереди, планировщик начинает формировать пакеты для передачи, используя EF-данные. EF-данные выбираются на основании «возраста» данных в очереди, этап 204. В одном варианте осуществления, если данные помещаются в очередь, в этот момент времени данные получают временную отметку. Планировщик находит EF-данные, имеющие самую «старую» временную отметку, и помещает их в пакет первыми. Планировщик затем продолжает помещать EF-данные в пакеты в соответствии с «возрастом» (нахождения) в очереди, этап 206. Как только все EF-данные были помещены в пакеты для передачи, планировщик затем применяет другой алгоритм для остальной части данных. В данном варианте осуществления планировщик применяет пропорциональный справедливый алгоритм к остальной части данных, которыми могут быть данные «наилучшего усилия» (BE), этап 208. BE-данные затем помещают в пакеты в соответствии с пропорциональным справедливым алгоритмом, этап 210.

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

Для передачи BE-данных планировщик выбирает пакет, чтобы максимизировать пропускную способность. Пропускная способность обычно вычисляется в виде:

пропускная способность = (биты на один пакет)/(временные интервалы на один пакет).

В соответствии с одним вариантом осуществления, PF (пропорциональная справедливость) может быть задана в виде:

PF=f(«возраст» пакета)*g(состояние канала)*h(нагрузка сотовой ячейки),

которая в планировании передач рассматривает «возраст» пакета, а также состояние канала и нагрузку сотовой ячейки. Такое вычисление может использоваться для планирования EF-данных или BE-данных.

Обращаясь снова к Фиг. 2, в одном варианте осуществления, планировщик 832 канала из очереди 830 данных принимает информацию, указывающую объем находящихся в очереди данных для каждой удаленной станции, также называемую размером очереди. Планировщик 832 канала затем выполняет планирование на основании информации DRC и размера очереди для каждой удаленной станции, обслуживаемой базовой станцией 820. Если требуется размер очереди для алгоритма планирования, используемого в дополнительном варианте осуществления, планировщик 812 канала может принимать информацию о размере очереди от селекторного элемента 816.

В течение передачи пакета одному или нескольким пользователям, пользователи передают сигнал "ACK" подтверждения приема после каждого временного интервала, содержащего порцию передаваемого пакета. Сигнал ACK, передаваемый каждым пользователем, проходит через обратный канал связи и принимается на базовой станции 820 через приемную антенну, соединенную с блоком 828 RF. В примерном варианте осуществления информация ACK демодулируется в канальном элементе 826 и поставляется на планировщик 812 канала, расположенный в контроллере 810 базовой станции, или планировщик 832 канала, расположенный в базовой станции 820. В первом примерном варианте осуществления планировщик 832 канала расположен в базовой станции 820. В альтернативном варианте осуществления планировщик 812 канала располагается в контроллере 810 базовой станции и соединяется с селекторными элементами 816 внутри контроллера 810 базовой станции.

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

Также, базовая станция 820 по варианту осуществления, обсужденному выше, осуществляет передачу на некоторую выбранную или некоторые выбранные из удаленных станций за исключением остальных удаленных станций, связанных с базовой станцией 820, используя схему МДКР (CDMA) множественного доступа с кодовым разделением каналов. В любое конкретное время базовая станция 820 осуществляет передачу на некоторую выбранную или некоторые выбранные удаленные станции, используя код, который назначен принимающей базовой станции(ям) 820. Однако настоящее изобретение является также применимым к другим системам, использующим отличающиеся способы множественного доступа с временным разделением каналов, МДВР (TDMA), чтобы поставлять данные на выбранную базовую станцию(и) 820 (обеспечивать данные выбора базовой станции(й) 820), исключая остальные базовые станции 820, для оптимального распределения ресурсов передачи.

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

Как показано на Фиг. 1A, удаленные станции рассредоточены по всей системе связи и могут находиться во взаимодействии с нулем или одной базовой станцией по прямой линии связи. В примерном варианте осуществления планировщик 812 канала координирует передачи данных по прямой линии связи по полной системе связи.

В соответствии с вариантом осуществления планировщик 812 канала по Фиг. 2 реализован в вычислительной системе, которая включает в себя процессор, оперативное запоминающее устройство, ОЗУ (RAM), и память для хранения программ, чтобы хранить команды, подлежащие исполнению посредством процессора (не показано). Процессор, ОЗУ и память для хранения программ могут быть выделены для функций планировщика 812 канала. В других вариантах осуществления процессор, ОЗУ и память для хранения программ могут быть частью совместно используемого вычислительного ресурса, предназначенного для выполнения дополнительных функций в контроллере 810 базовой станции. В примерном варианте осуществления обобщенный планировщик применяется к системе 800, проиллюстрированной на Фиг. 2, и подробно описывается ниже в документе. Те блоки в пределах контроллера 810 базовой станции (КБС, BSC) и BS 820, которые используются, чтобы осуществлять функцию приоритета для планируемых передач данных, обсуждаются после установления конкретных подробностей обобщенного планировщика.

При наличии возрастающего спроса на приложения беспроводной передачи данных, значительно увеличился спрос на высокоэффективные системы беспроводной передачи данных. Стандарт IS-95 способен передавать данные трафика и речевые данные по прямым и обратным линиям связи. В соответствии со стандартом IS-95 данные трафика или речевые данные разделяются на кадры кодового канала, которые имеют длительность (ширину) 20 миллисекунд со скоростями передачи данных величиной до 14,4 Кбит/с. В системе стандарта IS-95 каждой абонентской станции выделяется по меньшей мере один канал из ограниченного количества ортогональных каналов прямой линии связи. Пока продолжается обмен информацией между базовой станцией и абонентской станцией, канал прямой линии связи остается выделенным абонентской станции. Когда услуги передачи данных обеспечиваются в системе стандарта IS-95, канал прямой линии связи остается выделенным абонентской станции даже в течение времени, когда нет данных прямой линии связи, подлежащих посылке на абонентскую станцию.

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

Другим существенным различием между речевыми услугами и услугами передачи данных является то, что первые требуют фиксированного и общего класса качества обслуживания (GoS) для всех пользователей. Обычно, для цифровых систем, обеспечивающих речевые услуги, это осуществляется в виде фиксированной и равной скорости передачи для всех пользователей и максимального допустимого значения для коэффициента частоты ошибок для речевых кадров. Напротив, для услуг передачи данных GoS может отличаться от пользователя к пользователю и может быть параметром, оптимизируемым, чтобы повышать общую эффективность системы передачи данных. GoS для системы передачи данных обычно определяется в виде суммарной задержки, понесенной в ходе передачи заранее установленного объема данных, в дальнейшем обозначаемым как пакет данных.

Еще одним существенным различием между речевыми услугами и услугами передачи данных является то, что первые требуют надежного канала связи, который в примерной системе связи CDMA обеспечивается посредством мягкой передачи обслуживания. Мягкая передача обслуживания приводит к избыточным передачам от двух или нескольких базовых станций, чтобы повысить надежность. Однако эта дополнительная надежность не требуется для передачи данных, поскольку пакеты данных, принятые с ошибкой, могут быть переданы повторно. Для услуг передачи данных мощность передачи, используемая, чтобы поддерживать мягкую передачу обслуживания, может быть более эффективно использована для передачи дополнительных данных.

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

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

Другим признаком канала беспроводной связи является изменчивость самого канала. В системе типа HDR эта изменчивость приводит к разбросам значений запрошенной скорости передачи данных в течение периода времени. Чтобы максимизировать использование канала, планировщик разработан, чтобы обслуживать «высокоскоростных» пользователей, то есть пользователей, запрашивающих более высокие скорости передачи данных. Это означает, что иногда пользователи могут не обслуживаться в течение периодов времени, когда их запрошенные скорости передачи являются более низкими. Полная пропускная способность будет максимизирована, когда планировщик не обслуживает «низкоскоростных» пользователей в течение длительных периодов времени. Однако идеально планировщик сопоставляет это с требованием, чтобы задержки пакета и разбросы значений задержек были относительно согласующимися, как пояснено выше.

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

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

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

f(A_i(t), U_i(t)),

причем A_i(t) обозначается как метрика состояния канала, и U_i(t) обозначается как метрика справедливости для пользователя. Функция A_i(t) указывает желательность обслуживания пользователя i во время t на основании текущего состояния канала. Функция V_i(t) указывает желательность обслуживания пользователя i во время t на основании предыстории принятой услуги. Функция приоритета f() объединяет две метрики желательности, A_i(t) и U_i(t), чтобы определять уровень приоритета для каждого пользователя.

В соответствии с одним вариантом осуществления обобщенный планировщик обслуживает пользователя с высшим значением функции f(A_i(t), U_i(t)) приоритета в пределах данного класса или типа пользователей. В примерном варианте осуществления принимаемое функцией f(A_i(t), U_i(t)) значение приоритета увеличивается, если увеличивается функция A_i(t) состояния канала, и уменьшается, если увеличивается функция U_i(t) справедливости. Функции A_i(t) и U_i(t) определяются соответственно. Дополнительно, функция f() приоритета является функцией по меньшей мере для одного периода времени, в течение которого измеряются метрика состояния канала и метрика справедливости для пользователя. В альтернативном варианте осуществления функция f() приоритета может быть зависящей от времени функцией для каждого пользователя. Однако для простоты планировщик может использовать функцию сумматора (объединителя), общую для всех пользователей, и модифицировать метрику справедливости для пользователя, чтобы отражать требования пользователя.

Общий класс многопользовательских планировщиков классифицирует пользователей, принимающих услугу от AN, по меньшей мере на две широкие категории (класса), BE и EF. Другие категории передач также могут быть реализованы, например, AF и т.д. BE и EF являются такими, как определено в документе. Конкретно, приложения «наилучшее усилие» (BE) в общем имеют относительно большой объем данных для приема по радио-интерфейсу, но свойство трафика является таким, что могут допускаться относительно большие задержки, а частота потери данных должна быть сверхмалой; потоки приложений «срочной пересылки» (EF) обычно имеют малые объемы трафика, который поступает из Интернета на сеть доступа, однако, свойство трафика является таким, что пакеты данных должны быть доставлены пользователю в пределах некоторого относительно малого значения DelayBound, с надлежащей частотой потери данных.

В системе с передачей пакетов данных, такой как 1xEV-DO, планировщик обладает гибкостью позволять индивидуальным пользователям функционирование с переменной задержкой, чтобы максимизировать емкость. При этом емкость относится к пропускной способности для BE-пользователей и к количеству обслуживаемых пользователей с приемлемым функционированием в случае чувствительного к задержке трафика, такого как VoIP (EF-пользователи).

В стандарте 1xEV-DO обычно повышение значения DelayBound для пользователя улучшает использование FL, таким образом, увеличивая емкость системы для BE и EF. Это повышение емкости следует из различных факторов, включающих, но не ограниченных таковыми, более высокую эффективность упаковки и возможность воспользоваться преимуществом локальных состояний канала и усиления при разнесенном многопользовательском приеме.

В случае трафика «только-BE», типичный планировщик является пропорциональным справедливым (PF) планировщиком. Этот планировщик является пропорциональным справедливым в смысле, что пропускная способность, обеспечиваемая для индивидуальных пользователей, будет приблизительно пропорциональной геометрии (геометрическому расположению в системе) пользователя, то есть среднему состоянию канала. Пропорциональный справедливый планировщик являлся предпочтительным планировщиком для трафика «только-BE» вследствие преимуществ компромиссов пропускной способности по отношению к справедливости. Кроме того, PF-алгоритм разработан, чтобы воспользоваться преимуществом локальных пиков канала, обеспечивая при этом выгоды разнесенного многопользовательского приема. Как используется в документе, такой PF-планировщик будет именоваться как "планировщик пропорциональной справедливой пропускной способности".

Следует отметить, в случае трафика «только-ВЕ», имеется другой класс планировщиков: планировщик "равного уровня обслуживания". Этот планировщик имеет целью обеспечение равной пропускной способности всем пользователям. По этой причине емкость системы определяется в соответствии с самыми слабыми пользователями. Хотя планировщик равного уровня обслуживания мог быть желательным в некоторых приложениях, такие планировщики обычно не используют линию радиосвязи эффективно. Эти планировщики именуются в документе как "планировщики равной пропускной способности".

Описанные выше планировщики PF-пропускной способности и планировщики равной пропускной способности являются полезными в контексте трафика «только-ВЕ». Для чувствительного к задержке EF-трафика эти планировщики могут не быть подходящими из-за отсутствия механизма управления задержкой.

Нижеследующее представляет средства и способы чувствительного к задержке планирования, которые действуют параллельно с двумя подходами для трафика «только-ВЕ», то есть планировщики PF пропускной способности и равной пропускной способности. В случае чувствительного к задержке трафика, "пропорциональная" против "равной" справедливости применяется не только к пропускной способности, обеспечиваемой индивидуальным пользователям, но и к характеристике "задержки", обеспечиваемой индивидуальным пользователям. Характеристика задержки может быть определена количественно в виде средней задержки или веса «хвоста» (распределения) задержки, и т.д. Следует отметить, альтернативные варианты осуществления могут включать планирование BE и EF в состав общего способа при удовлетворении требований к пропускной способности и чувствительности к задержке соответственно.

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

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

Четыре категории планирования (передачи) пакетов иллюстрируются на Фиг. 4. Каждая категория проиллюстрирована с соотношением рассмотрений QoS. Конкретно, планировщик PF пропускной способности соотносит (сопоставляет) управление пропускной способностью с пропорциональной справедливостью. Планировщик равной пропускной способности соотносит управление пропускной способностью с равной справедливостью. Планировщик PF задержки соотносит управление задержкой с пропорциональной справедливостью. Планировщик равной задержки соотносит управление задержкой с равной справедливостью.

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

В дополнение к повышению емкости системы планировщик PF задержки может также усовершенствовать практический опыт пользователя. Например, более вероятно, что пользователи в тесной близости к станциям BS будут принимать лучшую характеристику задержки, чем пользователи на значительном расстоянии от BS. Это является отличием от характеристики задержки, которая не зависит от близости пользователя к BS. Кроме того, для пользователей с высокой геометрией, в тесной близости к BS, характеристика может быть предсказуемой с высоким уровнем достоверности; тогда как для планировщика равной задержки характеристика может быть непредсказуемой в зависимости от текущей нагрузки на систему. Следовательно, является желательным, чтобы планировщик обеспечивал повышения качества обслуживания в зависимости от повышений в геометрии индивидуальных пользователей.

Планировщик, который обслуживает и BE-, и EF-пользователей, может использовать подходящую комбинацию планирования пропорциональных справедливых пропускной способности и задержки. Такой планировщик будет именоваться как "планировщик пропорциональной справедливой пропускной способности/задержки". Следует отметить, в одном варианте осуществления, планирование пропорциональной справедливой пропускной способности/задержки является неявно основанным на относительных геометриях обслуживаемых пользователей для отдельного сектора. Это именуется как "внутрисекторная справедливость". Другим вопросом для рассмотрения в схеме планировщика, является "межсотовая справедливость", которая может быть описана в виде среднего уровня обслуживания, который может быть определен количественно в терминах пропускной способности, обеспечиваемой BE-пользователям, и средней задержки, обеспечиваемой EF-пользователям, и т.д., предоставляемого различными секторами пользователям, обслуживаемым этими секторами.

Чтобы продолжить аналогию между планировщиком пропорциональной справедливой пропускной способности и планировщиком пропорциональной справедливой задержки, следует отметить, что пропускная способность, предоставляемая индивидуальным BE-пользователям сектором, который использует планировщик пропорциональной справедливой пропускной способности, уменьшается, если повышается количество пользователей, обслуживаемых этим сектором. Однако поддерживается внутрисекторная справедливость. Подобным образом, предоставляемой индивидуальным EF-пользователям характеристике задержки, которая обеспечивается сектором, использующим планировщик пропорциональной справедливой задержки, может быть позволено повышаться, если повышается количество пользователей, обслуживаемых сектором.

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

DecisionMetric=f(PacketAge, ChannelCondition, SectorLoad)

(МетрикаРешения=f(ВозрастПакета, СостояниеКанала, НагрузкаСектора),

причем PacketAge относится к разности между текущим временем и соответствующей временной отметкой, определенной для каждого пакета, ожидающего в очереди базовой станции, состояние канала (ChannelCondition) относится к качеству линии радиосвязи между BS и AT, и SectorLoad относится к объему и профилю общего трафика, обслуживаемого сектором в течение короткого интервала вблизи текущего момента времени. Функция f() зависит от конкретного исполнения планировщика. Также DecisionMetric может относиться к метрике битов, метрике пакетов, метрике дейтаграмм или любому другому средству для обеспечения планировщика способом выбора экземпляра передачи.

Информация о ChannelCondition может быть включена в состав планировщика различными способами. Например, планировщик пропорциональной справедливой пропускной способности использует значение управление скоростью передачи данных (DRC)/AvgThroughput (средняя пропускная способность), которое имеет тенденцию достигать максимума в течение локальных пиков канала. Другим подходом может быть использование DRC/AvgDRC (среднее значение DRC), но в приложении можно оказывать предпочтение пользователям с более большими флуктуациями канала. Другой возможностью может быть использование контура обратной связи, чтобы указывать некоторый процентиль пиков канала. Один такой контур 300 проиллюстрирован на Фиг. 5.

Один вариант осуществления, как проиллюстрировано на Фиг. 5, является контуром 300, предназначенным для определения приемлемого качества канала относительно пороговой величины. Входные данные, IDRC (индекс DRC, ИУСП), является функцией или индексом значения DRC, например, возрастающей функцией скорости передачи данных, связанной с DRC, причем IDRC возрастает, если возрастает запрошенная скорость передачи данных. IDRC поставляется на блок 302 сравнения и на фильтр 306 с бесконечной импульсной характеристикой (БИХ, IIR). В одном примере постоянная времени установлена в 1 с, однако, могут быть осуществлены альтернативные постоянные времени. Фильтрованный выход фильтра 306 IIR поставляется на суммирующий блок 312, который поставляет пороговое значение на блок 302 сравнения. Блок 302 сравнения сравнивает IDRC с пороговой величиной. Результат сравнения указывает, является ли приемлемым текущее качество канала или не является. Система определяет целевой процент времени, когда качество канала должно быть приемлемым. В настоящем примере, целевой параметр установлен в 30%. Целевой параметр является переменным и может быть настроен в течение функционирования. Альтернативные системы могут осуществлять другие целевые значения или схемы. Выход блока 302 сравнения является двоичным (1,0), причем 1 указывает приемлемое качество канала, а 0 - недопустимое, то есть ниже пороговой величины.

Продолжая с Фиг. 5, выходной сигнал блока 302 сравнения подается на фильтр 304 IIR, причем в настоящем примере постоянная времени установлена в 0,5 с. Могут быть осуществлены альтернативные постоянные времени. От фильтра 304 IIR фильтрованный выходной сигнал поставляется на блок 310 сравнения для сравнения с входным значением, в настоящем примере входным значением является 0,3. Если результат сравнения выше входного значения, подается сигнал на реверсивный (управляющий) сумматор 308, чтобы увеличить пороговую величину для определения качества канала. Это указывает, что указатель 1 качества канала из блока 302 сравнения выше на 30%. Иначе, если результат сравнения ниже входного значения, то сигнал, поставляемый на реверсивный сумматор 308, уведомляет о повышении пороговой величины. Выход реверсивного сумматора 308 поставляется на суммирующий блок 312. Суммирующий блок 312 суммирует выходные данные реверсивного сумматора 308 и фильтра 306 IIR, причем вход от фильтра 306 IIR поставляет на блок 302 сравнения общее смещение для пороговой величины. Результат суммирования поставляется на блок 302 сравнения. Указатель оценки канала вычитается из выходного сигнала блока 302 сравнения. Таким образом, планировщик поддерживает указатель оценки канала или информацию ChannelCondition, чтобы идентифицировать процент от полезного времени, когда состояние канала является хорошим, то есть пики канала.

Параметр SectorLoad может быть включен в состав планировщика посредством измерения объема BE- и EF-потоков. В заключение, используемая планировщиком фактическая метрика принятия решения может не включать в явной форме измерений ChannelCondition и SectorLoad. Требуемое значение DelayBound на одного пользователя может быть выбрано динамически (адаптивно) посредством измерения доли EF-пользователей, которые могут не удовлетворять свои предельные значения задержки для некоторой доли переданных IP-пакетов.

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

В одном варианте осуществления индекс класса QoS является неотрицательным целочисленным значением, выбранным для планировщика, чтобы обеспечивать более высокий приоритет потокам, имеющим более высокие индексы класса QoS. При этом индекс 0 класса QoS соответствует потокам BE/AF; причем BE-потоки являются частными случаями AF-потоков, где минимальное требуемое значение пропускной способности установлено в нуль. Индексы класса QoS со значениями 1 и выше соответствуют EF-потокам.

Следует отметить, более высоким классам QoS задается более высокий приоритет; однако, BE-данные не будут обязательно планироваться передаваемыми после того, как переданы все EF-данные, ожидающие в очередях. В качестве примера, планировщик может планировать многопользовательский пакет, чтобы передать некоторое количество EF-битов, которые являются приближающими срок завершения. В том же экземпляре передачи планировщик также может включить в состав BE-данные от пользователей с совместимыми DRC, то есть форматами передачи, при этом не включая EF-биты от пользователей с несовместимыми DRC.

Поток QoS может быть приближенно описан посредством трех параметров: (1) распределением размера IP-дейтаграммы, (2) распределением промежутков времени между поступлениями IP-дейтаграмм и 3) предельным значением задержки относительно временной отметки IP-дейтаграммы, после которого содержимое дейтаграммы становится бесполезным.

Для BE/AF-потоков предельное значение задержки является гораздо менее строгим, чем для EF-потоков, поэтому она не будет рассматриваться для BE/AF-потоков, причем AF являются потоками пересылки с подтверждением. Для EF-потоков, имеющих такое же предельное значение задержки, но отличающихся в распределении размеров IP-дейтаграмм и промежутков времени между поступлениями, планировщик разработан, чтобы вести себя (изменяться) почти линейно. Например, данный поток, имеющий такое же предельное значение задержки и распределение размера пакетов, как поток VoIP, но имеющий половинное распределение промежутков времени между поступлениями, будет вести себя приблизительно так же, как два VoIP-потока. Подобным образом поток, имеющий такие же предельное значение задержки и распределение промежутков времени между поступлениями, но удвоенное распределение размера дейтаграмм, как VoIP-поток, также приблизительно будет вести себя как два VoIP-потока для планировщика. Нецелочисленные кратные значения для размера пакета и промежутка времени между поступлениями могут быть легко представлены агрегациями (объединениями) базового «единичного» типа потока.

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

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

В соответствии с одним вариантом осуществления, если повышается нагрузка системы, обычно BE/AF-потоки являются планируемыми так, что каждый терпит ухудшение (характеристик) справедливо. Для EF-потоков, однако, ухудшение является обычно неравномерным. Более конкретно, более низкие классы QoS ухудшаются первыми в попытке поддержать функционирование надлежащим образом более высокие классы QoS. В пределах заданного класса QoS «EF» и игнорируя различия в установках предельных значений задержки, «ухудшаются» пользователи с более низкими конфигурациями, чтобы удерживать принимающими желательную характеристику столько пользователей, сколько возможно. Этот подход предпринимается, чтобы максимизировать количество поддерживаемых EF-пользователей. Для однородных EF-потоков EF-пользователи ухудшаются неравно, начиная с пользователей с самой низкой геометрией и распространяясь на пользователей более высокой геометрии. Этот подход имеет несколько последствий, которые обрабатываются вне планировщика, и, более конкретно, посредством обработки управления допуском. Некоторые из этих последствий проиллюстрированы в нижеследующих примерах.

Эти функциональные возможности планировщика проиллюстрированы на Фиг. 6, причем потоки показаны в отсортированном виде в соответствии с геометрией, которая возрастает направо. При заданной текущей нагрузке системы планировщик задает более низкий приоритет пользователям с более низкой геометрией, чтобы максимизировать количество потоков QoS, получающих желательное QoS. Уровень пользователей с низкой геометрией распространяется направо вместе с возрастающей перегруженностью. Планировщик «ухудшает» услугу, принимаемую такими пользователями, задавая им более низкий приоритет. Однако он не ответственен за полное изъятие потока, что будет обычно функцией управления допуском и других блоков мониторинга рабочих характеристик.

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

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

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

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

Если рассматривать метрику пакета для частного случая, в котором все пользователи являются EF-пользователями и каждый пользователь имеет один EF-поток одинакового типа, например систему «только-VoIP», и многопользовательский формат передачи, причем, чтобы создать многопользовательский экземпляр передачи для этого формата, биты вставляются из очередей пользователей с совместимыми DRC. Среди этих пользователей биты выбираются на основании временной отметки соответствующих IP-дейтаграмм на основе принципа "первым пришел - первым обслужен". Предполагается, что предельные значения задержки должны быть одинаковыми для этого примера. Из числа битов, имеющих одинаковые временные отметки, выбор следует порядку в IP-пакете, и среди различных пользователей выбор выполняется таким способом, чтобы минимизировать количество пользователей, имеющих данные в упомянутом пакете.

Многочлен (представления) полезной нагрузки для экземпляра передачи тогда может быть задан в виде:

причем B_n представляет количество битов, включенных в возможный экземпляр передачи, отвечающих за задержку в n временных интервалов. Значение D может быть равным предельному значению задержки в качестве битов, которые могут быть изъяты из очереди в случае, когда такие биты находились в очереди в течение периода времени, превышающего предельное значение задержки, и таким образом отвечают за задержку более D временных интервалов.

Многочлен (представления) пропускной способности получают посредством фильтрации и прореживания (субдискретизации) многочлена полезной нагрузки. Один способ состоит в том, чтобы сегментировать вектор коэффициентов многочлена полезной нагрузки на N групп и затем суммировать коэффициенты в пределах каждой группы, чтобы получить сжатое представление многочлена полезной нагрузки. Затем получают многочлен пропускной способности путем деления сжатого многочлена полезной нагрузки на ожидаемое количество временных интервалов для возможного экземпляра передачи, подлежащего декодированию всеми заинтересованными пользователями. Процедура проиллюстрирована на Фиг. 7, причем верхняя строка представляет многочлен полезной нагрузки p(x), а нижняя строка представляет c(x), который является сжатым представлением многочлена полезной нагрузки. Переменная x является индексом экземпляра передачи.

Многочлен пропускной способности тогда задается в виде:

T(z)=c(z)/N_g,

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

Следует отметить, что вышеописанная метрика пакета предлагает компромиссное решение между требованием соблюдения времени ожидания (задержки) и пропускной способностью. Если было выбрано, чтобы N-1 являлось равным D, то есть если c(x)=p(x), то метрика пакета будет сначала побуждать передачу битов, отвечающих за наибольшую задержку. Потом в выборе возможного экземпляра передачи будут рассматриваться биты, отвечающие за следующую (по величине) наибольшую задержку. Это является результатом "лексического" сравнения, используемого в ходе сравнения метрики пакета (то есть многочленов пропускной способности). Таким образом, сравнение начинается с идентификации высшего порядка каждого многочлена. Если один многочлен имеет более высокий порядок, то этот многочлен определяется в качестве наибольшего многочлена. Если оба имеют одинаковый порядок, то сравниваются коэффициенты, начиная с высшего порядка; если высший коэффициент найден в одном многочлене, этот многочлен определяется в качестве большего многочлена.

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

В одном примере два сегмента (например, c(x) первого порядка) обеспечивают компромисс. Элемент (одночлен) наибольшего порядка имеет самое большое влияние. В случае, когда имеется связь между различными возможными экземплярами, будут рассматриваться элементы c(x). Следовательно, может не являться необходимым сегментировать коэффициенты p(x) более чем на два сегмента. Это приводит к единственному параметру, подлежащему оптимизации, который будет обозначен посредством α и называться "доля задержки". В итоге, при двух сегментах, c(x)=(hi2)z-1+(hi), где "hi2" и "hi" являются количествами битов в каждом сегменте, соответственно. Более конкретно, hi2 является количеством битов, включенных в возможный экземпляр передачи, отвечающий за задержку большую, чем α-кратное предельное значение задержки; и "hi" является количеством битов, отвечающих за меньшую задержку.

Для случая пользователей, которые все имеют EF-трафик, но с различными моделями трафика (например, различные предельные значения задержки), параметры модифицируются. Биты с меньшими предельными значениями задержек должны быть частью сегмента hi2 предпочтительнее, чем биты с более большими предельными значениями задержек. Естественным способом осуществления этого является использование β-кратной задержки, в противоположность "задержке" одиночной, во вставке битов в возможные экземпляры передачи и в определении, когда биты должны стать частью механизма (передач) hi2.

В целом β создается, чтобы быть пропорциональным некоторому значению свыше предельного значения задержки. Результат этого состоит в том, что EF-биты с более низкими предельными значениями задержки будут стремиться иметь приоритет над EF-битами с более большими предельными значениями задержки.

На Фиг. 8 проиллюстрирован планировщик в соответствии с одним вариантом осуществления. Планировщик 600 включает в себя блок 602 адаптивного управления задержкой, соединенный с блоком 604 запоминающего устройства, приспособленным для хранения и поддержания информации очереди. Блок 604 запоминающего устройства хранит также относящуюся к каждой очереди информацию, включая в нее чувствительность к задержке и/или пропускной способности, класс приоритета, такой как EF, BE и т.д., и другую информацию, которая может быть конструктивно внесена в планировщик, например другую информацию QoS. Данные очереди и информация, хранимая в блоке 604 запоминающего устройства, поставляются на блок 608 вычисления метрики битов и блок 606 вычисления метрики вставки битов. Эти блоки формируют метрику битов и метрику вставки битов соответственно. Вычисленная метрика битов поставляется на блок 608 вычисления метрики битов, блок вычисления 616 метрики пакетов и блок 610 выбора очереди. Метрика вставки битов и выбранные очереди поставляются на устройство 612 формирования возможного экземпляра передачи. Метрики пакета от блока вычисления 616 метрики пакетов и набор возможных экземпляров передачи, сформированные устройством 612 формирования, поставляются на блок 614 выбора экземпляра передачи.

На Фиг. 9 подробно представлен блок 604 запоминающего устройства в качестве хранящего множество очередей с наличием ожидающих передачи данных. Данные очереди являются хранимыми для каждого потока в виде очереди 620 данных. Для каждой очереди 620 имеется соответствующий класс QoS или класс 622 приоритета и обозначение 624 чувствительности.

На Фиг. 10 показана схема последовательности операций, иллюстрирующая способ планирования в соответствии с одним вариантом осуществления. Способ 500 сначала определяет в блоке-ромбе 502 принятия решения, является ли FL занятой, то есть доступен ли временной интервал для новой передачи пакета. Если временной интервал доступен для новой передачи пакета, на этапе 504 планировщик формирует перечень возможных экземпляров передачи на основании поднабора заданных и производных форматов передачи. Метрика пакета, соответствующая каждому возможному экземпляру передачи, вычисляется на этапе 506. На этапе 508 планировщик выбирает экземпляр передачи, имеющий самое большое значение метрики пакета. На этапе 510 экземпляр передачи форматируется для передачи.

На Фиг. 11 проиллюстрирован один вариант осуществления, предназначенный для формирования набора возможных экземпляров передачи и осуществления этапа 504 в способе 500. На этапе 520 планировщик вычисляет метрики битов для каждого элемента очереди. На этапе 522 планировщик вычисляет метрику вставки битов для каждой очереди. Значения метрики битов сравниваются, чтобы выбрать набор очередей для экземпляра передачи, этап 524. Метрика вставки битов используется, чтобы сформировать возможные экземпляры передачи, использующие набор очередей, этап 526. Примеры способов и средств для таких вычислений и сравнений представлены ниже в документе.

Следует отметить, в одном варианте осуществления, возможный экземпляр передачи с однопользовательским форматом формируется для каждого пользователя, который имеет ожидающие данные. Формат передачи устанавливается в канонический (стандартный) формат, соответствующий DRC этого пользователя. Для пользователей, от которых было принято DRC со значением NULL (нуль), возможный экземпляр передачи создается, только если пользователь имеет ожидающие "EF"-данные. Для BE-/AF-пользователей нулевые DRC не обслуживаются, поскольку эти пользователи на уровне протокола (Radio Layer Protocol, RLP) уровня радиосвязи пытаются поддерживать скорости передачи с небольшим спадом (низкий процент потери пакетов).

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

Следует отметить, набор возможных экземпляров передачи, сформированный на этапе 506, основан на "канонических" форматах. То есть «короткие» пакеты не включаются на этом этапе. Цель состоит в том, чтобы помочь смещению планировщика в пользу пользователей с более высокой геометрией и избежать злоупотребления короткими пакетами пользователями с более высокой геометрией и, таким образом, сокращения пропускной способности FL. Короткие пакеты используются на этапе максимизации эффективности упаковки (как проиллюстрировано на Фиг. 12) в случае, когда выбранный возможный экземпляр передачи имеет полезную нагрузку, которая умещается в короткий пакет.

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

(1) Если выбранный возможный экземпляр передачи содержит данные одиночного пользователя, разрешается, чтобы повторно выбираемый формат был либо однопользовательским форматом, совместимым с DRC пользователя, либо многопользовательским форматом.

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

В одном варианте осуществления этап 510 форматирования экземпляра передачи дополнительно включает в себя этап 530, где планировщик максимизирует эффективность упаковки экземпляра передачи, и этап 532, на котором планировщик выполняет априорное вычисление ACK, см. Фиг. 12. Дополнительно этап 530 может включать в себя способ, который проиллюстрирован на Фиг. 13. Сначала экземпляр передачи оценивается, чтобы определить, используется ли формат одиночного пользователя, блок-ромб 540 принятия решения. Если используется формат одиночного пользователя, каждый этап дополнительно подробно описан ниже в документе.

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

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

Вычисление метрики пакета выполняется на этапе 508, тогда как вставка битов является частью форматирования экземпляра передачи по этапу 508. В общем, однопользовательский экземпляр передачи может наполняться битами из одного или нескольких потоков, соответствующих одному и тому же пользователю. Многопользовательский экземпляр с "заданным" форматом, например некоторым таким, как определено в Таблице 1, может наполняться битами от одного или нескольких пользователей, причем такие пользователи осуществили передачу сообщений DRC, совместимых с многопользовательским форматом. Многопользовательский экземпляр с "производным" форматом может быть наполнен битами от одного или нескольких пользователей, которые передали DRC, совместимые с многопользовательским форматом, и которые удовлетворяют дополнительному требованию «мягкой совместимости». DRC считается «мягко совместимым» с производным многопользовательским форматом, если ожидаемое количество временных интервалов для декодирования соответствующего «заданного» формата меньше или равно диапазону для производного формата. Ожидаемое количество временных интервалов может быть получено посредством сравнения отношения сигнал/помеха/шум (ОСПШ, SINR), требуемого для принятого DRC, со значением SINR, требуемым для успешного декодирования производного формата (например, при условиях среднего белого гауссовского шума (СБГШ, AWGN)). В качестве альтернативы, ожидаемое количество временных интервалов может быть определено посредством сравнения запрошенной скорости передачи с фактической скоростью передачи данных согласно производному формату.

В нижеследующем описании предполагается, что классы QoS включают в себя: i) BE/AF; и один класс EF. Способ дает возможность также расширения до многих классов EF. В соответствии с настоящим вариантом осуществления каждому ожидающему в очереди биту назначается метрика бита, которая задается как многочлен вида:

b_i(z)=[hi2]z-² + [hi]z^-1 +[lo],

причем i является индексом бита, и разрешается, чтобы только один из этих трех коэффициентов {hi2, hi, lo} был ненулевым. Следует отметить, хотя описание дается в виде битового представления, обычно все биты в IP-дейтаграмме имеют одинаковую метрику, и вычисления метрики пакета могут не обязательно включать в себя накопления на уровне битового представления.

Пусть δ будет текущей задержкой, связанной с битом из потока EF. Устанавливаются нижеследующие определения для hi2 и hi:

и

при этом β является параметром, связанным с EF-потоком и обратно пропорционально связанным с предельным значением задержки; при этом μ является большим числом; и при этом α является постоянной скалярной величиной, например 0,25, и является независимой от типа EF-потока.

Для BE/AF-потока lo устанавливается, как изложено ниже:

причем AvgThroughput является средней пропускной способностью соответствующего пользователя, и TrgtThroughput (целевая пропускная способность) является минимальной желательной пропускной способностью для этого пользователя. Для BE-пользователя TrgtThroughput устанавливается в нуль. Метрику пакета (например, многочлен пропускной способности) затем получают, как изложено ниже:

PacketMetric=AccumulatedBitMetric/Ng

(Метрика пакета=Накопленная метрика битов),

причем Ng является общим диапазоном для заданного или производного рассматриваемого возможного экземпляра передачи, и накопленная метрика битов (AccumulatedBitMetric) является суммой метрик битов, соответствующих всем битам, включенным (или вставленным) в возможный экземпляр. Значение Ng может быть установлено в значение номинального диапазона для заданного или производного типа. В качестве альтернативы оно может быть установлено в единицу, в каком случае метрика пакета будет равной накопленной метрике битов. В этом случае планировщик будет действовать, чтобы предпочтительнее максимизировать полезную нагрузку, отнесенную на один экземпляр передачи, чем пропускную способность, отнесенную на один экземпляр передачи. Это может иметь нежелательный эффект создания нечувствительности DRC, таким образом вызывая ухудшенную характеристику, причем такое ухудшение может не следовать поведению, проиллюстрированному на Фиг. 6. Другой подход состоит в том, чтобы установить Ng в значение "псевдодиапазона", которое может быть установлено в единицу для высокоскоростных пакетов в 1 и 2 временных интервала, установлено в значение два для пакетов в 4 временных интервала, и т.д., таким образом, различая высокоскоростные пакеты на основании полезной нагрузки, тогда как низкоскоростным форматам препятствуют посредством установки Ng в более большие значения.

Нижеследующие свойства обеспечивают планировщику смещение в пользу пользователей с высокой геометрией:

(1) Если DRC является совместимым с многопользовательским форматом, оно также совместимо со всеми многопользовательскими форматами для более низкой номинальной скорости передачи данных; и

(2) Планировщик использует многочлен "пропускной способности" в качестве механизма выбора.

Одно конструктивное решение использует элемент μ с большим значением в определении коэффициентов hi и hi2 для метрик битов. Биты вставляются в порядке в соответствии со значением βδ, поскольку μ является общим для всех битов. Метрика пакета вычисляется, как если бы соответствующий элемент метрики битов изменился в единицу, таким образом имея результатом метрику пакета, пропорциональную многочлену пропускной способности. Это устраняет эффект βδ в метрике пакета, предназначенной для вычисления метрики пакета.

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

Один вариант осуществления динамически устанавливает предельное значение задержки и связанные параметры (например, α) посредством измерения доли «хороших» EF-пользователей. Значение DelayBound, используемое планировщиком, может итеративно увеличиваться или уменьшаться, чтобы поддерживать долю хороших пользователей на желательном уровне. В одном варианте осуществления реализована простая система (контур) первого порядка с более низким предельным значением для DelayBound.

В описанном выше планировщике способ определения метрики битов для BE/AF-пользователей использует нижеследующее вычисление:

Метрика битов=1/[AvgThroughput-TargetThroughput].

Иные определения метрики битов могут быть осуществлены для других систем, эксплуатационных целей и конструктивного решения.

Совместимые с каждым индексом DRC форматы передачи FL приведены также в Таблице 1 для двух наборов подтипов протокола, определенных в описаниях редакции Rel-0 и Revision A стандарта 1xEV-DO, соответственно, включая предложенные изменения в последние усовершенствования Rev-A, определяющие совместимые многопользовательские форматы для индексов DRC со значениями 0×0, 0×l и 0×2. Формат передачи, как в техническом описании Rev. А, представлен посредством тройки параметров (PacketSize, Span, PreambleLength). "PacketSize" (размер пакета) является количеством битов, которые переносит формат передачи, включая циклический избыточный код (ЦИК, CRC) и конечную часть. "Диапазон" является номинальным (например, максимальным) количеством временных интервалов, которые экземпляр передачи будет занимать по прямой линии связи. "PreambleLength" является общим количеством элементарных посылок преамбулы (начальной части). Как в редакции Revision А технического описания 1xEV-DO, "канонические" форматы передачи для каждого DRC указаны жирным шрифтом. Следует отметить, Rel-0 определяет только однопользовательские форматы передачи, тогда как некоторые подтипы в редакции Revision А определяют и однопользовательские, и многопользовательские форматы. Кроме того, в редакции Revision A форматы множественной передачи могут быть определены для каждого индекса DRC. AT пытается принимать пакеты в каждом из этих форматов. Многопользовательские форматы различают в соответствии с их уникальными индексами MAC, то есть преамбула для каждого многопользовательского формата использует различное покрытие Уолша. Однопользовательские форматы все используют индекс MAC, назначенный пользователю.

Таблица 1 Форматы передачи для Rel.0 и Rev.A стандарта 1xEV-DO
Индекс DRC	Скорость передачи (Кбит/с)	Формат передачи Rev0	Однопользовательские форматы передачи RevA	Многопользователь- ские форматы передачи RevA

В качестве напоминания, экземпляр передачи относится к формату передачи с конкретным набором битов из одной или нескольких очередей, выбранным, чтобы транспортироваться согласно нему. Возможный экземпляр передачи относится к экземпляру передачи, который будет оцениваться алгоритмом планировщика для возможной передачи. Многопользовательские форматы передачи (1024,4,256), (2048,4,128), (3072,2,64), (4096,2,64) и (5120,2,64) именуются каноническими многопользовательскими форматами передачи. Многопользовательские форматы передачи (128,4,256), (256,4,256) и (512,4,256) именуются "неканоническими многопользовательскими форматами". Производные форматы передачи получают просто посредством установки диапазона для соответствующего заданного формата в значения меньше номинального значения, как если бы получены от заданных форматов согласно раннему завершению. В кратком изложении форматы и экземпляры передачи могут быть каноническими или неканоническими; однопользовательскими или многопользовательскими; и заданными или производными. Термин "номинальное количество временных интервалов" будет использоваться, чтобы ссылаться на максимальное количество временных интервалов для заданного формата передачи и на повторно определенное максимальное количество временных интервалов для производного формата передачи.

Нижеследующее описание средства и способов планирования рассматривает планирование на основе октетов, в котором октеты, ожидающие в различных очередях, могут обслуживаться в любом количестве (в единицах октетов). Обычно, каждый поток будет храниться в виде по меньшей мере одной очереди данных. Поэтому каждая очередь имеет конкретные требования QoS, связанные с ней. Данные хранятся в каждой очереди в виде октетов. Может выполняться планирование, в котором в экземпляр передачи или пакет физического уровня помещают менее полного октета данных для передачи по FL.

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

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

Как используется в документе, "поток" относится к потоку данных, направленному заданному пользователю. Источник потока может быть одним или несколькими пользовательскими приложениями, включающими, но не ограниченными таковыми, загрузки (ftp) файлов по сети, «блуждание» (http) по сети Интернет, игры в онлайновом режиме или VoIP, среди многих других. Поток может также формироваться непосредственно системой связи, например потоки сигнализации, которые используются, чтобы поддерживать систему действующей при поддержании пользовательского сеанса надлежащим образом. Другим примером потока является поток данных, сформированный тестовым (контрольным) приложением, в котором поток данных используется, чтобы проверять по меньшей мере часть системы связи.

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

Пользователь может иметь множественные параллельные потоки с различными требованиями QoS. Каждый поток может формироваться либо в соответствии с одиночным приложением, таким как VoIP, ftp, сигнализация и т.д., или он может формироваться в соответствии со многими приложениями, которые агрегируются (объединяются) контроллером базовой станции (КБС, BSC) в единый поток. Если BSC агрегирует потоки таким образом, то агрегированный поток может появляться на планировщике в виде одиночного потока со строго определенными требованиями QoS. Планировщик может быть неспособным проводить различие между данными, сформированными различными приложениями, но содержащимися в агрегированном потоке. Другой тип агрегации, который может выполняться планировщиком, представлен ниже в документе.

Каждый поток имеет по меньшей мере одну очередь, хранящую данные для первичной передачи (именуемую FTx), и может иметь дополнительные очереди для повторных передач, такие как очередь повторной передачи (очередь RTx для потока x) по протоколу (RLP) уровня радиосвязи и/или очередь повторной передачи уровня MAC (задержанный автоматический запрос повторной передачи (ARQ) или очередь задержанных ARQ (DARQ)). В одном варианте осуществления каждый октет в каждой очереди имеет строго определенную временную отметку, согласно которой планировщик может определять текущую задержку, понесенную октетом. Временные отметки выделяются пакетам данных, таким как (инкапсулированные) дейтаграммы, имея результатом, что каждый октет пакета данных имеет одинаковую временную отметку. Индивидуальные дейтаграммы могут переносить множество кадров прикладного уровня, которые, возможно, были сформированы приложением в разное время. Предполагается, что временные отметки кадров приложения не являются известными планировщику. Это предположение является подходящим, поскольку полная дейтаграмма должна быть успешно принята пользователем прежде, чем какие-либо из кадров приложения, которые она переносит, могут быть проанализированы приложением приемного конца.

В схеме планировщика в соответствии с одним вариантом осуществления рассматриваются три основных класса QoS. «Наилучшее усилие» (BE) определяется как в глоссарии, и конкретно относится к потокам, которые могут обычно позволять относительно высокие сквозные задержки, но требовать низкой частоты ошибки в битах (ЧОБ, BER). Хотя не имеется требования минимальной пропускной способности, размер данных, подлежащих передаче, может быть высоким. Примеры потоков, которые могут считаться потоками BE, включают в себя загрузки (ftp) файлов по сети и «блуждание» по сети (http). Пересылка с подтверждением (AF) относится к потокам, которые, в общем, сходны с BE-потоками, как допускающие некоторый уровень задержки; однако AF-потоки отличаются от BE-потоков, поскольку AF-потоки обычно имеют минимальную среднюю пропускную способность. Одним примером приложения, классифицированного в качестве AF-потока, является поток видео, формируемый приложением видеоконференции. Срочная (высокоприоритетная) пересылка (EF) относится к потокам, которые обычно, но не обязательно, имеют низкое требование к пропускной способности и имеют очень строгие требования к сквозной задержке. Требование к надежности может не быть таким строгим, как для BE-потоков; может быть приемлемой потеря малой доли данных приложения, такой как, например, 1-2%. Примеры приложений, классифицированных в качестве EF-потоков, включают в себя, но не ограничены таковыми, VoIP и игру в онлайновом режиме.

Что касается средств и способов планирования, различие между BE- и AF-потоками состоит в требовании к минимальной пропускной способности, которое является нулевым для BE-потоков. В других отношениях эти два класса QoS являются сходными. Чтобы дополнительно дифференцировать конкретные потоки, можно рассмотреть класс EF, который может включать в себя ряд приложений различных типов. В пределах потоков класса EF могут иметься потоки с различными приоритетами. В качестве примера, приложения, такие как VoIP и аудио составляющая приложения видеоконференции, могут рассматриваться в качестве более высокоприоритетных, чем видео составляющая приложения видеоконференции. Игра в онлайновом режиме может рассматриваться в качестве имеющей более низкий приоритет, чем приложения и аудио, и видео.

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

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

Предельное значение задержки идентифицируется посредством переменной, именуемой "DelayBound", которая является указанным для каждого потока параметром, относящимся к максимальной задержке, в пределах которой дейтаграмма должна быть доставлена пользователю. DelayBound измеряется относительно временной отметки дейтаграммы, которая в настоящем варианте осуществления является октетом. Следует отметить, оно отличается от предельного значения сквозной задержки, которое включало бы в состав компоненты «ресурс-задержка», отличные от задержки FL. В одном варианте осуществления, как только достигается значение DelayBound для дейтаграммы, дейтаграмма удаляется из очереди. Другими словами, если дейтаграмма не может быть послана в пределах указанного предельного значения задержки, дейтаграмма отвергается.

Целевая пропускная способность идентифицирована посредством переменной, именуемой "TargetThroughput", которая является другим указываемым параметром QoS. Целевая пропускная способность относится к минимальной требуемой средней пропускной способности для потока. Усреднение пропускной способности может быть определено через фильтр первого порядка с бесконечной импульсной характеристикой (IIR) с подходящей постоянной времени. В одном варианте осуществления постоянная времени установлена в 1 мс.

Третьим требованием QoS может быть надежность. Обычно физический уровень системы обеспечивает частоту ошибки в пакетах (ЧОП, PER) в 1%, которая может не быть достаточной для требующих крайне низкой частоты ошибки приложений, таких как загрузка файла. Поэтому, чтобы дополнительно уменьшить потери по радиоинтерфейсу, могут использоваться механизмы повторной передачи. Типичными механизмами повторной передачи являются повторные передачи согласно RLP и повторные передачи согласно уровню MAC, такие как очереди RTx и DARQ соответственно. Сверх этого, чтобы обеспечивать дополнительную надежность, может использоваться протокол управления передачей (TCP) в качестве протокола транспортного уровня для приложения.

В одном варианте осуществления планировщик спроектирован, чтобы максимизировать емкость системы при обеспечении справедливости по всем потокам и удовлетворении некоторых требований к приоритету и QoS для каждого потока. Понятия емкости и справедливости зависят от требований QoS для индивидуальных потоков. Для BE-потоков емкость может быть определена в виде переданного сектором совокупного объема передач BE. Для EF-потоков конкретного типа емкость может быть определена в виде количества пользователей, которые могут быть поддержаны при удовлетворении их требований QoS. В одном примере планирования EF-потоков система определяет емкость VoIP так, чтобы число пользователей VoIP, выбранное в качестве этого количества, достигало 95% от числа пользователей, в среднем принимающих успешно 98% кадров (или октетов) данных приложения. В одном примере успех определяется в соответствии с кадрами, принятыми в пределах указанного DelayBound и без ошибок передачи. Альтернативные критерии успеха также могут использоваться. Чтобы достичь справедливости по всем потокам, может использоваться критерий пропорциональной справедливости (PF) для планирования BE-потоков и планирования EF-потоков в соответствии с критериями приоритетов. Таким образом, если нагрузка системы повышается, BE-потоки претерпевают равномерное ухудшение, то есть BE-потоки ухудшаются без дифференциации.

Для EF-потоков является желательным иметь неравномерное ухудшение по всем пользователям, если нагрузка системы повышается или происходит перегруженность (затор). Ухудшения первыми ощущают те EF-потоки, которые рассматривались имеющими самый низкий приоритет. Из числа потоков EF, имеющих сходные требования QoS и одинаковый уровень приоритета, ухудшение должно сначала влиять на потоки для пользователей, имеющих худшие состояния канала. С таким подходом, если перегруженность системы повышается, наибольшее возможное количество EF-потоков может удовлетворять свои требования к QoS. Этот подход обычно приводит к приближенно обратной пропорциональной зависимости между состоянием канала пользователя и статистикой задержки для его EF-потоков. Это свойство именуется "справедливостью задержки".

"Формат передачи" является тройкой элементов в форме (PacketSize, Span, PreambleLength), которая описывает некоторые параметры пакета FL. PacketSize относится к размеру в битах полезной нагрузки физического уровня, Span (временной диапазон) относится к максимальному количеству временных интервалов, в которые пакет того формата может передаваться, и PreambleLength относится к длительности преамбулы в единицах элементарных посылок.

В системе с поддержкой IS-856 адаптация линии связи используется, чтобы определять скорость передачи FL для каждого пользователя. Каждый AT передает запрос данных, указывающий максимальную скорость передачи, на которой AT может принимать данные. Запрос данных именуется как сообщение управления (DRC) скоростью передачи данных. Формат сообщения DRC использует ряд индексов DRC, каждый указывает формат передачи. AT посылает сообщение DRC по каналу DRC. Для каждого действительного индекса DRC, кроме DRC со значением NULL, в редакции Rel-0 стандарта IS-856 имеется один или несколько однопользовательских и нуль или несколько многопользовательских форматов передачи, которые могут использоваться на FL, чтобы транспортировать данные пользователю. В Таблице 1 подробно представлены индексы DRC, как оговорено в IS-856. Дополнительно, Таблица 1 далее включает в себя совместимые форматы передачи для каждого индекса DRC.

В техническом описании Rev-A стандарта 1xEV-DO для каждого индекса DRC определен один из совместимых однопользовательских форматов передачи, чтобы являться каноническим форматом для этого DRC. Следует отметить, как используется в документе, DRC соответствует конкретному формату, запрошенному AT и идентифицированному посредством индекса DRC. В общем, если AT успешно декодирует пакет, переданный с использованием канонического формата, соответствующего данному DRC, то такой AT также вероятно успешно декодирует пакет, переданный с помощью любого из совместимых неканонических однопользовательских форматов или любого из совместимых многопользовательских форматов. Это поддерживается кроме индексов DRC: 0×0; 0×1 и 0×2. Следует отметить, поскольку некоторые многопользовательские форматы, совместимые с заданным DRC, могут иметь более большие длительности преамбулы по сравнению с каноническим форматом, они могут не обязательно приводить к выигрышу от обработки данных.

Для любого DRC, кроме всех форматов, совместимых с индексом 0×0 DRC, и многопользовательских форматов, совместимых с индексами 0×1 и 0×2 DRC, размер полезной нагрузки для неканонического формата является обычно меньшим или равным таковому для канонического формата. Дополнительно, диапазон для неканонического формата обычно больше или равен диапазону для канонического формата. Если пользователь, от которого был принят индекс 0Ч0 DRC (например, запрос нулевой (NULL) скорости передачи), обслуживается в некотором формате, не имеется в общем какой-либо гарантии надежного приема пакета. Также, для индексов 0×1 и 0×2 DRC совместимые многопользовательские форматы передачи могут не гарантировать достаточно надежный прием, поскольку размер полезной нагрузки и диапазон для этих форматов не удовлетворяют этому свойству.

В одном варианте осуществления планировщик может не использовать многопользовательские пакеты, чтобы обслуживать пользователей, от которых принятыми DRC являются 0×0, 0×l или 0×2. Также, услуга пользователям, от которых принимается нулевое значение DRC (0×0), может быть ограничена некоторыми условиями. Эти условия могут быть конструктивно внесены в систему.

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

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

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

В одном варианте осуществления планировщика, включающего в состав адаптивное управление задержкой, планировщиком используются различные метрики и включают в себя: 1) метрику вставки битов; 2) метрику битов и 3) метрику пакетов. Метрика битов используется, чтобы выбрать очереди, которые являются пригодными для включения в текущий экземпляр передачи. Метрика вставки битов определяет порядок, в котором биты (или октеты), которые являются ожидающими в различных очередях, включаются в состав данного возможного экземпляра передачи. Как только возможный экземпляр передачи создан, вычисляется метрика пакета для возможного экземпляра передачи. Метрика пакета затем используется, чтобы выбрать «выигравший» экземпляр передачи из набора сходно созданных возможных экземпляров передачи. Метрика пакета для возможного экземпляра передачи определяется посредством простого суммирования метрики битов для всех октетов, включенных в возможный экземпляр передачи, и деления суммы на диапазон формата передачи для возможного экземпляра передачи:

причем k представляет указатель на конкретный возможный экземпляр передачи в пределах набора альтернатив, Span[k] представляет диапазон, определенный для соответствующего формата передачи, P[k] представляет набор октетов, которые включены в возможный экземпляр передачи, и BitMetric[i] представляет метрику битов для i^ого октета, включенного в состав возможного экземпляра.

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

В общем, если метрика вставки битов для октета i является больше метрики вставки битов для другого октета j, то метрика битов для октета i может быть установлена большей или равной метрике битов для октета j. В этом случае, октеты могут быть из различных очередей. Подобным образом, если метрика битов для октета i больше таковой для другого октета j, тогда метрика вставки битов для октета i должна быть установлена большей или равной таковой для октета j, то есть:

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

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

причем Metric может быть любым типов из типов метрик, и MC0, …, MC7 представляют метрические коэффициенты. Сложение двух метрик и умножение (или деление) метрики на скалярную величину определяется как в алгебре многочленов; причем, когда суммируются две метрики, суммируются соответствующие коэффициенты из этих двух многочленов. Когда метрика умножается (или делится) на скалярную величину, каждый из коэффициентов умножается (или делится) на эту же скалярную величину. Это дает возможность вычисления метрик пакетов, используя метрики битов, вычисленные, как дается выше.

Операторы сравнения ">, ≥, =, ≤, <" определены в лексическом смысле, то есть, когда сравниваются две метрики, сначала сравниваются коэффициенты элементов (членов) высшей степени. Если равны, то сравниваются коэффициенты следующих элементов высшей степени и т.д. Две метрики являются равными, если равны все соответствующие коэффициенты из двух представлений многочлена. Операции сравнения используются для сравнения метрик вставки битов, а также для сравнения метрик пакета.

Метрики битов. Вставка битов и метрики пакета

Для метрики битов и метрики вставки битов только один элемент из соответствующих представлений многочлена является ненулевым в любой данный момент времени. Степень ненулевого элемента является одинаковой для метрики битов и метрики вставки битов для данного октета. Степень этого ненулевого элемента, который будет обычно именоваться согласно имени соответствующего коэффициента MC0,…, MC7, будет называться "состоянием приоритета" метрики (вставки) битов (или соответствующего октета). Определение операции сравнения подразумевает, что элемент MC0 соответствует октетам низшего приоритета, и элемент MC7 соответствует октетам высшего приоритета. Состояние приоритета метрики (вставки) битов для октета i определяется текущей задержкой, понесенной октетом, задаваемой в виде

CurrentDelay[i]=CurrentTime-TimeStamp[i]

(текущая задержка[i]=текущее время-временная отметка[i])

и, используя упорядоченный набор пороговых величин, известных как "пороги приоритетов" (уровни приоритетов), заданных для потока, которому принадлежит октет. TimeStamp[i] является надлежащим образом заданной временной отметкой для октета i. Каждый интервал, заданный посредством пороговых величин приоритета, является отображаемым на состояние приоритета. Пороги приоритетов и отображение таким образом заданных интервалов на состояния приоритета могут быть указаны планировщику для каждого потока отдельно. CurrentDelay[i] для октета сравнивается с этими упорядоченными наборами пороговых величин, чтобы установить интервал, в который она попадает. Это, в свою очередь, задает состояние приоритета метрики (вставки) битов.

Вышеупомянутое действие использует М порогов приоритетов и M+1 состояние приоритета для каждого потока. Значение М устанавливается в 2 в одном варианте осуществления, которое является программным исполнением планировщика. Для каждого потока задаются два порога приоритетов и три состояния приоритета. Эти пороги приоритетов и состояние приоритета обычно остаются неизмененными в течение времени существования потока, хотя каждый может быть изменен в течение функционирования посредством подходящей команды интерфейса DSP-Driver (цифровой процессор сигналов - драйвер).

Для потоков чувствительного к пропускной способности трафика метрика битов устанавливается в:

и метрика вставки битов устанавливается в

причем

1. GoSFactor (коэффициент GoS) является отнесенным к одному потоку, заданным параметром, который используется, чтобы обеспечивать различные уровни градации (класса) обслуживания по всем потокам.

2. AvgThroughput является фильтрованной (усредненной) полной (суммарной) пропускной способностью потока, включая очереди FTx, RTx и DARQ для потока. Для усреднения используется фильтр первого порядка с бесконечной импульсной характеристикой (БИХ, IIR) с постоянной времени, например такой, как 600 временных интервалов (1 секунда).

3. TargetThroughput является отнесенным к одному потоку заданным параметром.

4. Thrghpt2DelayConvFactorBM является отнесенным к одному потоку заданным параметром.

5. Thrghpt2DelayConvFactorBSM является отнесенным к одному потоку заданным параметром.

6. ε представляет очень малое положительное число.

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

DS_BSM=AccelerationFactor*CurrentDelay+AccelerationOffset,

причем AccelerationFactor (коэффициент ускорения) является заданным параметром, отнесенным к одному потоку. AccelerationFactor нормирует DelayBound, которое может быть различным для различных потоков. В качестве примера можно рассмотреть две различные онлайновые игры. Вследствие различных характеристик двух приложений, они могут иметь различные установочные параметры DelayBound, указанные планировщику, однако одна игра не обязательно имеет более высокий приоритет, чем другое приложение. Для планировщика может быть желательно обрабатывать оба приложения с равным приоритетом. Можно предположить, что первая игра имеет предельное значение задержки 300 мс и вторая игра имеет 150 мс. Тогда в любой момент времени не будет каких-либо октетов, принадлежащих второй игре, которые «старше» 150 мс, поскольку планировщик их отвергает. Могут, однако, быть октеты, принадлежащие первой игре, которые «старше» 150 мс. Без AccelerationFactor это приведет к октетам первой игры, получающим приоритет над октетами второй игры. Посредством установки значения AccelerationFactor каждого приложения обратно пропорциональным соответственным настроечным параметрам DelayBound, планировщик может нормировать это нежелательное влияние.

AccelerationOffset (смещение ускорения) является отнесенным к одному потоку заданным параметром. Значение AcceleratoinOffset может быть установлено в целое число, кратное наибольшему значению, которое может принимать AccelerationFactor. Это наибольшее значение является независимым от потоков и может быть определено посредством программной реализации (функции). В качестве примера, из числа двух потоков, одного с нулевым AccelerationOffset и другого с положительным AccelerationOffset, октеты последнего потока будут включены в любой возможный экземпляр передачи прежде каких-либо октетов первого из двух потоков, если оба потока DRC являются совместимыми с форматом передачи для данного возможного экземпляра.

Для метрики битов коэффициент многочлена для состояния приоритета устанавливается в постоянное значение, как изложено ниже

DS_BM=DSBitMetricValue,

причем DSBitMetricValue является отнесенным к одному потоку заданному параметру, используемому для мягкого назначения приоритета. Дополнительно, когда два приложения, имеющих приблизительно равный приоритет, но имеющие различную среднюю входящую пропускную способность (объем данных) (например, из Интернет в очередь), значение DSBitMetricValue для каждого потока может быть установлено обратно пропорциональным по отношению к типичной пропускной способности потока с тем, чтобы избежать, что приложение с более высокой пропускной способностью получит приоритет просто согласно наличию более большого объема данных, чтобы эффективно наполнять пакеты FL.

Каждый поток трафика на основании параметра FlowClass (класс потока) классифицируется на класс «чувствительный к пропускной способности» или класс «чувствительный к задержке». Тогда метрика MCX битов (где X является элементом {0,…,7}) задается, как изложено ниже:

Подобным образом метрика вставки битов задается в виде

В одном варианте осуществления планировщик осуществлен по меньшей мере частично в виде программной реализации. В соответствии с этим вариантом осуществления метрики вставки битов представляются 16-битовыми величинами, которые могут быть обозначены как [B15...B0]. Три самых старших бита задают состояние приоритета (например, "000" отображается в MC0, и "111" отображается в MC7). Остающиеся 13 младших битов содержат собственно значение коэффициента. С помощью этого представления операции сравнения между метрикой вставки битов могут непосредственно выполняться между этими 16-битовыми величинами.

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

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

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

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

Если на этапе выбора в составе планировщика выигравший возможный экземпляр передачи имеет многопользовательский формат, в настоящем варианте осуществления поддерживается только преобразование формата (1024,4,256) в любой из трех форматов ({128,256,512}, 4,256) (то есть используется формат самой низкой скорости передачи данных, который может переносить октеты выбранных данных).

Данное выше обсуждение метрики битов и вставки битов рассматривает общий случай, где каждому октету в каждой очереди назначается индивидуальная метрика. Метрика затем повторно вычисляется в каждый временной интервал. Альтернативные варианты осуществления уменьшают сложность такого вычисления(й). Если очереди являются упорядоченными в соответствии с временными отметками, в одном варианте осуществления вычисляет одну метрику (вставки) битов, отнесенную на поток, на основании самой старшей временной отметки из числа октетов головного-элемента-очереди из очередей потока. Эта метрика может использоваться для ожидающих в настоящий момент октетов потока. Такое упрощение предполагает, что метрика должна быть монотонно возрастающей функцией CurrentDelay для октета. Иначе имеется риск, что октет головного-элемента-очереди может препятствовать обслуживанию последовательных октетов. С этим упрощением метрика вставки битов может также именоваться как метрика потока.

Кроме того, любой октет головного-элемента-очереди, ожидающий в очереди RTx потока, вероятно, будет старше любых октетов головного-элемента-очереди, которые могут быть ожидающими в очередях FTx и DARQ. Подобным образом любой октет головного-элемента-очереди, который может быть ожидающим в очереди DARQ, вероятно, будет старше октета головного-элемента-очереди из очереди FTx. По этой причине предпочтительнее поиска самой «старой» временной отметки из числа этих трех очередей один вариант осуществления использует фиксированный порядок RTx, DARQ и затем FTx очередей, чтобы найти первую непустую очередь для определения временной отметки, подлежащей использованию в вычислении метрики для потока. Очереди потока также могут обслуживаться в порядке RTx, DARQ и затем FTx.

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

Способ планировщика, проиллюстрированный на Фиг. 10, состоит из четырех основных этапов: 1) формирование набора возможных экземпляров передачи; 2) выбор одного возможного из набора; 3) максимизация эффективности упаковки и 4) вычисление априорно или PACK. Вычисление PACK определяет вероятность, что AT имеет успешно декодированный пакет.

Обращаясь снова к Фиг. 10, на этапе 504 планировщик формирует перечень возможных экземпляров передачи. Возможный однопользовательский экземпляр передачи с однопользовательским форматом, соответствующим каждому доступному пользователю, причем доступный пользователь является некоторым, по какой-либо причине в настоящий момент не запрещенным к обслуживанию согласно подтипу протокола. Кроме того, принятый DRC от пользователя должен быть ненулевым, в противном случае с пользователем будут вестись переговоры по протоколу уровня MAC, дающему возможность, чтобы обслуживался один или несколько форматов передачи при нулевом DRC. Если возможный экземпляр передачи создается для пользователя, от которого был принят DRC значением NULL, возможному экземпляру позволяется только переносить данные, принадлежащие потоку с конечным значением DelayBound и только из FTx-очереди потока. Формат передачи для возможного экземпляра является каноническим форматом, соответствующим DRC пользователя, как подробно описано в Таблице 1.

Возможный многопользовательский экземпляр передачи формируется для каждого из пяти многопользовательских форматов передачи: (1024,4,256), (2048,4,128), (3072,2,64), (4096,2,64) и (5120,2,64). Те пользователи, которые запросили 153,6 Кбит/с или выше, обслуживаются в многопользовательских форматах. Кроме того, DRC пользователя должно быть совместимым с форматом возможного экземпляра передачи. Кроме того, многопользовательский возможный экземпляр передачи будет удовлетворять одному или обоим из нижеследующих условий, или иначе он отвергается из дальнейшего рассмотрения; он будет переносить данные двух или нескольких пользователей, или по меньшей мере данные одного пользователя, DRC которого было стерто.

Возможный экземпляр передачи в любой из групп формируется посредством вставки битов из одного или нескольких потоков, причем: 1) однопользовательские форматы могут только наполняться битами из потоков того же пользователя; 2) многопользовательские форматы наполняются битами из потоков пользователей с совместимыми DRC.

Вставка битов выполняется в порядке убывания метрики вставки битов. Как упомянуто выше, требования к вычислениям могут приводить к вычислению одной метрики вставки битов на поток, которая затем используется для ожидающих в настоящий момент октетов в очередях потока. В этом случае метрика вставки битов помогает определять, какие потоки будут обслуживаться первыми; однако, она не определяет, как будут обслуживаться октеты данного потока. Это предполагает, что ожидающие в очередях потока октеты появляются в порядке временной отметки, и октеты потока обслуживаются в порядке, в котором они появляются в очередях. Это используется для очередей FTx, но не обязательно для очередей RTx/DARQ.

Как упомянуто выше, каждый поток может иметь многие очереди, одна очередь для передаваемых в первый раз данных (FTx) и другие очереди для повторных передач (очередь RTx для повторных передач по RLP и/или очередь DARQ для повторных передач уровня MAC). Если поток имеет непустые очереди RTx и/или DARQ, метрика вставки битов для потока вычисляется на основании самых «старых» из временных отметок головного-элемента-очереди из числа любых непустых очередей FTx/RTx/DARQ. Только одна метрика вставки битов вычисляется для очередей потока. Вставка битов из данного потока должна также выполняться на основании возрастающего порядка временных отметок головного-элемента-очереди из числа очередей FTx/RTx/DARQ.

Упорядочение очередей потока на основе временных отметок может быть приближенно выражено в виде фиксированного порядка очередей RTx/DARQ/FTx.

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

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

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

Что касается этапа 508, после того как создан перечень однопользовательских и многопользовательских возможных экземпляров передачи, планировщик выбирает один из этих возможных (если вышеупомянутый сформированный перечень содержит по меньшей мере один возможный экземпляр передачи). Это выполняется путем вычисления метрики пакета для каждого из возможных кандидатов в перечне и выбора возможного кандидата с наибольшей метрикой пакета в качестве выигравшего кандидата. Если имеют место связи, является желательным предпочитать однопользовательские форматы многопользовательским форматам. Также, желательно отбирать более высокоскоростные многопользовательские форматы по всем более низкоскоростным многопользовательским форматам.

На этапе 510 формат передачи выигравшего возможного экземпляра передачи рассматривается повторно и может быть изменен, чтобы максимизировать эффективность его упаковки без изменения набора октетов данных, которые выбраны, подлежащими переносу посредством него. Завершение этапа 510, таким образом, может обеспечивать выгоды ARQ.

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

Механизм адаптивного управления скоростью передачи данных внутри AT должен быть насколько возможно приспосабливаемым, чтобы поддерживать пакеты одиночного пользователя (однопользовательские). Многие DRC являются совместимыми с неканоническими однопользовательскими форматами с меньшими размерами полезной нагрузки; следовательно, нежелательно преобразовывать однопользовательские кандидаты в многопользовательские форматы, чтобы достигать выгод от ARQ.

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

Что касается Фиг. 12, планировщик может определять максимальное количество временных интервалов (например, менее номинального интервала для выбранного экземпляра передачи), вне которого он не будет передавать экземпляр передачи даже при том, что он может не выявлять сообщения ACK от обслуживаемых пользователей в экземпляре передачи. Поскольку этот этап необязательный, он может быть выключен с тем, чтобы сеть доступа завершила передачу пакета после выявления ACK от обслуживаемых в пакете пользователей или после передачи полного временного диапазона (предельного объема) пакета.

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

причем ScheduledTxFormatSpan является диапазоном планируемого формата передачи, и DRCSpan[i] является диапазоном канонического формата передачи, соответствующего декодированному DRC от i-ого обслуживаемого пользователя в пакете.

Выше были обсуждены несколько используемых планировщиком параметров. При этом представлены параметры, поставляемые на планировщик в интерфейсе DSP-Driver. Глобальные параметры относятся к тем параметрам, которые применяются ко всем потокам, а параметры потока относятся к таковым параметрам, указываемым для каждого потока отдельно.

1. Глобальные параметры:

a. FlowTPutFilterTimeConst (постоянная времени фильтра пропускной способности потока) - задает постоянную времени фильтра IIR первого порядка, используемого для формирования переменной, AvgThroughput, средней пропускной способности, которая ведется для каждого потока. Фильтр является повторяемым (итерируемым) один раз в каждый временной интервал. Входными данными на фильтр является количество октетов, обслуживаемых из очередей данного потока в пакете, который начинается в этом временном интервале. Фильтр обновляется нулевыми входными сигналами (данными) во временных интервалах, в которых не начинается передача нового пакета.

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

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

d. FlowClass - описывает, имеет ли поток тип чувствительного к пропускной способности или тип чувствительного к задержке.

e. FlowEligibleForDRCErasureMapping (поток приемлемый для отображения стирания DRC) - подлежит использованию алгоритмом отображения стирания DRC.

f. ErasureMapDelayThreshold (порог задержки отображения стирания) - подлежит использованию алгоритмом отображения стирания DRC.

2. Параметры потока:

a. UserId (идентификатор пользователя), FlowId (идентификатор потока) - обеспечивают средство для индексирования и определения владельца каждого потока.

b. QoSMetricState (состояние метрики QoS), PriorityThold[2] (порог приоритета) - они описывают состояние приоритета метрики (вставки) битов в виде функции текущей задержки. Элементы совокупности PriorityThold[] являются структурами, которые содержат переменные DelayThold (порог задержки) и QoSMetricState. В случае, когда значение CurrentDelay (текущая задержка) потока меньше PriorityThold[0].DelayThold, состояние приоритета устанавливается в QoSMetricState. Если значение CurrentDelay больше PriorityThold[0].DelayThold, но меньше PriorityThold[1].DelayThold, то состояние приоритета устанавливается в PriorityThold[1].QoSMetricState. Если значение CurrentDelay больше PriorityThold[1].DelayThold, то состояние приоритета устанавливается в PriorityThold[1].QoSMetricState. Переменные QoSMetricState принимают значения {0,…,7}, соответствующие состояниям приоритета {MC0,…,MC7} соответственно.

c. AccelerationFactor.

d. AccelerationOffset.

e. DelayBound - 0 представляет бесконечность (то есть никогда не отвергать октет перед его обслуживанием): иначе оно представляет величину задержки относительно временной отметки данного октета, после которой октет исключается из очереди.

f. TargetThroughput - параметр, используемый в метрике (вставки) битов для чувствительных к пропускной способности потоков.

g. FlowAggregateIndex (индекс потока-агрегата) - потоки с установленным в 0 FlowAggregateIndex планировщик не агрегирует. Иначе, потоки с одинаковым (ненулевым) значением FlowAggregateIndex являются агрегируемыми в планировщике. Область действия FlowAggregateIndex является ограниченной относительно пользователя, то есть одинаковый индекс может многократно использоваться для потоков другого пользователя без смешения.

h. IntraFlowPriority (внутри-потоковый приоритет) - составляющие потоки в агрегированном (планировщиком) потоке обслуживаются в порядке IntraFlowPriority. Среди составляющих потоков с одинаковым IntraFlowPriority порядок определяется в соответствии с временной отметкой составляющего потока.

i. GoSFactor (коэффициент GoS) - используется, чтобы обеспечивать уровни градации (класса) обслуживания между потоками.

j. DSBitMetricValue - значение коэффициента метрики битов в состояниях приоритета в MCX.

Следует отметить, в интерфейсе DSP-Driver потоки не указываются в виде BE, AF, EF или посредством любого другого высокоуровневого описателя. Предпочтительнее, интерфейс DSP-Driver использует единообразное и низкоуровневое описание для всех потоков. На более высоком уровне, таком как на BSC, конкретные высокоуровневые описатели потоков, такие как требования QoS и классификации BE/EF/AF, должны быть для каждого потока отображены на базовые параметры, определенные в интерфейсе DSP-Driver. Такие таблицы отображения формируются для потенциальных типов потоков посредством надлежащего (имитационного) моделирования и тестирования.

Нижеследующее представляет примеры, иллюстрирующие использование различных параметров. Для BE-потоков могут использоваться нижеследующие параметры:

a. QoSMetricState=0 (MC0).

b. PriorityTholdQ[].QoSMetricState - {любой, любой}.

c. PriorityThold[].DelayThold={0,0} (бесконечность).

d. DelayBound=0 (бесконечность).

e. TargetThroughput=0.

f. FlowAggregateIndex=1 (агрегирует все BE-потоки пользователя).

g. Thrghpt2DelayConvFactorBM=16.

h. Thrghpt2DelayConvFactorBSM=128.

i. FlowClass=ThrputSensitive.

j. FlowEligibleForDRCErasureMapping=0.

k. ErasureMapDelayThreshold=0 {бесконечность}.

Для AF-потоков могут использоваться нижеследующие параметры:

a. QoSMetricState =0 (MC0).

b. PriorityThold[].QOSMetricState={любой, любой}.

c. PriorityThold[].DelayThold={0,0} (бесконечность).

d. DelayBound=0 (бесконечность).

e. TargetThroughput= положительное значение.

f. FlowAggregateIndex=0 (без агрегации).

g. Thrghpt2DelayConvFactorBM=16.

h. Thrghipt2DelayConvFactorBSM=128.

i. FlowClass=ThrputSensitive.

j. FlowEligibleForDRCErasureMapping=0.

k. ErasureMapDelayThreshold=0 {бесконечность}.

Для EF-потоков могут использоваться нижеследующие параметры:

a. QoSMetricState=0 (MC0).

b. PriorityThold[].QOSMetricState={2,3}.

c. PriorityThold[].DelayThold={0,25*DelayBound, 0,5*DelayBound)

d. DelayBound= зависит от приложения.

e. TargetThroughput=0.

f. FlowAggregateIndex=0 (без агрегации).

g. Tbrghpt2DelayConvFactorBM=1.

h. Thrghpt2DelayConvFactorBSM=1.

i. FlowClass=DelaySensitive.

j. FlowEligibleForDRCErasureMapping=1.

k. ErasureMapDelayThreshold=0,25*DelayBound.

Поток сигнализации представляется, как изложено ниже:

a. QoSMetricState=7 (MC7, высший приоритет).

b. PriorityTholdQ.QOSMetricState = {7,7}.

c. PriorityThold[].DelayThold={0,0} (бесконечность).

d. DelayBound=0 (бесконечность).

e. TargetThroughput=0.

f. AggregateIndex=0 (без агрегации).

g. Thrghpt2DelayConvFactorBM=1.

h. Thrghpt2DelayConvFactorBSM=1.

i. FlowClass=DelaySensitive.

j. FlowEligibleForDRCErasureMapping=1.

k. ErasureMapDelayThreshold=0,25*DelayBound.

Потокам BE/AF могут быть назначены приоритеты путем использования подходящей комбинации нижеследующих параметров:

1. Состояния MC0,…,MC7 дают возможность точного назначения приоритета.

2. GoSFactor для мягкого назначения приоритета.

3. TargetThroughput обычно для AF-потоков, которые требуют некоторой минимальной пропускной способности.

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

1. Состояния MC0,…,MC7 дают возможность точного назначения приоритета.

2. AccelerationOffset обеспечивает назначение приоритета в течение вставки битов среди октетов с одинаковым состоянием приоритета, но непосредственно не влияет на окончательный выбор пакета (поскольку этот последний этап использует метрики битов, чтобы вычислять метрику пакета, которая не зависит от AccelerationOffset). Когда два потока, принадлежащие тому же пользователю или двум различным пользователям, являются конкурирующими, чтобы быть включенными в состав одного и того же возможного экземпляра передачи, поток с более большим AccelerationOffset получает приоритет.

3. DSBitMetricValue влияет на метрики битов, так что оно имеет непосредственное влияние на метрику пакета. Этот параметр также может использоваться для мягкого назначения приоритета. В настоящее время этот параметр не реализован.

Интерфейс DSP-Driver обеспечивает гибкий способ агрегирования потоков в планировщике. Следует отметить, выполняемые планировщиком агрегации отличаются от агрегаций, которые могут быть выполнены посредством BSC. Если BSC агрегирует ряд потоков, этот агрегат предстает на планировщик в виде одиночного потока, и планировщик принимает единственный набор параметров для потока. Планировщик не может различать составляющие потоки в отдельности. Когда агрегация выполняется в планировщике, планировщик естественно будет отличать составляющие потоки.

Переменная AvgThroughput включает в себя полную пропускную способность составного потока (агрегата). Некоторые параметры, такие как DelayBound, указанные для составляющих потоков составного потока, устанавливаются в одинаковое значение в интерфейсе DSP-Driver. Перечнем переменных, которые должны быть установлены равными для всех составляющих потоков, является:

a. UserID

b. AggregateIndex (индекс составного потока)

c. QoSMetricState

d. PriorityThold[2]

e. AccelerationFactor

f. AccelerationOffset

g. DelayBound

h. TargetThroughput

i. GoSFactor

j. DSBitMetricValue

Параметром, который могут устанавливаться различно, является IntraFlowPriority, и параметром, который должен быть установлен различно, является FlowID.

В одном варианте осуществления, агрегированному потоку назначается одиночная метрика (вставки) бита. Эта метрика основывается на самой старшей временной отметке среди составляющих потоков в составе агрегированного потока. Временная отметка составляющего потока вычисляется на основании временных отметок головного-элемента-очереди из его очередей FTx/RTx/DARQ. Когда поток выбирается для вставки битов, тем не менее порядок, в котором обслуживаются составляющие потоки, определяется первично в соответствии с параметрами IntraFlowPriority, назначенными каждому из составляющих потоков, и во вторую очередь в соответствии с временными отметками составляющих потоков. Путем установки параметров IntraFlowPriority в одинаковое значение порядок выбора составляющих потоков может выполняться строго на основании их временных отметок. Параметр IntraFlowPriority является в основном предназначенным для BE-потоков.

Как обсуждено выше, каждый поток имеет очередь FTx и может иметь очереди RTx и/или DARQ. В программной реализации для каждого потока вычисляется одиночная метрика вставки битов. Этот метрика применяется к октетам в очереди FTx, а также к октетам в очередях RTx и DARQ. Если поток выбирается, чтобы быть обслуженным, индивидуальные очереди также обслуживаются в том порядке, который определен.

Один программный вариант осуществления обеспечивает возможность повышать приоритет потока, если очереди RTx и/или DARQ являются непустыми. Это выполняется путем просто модифицирования значения Metric_TS, заданного в Уравнении (3.3-2) в виде:

Коэффициент RetransmissionPriorityFactor (коэффициент приоритета повторной передачи) принимает значение 1, если обе очереди и RTx, и DARQ являются пустыми. Он принимает другое значение, если очередь RTx является пустой, а очередь DARQ содержит данные. И еще одно другое значение, если очередь RTx является непустой.

В редакции Revision А технического описания 1xEV-DO некоторые подтипы протокола оговаривают, что DRC значением NULL должно быть совместимым с набором однопользовательских и многопользовательских форматов передач. Также, в Rel-0 технического описания оговариваются атрибуты конфигурации для некоторых подтипов протокола, которые дают возможность сети доступа обслуживать пользователя, от которого было принято DRC со значением NULL, с помощью однопользовательского формата передачи (1024,16,1024).

В любом случае планировщик может создавать возможный экземпляр передачи, содержащий данные для пользователя, от которого был принят DRC со значением NULL. Это именуется преобразованием «нуль-скорость» (NULL-to-Rate). Планировщик налагает нижеследующие ограничения на преобразования «нуль-скорость»:

a) разрешается обслуживать потоки с конечным значением DelayBound;

b) очереди RTx/DARQ не могут обслуживаться.

Ограничения, отличные от этих, планировщик не различает, было ли DRC, принятое от пользователя, 0×0 (то есть нулевое DRC), или 0×1, (то есть 38,4 Кбит/с), оба из которых определены, что должны быть совместимыми с такими же форматами передачи в некоторых подтипах протокола в Rev-A. Вновь осуществляется ссылка на Таблицу 1 для конкретных определений подтипов протокола.

Когда от пользователя принимается DRC со значением NULL, не имеется гарантии, что обслуживаемый пакет будет успешно декодирован пользователем. Будущее усовершенствование может включать в состав фактически мониторинг, достаточно ли успешно фактически декодируют пользователи, которые послали DRC со значением NULL и затем обслуживались в пакете. В зависимости от статистики успеха, преобразование может быть включено/выключено для потока. Один вариант осуществления возможных экземпляров передачи, созданных для пользователей, которые послали DRC со значением NULL, ранжирует ниже возможных экземпляров передачи, созданных для пользователей, которые послали DRC 0x1.

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

Что касается синхронизации планировщика, временная диаграмма внутри временного интервала делится на две части: первая часть является некритическим сегментом, и последняя часть является критическим сегментом. Значения DRC пользователей становятся доступными в течение критического сегмента. Однако критический сегмент может не обеспечивать достаточно циклов процессора для выполнения вычислений, включенных в состав планировщика, при нагрузке «наихудшего случая». Следовательно, некоторые из этих вычислений должны быть делегированы (переданы) некритическому сегменту. Поскольку значения DRC некоторых пользователей могут не быть известными в течение некритического сегмента, программная реализация использует значения DRC из предыдущего временного интервала, чтобы создать возможные экземпляры передачи и выбрать выигравший возможный экземпляр. Является допустимым, что значения DRC некоторых пользователей могут изменяться, и выигравший возможный экземпляр может стать недействительным в течение критического сегмента. Чтобы решить эту трудность, выбирается несколько «сильных» кандидатов в течение некритического сегмента. Когда фактические значения DRC принимаются в критическом сегменте, этот сокращенный набор кандидатов повторно оценивается. Сокращенный набор возможных экземпляров может содержать:

a) небольшое число (например, пять) однопользовательских кандидатов;

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

В редакции Rel.0 стандарта 1xEV-DO, AN не распределяет пакеты на AT, если информация DRC является стертой. Когда AN обслуживает множество AT с нечувствительными к задержке приложениями, например трафиком «наилучшего усилия», могут быть допустимыми относительно большие скорости (частоты) стирания DRC (например, вследствие многопользовательского разнесения) без потери емкости системы. Когда скорость стирания DRC является чрезмерно высокой, бит блокировки DRC посредством AN будет установлен в нуль, и затем AT может выбирать, передавать ли обслуживание другому сектору или переключаться на режим фиксированной скорости передачи данных. Однако способ формирования бита блокировки DRC имеет встроенную задержку, которая, по меньшей мере частично, происходит вследствие фильтрации, чтобы препятствовать ненужным передачам обслуживания. Таким образом, относительно длительные последовательности стираний DRC могут все еще происходить на обратной линии связи. Для чувствительных к задержке приложений, например EF-трафика, эти стирания могут приводить к недопустимым величинам перерывов в обслуживании. Алгоритм отображения стирания DRC пытается минимизировать планируемому получателю сообщения перерывы в обслуживания на FL.

Базовый алгоритм описан в виде двух этапов. Первый этап поясняет решение относительно отображения стирания DRC. Второй этап описывает модификации планировщика FL для Редакции А стандарта 1xEV-DO. На Фиг. 14 описан алгоритм отображения стирания DRC, исполняемый посредством AN в каждый временной интервал для каждого AT, который находится в режиме передачи данных с переменной скоростью. Для каждого AT алгоритм исполняется в каждом секторе сотовой ячейки, которая имеет активную очередь, установленную посредством BSC для этого пользователя. Для простоты алгоритм описан подлежащим исполнению в каждом элементарном временном интервале, но параметры будут обновляться только в каждом интервале длительностью DRC_Length.

Основными выходными данными алгоритма является флажок Erasure_Mapped_flag (флаг «стирание отображено»), который указывает планировщику, что отображение стирания DRC выполнено и для AT может выполняться ограниченное планирование FL.

Значение DRC_index_store (сохранить индекс DRC) используется, чтобы сохранять самый последний действительный, то есть успешно декодированный индекс DRC. Значение Eras_Count используется для вычисления длины последовательности стираний DRC. Отображение стирания DRC выполняется, только если длина последовательности стираний больше Max_Ers_Len (максимальная длина стираний). Эта пороговая величина обеспечивает, что отображение стирания DRC выполняется только, когда вероятность перерывов в обслуживания является относительно высокой. Пакеты, однако, могут быть планируемыми на AT в случае, когда является высокой соответствующая задержка пакета FL. Таким образом, Max_Ers_Len не может быть слишком высокой. Для EF-потоков, например VoIP, надлежащие установочные параметры для Max_Ers_Len могут находиться в диапазоне от 0 до 16 временных интервалов.

Как проиллюстрировано на Фиг. 14, способ 700 сначала проверяет в блоке-ромбе 702 принятия решения, стерто ли DRC. Если DRC стерто, на этапе 704 Eras_Cnt увеличивается. Затем на этапе 706 Eras_Cnt сравнивается с максимальным значением Max_Ers_Len. Если Eras_Cnt больше Max_Ers_Len, Erasure_Mapped_flag устанавливается в 1; иначе на этапе 712 Erasure_Mapped_flag очищается, то есть устанавливается в 0. Если в блоке-ромбе 702 принятия решения определяется, что DRC не является стертым, то Erasure_Mapped_flag устанавливается в 0, Eras_Cnt устанавливается в 0, и DRC_Index_Store устанавливается в DRC_Index на этапе 708. Обработка переходит на этап 712, причем Erasure_Mapped_flag устанавливается в 0.

Описанные выше планировщики FL могут быть модифицированы, чтобы работать с алгоритмом отображения стирания DRC. Для каждого индивидуального потока данных для каждого AT поток является приемлемым для ограниченного планирования FL, если:

причем FlowEligibleForDRCErasMapping является параметром, который указывает приемлемость каждого потока трафика для отображения стирания DRC. В качестве значения по умолчанию EF-потоки предполагаются приемлемыми для отображения, тогда как BE- и AF-потоки - нет.

HeadofQueueDelay (задержка головного элемента очереди) указывает значение "Current_Delay" для пакета в начале очереди FL (то есть старейший пакет в очереди FTx, RTx или DARQ). ErasureMapDelayThreshold является минимальной требуемой задержкой для конкретного потока, чтобы отображать стирание (имеет эффект, сходный с "PriorithyThold[i].DelayHold"). Если поток является приемлемым для ограниченного планирования FL, нижеследующие модификации выполняются над планировщиком FL:

a) поток не является приемлемым в качестве кандидата на однопользовательский экземпляр передачи;

b) поток является приемлемым для многопользовательского экземпляра передачи с запрошенным индексом DRC, DRC_index_mapped (индекс DRC отображен).

Является возможным динамически изменять DRC_index_mapped в виде функции длины (последовательности) стираний. Это можно достичь, используя DRC_index_store и Eras_Count. Параметр по умолчанию для DRC_index может быть отображен в 0×3. Для планировщика FL значение индекса 0×3 для DRC будет соответствовать многопользовательскому формату (1024,4,256) передачи, который может, возможно, быть преобразованным в форматы ({128,256,512},4,256). Все эти многопользовательские форматы являются совместимыми со всеми индексами DRC, так что AT должен быть способен декодировать отображенный DRC, пока он имеет достаточное значение SINR (независимое от фактического запрошенного индекса DRC). Альтернативные алгоритмы могут применять более осторожные, ограничивающие доступные многопользовательские форматы передачи до более низких скоростей передачи данных, если Eras_Count повышается.

Следует отметить, необязательная возможность DARQ может быть включена для VoIP. Поэтому, в случае, если AT не декодировал переданный многопользовательский пакет в первой попытке передачи, DARQ обеспечивает возможность второй попытки передачи и уменьшает остаточную частоту ошибок передачи пакета. Характеристика DARQ, однако, связана с характеристикой ACK канала, что может не быть очень надежным, когда DRC находится в ходе стирания. Порог принятия решения о ACK/NAK (отсутствие подтверждения приема) может быть оптимизирован для DARQ, возможно в зависимости от индекса DRC или состояния отображения DRC. В другом варианте осуществления попытку передачи DARQ делают совместимой только с форматами многопользовательских пакетов с более низкой скоростью передачи, например (512,4,1024), или (256,4,1024), в случае отображения стирания DRC.

Дополнительные варианты осуществления могут обеспечивать дополнительные этапы и средства для планировщика, представленного в документе. Например, BE/AF-потоки будут обычно использовать состояния приоритета, которые имеют строго более низкий приоритет, чем упомянутые состояния приоритета. Это может приводить к ухудшению пропускной способности для BE/AF в присутствии EF-пользователей, которые наиболее вероятно будут использовать состояния более высокого приоритета. Пропускная способность для BE/AF может быть добавочно повышена посредством повышения приоритета потоков BE/AF до более высоких состояний при некоторых условиях.

В соответствии с одним вариантом осуществления, AvgRequestedRate является фильтрованной запрошенной скоростью передачи для пользователя, причем K пользователей заданы в конфигурации в качестве BE-пользователей в системе. Если пропускная способность, AvgThroughput, пользователя для его BE-потоков удовлетворяет

то состояние приоритета пользователя для его BE-потоков может быть добавочно повышено до состояний более высокого приоритета. Значение α может быть выбрано в зависимости от EF-нагрузки системы, меньшее α - для более высокой нагрузки. Кроме того, требования минимальной запрошенной скорости передачи данных могут быть наложены на пользователей для такого содействия. Являются возможными другие способы повышения емкости для BE/AF.

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

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

причем указатель (индикатор) состояния канала (УСК, CCI) принимает значения из множества {0,1} или интервала [0,1], которые могут формироваться отдельно, так что когда он (указатель) принимает более высокие значения, это указывает относительно хорошие условия канала по сравнению с долгосрочным состоянием канала для пользователя. Также, κ является коэффициентом преобразования «указатель качества канала-задержка» (CCI-to-Delay). Он указывает, какой величины повышение в терминах задержки получит поток, когда состояние канала пользователя является хорошим относительно статистики его собственного канала.

Один простой способ формировать CCI для двоичного {0,1} случая дается, как изложено ниже. Пусть RateIndex (индекс скорости) будет целым числом, назначенным значениям DRC в порядке возрастания скорости передачи данных, причем значение DRC не используется, поскольку оно не является увеличивающимся монотонно вместе со скоростью передачи данных. Пусть AvgRateIndex будет средним (фильтрованным) RateIndex для пользователя. Пусть CCIThreshold будет параметром, таким как 1,2. Тогда, если RateIndex>CCIThreshold*AvgRateIndex, то значение CCI может быть установлено в единицу. В противном случае оно устанавливается в нуль. В этом примере CCI будет указывать относительно хорошее состояние канала, если текущим RateIndex, соответствующим принятому DRC, является 120% или качество выше среднего.

Приоритетное прерывание обслуживания относится к прекращению передачи FL прежде ее декодирования пользователями-получателями. Приоритетное прерывание обслуживания может использоваться, если выявляются данные с очень высоким приоритетом в то время, как все четыре перемежения на FL заняты относительно «низкоскоростными» пользователями. Алгоритм планировщика в настоящее время не обеспечивает способ приоритетного прерывания обслуживания для продолжающихся передач. Одна причина этого состоит в том, что если тщательно не контролируются, то неконтролируемые приоритетные прерывания обслуживания могут приводить к потере емкости.

Принятый при этом подход состоит в том, чтобы избежать обстоятельств, которые могут потребовать приоритетное прерывание обслуживания. Одним таким условием, как упомянуто выше, является, что все четыре перемежения являются занимаемыми низкоскоростными пользователями. Чтобы избежать этого, могут использоваться простые способы. Один такой способ состоит в том, чтобы не позволять больше установленного числа одновременных передач для форматов с интервалами в 8 временных интервалов и 16 временных интервалов. В качестве примера это число может быть установлено в 2 или 3.

Один вариант осуществления ведет текущий контроль характеристики декодирования для пользователей, которые передают DRC со значением NULL и обслуживаются в пакете. В зависимости от PER, измеренным по этим фактам «нуль-скорость», является возможным включать/выключать преобразования «нуль-скорость» для каждого пользователя. Подобным образом является возможным включать/выключать ограничения на обслуживание очередей RTx/DARQ, а также очередей для потоков с бесконечным значением DelayBound в экземплярах «нуль-скорость», если накопленная статистика указывает, что терминал доступа достаточно надежно декодирует эти пакеты.

Коэффициенты метрик битов и вставки битов для чувствительных к пропускной способности потоков обеспечивают пропорциональную справедливость в системе «только-BE» (например, TargetThroughput=0 и GoSFactor=1 для всех потоков) с наличием пользователей, имеющих большие объемы данных для приема. Форма коэффициента метрики может применяться подобным образом для других планировщиков. Для этой цели коэффициент метрики для чувствительных к пропускной способности потоков может быть выражен в виде

причем f(.) и h(.) являются характеристическими функциями, а AvgRequestedRate является средней запрошенной скоростью передачи для пользователя. Установка f(x)=x и h(x)=x дает планировщик приблизительно равного-GoS.

Расширенный протокол MAC прямого информационного канала (Enhanced Forward Traffic Channel MAC Protocol), определенный в редакции Revision А технического описания 1xEV-DO, налагает ограничение на обслуживание пользователей, следующих многопользовательскому пакету, как подытожено ниже. В описании редакции Revision A утверждается, что временной интервал t будет определяться продолжением более раннего временного интервала s, если удовлетворяются нижеследующие условия:

c) терминал доступа является потенциальным получателем пакета, передача которого начинается во временном интервале s;

d) временной интервал t находится в том же перемежении FL, что и временной интервал s, то есть t-s=0 (mod 4);

e) s<t<s+4N, причем N обозначает диапазон индекса DRC, соответствующего значению DRC, которое находится в действии в течение временного интервала s;

f) прежде временного интервала t, сеть доступа не принимала положительное подтверждение для пакета, передача которого началась во временном интервале s.

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

Вышеупомянутое сформулированное ограничение налагает ограничения на пользователей, которые могут быть обслужены, следуя многопользовательскому пакету. В качестве примера, если сеть доступа обслуживает для набора пользователей многопользовательский пакет, который затем рано завершается, тогда сеть доступа не может обслуживать какие-либо пакеты (однопользовательские или многопользовательские) в течение продолжения обслуживаемого пакета для пользователей, которые не были обслужены в предыдущем пакете, но были совместимыми с его форматом. В одной ситуации сеть доступа обслуживает многопользовательский пакет 153,6 Кбит/с, и пользователи с помощью данных, которые он переносит, декодируют пакет в течение менее 4 временных интервалов. Если сеть доступа немедленно обслуживает другой многопользовательский пакет 153,6 Кбит/с на том же перемежении, то пользователям, которые фактически запросили 153,6 Кбит/с или любое DRC с диапазоном в 4 временных интервала, но не были обслужены в предыдущем пакете, не будет разрешено обслуживаться в новой передаче. Следовательно, только те пользователи, которые запросили несколько DRC с диапазоном менее 4 временных интервалов, то есть обычно пользователи в лучших условиях канала, могут обслуживаться в новой передаче. Но это делает даже более вероятным, что новый пакет будет декодирован рано. Эта цепочка может продолжаться, пока не опустошены очереди пользователей с более высокой геометрией. Между тем, пользователи с более низкой геометрией, которые запрашивают несколько DRC с диапазонами в 4 временных интервала, не будут обслуживаться. Результатом будет чрезмерная задержка для пользователей с более низкой геометрией и возможно малое увеличение в задержке для пользователей с более высокой геометрией.

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

Таким образом, были описаны новый и усовершенствованный способ и устройство, предназначенные для планирования передач в системе связи. Специалисты в данной области техники поймут, что данные, инструкции, команды, информация, сигналы, биты, символы и микросхемы, на которые могут быть ссылки по всему вышеупомянутому описанию, являются преимущественно представлены посредством напряжений, токов, электромагнитных волн, магнитных полей или частиц, оптических полей или частиц, или любой их комбинацией. Специалисты в области техники оценят дополнительно, что различные иллюстративные логические блоки, модули, схемы и этапы алгоритма, описанные в связи с раскрытыми в документе вариантами осуществления, могут быть реализованы в виде электронных аппаратных средств, программного обеспечения или комбинаций обоих. Различные иллюстративные компоненты, блоки, модули, схемы и этапы были описаны в общих чертах в терминах их функциональных возможностей. Осуществлены ли функциональные возможности в виде аппаратных средств или программного обеспечения, зависит от конкретного применения и конструктивных ограничений, наложенных на систему в целом. Специалисты в области техники признают взаимозаменяемость аппаратных средств и программного обеспечения в этих условиях, и то, как наилучшим образом осуществить описанные функциональные возможности для каждого конкретного применения. В качестве примеров различные иллюстративные логические блоки, модули, схемы и этапы алгоритма, описанные в связи с раскрытыми в документе вариантами осуществления, могут быть осуществлены или выполнены с помощью цифрового процессора сигналов (ЦПС, DSP), проблемно-ориентированной интегральной микросхемы (ASIC), программируемой вентильной матрицы (FPGA) или другого программируемого логического устройства, дискретной вентильной или транзисторной логики, дискретных компонентов аппаратных средств, таких как, например, регистры и стек (очередь FIFO) обратного магазинного типа, процессора, исполняющего систему микропрограммных команд, любого обычного программируемого программного модуля и процессора или любой их комбинации, предназначенной для выполнения функций, описанных в документе. Процессор может преимущественно быть микропроцессором, но, в качестве альтернативы, процессор может быть любым обычным процессором, контроллером, микроконтроллером, программируемым логическим устройством, матрицей логических элементов или конечным автоматом. Программный модуль может постоянно находиться в оперативном запоминающем устройстве (ОЗУ, RAM), флэш-памяти, постоянном запоминающем устройстве (ПЗУ, ROM), стираемом программируемом постоянном запоминающем устройстве (СППЗУ, EPROM), электрически стираемом программируемом постоянном запоминающем устройстве (ЭСППЗУ, EEPROM), регистрах, накопителе на жестком диске, сменном диске, постоянном запоминающем устройстве на компакт-диске (КД-ПЗУ, CD-ROM) или известном в области техники носителе данных любого другого вида. Иллюстративный процессор является преимущественно соединенным с носителем данных с тем, чтобы считывать информацию с носителя данных и записывать информацию на него. В виде альтернативы носитель данных может быть выполнен заодно с процессором. Процессор и носитель данных могут постоянно находиться в ASIC. ASIC может постоянно находиться в телефоне или другом пользовательском терминале. В виде альтернативы процессор и носитель данных могут постоянно находиться в телефоне или другом пользовательском терминале. Процессор может быть исполнен в виде комбинации DSP сигналов и микропроцессора или в виде двух микропроцессоров в объединении с базовыми средствами DSP и т.д.

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

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

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

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

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