УСТРОЙСТВО И СПОСОБ ПРЕДОТВРАЩЕНИЯ БЛОКИРОВКИ КАНАЛА УПРАВЛЕНИЯ

Область техники

Настоящее изобретение относится к системе беспроводной связи, в частности к устройству и способу предотвращения блокировки канала управления.

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

Системы радиосвязи диверсифицировались для обеспечения различных типов услуг связи, например, услуг передачи голоса или данных. В целом, система радиосвязи является системой множественного доступа, способной к совместному использованию доступных системных ресурсов (полосы, мощности передачи и т.п.) для поддержки связь с множественными пользователями. Примеры системы множественного доступа включают в себя систему множественного доступа с кодовым разделением (CDMA), систему множественного доступа с частотным разделением (FDMA), систему множественного доступа с временным разделением (TDMA), систему множественного доступа с ортогональным частотным разделением (OFDMA), систему множественного доступа с частотным разделением с одной несущей (SC-FDMA) и пр.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

ТЕХНИЧЕСКАЯ ПРОБЛЕМА

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

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

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

ТЕХНИЧЕСКОЕ РЕШЕНИЕ

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

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

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

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

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

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

Предпочтительно, канал управления является CRC (циклическим избыточным кодом), скремблированным RNTI (временным идентификатором радиосети).

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

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

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

Предпочтительно, вышеупомянутые аспекты дополнительно включают в себя осуществление операции в соответствии с каналом управления.

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

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

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

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

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

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

Предпочтительно, канал управления является CRC (циклическим избыточным кодом), скремблированным RNTI (временным идентификатором радиосети).

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

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

ПРЕИМУЩЕСТВА ИЗОБРЕТЕНИЯ

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

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

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

В ЧЕРТЕЖАХ:

Фиг. 1 - схема, демонстрирующая иллюстративную структуру кадра радиоканала системы проекта партнерства третьего поколения (3GPP).

Фиг. 2 - схема, демонстрирующая сетку ресурсов для слота нисходящей линии связи.

Фиг. 3 - схема, демонстрирующая иллюстративную структуру кадра нисходящей линии связи.

Фиг. 4 - блок-схема, иллюстрирующая процесс составления PDCCH на базовой станции (BS).

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

Фиг. 6 - схема, демонстрирующая иллюстративную структуру подкадра восходящей линии связи.

Фиг. 7 - схема, демонстрирующая систему связи с агрегацией несущих (CA).

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

Фиг. 9 - схема, демонстрирующая способ составления пространств поиска согласно варианту осуществления настоящего изобретения.

Фиг. 10 - схема, демонстрирующая способ обработки канала управления согласно варианту осуществления настоящего изобретения.

Фиг. 11 и 12 - схемы, демонстрирующие примеры составления пространств поиска в случае использования одной DL CC мониторинга, согласно варианту осуществления настоящего изобретения.

Фиг. 13 - схема, демонстрирующая пример составления пространств поиска в случае использования множества DL CC мониторинга, согласно варианту осуществления настоящего изобретения.

Фиг. 14 - 15 - схемы, демонстрирующие примеры составления пространств поиска в случае, когда слепое декодирование может осуществляться ограниченное число раз, согласно варианту осуществления настоящего изобретения.

Фиг. 16 - схема, демонстрирующая пример составления пространств поиска с использованием унификации размера DCI согласно варианту осуществления настоящего изобретения.

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

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

Фиг. 23 - схема, иллюстрирующая BS и UE, которые можно применять к варианту осуществления настоящего изобретения.

ПОДРОБНОЕ ОПИСАНИЕ

Нижеперечисленные технологии можно использовать в различных системах радиодоступа, например, в системе множественного доступа с кодовым разделением (CDMA), системе множественного доступа с частотным разделением (FDMA), системе множественного доступа с временным разделением (TDMA), системе множественного доступа с ортогональным частотным разделением (OFDMA) или в системе множественного доступа с частотным разделением с одной несущей (SC-FDMA). Систему CDMA можно реализовать, например, посредством технологии радиосвязи «универсальный наземный радиодоступ» (UTRA) или CDMA2000. Систему TDMA можно реализовать, например, посредством технологии радиосвязи «глобальная система мобильной связи» (GSM)/ «общая радиослужба пакетной передачи» (GPRS)/ «повышение скорости передачи данных для развития GSM» (EDGE). Систему OFDMA можно реализовать, например, посредством технологии радиосвязи IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20 или E-UTRA (усовершенствованный UTRA). Система UTRA составляет часть стандарта «универсальной системы мобильных телекоммуникаций» (UMTS). Система связи проекта долгосрочного развития систем связи в рамках проекта партнерства третьего поколения (LTE 3GPP) составляет часть стандарта E-UMTS (усовершенствованной UMTS), в котором на нисходящей линии связи применяется система OFDMA, и на восходящей линии связи применяется система SC-FDMA. LTE-A (усовершенствованная) является усовершенствованной версией LTE 3GPP.

Для пояснения описания, заявитель сосредоточил внимание на LTE/LTE-A 3GPP, но технический объем настоящего изобретения этим не ограничивается. Следует отметить, что конкретные термины, раскрытые в настоящем изобретении, предложены для удобства описания и улучшения понимания настоящего изобретения, и эти термины можно заменить другими терминами в пределах технического объема или сущности настоящего изобретения.

На фиг. 1 показана иллюстративная структура кадра радиоканала.

Согласно фиг. 1, кадр радиоканала включает в себя 10 подкадров. Подкадр включает в себя два слота во временной области. Время передачи одного подкадра определяется как интервал времени передачи (TTI). Например, один подкадр может иметь длину в 1 миллисекунду (мс), и один слот может иметь длину 0,5 мс. Один слот включает в себя множество символов мультиплексирования с ортогональным частотным разделением (OFDM) во временной области. Поскольку LTE 3GPP использует OFDMA на нисходящей линии связи, символ OFDM служит для представления одного символьного периода. Символ OFDM также можно именовать символом или символьным периодом SC-FDMA. Блок ресурсов (RB) представляет собой единицу выделения ресурсов и включает в себя множество смежных поднесущих в одном слоте. Структура кадра радиоканала показана исключительно в иллюстративных целях. Таким образом, количество подкадров, включенных в кадр радиоканала или количество слотов, включенных в подкадр, или количество символов OFDM, включенных в слот, можно изменять тем или иным образом.

На Фиг. 2 показана сетка ресурсов для одного слота нисходящей линии связи.

Согласно Фиг. 2, слот нисходящей линии связи включает в себя множество символов OFDM во временной области. Здесь описано, что один слот нисходящей линии связи включает в себя 7 символов OFDM, и один блок ресурсов (RB) включает в себя, например, 12 поднесущих в частотной области. Однако настоящее изобретение этим не ограничивается. Каждый элемент на сетке ресурсов называется ресурсным элементом (RE). Один RB включает в себя 12×7 RE. Количество N^DL RB, включенных в слот нисходящей линии связи, зависит от ширины полосы передачи нисходящей линии связи. Структура слота восходящей линии связи может быть такой же, как у слота нисходящей линии связи.

На Фиг. 3 показана иллюстративная структура структуры нисходящей линии связи.

Согласно Фиг. 3, максимум три символа OFDM, находящиеся в передней части первого слота в подкадре, соответствуют области управления, назначаемой каналом управления. Остальные символы OFDM соответствуют области данных, назначаемой физическим совместно используемым каналом нисходящей линии связи (PDSCH). Примеры каналов управления нисходящей линии связи, используемых в LTE 3GPP, включают в себя физический канал индикатора формата управления (PCFICH), физический канал управления нисходящей линии связи (PDCCH), физический канал индикатора гибридного ARQ (PHICH), и т.д. PCFICH передается в первом символе OFDM подкадра и несет информацию, касающуюся количества символов OFDM, используемых для передачи каналов управления в подкадре. PHICH является ответом на передачу по восходящей линии связи и несет сигнал квитирования (ACK)/отрицательного квитирования (NACK) HARQ. Информация управления, передаваемая через PDCCH, именуется информацией управления нисходящей линии связи (DCI). DCI включает в себя информацию планирования восходящей линии связи или нисходящей линии связи или включает в себя команду управления мощностью передачи (Tx) восходящей линии связи для произвольных групп UE.

PDCCH может нести транспортный формат и выделение ресурсов совместно используемого канала нисходящей линии связи (DL-SCH), информацию выделения ресурсов совместно используемого канала восходящей линии связи (UL-SCH), информацию поискового вызова на канале поискового вызова (PCH), системную информацию на DL-SCH, выделение ресурсов управляющего сообщения более высокого уровня, например, ответа произвольного доступа, передаваемого на PDSCH, набор команд управления передаваемой мощностью на отдельных UE в произвольной группе UE, команду управления мощностью передачи, команду активации речевой связи по IP-протоколу (VoIP), и т.д. В области управления можно передавать множество PDCCH. UE может осуществлять мониторинг множества PDCCH. PDCCH передается в агрегации одного или нескольких последовательных элементов канала управления (CCE). CCE - это логическая единица выделения, используемая для обеспечения скорости кодирования PDCCH на основании состояния радиоканала. CCE соответствует множеству групп ресурсных элементов (REG). Формат PDCCH и количество битов доступного PDCCH определяются согласно корреляции между количеством CCE и скоростью кодирования, обеспечиваемой CCE. BS определяет формат PDCCH согласно DCI, подлежащей передаче на UE, и присоединяет циклический избыточный код (CRC) к информации управления. CRC маскируется уникальным идентификатором (именуемым временным идентификатором радиосети (RNTI)) согласно владельцу и использованию PDCCH. Если PDCCH предназначен для конкретного UE, CRC может маскироваться уникальным идентификатором (например, RNTI соты (C-RNTI)) для UE. Альтернативно, если PDCCH предназначен для сообщения поискового вызова, CRC может маскироваться идентификатором индикатора поискового вызова (например, RNTI поискового вызова (P-RNTI)). Если PDCCH предназначен для системной информации (в частности, блока системной информации (SIB), описанный, ниже), CRC может маскироваться идентификатором системной информации и RNTI системной информации (SI-RNTI). Для указания ответа произвольного доступа, который является ответом для передачи преамбулы произвольного доступа UE, CRC может маскироваться RNTI произвольного доступа (RA-RNTI).

PDCCH несет сообщение, известное как информация управления нисходящей линии связи (DCI), которое включает в себя назначения ресурсов и другую информацию управления для UE или группы UE. В целом, в подкадре можно передавать несколько PDCCH. Каждый PDCCH передается с использованием одного или более так называемых элементов канала управления (CCE), причем каждый CCE соответствует девяти наборам из четырех физических ресурсных элементов, именуемым группами ресурсных элементов (REG). Четыре символа QPSK отображаются в каждую REG. Ресурсные элементы, занятые опорными символами, не входят в состав REG, и это означает, что суммарное количество REG в данном символе OFDM зависит от наличия опорных сигналов, специфичных для соты. Концепция REG (т.е. отображение в группы из четырех ресурсных элементов) также используется для других каналов управления нисходящей линии связи (PCFICH и PHICH). Поддерживается четыре формата PDCCH, перечисленные в таблице 1.

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

Подход, принятый в LTE, предусматривает задание для каждого UE ограниченного набора местоположений CCE, где может располагаться PDCCH. Набор местоположений CCE, в котором UE может найти свой PDCCH, можно рассматривать как 'пространство поиска'. В LTE пространство поиска имеет особый размер для каждого формата PDCCH. Кроме того, задаются отдельные специализированные (специфичные для UE) и общие пространства поиска, причем специализированное пространство поиска конфигурируется для каждого UE в отдельности, в то время как все UE информируются о протяженности общего пространства поиска. Заметим, что специализированные и общие пространства поиска для данного UE могут перекрываться. При таких малых пространствах поиска весьма возможно, что в данном подкадре базовая станция не сможет найти ресурсов CCE для передачи PDCCH на все необходимые UE, поскольку после назначения некоторых местоположений CCE остальные не будут находиться в пространстве поиска конкретного UE. Для минимизации возможности продолжения такой блокировки в следующем подкадре, последовательность скачкообразных переходов, специфичная для UE, применяется к начальным позициям специализированных пространств поиска. Размеры общих и специализированных пространств поиска перечислены в таблице 2.

Чтобы держать под контролем вычислительную нагрузку, обусловленную суммарным количеством попыток слепого декодирования (BD), UE не требуется искать одновременно все заданные форматы DCI. Обычно, в специализированном пространстве поиска, UE всегда ищет форматы 0 и 1A, имеющие одинаковый размер и различаемые по флагу в сообщении. Кроме того, UE может потребоваться принять дополнительный формат (т.е. 1, 1B или 2, в зависимости от режима передачи PDSCH, установленного базовой станцией). В общем пространстве поиска UE будет искать форматы 1A и 1C. Кроме того, UE может быть сконфигурировано на поиск формата 3 или 3A, имеющего такой же размер, как форматы 0 и 1A, и отличимого по наличию CRC, скремблированного другим (общим) идентификатором, а не идентификатором, специфичным для UE. Ниже описаны режимы передачи для конфигурирования многоантенного оборудования и информационное содержание различных форматов DCI.

РЕЖИМ ПЕРЕДАЧИ

режим передачи 1: передача с единичного антенного порта базовой станции

режим передачи 2: разнесенная передача

режим передачи 3: пространственное мультиплексирование без обратной связи

режим передачи 4: пространственное мультиплексирование с обратной связью

режим передачи 5: многопользовательский MIMO

режим передачи 6: предварительное кодирование ранга 1 с обратной связью

режим передачи 7: передача с использованием опорных сигналов, специфичных для UE

ФОРМАТ DCI

формат 0: предоставления ресурсов для передач PUSCH (восходящей линии связи)

формат 1: назначения ресурсов для передач PDSCH с одним кодовым словом (режимы передачи 1, 2 и 7)

формат 1A: компактная сигнализация назначений ресурсов для PDSCH с одним кодовым словом (все режимы)

формат 1B: компактные назначения ресурсов для PDSCH с использованием предварительного кодирования ранга 1 с обратной связью (режим 6)

формат 1C: очень компактные назначения ресурсов для PDSCH (например, поискового вызова/широковещания системной информации)

формат 1D: компактные назначения ресурсов для PDSCH с использованием многопользовательского MIMO (режим 5)

формат 2: назначения ресурсов для PDSCH для операции MIMO с обратной связью (режим 4)

формат 2A: назначения ресурсов для PDSCH для операции MIMO без обратной связи (режим 3)

форматы 3/3A: команды управления мощностью для PUCCH и PUSCH с 2-битовыми/1-битовыми регулировками мощности

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

На Фиг. 4 показана блок-схема, иллюстрирующая процесс составления PDCCH на базовой станции (BS).

Согласно Фиг. 4, BS генерирует информацию управления согласно формату DCI. BS может выбирать один из множества доступных форматов DCI (форматы 1, 2, …, и N DCI) согласно информации управления, подлежащей передаче на UE. На этапе S410 циклический избыточный код (CRC) для обнаружения ошибок присоединяется к информации управления, сгенерированной согласно каждому формату DCI. CRC маскируется временным идентификатором радиосети (RNTI) согласно владельцу и использованию PDCCH. Другими словами, PDCCH подвергается скремблированию CRC идентификатором (например, RNTI).

В таблице 3 приведен пример идентификаторов, используемых для маскирования PDCCH.

Если используется C-RNTI, временный C-RNTI или полупостоянный C-RNTI, PDCCH несет информацию управления для конкретного UE и, если используется другой RNTI, PDCCH несет общую информацию управления, принимаемую всеми UE в соте. На этапе S420, в отношении информации управления, к которой присоединен CRC, осуществляется канальное кодирование для генерации кодированных данных. На этапе S430 осуществляется согласование по скорости согласно уровню агрегации CCE, назначенному формату PDCCH. На этапе S440 кодированные данные модулируются для генерации символов модуляции. Уровень агрегации CCE символов модуляции, составляющих один PDCCH, может быть любым из 1, 2, 4 и 8. На этапе S450 символы модуляции отображаются в физические ресурсные элементы (RE).

На Фиг. 5 показана блок-схема, иллюстрирующая способ обработки PDCCH на пользовательском оборудовании (UE).

Согласно Фиг. 5, на этапе S510 UE осуществляет обратное отображение физических RE из CCE. На этапе S520, поскольку UE неизвестен уровень агрегации CCE принятого PDCCH, UE осуществляет демодуляцию на каждом уровне агрегации CCE. На этапе S530 UE осуществляет рассогласование по скорости в отношении демодулированных данных. Поскольку UE неизвестен формат DCI (или размер полезной нагрузки DCI) принятой информации управления, рассогласование по скорости осуществляется в отношении форматов DCI (или размеров полезной нагрузки DCI). На этапе S540 канальное декодирование осуществляется в отношении рассогласованных по скорости данных согласно скорости кодирования, и осуществляется проверка CRC для выявления ошибок. Если ошибки не обнаружены, значит UE детектирует свой собственный PDCCH. В случае обнаружения ошибки, UE непрерывно осуществляет слепое декодирование в отношении других уровней агрегации CCE или других форматов DCI (или размеров полезной нагрузки DCI). На этапе S550 UE, детектирующее свой собственный PDCCH, удаляет CRC из декодированных данных для получения информации управления.

Множество PDCCH для множества UE можно передавать в области управления одного и того же подкадра. BS не снабжает UE информацией, указывающей местоположение PDCCH в области управления. Соответственно, UE осуществляет мониторинг набора PDCCH кандидатов в подкадре и находит свой собственный PDCCH. Термин "мониторинг" означает, что UE пытается декодировать принятые PDCCH кандидаты согласно соответствующим форматам DCI. Это называется слепым декодированием (слепым детектированием). Производя слепое декодирование, UE одновременно осуществляет идентификацию PDCCH, передаваемого на UE, и декодирование информации управления, передаваемой через соответствующий PDCCH. Например, в случае, когда PDCCH демаскируется с использованием C-RNTI, отсутствие обнаружения ошибок с помощью CRC означает, что UE детектирует свой собственный PDCCH.

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

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

Таблица 4   Поле Бит(ы) (1) Флаг для различения формата 0/формата 1A 1 (2) Флаг скачкообразного перехода 1 (3) Назначение блоков ресурсов и выделение ресурсов со скачкообразным переходом (4) Схема модуляции и кодирования и версия избыточности 5 (5) Индикатор новых данных 1 (6) Команда TPC для запланированного PUSCH 2 (7) Циклический сдвиг для DM RS 3 (8) Индекс UL (TDD) 2 (9) Запрос CQI 1

Поле флага позволяет отличить формат 0 от формата 1A. Таким образом, форматы 0 и 1A DCI имеют одинаковый размер полезной нагрузки и отличаются полем флага. Длина в битах поля назначения блоков ресурсов и выделения ресурсов со скачкообразным переходом может изменяться согласно PUSCH со скачкообразным переходом или PUSCH без скачкообразного перехода. Поле назначения блоков ресурсов и выделения ресурсов со скачкообразным переходом для PUSCH без скачкообразного перехода обеспечивает битов для выделения ресурсов первого слота в подкадре восходящей линии связи. обозначает количество RB, включенных в слот восходящей линии связи, и зависит от ширины полосы передачи восходящей линии связи, установленной в соте. Соответственно, размер полезной нагрузки формата 0 DCI может изменяться согласно ширине полосы восходящей линии связи. Формат 1A DCI включает в себя поле для назначения PDSCH, и размер полезной нагрузки формата 1A DCI может изменяться согласно ширине полосы нисходящей линии связи. Формат 1A DCI обеспечивает размер в битах опорной информации для формата 0 DCI. Соответственно, если количество битов информации формата 0 DCI меньше количества битов информации формата 1A DCI, к формату 0 DCI присоединяется "0", пока размер полезной нагрузки формата 0 DCI не станет равным размеру полезной нагрузки формата 1A DCI. Поле заполнения формата DCI заполняется "0".

На Фиг. 6 показана схема, демонстрирующая иллюстративную структуру подкадра восходящей линии связи, используемого в системе LTE.

Согласно Фиг. 6, подкадр восходящей линии связи включает в себя множество слотов (например, два). Каждый слот может включать в себя символы SC-FDMA, количество которых изменяется согласно длине CP. Например, в случае нормального CP, слот может включать в себя семь символов SC-FDMA. Подкадр восходящей линии связи делится на область данных и область управления в частотной области. Область данных включает в себя PUSCH и используется для передачи сигнала данных, например речевого сигнала. Область управления включает в себя PUCCH и используется для передачи информации управления. PUCCH включает в себя пару RB (например, m=0, 1, 2, 3), расположенных на обоих концах области данных на частотной оси, и совершает скачкообразные переходы между слотами. Информация управления включает в себя ACK/NACK HARQ, информацию качества канала (CQI), индикатор матрицы предварительного кодирования (PMI) и указатель ранга (RI).

На Фиг. 7 показана схема, демонстрирующая систему связи с агрегацией несущих (CA).

Согласно фиг. 7, множество компонентных несущих (CC) восходящей линии связи/нисходящей линии связи можно агрегировать для поддержки более широкой ширины полосы восходящей линии связи/нисходящей линии связи. CC могут быть смежными или несмежными в частотной области. Ширина полосы CC устанавливается независимо. Возможна также асимметричная CA, в которой количество UL CC и количество DL CC различны. Можно сделать так, чтобы информация управления передавалась/принималась только через особую CC. Такую особую CC можно называть первичной CC, а остальные CC можно называть вторичными CC. Например, в случае применения планирования между несущими (или планирования между CC), PDCCH для назначения нисходящей линии связи можно передавать через DL CC#0, и соответствующий PDSCH можно передавать через DL CC#2. Термин "CC" можно заменить другими эквивалентными терминами (например, несущая, сота и пр.).

Для планирования между CC можно предусмотреть введение поля индикатора несущей (CIF). Конфигурацию для присутствия или отсутствия CIF в PDCCH можно полустатически и специфично для UE (или специфично для группы UE) обеспечить за счет сигнализации более высокого уровня (например, сигнализации RRC). Ниже кратко описаны основные варианты передачи PDCCH.

CIF отключено: PDCCH на DL CC назначает ресурсы PDSCH на той же DL CC и ресурсы PUSCH на единичной связанной UL CC

CIF отсутствует

Такие же структура PDCCH LTE (такое же кодирование, такое же отображение ресурсов на основе CCE) и форматы DCI

CIF включено: PDCCH на DL CC может назначать ресурсы PDSCH или PUSCH в одной из множественных агрегированных DL/UL CC с использованием CIF

форматы DCI LTE, расширенные CIF

- CIF (если сконфигурировано) является полем с фиксированным количеством битов x (например, x=3)

- местоположение CIF (если сконфигурировано) фиксировано независимо от размера формата DCI

Повторное использование структуры PDCCH LTE (такое же кодирование, такое же отображение ресурсов на основе CCE)

Назначения ресурсов между CC можно конфигурировать, когда форматы DCI имеют одинаковые или различные размеры

- явное CIF для случая одного и того же размера формата DCI

- в случае если размеры формата DCI различны, будет производиться определение, присутствует ли CIF

Будет задан верхний предел суммарного количества BD

В случае присутствия CIF, желательно, чтобы базовая станция могла назначить набор DL CC мониторинга PDCCH для снижения сложности BD на стороне UE. Этот набор CC составляет часть всех агрегированных DL CC, и UE осуществляет детектирование/декодирование PDCCH, запланированных для него, только на этом наборе. Другими словами, для планирования PDSCH/PUSCH для UE, базовая станция передает PDCCH только через набор DL CC мониторинга PDCCH. Набор DL CC мониторинга PDCCH можно задавать специфично для UE или специфично для группы UE или специфично для соты.

На Фиг. 8 показан пример подкадра DL, для которого агрегировано 3 DL CC, и DL CC A сконфигурирована как DL CC мониторинга PDCCH. Если CIF отключено, каждая DL CC может передавать только PDSCH планирования PDCCH каждой DL CC без CIF, согласно следующему принципу PDCCH LTE. С другой стороны, если CIF включено сигнализацией более высокого уровня, специфичной для UE (или специфичной для группы UE или специфичной для соты), только DL CC A может передавать PDCCH, планирующие не только PDSCH DL CC A, но и PDSCH других CC, за счет использования CIF. Заметим, что PDCCH не передаются на DL CC B и C, которые не сконфигурированы как DL CC мониторинга PDCCH. Термин "DL CC мониторинга PDCCH" можно заменить эквивалентными терминами, например, несущая мониторинга, сота мониторинга, обслуживающая несущая, обслуживающая сота.

ПРИМЕР

Если в системе CA не установлено перекрестное планирование, PDCCH для конкретной несущей передается только через соответствующую несущую. Например, согласно фиг. 7, если установлено планирование не между CC, PDCCH для DL CC0/UL CC0 передается только через DL CC0. Соответственно, в DL CC0 присутствует только пространство поиска PDCCH для DL CC0/UL CC0. Таким образом, пространство поиска PDCCH составляется для каждой несущей, и каждое пространство поиска PDCCH передается только через соответствующую DL CC.

Однако согласно фиг. 8, если планирование между CC установлено (т.е. CIF включено), DL CC мониторинга должна передавать не только PDCCH, ассоциированный с DL CC мониторинга, но и PDCCH, ассоциированные с другими несущими. Таким образом, DL CC мониторинга (DL CC A) должна передавать все PDCCH, ассоциированные с DL CC A, DL CC B и DL CC C. Соответственно, DL CC мониторинга (DL CC A) должна включать в себя пространство поиска PDCCH, ассоциированное с DL CC A, пространство поиска PDCCH, ассоциированное с DL CC B, и пространство поиска PDCCH, ассоциированное с DL CC C. Если CIF задано, как описано выше, поскольку множество пространств поиска PDCCH нужно задавать в одной DL CC, может происходить блокировка PDCCH в силу ограниченности ресурсов PDCCH и увеличение числа раз осуществления слепого декодирования. Блокировка PDCCH означает, что планирование PDCCH для соответствующей несущей ограничивается в силу ограниченности ресурсов PDCCH. Например, если множество пространств поиска PDCCH определено на одной несущей, доступные ресурсы пространства поиска PDCCH, соответствующего каждой несущей, могут ограничиваться в силу ограниченности ресурсов PDCCH, и, таким образом, местоположение назначения PDCCH может быть ограничено, или назначение PDCCH может быть невозможно.

Соответственно, если CIF задано, необходим способ выхода из блокировки PDCCH, и увеличения числа раз осуществления слепого декодирования. Для этого, в DL CC мониторинга, пространство поиска PDCCH можно вновь задавать отлично от традиционного способа. Таким образом, пространство поиска PDCCH можно вновь задавать в соответствии с управлением планирования между CC. Например, пространство поиска PDCCH можно задавать на множестве несущих. Однако если пространство поиска PDCCH вновь задано, обратная совместимость с традиционной системой (например, LTE) проблематична. Кроме того, поскольку размер полезной нагрузки традиционной DCI изменяется согласно полосе несущей даже в одном и том же формате, структуру DCI необходимо изменять для задания DCI в унифицированном пространстве поиска PDCCH.

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

Далее, вариант осуществления настоящего изобретения будет подробно описан со ссылкой на чертежи. Как описано выше, режимы передачи агрегированных CC можно устанавливать независимо и полосы CC можно назначать для каждой CC и, таким образом, они могут быть одинаковыми или отличаться друг от друга. Из всех CC, агрегированных для каждого(й) (группы) UE, одну или множество DL CC можно задать как DL CC мониторинга PDCCH для (группы) UE. DL CC мониторинга PDCCH задается произвольно для указания DL CC, используемой для передачи множества пространств поиска PDCCH, соответствующих несущим после планирования между CC. DL CC мониторинга PDCCH можно заменить другими эквивалентными терминами. Например, термин "DL CC мониторинга PDCCH" можно заменить эквивалентными терминами, например, несущая мониторинга, сота мониторинга, обслуживающая несущая, обслуживающая сота.

Для удобства, хотя на чертежах показано планирование DL CC на PDSCH, настоящее изобретение в равной степени применимо к планированию UL CC, связанных с DL CC, на PUSCH. Для удобства, хотя на чертежах показан уровень агрегации CCE, равный 1, настоящее изобретение в равной степени или аналогично применимо к случаю, когда уровень агрегации CCE имеет другие значения (например, 2, 4, или 8). Хотя предполагается, что BD для двух форматов DCI для каждого PDCCH кандидата может осуществляться по аналогии с традиционной системой LTE в отношении всех случаев в настоящем изобретении, BD можно осуществлять для одного или трех или более форматов DCI для каждого PDCCH кандидата. Для удобства, хотя на чертежах показана симметричная CA, в которой количество DL CC и количество UL CC одинаковы, настоящее изобретение в равной степени или аналогично применимо асимметричной CA, в которой количество DL CC и количество UL CC различны. Для удобства, хотя показан случай, когда DL CC и UL CC связаны взаимно-однозначным соответствием, настоящее изобретение в равной степени или аналогично применимо к случаю, когда DL CC и UL CC связаны соответствием «многие-к-одному» или соответствием «один-ко-многим».

Вариант осуществления 1: построение пространства поиска согласно информации (например, DCI)

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

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

На Фиг. 9 показана схема, демонстрирующая способ передачи канала управления на конкретное UE на BS.

Согласно Фиг. 9, BS составляет множество пространств поиска (S910). Каждое пространство поиска включает в себя множество каналов управления кандидатов и задано для каждой несущей (например, CC). Задание пространств поиска для каждой CC можно осуществлять согласно способу составления пространства поиска PDCCH традиционной системы LTE. Параметр (например, шаблон хэширования, местоположение, размер и т.д.) для пространства поиска для каждой CC можно получить объединением параметра для пространства поиска PDCCH традиционной системы LTE и значения CIF.

Множество пространств поиска включает в себя пространство поиска, специфичное для UE, или общее пространство поиска и, предпочтительно, включает в себя пространство поиска, специфичное для UE. Канал управления включает в себя PDCCH, и канал управления кандидат включает в себя PDCCH кандидат. Канал управления несет разнообразную информацию управления, и присутствуют разнообразные форматы информации управления согласно типу/содержанию информации управления. После этого, BS передает канал управления для конкретного UE через множество пространств поиска (S920). Канал управления (или информация управления) может нести идентификатор для указания конкретного UE. Идентификатор включает в себя RNTI, например, CRNTI или SPS-RNTI. Канал управления (или информация управления) можно скремблировать с использованием идентификатора. Например, BS может передавать PDCCH, CRC-скремблированный с помощью C-RNTI, на UE.

Если установлено планирование между несущими, множество пространств поиска составляется на одной и той же DL CC. Планирование между несущими можно осуществлять с использованием CIF в канале управления. CIF может иметь репрезентативное значение (например, значение, указывающее DL CC), указывающее пару связанных DL/UL CC, или значение, отдельно указывающее DL CC или UL CC. CIF можно представлять абсолютным индексом или относительным индексом (например, смещением).

Пространства поиска можно составлять для каждой пары связанных DL/UL CC, DL CC или UL CC. Пространства поиска могут иметь последовательные логические индексы или могут быть заданы независимо, и пространства поиска могут частично или полностью перекрывать друг друга. Размер пространства поиска, соответствующего каждой несущей (или CIF), можно определять пропорционально максимальному количеству PDCCH, которое можно передавать через пространство поиска, или ему можно присваивать весовые коэффициенты, или все размеры пространств поиска могут быть одинаковыми. Можно задавать по одному формату информации управления для каждой DL CC или UL CC или можно задавать два или более форматов информации управления для каждой DL CC или UL CC, в пространстве поиска, соответствующем каждой несущей (или CIF). Общий формат информации управления DL/UL, например, формат 0/1A DCI системы LTE можно задавать в пространствах поиска. Тип формата информации управления, заданный в пространствах поиска, может изменяться согласно режиму передачи (например, режиму MIMO).

Когда пространства поиска составлены, если форматы канала управления, имеющие одинаковый размер (или информация управления, имеющая одинаковый размер независимо от формата), присутствуют во множестве пространств поиска, пространства поиска соответствующих форматов канала управления совместно используются. Если количество пространств поиска, составленных на одной несущей, равно M (M≥2), может совместно использоваться N (N≤M) пространств поиска. Совместное/раздельное использование пространств поиска или количество пространств поиска можно определять для каждого формата канала управления (или для каждого размера информации управления независимо от формата). Соответственно, если пространства поиска составляются для каждой несущей, но присутствуют форматы канала управления, имеющие одинаковый размер (или информация управления, имеющая одинаковый размер независимо от формата), то пространства поиска унифицируются. В этом случае, канал управления для UE, который связан с одной из несущих (или CIF), соответствующих совместно используемым N пространствам поиска, можно передавать через любое из N пространств поиска. Таким образом, каналы управления кандидаты, имеющие одинаковый размер по N пространствам поиска, можно передавать через любое из N пространств поиска. В этом случае, каналы управления кандидаты, имеющие одинаковый размер, различаются с использованием значений CIF (поля индикатора несущей).

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

Например, BS может составлять пространства поиска для каждой CC и сравнивать размеры (формата) DCI для всех CC. Если присутствуют (форматы) DCI, имеющие одинаковый размер, BS может унифицировать пространства поиска (форматов) DCI для составления расширенного пространства поиска. Соответственно, PDCCH для (форматов) DCI, имеющих одинаковый размер, можно передавать через любой PDCCH кандидат в расширенном пространстве поиска, а не через соответственные пространства поиска. В этом случае, PDCCH кандидаты в расширенном пространстве поиска различаются с использованием значений CIF (поля индикатора несущей).

На Фиг. 10 показана схема, демонстрирующая пример обработки канала управления (например, PDCCH) на UE. Процесс, представленный на Фиг. 10, соответствует процессу, представленному на Фиг. 9, и подробное описание соотносится с описанием Фиг. 9.

Согласно Фиг. 10, UE принимает множество (M: M≥2) пространств поиска (S1110). Каждое пространство поиска определяется для каждой несущей. После этого, UE осуществляет мониторинг каналов управления кандидатов в пространствах поиска для отыскания канала управления, назначенного UE (S1120). Процесс мониторинга включает в себя слепое декодирование каждого из каналов управления кандидатов. После этого, UE может осуществлять операцию согласно каналу управления, назначенному UE (S1130).

При этом если каналы управления кандидаты имеют одинаковый размер информации по N (N≤M) пространствам поиска, канал управления для UE, который связан с одной из несущих (или CIF), соответствующих N пространствам поиска, можно принимать через любое из N пространств поиска. Таким образом, UE осуществляет мониторинг каналов управления кандидатов, исходя из того, что каналы управления кандидаты, имеющие одинаковый размер информации, можно принимать через любое из N пространств поиска. В этом случае, каналы управления кандидаты, имеющие одинаковый размер информации, различаются с использованием значений CIF (поля индикатора несущей).

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

На Фиг. 11A показан пример составления пространств поиска согласно варианту осуществления настоящего изобретения. В настоящем примере, агрегируется три DL CC, и режимы передачи DL CC заданы равными 1, 3 и 4. Для удобства, предполагается, что ширина полосы у всех CC одинакова, и DL CC #1 является DL CC мониторинга PDCCH. Хотя в настоящем примере число раз осуществления BD для каждого формата DCI одинаково (BD осуществляется в отношении шести PDCCH кандидатов по аналогии с системой LTE), число раз осуществления BD может изменяться согласно форматам DCI.

Согласно фиг. 11A, BS составляет пространства поиска для каждой CC и сравнивает размеры формата DCI для всех CC. В результате этого сравнения, размеры форматов 1A DCI для трех DL CC одинаковы, и форматы 1, 2A и 2 DCI соответственно имеют различные размеры. Соответственно, BS унифицирует три пространства поиска для формата 1A DCI (совместное использование пространства поиска). Соответственно, BS может передавать формат 1A DCI (CIF=DL CC #1) через PDCCH кандидат любого из пространства поиска для DL CC #1, пространства поиска для DL CC #2 и пространства поиска для DL CC #3. Аналогично, формат 1A DCI (CIF=DL CC #2) и формат 1A DCI (CIF=DL CC #3) можно передавать через PDCCH кандидат любого из трех пространств поиска. Таким образом, кандидаты формата 1A DCI (CIF=DL CC #1, #2 или #3) можно передавать через любое из пространств поиска для DL CC #1, #2 и #3. Таким образом, UE осуществляет мониторинг PDCCH кандидатов, исходя из того, что кандидаты формата 1A DCI (CIF=DL CC #1, #2 или #3) можно принимать через любое из пространств поиска для DL CC #1, #2 и #3. В этом случае, кандидаты формата 1A DCI различаются с использованием значений CIF.

Напротив, поскольку форматы 1, 2A и 2 DCI соответственно имеют уникальные размеры, пространства поиска для форматов 1, 2A и 2 DCI не подлежат совместному использованию и отображаются для каждой CC. Таким образом, формат 1 DCI (CIF=DL CC #1) можно передавать только через пространство поиска, соответствующее DL CC #1. Аналогично, формат 2A DCI (CIF=DL CC #2) и формат 2 DCI (CIF=DL CC #3) можно передавать только через пространства поиска, соответствующие DL CC #2 и DL CC #3, соответственно.

Нижеследующее подробное описание опирается на тот факт, что максимальное число раз осуществления BD (MaxBD) может быть ограничено. MaxBD=36 указывает, что число раз осуществления BD не снижается по сравнению с моментом до совместного использования пространств поиска. В случае MaxBD=36, BD для формата 1A DCI может часто осуществляться через пространства поиска, включающие в себя 18 (=6×3) PDCCH кандидатов унифицированного и расширенного пространства поиска. Напротив, BD для форматов 1, 2A и 2 DCI осуществляется через пространства поиска, включающие в себя шесть PDCCH кандидатов.

Если MaxBD сокращается до 24, число раз осуществления BD для каждого формата DCI должно снижаться. Если предполагается, что число раз осуществления BD для каждого формата DCI остается постоянным, число раз осуществления BD для каждого формата DCI уменьшается до 4 (=24/6). В этом случае, пространство поиска для формата 1A DCI может состоять из 12 PDCCH кандидатов и пространство поиска для каждого из форматов 1, 2A и 2 DCI может состоять из четырех PDCCH кандидатов. Аналогично, в случае MaxBD=18, количество PDCCH кандидатов для формата 1A DCI может быть равно 9, и пространство поиска для каждого из форматов 1, 2A и 2 DCI может включать в себя три PDCCH кандидатов.

На Фиг. 11B показан пример осуществления передачи PDCCH и BD в случае совместного использования пространства поиска. Для удобства, предполагается, что составляются пространства поиска, соответствующие трем несущим (или CIF). Каждое пространство поиска может соответствовать любой из пары связанных DL CC-UL CC, DL CC или UL CC. На чертеже, предполагается, что размеры трех пространств поиска могут различаться, и уровни агрегации CCE PDCCH кандидатов в каждом пространстве поиска могут различаться. Например, пространство поиска для CC #1 может иметь уровень агрегации CCE, равный 1, и пространство поиска для CC #2/#3 может иметь уровень агрегации CCE, равный 2, 4 или 8. На чертеже, PDCCH (или PDCCH кандидаты) (CIF=CC #X) (X=1, 2, 3) может иметь один и тот же формат DCI или различные форматы DCI.

Случай 1 Фиг. 11B демонстрирует случай совместного использования всех пространств поиска. Таким образом, PDCCH кандидаты пространств поиска для CC #1-#3 имеют одинаковый размер полезной нагрузки DCI. Поскольку все пространства поиска совместно используются, PDCCH можно передавать через PDCCH кандидаты любого из пространств поиска, составленных для каждой CC. Таким образом, PDCCH кандидаты можно передавать через любое из пространств поиска, составленных для каждой CC. Согласно чертежу, PDCCH (CIF=CC #2) передается через пространство поиска для CC #1, и PDCCH (CIF=CC #1) и PDCCH (CIF=CC #3) можно передавать через пространство поиска для CC #2. Соответственно, UE осуществляет BD в отношении PDCCH кандидатов пространств поиска для CC #1-#3 для отыскания PDCCH (CIF=CC #X) (X=1, 2, 3), исходя из того, что PDCCH (или PDCCH кандидаты) (CIF=CC #X) (X=1, 2, 3) можно передавать через пространство поиска для CC #1, пространство поиска для CC #2 или пространство поиска для CC #3.

Случай 2 на Фиг. 11B демонстрирует случай, когда пространства поиска являются частично совместно используемыми. Для удобства, предполагается, что пространства поиска для CC #1/CC #3 совместно используются. Таким образом, PDCCH кандидаты пространств поиска для CC #1/CC #3 имеют одинаковый размер полезной нагрузки DCI, и PDCCH кандидаты пространства поиска для CC #2 имеют другой размер полезной нагрузки DCI, отличный от PDCCH кандидатов пространств поиска для CC #1/CC #3. Согласно чертежу, PDCCH (или PDCCH кандидаты) (CIF=CC #3) можно передавать через любое из совместно используемых пространств поиска. Соответственно, UE осуществляет BD только в отношении PDCCH кандидатов пространств поиска для CC #1/#3, исходя из того, что PDCCH (или PDCCH кандидаты) (CIF=CC #3) можно передавать через пространство поиска для CC #1 или пространство поиска для CC #3. Напротив, для подтверждения PDCCH (CIF=CC #2), UE осуществляет BD только в отношении PDCCH кандидатов пространств поиска для CC #2.

На Фиг. 12 показан способ составления пространств поиска PDCCH, если режимы передачи DL CC заданы равными 1, 1 и 4 при том же условии, что и на фиг. 11A.

Согласно Фиг. 12, BS составляет пространства поиска для каждой CC и сравнивает размеры формата DCI для всех CC. В результате этого сравнения, размеры форматов 1A DCI для трех DL CC одинаковы, размеры форматов 1 DCI для двух CC одинаковы, и только формат 2 DCI имеет другой размер. Соответственно, BS унифицирует три пространства поиска для формата 1A DCI и унифицирует два пространства поиска для формата 1 DCI. Соответственно, BS может передавать формат 1A DCI (CIF=DL CC #1) через PDCCH кандидат любого из пространства поиска для DL CC #1, пространства поиска для DL CC #2 и пространства поиска для DL CC #3. Аналогично, BS может передавать формат 1 DCI (CIF=DL CC #X) (X=1, 2) через PDCCH кандидат любого из пространства поиска для DL CC #1 и пространства поиска для DL CC #2. Напротив, поскольку формат 2 DCI имеет уникальный размер, пространство поиска для формата 2 DCI не является совместно используемым и отображается для каждой CC. Таким образом, формат 2 DCI (CIF=DL CC #3) можно передавать через пространство поиска только для DL CC #3.

Ниже приведено более подробное описание применительно к максимальному числу MaxBD осуществления BD. В случае MaxBD=36, пространства поиска для BD формата 1A DCI включают в себя 18 (=6×3) PDCCH кандидатов по аналогии с примером, представленным на Фиг. 11A. Пространство поиска формата 1 DCI может включать в себя 12 (=6×2) PDCCH кандидатов унифицированного расширенного пространства поиска, и пространство поиска формата 2 DCI может включать в себя шесть PDCCH кандидатов. Если MaxBD сокращается до 24, число раз осуществления BD для каждого формата DCI должно снижаться. Если предполагается, что число раз осуществления BD для каждого формата DCI остается постоянным, число раз осуществления BD для каждого формата DCI уменьшается до 4. В этом случае, пространство поиска для форматов 1A, 1 и 2 DCI может, соответственно, состоять из 12, 8 и 4 PDCCH кандидатов. Аналогично, в случае MaxBD=18, количество PDCCH кандидатов для форматов 1A, 1 и 2 DCI может быть равно 9, 6 и 3, соответственно.

На Фиг. 13 показана схема, демонстрирующая другой пример составления пространств поиска PDCCH. Хотя на Фиг. 11-12 показан случай, когда только одна DL CC задана как DL CC мониторинга PDCCH, множество DL CC можно задавать как набор DL CC мониторинга PDCCH. Если количество CC в наборе CC мониторинга PDCCH равно L, согласно Фиг. 13, можно применять способ ограничения (MaxBD)/L максимально допустимым числом раз осуществления BD для каждой CC мониторинга или применения различных весовых коэффициентов к CC мониторинга (например, DL CC привязки) (т.е. по-разному ограничивать максимально допустимое число раз осуществления BD для каждой CC мониторинга). BS может заранее задавать способ составления пространств поиска согласно количеству CC мониторинга, или UE может автоматически задавать его при ограничении MaxBD.

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

Вариант осуществления 2: сокращение пространства поиска для PDCCH, планируемых между CC

Для удобства, PDCCH, передаваемый через особую CC, который осуществляет назначение ресурсов в отношении канала данных соответствующей CC, определяется как PDCCH собственной CC, и PDCCH, который осуществляет назначение ресурсов в отношении канала данных CC, отличной от соответствующей CC, определяется как PDCCH между CC. В этом случае, для сокращения числа раз осуществления BD на особой CC и, предпочтительно, на DL CC мониторинга PDCCH, можно сокращать как пространство поиска для PDCCH собственной CC, так и пространство поиска для PDCCH между CC. Предпочтительно, пространство поиска для PDCCH между CC сокращается в большей степени, чем пространство поиска для PDCCH собственной CC. Альтернативно, пространство поиска для PDCCH собственной CC можно не сокращать, и можно сокращать только пространство поиска для PDCCH между CC.

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

На Фиг. 14 показан пример составления пространств поиска PDCCH в режимах 1, 3 и 4 передачи DL CC в состоянии, в котором агрегируются три DL CC. Для удобства, предполагается, что ширина полосы у всех CC одинакова, и DL CC #1 задана как DL CC мониторинга PDCCH.

Согласно Фиг. 14, размеры форматов 1A DCI для трех CC одинаковы, и форматы 1, 2A и 2 DCI соответственно имеют уникальные размеры. Соответственно, могут совместно использоваться пространства поиска для формата 1A DCI. На чертеже, MaxBD=36 указывает случай, когда максимальное число раз осуществления BD не сокращается. В этом случае, число раз осуществления BD для каждого формата DCI будет равно 6 (=36/6), и пространства поиска для форматов 1A, 1, 2A и 2 DCI соответственно включают в себя 18 (=6×3), 6, 6 и 6 PDCCH кандидатов. Напротив, если MaxBD сокращается до 24, пространство поиска для PDCCH собственной CC можно оставить неизменным, и пространство поиска для PDCCH между CC можно сократить. Например, отношение размера пространства поиска для PDCCH собственной CC к размеру пространства поиска для PDCCH между CC для каждой CC (например, DL CC без мониторинга) можно задать равным 2:1. В этом случае, пространство поиска для PDCCH собственной CC включает в себя 12 PDCCH кандидатов, и пространство поиска, для PDCCH между CC для каждой CC без мониторинга включает в себя шесть PDCCH кандидатов. Соответственно, число раз осуществления BD для каждого формата DCI CC мониторинга будет равно 6 (=12/2) и число раз осуществления BD для каждого формата DCI CC без мониторинга будет равно 3 (=6/2). В итоге, поскольку формат 1A DCI используется в трех CC, пространство поиска включает в себя всего 12 (=6+3+3) PDCCH кандидатов. Напротив, формат 1 DCI, используемый только в DL CC #1 (мониторинга), может иметь шесть PDCCH кандидатов, и форматы 2A и 2 DCI, используемые только в DL CC #2 и #3 (без мониторинга), могут иметь три PDCCH кандидата.

На Фиг. 15 показан пример составления пространств поиска для BD PDCCH в режимах передачи 1, 1 и 4 DL CC при том же условии, что и на Фиг. 14. Для удобства, предполагается, что ширина полосы у всех CC одинакова, и DL CC #1 задана как DL CC мониторинга PDCCH.

Согласно Фиг. 15, размеры форматов 1A DCI для трех CC одинаковы, размеры форматов 1 DCI для двух CC одинаковы, и только формат 2 DCI имеет уникальный размер. Соответственно, могут совместно использоваться три пространства поиска для формата 1A DCI, и могут совместно использоваться два пространства поиска для формата 1 DCI. На чертеже, MaxBD=36 указывает, что максимальное число раз осуществления BD не сокращается. В этом случае, число раз осуществления BD для каждого формата DCI будет равно 6 (=36/6), и пространства поиска для форматов 1A, 1 и 2 DCI соответственно включают в себя 18 (=6×3), 12 (=6×2) и 6 PDCCH кандидатов. Напротив, если MaxBD сокращается до 24, пространство поиска для PDCCH собственной CC можно оставить неизменным и пространство поиска для PDCCH между CC можно сокращать. Например, отношение размера пространства поиска для PDCCH собственной CC к размеру пространства поиска для PDCCH между CC для каждой CC (например, DL CC без мониторинга) можно задать равным 2:1. В этом случае, пространство поиска для PDCCH собственной CC включает в себя 12 PDCCH кандидатов, и пространство поиска для PDCCH между CC для каждой CC без мониторинга включает в себя шесть PDCCH кандидатов. Соответственно, число раз осуществления BD для каждого формата DCI CC мониторинга будет равно 6 (=12/2), и число раз осуществления BD для каждого формата DCI CC без мониторинга будет равно 3 (=6/2). В итоге, поскольку формат 1A DCI используется в трех CC, пространство поиска включает в себя всего 12 (=6+3+3) PDCCH кандидатов. Аналогично, поскольку формат 1 DCI используется в двух CC, пространство поиска включает в себя всего 9 (=6+3) PDCCH кандидатов. Напротив, формат 2 DCI, используемый только в DL CC #3 (без мониторинга), может иметь три PDCCH кандидата.

Вариант осуществления 3: унификация размера информации (например, DCI)

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

Если (форматы) DCI сгруппированы в единый размер, пространства поиска для него могут совместно использоваться, как описано в варианте осуществления 1. Соответственно, пространства поиска можно расширять пропорционально количеству (форматов) DCI, сгруппированных в единый размер. Использование/неиспользование настоящего способа и параметр настоящего способа могут задаваться BS для каждого UE, для каждой группы UE или соты или могут автоматически задаваться UE в пределах максимально допустимого числа (MaxBD) раз осуществления BD.

На Фиг. 16 показана схема, демонстрирующая пример составления пространств поиска для BD PDCCH, в режимах 1, 3 и 4 передачи DL CC в состоянии, в котором агрегируются три DL CC. Предполагается, что ширина полосы DL CC #1 равна ширине полосы DL CC #2, но отличается от ширины полосы DL CC #3, и DL CC #1 задана как DL CC мониторинга PDCCH. Соответственно, размеры формата 1A DCI для двух CC (DL CC #1 и #2) одинаковы (унифицированный F1) и формат 1A DCI (формат 3-1A) для DL CC #3 и форматы 1, 2A и 2 DCI соответственно имеют уникальные размеры. В настоящем примере, предполагается, что порог для согласования размера DCI задан равным 3 битам.

Согласно Фиг. 16, если MaxBD равен 36 битам, и битовое заполнение не осуществляется, то число раз осуществления BD для каждого формата DCI равно 6, и пространства поиска для унифицированного F1 (40 битов), формата 3-1A (44 бита), 1-1 (48 битов), 2-2A (53 бита) 3-2 (55 битов) соответственно включают в себя 12 (=6×2), 6, 6, 6 и 6 PDCCH кандидатов. Напротив, если MaxBD сокращается до 24, и битовое заполнение осуществляется, то формат DCI, удовлетворяющий условию заполнения (т.е. разность размеров DCI составляет 3 бита или менее) является форматом 2-2A и форматом 3-2 ((формат 3-2: 55 битов)-(формат 2-2A: 53 бита)=2 бита <3 битов). Соответственно, формат 2-2A заполняется 2 битами и формат 2-2A и формат 3-2 можно группировать в единый размер (унифицированный F2). Поскольку число раз осуществления BD для каждого формата DCI равно 4, пространства поиска для унифицированного F1, формата 1-1, унифицированного F2 и формата 3-1A могут соответственно включать в себя 8 (=4×2), 4, 8 (=4×2), 4 PDCCH кандидата. В результате, две DCI (формат 2-2A и формат 3-2) группируются в один размер, пространства поиска удвоенных размеров совместно используются, и степень свободы в планировании DCI может, по существу, удваиваться.

Фиг. 16 демонстрирует случай, когда унификация размера DCI (или согласование размера DCI) осуществляется, если максимальное число, раз MaxBD осуществления BD сокращается. Однако это всего лишь иллюстрация, и унификация размера DCI (или согласование размера DCI) настоящего изобретения применима независимо от того, сокращается ли MaxBD.

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

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

Хотя выше был проиллюстрирован случай, в котором настоящее изобретение применяется к DL CC, теперь подробно рассмотрим способ составления пространств поиска PDCCH применительно к UL CC. Прежде, чем перейти к описанию, следует отметить, что размер каждого пространства поиска, составленного для каждой пары DL/UL CC, DL CC или UL CC, можно определять пропорционально максимальному количеству PDCCH, которое можно передавать через пространство поиска, или ему можно присваивать весовые коэффициенты. Для удобства, хотя в следующем чертеже один формат DCI для каждой DL CC или UL CC задан согласно режиму передачи, можно задавать множество (два или более) форматов DCI. Как и формат 0/1A DCI традиционной системы LTE, можно задать DL/UL общий формат DCI.

В пространствах поиска, которые рассматривают DL/UL CC, можно независимо составлять пространство поиска для DL CC и пространство поиска для UL CC [схема 1] или для каждой пары связанных DL/UL CC можно составлять одно пространство поиска [схема 2].

[Схема 1] Случай, когда пространство поиска для DL CC и пространство поиска для UL CC составляются независимо

На Фиг. 17 показан случай асимметричной агрегации CC, в котором агрегируются три DL CC и две UL CC. Согласно Фиг. 17, пространство поиска для каждой DL CC и пространство поиска для каждой UL CC можно составлять независимо. В этом случае, (форматы) DCI, имеющие одинаковый размер независимо от DL/UL, могут совместно использовать пространства поиска, соответствующие CC, как описано в варианте осуществления 1. Кроме того, для уменьшения числа раз осуществления BD и увеличения степени свободы в планировании, варианты осуществления 2 и 3 можно применять совместно/отдельно.

[Схема 2] Случай, когда пространство поиска составляется для каждой пары связанных DL/UL CC

1) Пространства поиска составляются для каждой пары связанных DL/UL CC. В случае асимметричной агрегации CC, в котором количество DL CC и количество UL CC различны, несвязанные CC могут составлять пространства поиска для каждой DL CC или UL CC. В результате, суммарное количество составленных пространств поиска может соответствовать большему из суммарного количества DL CC и суммарного количества UL CC. (Форматы) DCI DL/UL, имеющие одинаковый размер, совместно используют пространства поиска, соответствующие парам CC, как описано в варианте осуществления 1. Кроме того, для уменьшения числа раз осуществления BD и увеличения степени свободы в планировании, варианты осуществления 2 и 3 можно применять совместно/отдельно.

1-a) случай симметричной агрегации CC (т.е. количество DL CC = количество UL CC): пространства поиска составляются для каждой пары связанных DL/UL CC (см. фиг. 18).

1-b) Случай агрегации CC с преобладанием DL (т.е. количество DL CC> количество UL CC): пространства поиска составляются для каждой пары связанных DL/UL CC, и пространства поиска составляются для каждой DL CC в отношении несвязанных DL CC (см. фиг. 19).

1-c) случай агрегации CC с преобладанием UL (т.е., количество DL CC< количество UL CC): пространства поиска составляются для каждой пары связанных DL/UL CC, и пространства поиска составляются для каждой UL CC в отношении несвязанных UL CC.

2) Если пространство поиска, составленное для каждой несвязанной CC (DL или UL) является SS типа A, и пространство поиска, составленное для каждой пары связанных DL/UL CC, является SS типа B, размер SS типа A может быть меньше или равен размера SS типа B.

2-a) Если предполагается, что можно планировать максимум один PDSCH/PUSCH для каждой CC независимо от DL/UL, согласно Фиг. 20, поскольку через SS типа A можно передавать максимум один PDCCH (планирование DL или UL), и через SS типа B можно передавать максимум два PDCCH (планирование DL+UL), отношение размера SS типа A к размеру SS типа B можно задать равным 1:2.

3) форматы DCI, имеющие одинаковый размер независимо от DL/UL, совместно используют унифицированное пространство поиска, как описано в варианте осуществления 1.

4) для уменьшения числа раз осуществления BD и увеличения степени свободы в планировании, варианты осуществления 2 и 3 можно применять совместно/отдельно.

Хотя, в настоящем изобретении, возможно планирование между CC для всех DL/UL CC, назначенных UE из DL CC мониторинга PDCCH, планирование между CC можно устанавливать для осуществления в отношении ограниченного количества групп DL/UL CC. Установление планирования между CC может изменяться согласно DL CC мониторинга PDCCH. Если используется множество DL CC мониторинга PDCCH, (форматы) DCI, имеющие одинаковый размер совместно используют соответствующие пространства поиска на соответственной CC мониторинга. Если (форматы) DCI, имеющие одинаковый размер, присутствуют между CC мониторинга, соответствующие пространства поиска могут совместно использоваться. Пространства поиска могут совместно использоваться между CC мониторинга без ограничения в установлении планирования между CC. Для сокращения числа раз осуществления BD, размеры пространств поиска, совместно используемых между (форматами) DCI, имеющими одинаковый размер, можно дополнительно сокращать. Например, если размеры множества (форматов) DCI одинаковы, только часть (одно) из пространств поиска для (форматов) DCI можно назначать в качестве пространства поиска, совместно используемого между (форматами) DCI или множество пространств поиска для (форматов) DCI совместно сокращается для составления одного совместно используемого пространства поиска. Кроме того, отношение размера пространства поиска, совместно используемого между (форматами) DCI, имеющими одинаковый размер, можно задавать пропорционально количеству (форматов) DCI, совместно использующих соответствующее пространство.

МОДЕЛИРОВАНИЕ

Была оценена вероятность блокировки PDCCH в случаях применения или неприменения совместного использования SS для форматов DCI одного и того же размера. Гипотеза моделирования приведена в таблице 5. Распределение уровня агрегации CCE для планирования PDCCH (%) также приведено в таблице 6.

На Фиг. 21 и 22 показана вероятность блокировки PDCCH согласно совместному использованию SS, когда 2 CC агрегируются для каждого UE, и полосы PDCCH CC составляют 10 МГц, 20 МГц, соответственно. Согласно фигурам, наблюдается, что общую вероятность блокировки PDCCH можно значительно снизить (более чем на 25% и 33% в полосах 10 МГц и 20 МГц, соответственно) за счет применения совместного использования SS по сравнению со случаем отсутствия совместного использования SS.

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

Согласно Фиг. 23, система беспроводной связи включает в себя базовую станцию (BS) 110 и пользовательское оборудование (UE) 120. Базовая станция 110 включает в себя процессор 112, память 114 и радиочастотный (РЧ) блок 116. Процессор 112 может быть сконфигурирован для реализации процедур и/или способов, предусмотренных в настоящем изобретении. Память 114 соединена с процессором 112, и в ней хранятся различные виды информации, относящейся к работе процессора 112. РЧ блок 116 соединен с процессором 112 и передает и/или принимает радиосигнал. Пользовательское оборудование 120 включает в себя процессор 122, память 124 и радиочастотный (РЧ) блок 126. Процессор 122 может быть сконфигурирован для реализации процедур и/или способов, предусмотренных в настоящем изобретении. Память 124 соединена с процессором 122, и в ней хранятся различные виды информации, относящейся к работе процессора 122. РЧ блок 126 соединен с процессором 122 и передает и/или принимает радиосигнал. Базовая станция 110 и/или пользовательское оборудование 120 может иметь одну антенну или множественные антенны.

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

Варианты осуществления настоящего изобретения были описаны на основании передачи и приема данных между базовой станцией и пользовательским оборудованием. Конкретная работа, которая была описана как осуществляемая базовой станцией, может осуществляться узлом, расположенным выше базовой станции, что может иметь место. Другими словами, очевидно, что различные операции, осуществляемые для связи с пользовательским оборудованием в сети, которая включает в себя множество узлов сети, в том числе базовую станцию, может осуществляться базовой станцией или узлами сети, отличными от базовой станции. Термин «базовая станция» можно заменить другими терминами, например «фиксированная станция», «Node B», «eNode B (eNB)» и «точка доступа». Также, термин «пользовательское оборудование» можно заменить другими терминами, например «мобильная станция (MS)» и «мобильная абонентская станция (MSS)».

Варианты осуществления согласно настоящему изобретению можно реализовать различными средствами, например аппаратными, программно-аппаратными, программными или их комбинацией. Если вариант осуществления согласно настоящему изобретению реализован аппаратно, вариант осуществления настоящего изобретения можно реализовать посредством одной(го) или более специализированных интегральных схем (ASIC), цифровых сигнальных процессоров (DSP), устройств обработки цифрового сигнала (DSPD), программируемых логических устройств (PLD), вентильных матриц программируемых пользователем (FPGA), процессоров, контроллеров, микроконтроллеров, микропроцессоров и т.д.

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

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

ПРОМЫШЛЕННАЯ ПРИМЕНИМОСТЬ

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