Устройство и способ для индентификации ресурсов формата 3 pucch

Изобретение относится к системе беспроводной связи и предназначено для обеспечения более высоких скоростей передачи данных, улучшения эффективности пользовательского оборудования и ассоциированного с ним способа, предназначенного для идентификации ресурса, чтобы использовать его для передачи управляющей информации в формате 3 физического управляющего канала восходящей линии связи (PUCCH). Способ содержит прием (610) индекса ресурса из обслуживающей базовой станции и идентификацию (620) ресурса, чтобы использовать его для передачи управляющей информации в подкадре на основе принятого индекса ресурса, причем идентифицированный ресурс находится в одном и том же ограниченном наборе блоков физических ресурсов, независимо от того, используется ли обычный и укороченный формат 3 PUCCH в подкадре. 2 н. и 14 з.п. ф-лы, 15 ил., 6 табл.

 

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

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

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

Долгосрочное развитие (LTE) Проекта партнерства 3-го поколения (3GPP) является проектом таким, чтобы улучшить стандарт универсальной мобильной телекоммуникационной системы (UMTS), чтобы удовлетворить будущие требования в отношении улучшенных услуг, такие как более высокие скорости передачи данных, улучшенная эффективность и пониженные затраты. Универсальная наземная сеть радиодоступа (UTRAN) является сетью радиодоступа UMTS, а развитая UTRAN (E-UTRAN) является сетью радиодоступа системы LTE. В E-UTRAN пользовательское оборудование (UE) 150 соединено беспроводным способом с радиобазовой станцией (RBS) 110а, обычно упомянутой как eNodeB или eNB (развитой NodeB), как проиллюстрировано на фиг.1. В E-UTRAN eNodeB 110а-с непосредственно соединены с базовой сетью (CN) 190. Систему LTE иногда также называют системой связи развитого универсального наземного радиодоступа (E-UTRA). В системе LTE используют мультиплексирование с ортогональным частотным разнесением (OFDM) в нисходящей линии связи, т.е. в передаче из eNodeB в UE, и используют OFDM, расширенное дискретным преобразованием Фурье, (DFTS) в восходящей линии связи, т.е. в передаче из UE в eNodeB.

Основные физические ресурсы нисходящей линии связи LTE могут рассматриваться как частотно-временная сетка, как проиллюстрировано на фиг.2а, где каждый элемент ресурса соответствует одной поднесущей OFDM в течение интервала, равного одному символу OFDM. Во временной области передачи нисходящей линии связи LTE организованы в радиокадры, равные 10 мс, причем каждый радиокадр состоит из десяти подкадров одинакового размера, длины $$T_{subframe}=1$$ мс, как проиллюстрировано на фиг.2b. Кроме того, назначение ресурса в LTE обычно описывают в единицах блоков ресурсов, также называемых блоками физических ресурсов (PRB), где блок ресурсов соответствует одному слоту, равному 0,5 мс, во временной области и двенадцати непрерывным поднесущим в частотной области, как проиллюстрировано на фиг.3а. Блоки ресурсов пронумерованы в частотной области, начиная с 0 от одного конца ширины полосы системы.

Передачи нисходящей линии связи планируют динамически, т.е. в каждом подкадре базовая станция или eNodeB передает управляющую информацию, включающую в себя информацию о том, в какие UE или терминалы передаются данные, и на основе каких блоков ресурсов передаются данные в текущем подкадре нисходящей линии связи. Эту управляющую сигнализацию обычно передают в первых 1, 2, 3 и 4 символах OFDM в каждом подкадре. Система нисходящей линии связи с тремя символами OFDM для управляющей сигнализации проиллюстрирована на фиг.2с.

LTE использует гибридный автоматический запрос повторения (HARQ). После приема данных нисходящей линии связи в подкадре UE пытается декодировать их и сообщает в eNodeB, было ли декодирование успешным или нет. Подтверждение приема посылают в виде ACK, когда декодирование является успешным, и в виде NACK, когда декодирование является неуспешным. В случае неуспешной попытки декодирования eNodeB может повторно передать ошибочные данные.

Управляющая сигнализация восходящей линии связи из UE в eNodeB содержит, помимо подтверждений приема HARQ для принятых данных нисходящей линии связи:

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

- отчеты UE, ассоциированные с условиями канала нисходящей линии связи, обычно упоминаемые как отчеты о статусе канала, используемые в качестве помощи для планирования нисходящей линии связи eNodeB.

Такую управляющую информацию восходящей линии связи называют управляющей информацией уровня 1 и уровня 2 (L1/L2). Если UE еще не назначен ресурс восходящей линии связи для передачи данных, управляющую информацию L1/L2 передают в ресурсах восходящей линии связи, конкретно назначенных для управления L1/L2, в физическом управляющем канале восходящей линии связи (PUCCH). Как проиллюстрировано на фиг.3а, эти ресурсы могут быть расположены на краях полной доступной ширины полосы соты. Каждый такой ресурс состоит из 12 поднесущих в каждом из двух слотов подкадра восходящей линии связи, т.е. пары блоков ресурсов или PRB. Для того чтобы обеспечить разнесение частоты, эти частотные ресурсы подвергают скачкообразной перестройке частоты на границе слота, т.е. один ресурс состоит из 12 поднесущих в нижней части спектра в первом слоте подкадра и ресурсов одинакового размера в верхней части спектра в течение второго слота подкадра, или наоборот. Если больше ресурсов требуются для управляющей сигнализации L1/L2 восходящей линии связи, например, в случае очень большой общей ширины полосы передачи, поддерживающей большое число пользователей, дополнительные блоки ресурсов могут быть назначены после ранее назначенных блоков ресурсов в частотной области.

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

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

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

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

Имеются разные форматы PUCCH, определенные в стандарте LTE 3GPP, чтобы управлять разными типами управляющей сигнализации восходящей линии связи. В Rel-8 LTE определен ресурс формата 1 PUCCH, и его используют либо для подтверждения приема HARQ, либо для запроса планирования. Формат 1 PUCCH допускает максимум два бита информации на подкадр. Так как отчет о статусе канала состоит из множества бит в каждом подкадре, формат 1 PUCCH, очевидно, не может быть использован для сигнализации отчетов о статусе канала. Передачей отчетов о статусе канала в PUCCH вместо этого управляют посредством формата 2 PUCCH, который допускает множество битов информации в каждом подкадре. Фактически имеются три варианта этого формата PUCCH: формат 2 PUCCH, формат 2а PUCCH и формат 2b PUCCH. Ради простоты далее в настоящей заявке все они будут упомянуты как формат 2 PUCCH.

Однако с введением агрегирования несущих (CA) в Rel-10 LTE требуется новый формат PUCCH. В Rel-10 LTE полный доступный спектр может быть шире, чем максимальная несущая LTE 20 MГц, соответствующая полному доступному спектру в Rel-8, и может казаться как некоторое число несущих LTE для UE в Rel-8 LTE. Каждая такая несущая может называться компонентной несущей (СС) или сотой. Чтобы гарантировать эффективное использование широкой несущей также для существующих UE, используют СА, предполагая, что UE Rel-10 LTE может принимать множество СС, где СС имеют или, по меньшей мере, им дана возможность иметь ту же структуру, что и несущая в Rel-8. СА схематически проиллюстрировано на фиг.4, где пять СС, равные 20 MHz, обеспечивают полную агрегированную ширину полосы, равную 100 MГц. Однако другим случаем использования для СА является случай, когда оператор использует меньшие части ширин полосы в разных полосах частот или в одной и той же полосе частот, чтобы получить одну большую агрегированную ширину полосы. С СА требуется формат PUCCH, который дает возможность передачи по обратной связи множества битов HARQ, соответствующих множеству СС. Такой формат PUCCH в дальнейшем упомянут как формат 3 PUCCH. Однако формат 3 PUCCH также может быть упомянут как формат PUCCH СА или формат PUCCH DFTS-OFDM.

Зондирующие опорные сигналы (SRS), передаваемые UE, могут быть использованы базовой станцией, чтобы оценивать качество канала восходящей линии связи для больших ширин полос вне диапазона, назначенного конкретному UE. SRS конфигурируют периодически в подкадре и передают в последнем символе DFTS-OFDM подкадра. Это предполагает потребность как в обычном формате 3 PUCCH, чтобы использовать, когда никакие SRS не передают в подкадре, так и в укороченном формате 3 PUCCH, который приглушают в последнем символе DFTS-OFDM подкадра, чтобы избежать конфликтов с передачами SRS, когда их передают в подкадре. Количество UE, которые могут совместно использовать ресурс формата 3 PUCCH, таким образом, может изменяться в зависимости от того, используется ли укороченный или обычный формат 3 PUCCH.

Раскрытие изобретения

С позиции конфигурации сети представляет интерес иметь одинаковое количество ресурсов, используемых для формата 3 PUCCH во всех подкадрах. Ресурсы формата 3 PUCCH, наиболее вероятно, должны быть назначены на краю полосы вместе с форматом 2 PUCCH и форматом 1 PUCCH. Однако тот факт, что меньше UE могут совместно использовать ресурс формата 3 PUCCH в подкадре, где передают SRS, и используют укороченный формат 3 PUCCH, будет иметь тот результат, что будет назначено больше блоков ресурсов для формата 3 PUCCH, когда SRS передают в том же подкадре, что и PUCCH, по сравнению с тем, когда не передают никаких SRS. Традиционным решением для проблемы изменения необходимости ресурса было бы избыточно обеспечивать ресурсы формата 3 PUCCH таким образом, чтобы формат 3 PUCCH мог расширяться в большее количество блоков ресурсов в случае подкадров, в которых используют формат 3 PUCCH, без риска конфликта с другими передачами. Однако недостатком является субоптимальное использование ресурса, которое влияет на пропускную способность и производительность системы.

Другим подходом было бы назначение ресурсов для формата 2 PUCCH и формата 1 PUCCH таким образом, чтобы они не конфликтовали с расширенным размером укороченного формата 3 PUCCH вместо избыточного обеспечения ресурсов формата 3 PUCCH. Однако это возможно, только если периодичности, используемые для ресурсов формата 2 PUCCH и формата 1 PUCCH, являются четными кратными величинами к величинам периодичностей подкадров, зарезервированных для передачи SRS.

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

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

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

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

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

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

Фиг.1 - блок-схема, иллюстрирующая сеть LTE, в которой могут быть выполнены варианты осуществления.

Фиг.2а иллюстрирует физические ресурсы нисходящей линии связи LTE.

Фиг.2b иллюстрирует структуру временной области LTE.

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

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

Фиг.3b иллюстрирует пример назначения блоков ресурсов для разных форматов PUCCH.

Фиг.4 иллюстрирует агрегирование несущих из пяти компонентных несущих 20 MГц.

Фиг.5а-5b иллюстрируют схему передачи для обычного и укороченного формата 3 PUCCH, соответственно.

Фиг.6а-6с - блок-схемы последовательности этапов способа, выполняемого UE, в соответствии с вариантами осуществления.

Фиг.7 - блок-схема, иллюстрирующая устройство в UE, которое может выполнять способ, проиллюстрированный в блок-схемах последовательности этапов фиг.6а-6с.

Фиг.8а-8b - блок-схемы, иллюстрирующие UE, в соответствии с вариантами осуществления.

Осуществление изобретения

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

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

Варианты осуществления изобретения описаны здесь со ссылкой на конкретные примерные сценарии. Конкретные аспекты описаны, в не ограничивающем общем контексте, относительно системы Rel-10 LTE. Все же следует заметить, что варианты осуществления также могут быть применены к другим типам беспроводных систем связи, использующих формат 3 PUCCH. Пользовательское оборудование (UE) в вариантах осуществления включает в себя, например, мобильные телефоны, пейджеры, гарнитуры, портативные переносные компьютеры и другие мобильные терминалы.

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

Формат 1 PUCCH

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

Запросы планирования используют, чтобы запрашивать ресурсы для передачи данных восходящей линии связи. Очевидно, запрос планирования должен быть передан, только когда UE запрашивает ресурсы, иначе UE должно молчать, для того, чтобы экономить ресурсы батареи и не создавать излишних помех. Следовательно, в отличие от подтверждений приема HARQ, в запросе планирования не передают никакого явного бита информации, вместо этого информацию передают посредством наличия или отсутствия энергии в соответствующем PUCCH. Однако запрос планирования несмотря на то, что используется для совершенно разных целей, совместно использует тот же формат PUCCH, что и подтверждение приема HARQ. Этот формат упомянут как формат 1 PUCCH в спецификациях LTE 3GPP.

Ресурс формата 1 PUCCH, используемый либо для подтверждения приема HARQ, либо для запроса планирования, представляют посредством одного скалярного индекса ресурса. UE не знает, какие физические ресурсы сконфигурированы для PUCCH, оно знает только индекс ресурса. Из индекса получают циклический сдвиг фазы и ортогональные последовательности покрытия. Для передачи HARQ индекс ресурса, чтобы использовать для передачи подтверждения приема HARQ, задают неявно посредством управляющей сигнализации нисходящей линии связи в физическом управляющем канале нисходящей линии связи (PDCCH), используемом, чтобы планировать передачу нисходящей линии связи в UE. Таким образом, ресурсы для использования для подтверждения приема HARQ восходящей линии связи изменяются динамически и зависят от управляющего канала нисходящей линии связи, используемого для планирования UE в каждом подкадре.

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

Таким образом, в итоге, ресурсы формата 1 PUCCH разделяют на две части:

1. Полустатическую часть, используемую для запросов планирования и подтверждений приема HARQ от периодически планируемых UE. Количество ресурсов, используемых для полустатической части ресурсов формата 1 PUCCH, не изменяется динамически.

2. Динамическую часть, используемую для динамически планируемых UE. Так как число динамически планируемых терминалов изменяется, изменяется количество ресурсов, используемых для динамических PUCCH.

Формат 2 PUCCH

Отчеты о статусе канала используют, чтобы обеспечивать eNodeB оценкой свойств канала в UE, для того, чтобы поддерживать планирование, зависящее от канала. Отчет о статусе канала состоит из множества битов в каждом подкадре. Формат 1 PUCCH, который допускает максимум два бита информации на подкадр, очевидно, не может быть использован для этой цели. Вместо этого передачей отчетов о статусе канала в PUCCH управляют посредством формата 2 PUCCH, который допускает множество битов информации в каждом подкадре.

Формат 2 PUCCH основан на циклическом сдвиге фазы той же специфической для соты последовательности, что и формат 1 PUCCH. Аналогично формату 1 PUCCH, ресурс формата 2 PUCCH может быть представлен посредством индекса ресурса, из которого получают циклический сдвиг фазы и другие необходимые величины. Ресурсы формата 2 PUCCH конфигурируют полустатически.

Отображение блоков ресурсов для PUCCH

Управляющие сигналы L1/L2, описанные выше для обоих из форматов 1 и 2 PUCCH, как уже объяснено, передают в паре блоков ресурсов с одним блоком ресурсов в каждом слоте. Пару блоков ресурсов для использования определяют из индекса ресурса PUCCH. Номер блока ресурсов для использования в первом и втором слотах подкадра может быть выражен как:

RBnumber(i)=f(idex PUCCH, i),

где i - номер слота (0 или 1) в подкадре, а f - функция, найденная в спецификации 3GPP.

Множество пар блоков ресурсов может быть использовано для того, чтобы увеличить пропускную способность управления-сигнализации, когда одна пара блоков ресурсов является полной, следующий индекс ресурса PUCCH отображают в следующую пару блоков ресурсов подряд. Отображение, в принципе, выполняют таким образом, что формат 2 PUCCH, используемый для отчетов о статусе канала, передают ближайшим к краям ширины полосы соты восходящей линии связи со следующей полустатической частью формата 1 PUCCH и, в конце концов, с динамической частью формата 1 PUCCH в самой отдаленной от краев части ширины полосы, как проиллюстрировано на фиг.3b.

Три полустатических параметра используют, чтобы определять ресурсы для использования для разных форматов PUCCH:

- $$N_{RB}^{(2)}$$ , обеспеченный как часть системной информации, управляет тем, в какой паре блоков ресурсов начинается отображение формата 1 PUCCH;

- $$N_{PUCCH}^{(1)}$$ управляет разделением между полустатической и динамической частью формата 1;

- $$N_{cs}^{(1)}$$ управляет смесью формата 1 и формата 2 PUCCH в одном блоке ресурсов. В большинстве случаев конфигурирование выполняют таким образом, что два формата PUCCH отображают в отдельные наборы блоков ресурсов, но также имеется возможность иметь границу между форматом 1 и 2 в блоке ресурсов.

Агрегирование несущих

Стандарт Rel-8 LTE недавно стандартизован в 3GPP, поддерживая ширины полос до 20 MГц. Однако, для того, чтобы удовлетворить требования для усовершенствованной международной мобильной связи (IMT) концепции Международного союза электросвязи (ITU), 3GPP начал работу по Rel-10 LTE. Одна из частей Rel-10 LTE относится к поддержке ширины полос больших чем 20 MГц. Одним важным требованием в Rel-10 LTE является гарантировать обратную совместимость с Rel-8 LTE. Это также должно включать в себя совместимость спектра. Из этого следовало бы, что несущая Rel-10 LTE шире 20 MГц должна казаться как некоторое число несущих LTE для UE Rel-8 LTE. Каждая такая несущая может называться компонентной несущей (СС). В частности, для начальных развертываний Rel-10 LTE можно ожидать, что будет меньшее число UE, совместимых с Rel-10 LTE, по сравнению с множеством существующих UE LTE. Следовательно, необходимо обеспечить эффективное использование широкой несущей также для существующих UE, т.е. можно осуществлять несущие, где существующие UE могут быть запланированы во всех частях несущей Rel-10 LTE широкой полосы. Простым способом получения этого является агрегирование несущих (СА). СА предполагает, что UE Rel-10 LTE может принимать множество СС, где СС имеют или, по меньшей мере, им дана возможность иметь ту же структуру, что и несущая Rel-8. СА схематически проиллюстрировано на фиг.4, где пять СС, равные 20 MГц, обеспечивают полную агрегированную ширину полосы, равную 100 MГц.

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

Сначала UE Rel-10 LTE ведет себя аналогично UE Rel-8 LTE и будет сконфигурировано с одной парой СС UL/DL, на которой оно выполняет первоначальный производный доступ. Эти СС называют первичными компонентными несущими (РСС). Помимо пары PCC восходящей линии связи (UL)/нисходящей линии связи (DL), eNB, в зависимости от функциональных возможностей и сети UE, может сконфигурировать UE с дополнительными СС так называемыми вторичными компонентными СС (SCC), по мере необходимости. Это конфигурирование основано на конфигурации радиоресурсов (RRC). Вследствие интенсивной сигнализации и довольно медленной скорости сигнализации RCC предусматривается, что UE может быть сконфигурировано с множеством СС, даже если не все из них используют в текущий момент. Чтобы избежать того, что UE должно осуществлять мониторинг всех сконфигурированных СС DL для PDCCH и физического совместно используемого канала нисходящей линии связи (PDSCH), что приводит к более высокому потреблению мощности, Rel-10 LTE поддерживает активацию СС наверху конфигурации. Поскольку активация основана на сигнализации управления доступом к среде (MAC), которая является более быстрой, чем сигнализация RRC, активация и деактивация может зависеть от числа СС, которые требуются для того, чтобы удовлетворить текущие потребности в скорости передачи данных. После поступления больших объемов данных активируется множество СС, используемых для передачи данных, и они деактивируются, если больше не требуются. Могут быть деактивированы все, за исключением одной СС, PCC нисходящей линии связи. Следовательно, активация обеспечивает возможность конфигурировать множество СС и активировать их только по мере необходимости. Большую часть времени UE имела бы одну или очень мало активированных СС, что дает в результате более низкую ширину полосы приема и, следовательно, расход батареи.

Планирование СС выполняют в PDCCH посредством назначений нисходящей линии связи. Управляющую информацию в PDCCH форматируют как сообщение управляющей информации нисходящей линии связи (DCI). В Rel-8 UE работает только с одной DL и одной СС UL, и, таким образом, понятна связь между назначением DL, разрешениями UL и соответствующими СС DL и UL. В Rel-10 должны быть различены два режима СА. Первый режим работы является очень похожим на работу множества терминалов Rel-8, назначение DL или разрешение UL, содержащееся в сообщении DCI, переданном на СС, является справедливым либо для самой СС DL, либо для ассоциированных СС UL, ассоциированных посредством связывания, либо специфического для соты, либо специфического для UE. Второй режим работы расширяет сообщение DCI посредством поля указателя несущей (CIF). DCI, содержащая назначение DL с CIF, является справедливой для СС DL, указанной посредством CIF, а DCI, содержащая разрешение UL с CIF, является справедливой для указанной СС UL.

Сообщения DCI для назначений нисходящей линии связи содержат, помимо прочего, назначение блока ресурсов, параметры, ассоциированные со схемой модуляции и кодирования, и избыточную версию HARQ. Помимо параметров, которые относятся к фактической передаче нисходящей линии связи, большинство форматов DCI для назначений нисходящей линии связи также содержат поле бит для команд управления мощностью передачи (ТРС). Эти команды ТРС используют, чтобы управлять характером управления мощностью UL соответствующего PUCCH, который используют, чтобы передавать обратную связь HARQ.

Передача PUCCH с агрегированием несущих

Когда вводят поддержку СА в Rel-10 LTE, требуется формат PUCCH, который дает возможность передачи по обратной связи множества бит HARQ, соответствующих множеству СС, как будет объяснено ниже. Такой формат PUCCH в дальнейшем упомянут как формат 3, что является терминологией, используемой в стандарте 3GPP. Эквивалентными терминами являются формат PUCCH СА и формат PUCCH DFTS-OFDM. Формат 1 PUCCH также может быть упомянут как PUCCH Rel-8.

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

Следовательно, передача PUCCH не имеет зависимости от конфигурации СС UL/DL, т.е. так как в качестве принципа конструирования вся управляющая информация UL для UE полустатическим способом отображается в одну конкретную СС UL, то PCC UL также упоминается как базовая несущая. Кроме того, существует специфическое для соты связывание между PCC UL и PCC DL, т.е. все терминалы, совместно использующие одну и ту же PCC DL, будут иметь одну и ту же PCC UL. В асимметричном сценарии развертывания, тем не менее, возможно, что множество СС DL специфическим для соты образом связано с одной и той же PCC UL.

UE, которые сконфигурированы только с PCC DL и PCC UL, выполняют операцию динамического ACK/NACK в PUCCH, в соответствии со спецификацией Rel-8, т.е. в ресурсе формата 1 PUCCH, как описано ранее. Первый элемент управляющего канала (ССЕ), используемый, чтобы передавать PDCCH для назначения DL, определяет или идентифицирует динамический ресурс ACK/NACK в формате 1 PUCCH. Если только одна СС DL специфическим для соты образом связана с PCC UL, никакие конфликты PUCCH не могут иметь места, поскольку все PDCCH передают с использованием разной первой ССЕ.

В асимметричном для соты сценарии СА множество СС DL специфическим для соты образом могут быть связаны с одной и той же CC UL. Разные UE, сконфигурированные с одной и той же CC UL, но с разной CC DL, совместно используют одну и ту же PCC UL, хотя они имеют разные PCC DL. UE, принимающие свои назначения DL на разных СС DL, будут передавать свою обратную связь HARQ на одной и той же СС UL. В этом случае планирование eNB должно гарантировать, что никакие конфликты PUCCH не имеют места.

Можно расширить эту концепцию даже на UE, которые имеют множество сконфигурированных CC DL. Каждый PDCCH, передаваемый на PCC DL, в соответствии с Rel-8, имеет ресурс PUCCH, зарезервированный на PCC UL. Если UE сконфигурировано с множеством СС DL, но принимает только одно назначение РСС DL, оно, тем не менее, могло бы использовать ресурс формата 1 PUCCH на PCC UL. Альтернативой было бы использовать формат 3 PUCCH, который дает возможность передавать по обратной связи биты HARQ, соответствующие определенному числу сконфигурированных СС, также для одного назначения РСС DL. Однако, поскольку конфигурирование является довольно медленным процессом, а UE часто может быть сконфигурировано с множеством СС, даже если только СС DL является активной и используемой, это привело бы к неэффективному использованию ресурсов формата 3 PUCCH.

После приема назначений DL на одной SCC или приема множества назначений DL должен быть использован формат 3 PUCCH. Хотя в последнем случае является очевидным использовать формат 3 PUCCH, так как он является единственным форматом, который поддерживает передачу по обратной связи битов HARQ множества СС, менее явным является использование формата 3 PUCCH в первом случае. Однако только назначение SCC DL является нетипичным. Планировщик eNB должен стараться планировать одно назначение СС DL на PCC DL и стараться деактивировать SCC, если они не требуются. Другой проблемой является то, что PDCCH для назначения SCC DL передают на SCC при допущении, что CIF не сконфигурировано, и, следовательно, нет автоматически зарезервированного ресурса формата 1 PUCCH на PCC UL в этом случае. Использование ресурса формата 1 PUCCH, даже для автономных назначений SCC DL, потребовало бы резервирования ресурсов формата 1 PUCCH на PCC UL для любой СС DL, которая сконфигурирована посредством любого UE, использующего эту PCC UL. Поскольку автономные назначения SCC являются нетипичными, это привело бы к излишнему избыточному обеспечению ресурсов формата 1 PUCCH на PCC UL.

Возможным ошибочным случаем, который может иметь место, является то, что eNB планирует UE на множестве СС DL, включая PCC. Если UE не в состоянии декодировать все, за исключением назначения PCC DL, оно будет использовать формат 1 PUCCH вместо формата 3 PUCCH. Чтобы обнаружить этот ошибочный случай, eNB должен осуществлять мониторинг как формата 1 PUCCH, так и формата 3 PUCCH.

В зависимости от числа фактически принятых назначений DL, UL должно обеспечить соответствующее число битов обратной связи HARQ. В первом случае UE могло бы принять формат 3 PUCCH, в соответствии с числом принятых назначений, и, таким образом, обеспечить обратную связь. Однако PDCCH с назначениями DL может потеряться, и принятие формата 3 PUCCH, в соответствии с принятыми назначениями DL, следовательно, является неоднозначным и потребовало бы проверки множества разных гипотез в eNB.

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

Следовательно, базирование формата PUCCH на числе сконфигурированных СС, по-видимому, является самым надежным выбором, и он принят для систем, использующих дуплексную связь с частотным разделением, в стандарте LTE 3GPP. Конфигурирование СС основано на сигнализации RRC, как уже упомянуто ранее. После успешного приема и применения новой конфигурации сообщение подтверждения посылают обратно, таким образом, делая конфигурацию, основанную на сигнализации RRC, очень надежной. Недостатком сигнализации RRC является относительно медленная скорость и то, что число используемых в текущий момент СС не может отслеживаться, что приводит к потере эффективности, когда число фактически используемых СС меньше, чем число сконфигурированных несущих.

Формат 3 PUCCH

Фиг.5а изображает блок-схему одного варианта осуществления схемы передачи для обычного формата 3 PUCCH, который основан на DFTS-OFDM для UE, поддерживающих более четырех битов ACK/NACK. Множество битов ACK/NACK, которые также могут включать в себя биты информации запроса планирования и/или биты информации статуса канала, кодируют 501, 502, чтобы сформировать 48 закодированных битов. Затем закодированные биты шифруют 503 посредством специфических для соты и, возможно, зависящих от символа DFTS-OFDM последовательностей. 24 бита передают в первом слоте в каждом символе DFTS-OFDM, а другие 24 бита передают во втором слоте в каждом символе DFTS-OFDM. 24 бита на каждый символ DFTS-OFDM преобразуют 504 в 12 символов QPSK, перемножают с ортогональной последовательностью покрытия во временной области [w(0)…w(4)] в пяти символах DFTS-OFDM, предварительно кодируют с дискретным преобразованием Фурье (DFT) и передают в одном блоке ресурсов в частотной области и в пяти символах во временной области. Ортогональная последовательность покрытия во временной области является специфической для UE и дает возможность мультиплексирования до пяти UE в одном и том же блоке ресурсов. Пример ортогональной последовательности, которая могла бы быть использована, изображен в таблице 1, где каждая ортогональная последовательность идентифицирована посредством индекса ортогональной последовательности $$n_{oc}$$ , $$N_{SF\mathrm{,0}}^{PUCCH}$$ соответствует числу ортогональных последовательностей, доступных для PRB в первом слоте, т.е. слоте 0, подкадра. В этом варианте осуществления $$N_{SF\mathrm{,0}}^{PUCCH}$$ равно 5.

Для символов опорных сигналов могут быть использованы циклически сдвинутые последовательности нулевой автокорреляции постоянной амплитуды (CAZAC). Чтобы еще дополнительно улучшить ортогональность между опорными сигналами, ортогональный код покрытия длины два $$\left[\overline{w}(0),\overline{w}(1)\right]$$ может быть применен к символам опорных сигналов.

Таблица 1

Когда SRS сконфигурированы в подкадре, их передают в последнем символе DFTS-OFDM подкадра. Это предполагает необходимость специального укороченного формата 3 PUCCH, который приглушен в последнем символе DFTS-OFDM подкадра, переносящего SRS. Это приглушение выполняют для того, чтобы избежать конфликтов с передачами SRS из других UE, когда SRS и PUCCH передают в одном и том же подкадре.

Один вариант осуществления схемы передачи для такого укороченного формата 3 PUCCH проиллюстрирован на блок-схеме фиг.5b. Различием между фиг.5b и фиг.5а является то, что последний символ DFTS-OFDM проколот таким образом, что UE не создает помехи другим UE, которые передают SRS в том же блоке ресурсов, что и передают формат 3 PUCCH. Преимуществом укороченного формата 3 PUCCH является то, что UE, передающее PUCCH, имеет возможность послать SRS в последнем символе DFTS-OFDM во втором слоте подкадра без передачи множества кластеров. Однако, так как последний символ DFTS-OFDM во втором слоте подкадра проколот, будет возможным мультиплексировать только четырех пользователей в одной и той же паре блоков ресурсов в этом варианте осуществления. Пример четырехточечной ортогональной последовательности, которая могла бы быть использована, изображен в таблице 2. $$N_{SF\mathrm{,1}}^{PUCCH}$$ соответствует числу ортогональных последовательностей, доступных для PRB во втором слоте, т.е. слоте 1, подкадра. В этом варианте осуществления $$N_{SF\mathrm{,1}}^{PUCCH}$$ равно 4, так как использован укороченный формат 3 PUCCH.

Следовательно, выбор UE использования обычного или укороченного формата 3 PUCCH в конкретном подкадре, в частности, зависит от того, назначил ли eNB шаблон SRS, специфический для соты в этом подкадре, или нет.

Таблица 2

Назначенный ресурс, в котором надо посылать формат 3 PUCCH, может быть задан посредством явной сигнализации, например, посредством сигнализации RRC, и/или посредством динамической явной сигнализации в одном или в нескольких сообщениях DCI. Ресурс также может быть задан посредством неявной сигнализации, например, посредством которой посылают соответствующее сообщение PDCCH на ССЕ. Он также может быть задан посредством комбинации явной и неявной сигнализации.

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

В следующем примере сконфигурированы 15 блоков ресурсов формата 3 PUCCH или PRB. В подкадре, в котором не передают SRS и используют обычный формат 3 PUCCH, 15 ресурсов формата 3 PUCCH могут быть организованы с местоположениями PRB и индексами последовательностей ортогонального кода покрытия (ОСС), заданными в таблице 3.

В подкадре, в котором передают SRS и используют укороченный формат 3 PUCCH, только четыре UE могут совместно использовать один и тот же PRB, вместо пяти. Следовательно, 15 ресурсов формата 3 PUCCH могут быть организованы с местоположениями PRB и индексами последовательностей ОСС, заданными в таблице 4, если используют традиционное отображение блоков ресурсов для PUCCH.

Таким образом, 15 ресурсов формата 3 PUCCH не войдут в тот же набор PRB. Ресурсы, используемые для формата 3 PUCCH, будут распространены в один дополнительный PRB. Это изменение необходимых блоков ресурсов является проблемой, так как сеть в таком случае имеет потребность в избыточном обеспечении ресурсов формата 3 PUCCH в подкадре, в котором использован обычный формат 3 PUCCH, с учетом того, что формат 3 PUCCH должен быть расширен в большее число блоков ресурсов в подкадре, в котором использован укороченный формат 3 PUCCH. Другим подходом было бы назначение ресурсов для формата 2 PUCCH и формата 1 PUCCH таким образом, чтобы они не конфликтовали с расширенным размером укороченного формата 3 PUCCH. Однако это возможно, только если периодичности, используемые для ресурсов формата 2 PUCCH и формата 1 PUCCH, являются четными кратными величинами к величинам периодичностей подкадров, зарезервированных для передачи SRS.

Следовательно, представляет интерес иметь одинаковое количество ресурсов, используемых для формата 3 PUCCH из всех UE, независимо от того, использован ли обычный или укороченный формат 3 PUCCH.

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

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

В этом примере сконфигурированы 15 ресурсов формата 3 PUCCH. В подкадре, в котором использован обычный формат 3 PUCCH, 15 ресурсов формата 3 PUCCH организованы, как проиллюстрировано в таблице 3.

Однако в подкадре, в котором использован укороченный формат 3 PUCCH, 15 ресурсов формата 3 PUCCH организованы с местоположениями PRB и индексами последовательностей ОСС, заданными в таблице 5.

Можно заметить, что, например, индексы 0 и 4 ресурса формата 3 PUCCH используют одинаковые физические радиоресурсы или PRB. Следовательно, эти два радиоресурса не могут быть использованы посредством двух UE в этом подкадре с укороченным форматом 3 PUCCH. Чтобы избежать такого конфликта, сеть может спланировать PUSCH для этих UE так, что только одно будет передавать формат 3 PUCCH. Когда UE запланировано передавать данные PUSCH, управляющая информация, которую обычно передают в PUCCH, вместо этого может быть передана вместе с данными PUSCH, и, таким образом, никакой ресурс формата 3 PUCCH не требуется для этого UE. Однако первый вариант осуществления не вводит такое ограничение планирования, если ресурсы формата 3 PUCCH назначены так, что не более четырех ресурсов занимают любой из сконфигурированных PRB.

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

$$n_{PUCCH}$$ =( $$n_{static\_resource}$$ + $$n_{dynamic\_resource}$$ + $$n_{implicit}$$ )+ $$N_{SF\mathrm{,0}}^{PUCCH}\cdot N_{start}$$ , (1)

где $$n_{static\_resource}$$ - индекс ресурса, назначенный явно и статически посредством использования, например, сигнализации RRC, $$n_{dynamic\_resource}$$ - динамический указатель ресурса, который указывают в одном или нескольких назначениях DL, $$n_{implicit}$$ - неявный указатель ресурса, полученный, например, для одной или нескольких позиций ССЕ назначений DL, $$N_{start}$$ - начальная позиция ресурса формата 3 PUCCH, которая может быть задана некоторым числом PRB от края полосы, $$N_{SF\mathrm{,0}}^{PUCCH}$$ = 5, и $$N_{DFTS-OFDM}$$ - полное число ресурсов формата 3 PUCCH, которые существуют, например, в единицах блоков ресурсов. Если любые из индексов ресурсов или указателей $$n_{static\_resource}$$ , $$n_{dynamic\_resource}$$ , $$n_{implicit}$$ не присутствуют, их устанавливают в ноль в формуле (1).

Блок ресурсов, используемый посредством формата 3 PUCCH, в вариантах осуществления задают посредством:

$$n_{PRB}$$ = $$\lfloor \frac{n_{PUCCH}}{N_{SF\mathrm{,0}}^{PUCCH}}\rfloor$$ $$\begin{array}{ccc}& & \end{array}$$ (2)

Индекс ортогональной последовательности, используемый для формата 3 PUCCH, в вариантах осуществления задают посредством:

$$n_{oc}(n_s)$$ = $$n_{PUCCH}\mathrm{mod}{N}_{SF\mathrm{,1}}^{PUCCH}$$ , $$\begin{array}{ccc}& & \end{array}$$ (3)

где $$N_{SF\mathrm{,1}}^{PUCCH}$$ = 5 в случае, когда используют формат 3 PUCCH, а $$N_{SF\mathrm{,1}}^{PUCCH}$$ = 4 в случае, когда используют укороченный формат 3 PUCCH.

Во втором варианте осуществления ресурс, используемый UE, чтобы передавать формат 3 PUCCH, ограничен, чтобы входить в состав ограниченного набора значений. Пример этого второго варианта осуществления описан далее в настоящей заявке.

В примере 15 ресурсов формата 3 PUCCH сконфигурированы по аналогии с предыдущими примерами. В подкадре, в котором использован обычный формат 3 PUCCH, 15 ресурсов формата 3 PUCCH организованы, как проиллюстрировано в таблице 3.

В подкадре, в котором использован укороченный формат 3 PUCCH, 15 ресурсов формата 3 PUCCH организованы с местоположениями PRB и индексами последовательностей ОСС, заданными в таблице 6.

Можно заметить, что, например, ресурсы 0 и 12 формата 3 PUCCH используют одинаковые физические радиопоследовательности. Следовательно, эти два ресурса формата 3 PUCCH не могут быть использованы посредством двух UE в подкадре с укороченным форматом 3 PUCCH. Чтобы избежать такого конфликта, сеть может спланировать PUSCH для UE так, что только одно из них будет передавать формат 3 PUCCH.

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

$$n_{PUCCH}$$ =( $$n_{static\_resource}$$ + $$n_{dynamic\_resource}$$ + $$n_{implicit}$$ ) $$\mathrm{mod}(N_{SF\mathrm{,1}}^{PUCCH}\cdot N_{DFTS-OFDM})$$ , $$\begin{array}{ccc}& & \end{array}$$ (4)

где $$n_{static\_resource}$$ - индекс ресурса, назначенный явно и статически посредством использования, например, сигнализации RRC, $$n_{dynamic\_resource}$$ - динамический указатель ресурса, который указывают в одном или нескольких назначениях DL, $$n_{implicit}$$ - неявный указатель ресурса, полученный, например, для одной или нескольких позиций ССЕ назначений DL, $$N_{SF\mathrm{,1}}^{PUCCH}$$ = 5 в случае, когда используют формат 3 PUCCH, а $$N_{SF\mathrm{,1}}^{PUCCH}$$ = 4 в случае, когда используют укороченный формат 3 PUCCH. Если любые из индексов ресурсов или указателей $$n_{static\_resource}$$ , $$n_{dynamic\_resource}$$ , $$n_{implicit}$$ не присутствуют, т.е. их не используют, чтобы сигнализировать индекс ресурса, их устанавливают в ноль в формуле (4). Обычно $$N_{SF\mathrm{,1}}^{PUCCH}$$ обеспечивает пропускную способность мультиплексирования или число ортогональных последовательностей, доступных для блока ресурсов во втором слоте данного подкадра, и $$N_{DFTS-OFDM}$$ - полное число ресурсов формата 3 PUCCH, которые существуют, например, в единицах блоков ресурсов.

Блок ресурсов, используемый посредством формата 3 PUCCH, в одном варианте осуществления задают посредством:

$$n_{PRB}$$ = $$\lfloor \frac{n_{PUCCH}}{N_{SF\mathrm{,1}}^{PUCCH}}\rfloor$$ + $$N_{start}$$ , $$\begin{array}{ccc}& & \end{array}$$ (5)

где $$N_{start}$$ - начальная позиция ресурса формата 3 PUCCH, которая может быть задана некоторым числом PRB от края полосы. Ортогональную последовательность, используемую для формата 3 PUCCH, в одном варианте осуществления, задают посредством:

$$n_{oc}(n_s)$$ = $$n_{PUCCH}$$ $$\mathrm{mod}{N}_{SF\mathrm{,1}}^{PUCCH}$$ $$\begin{array}{ccc}& & \end{array}$$ (6)

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

$${\tilde{n}}_{PUCCH}$$ = $$n_{PUCCH-sig}$$ $$\mathrm{mod}{N}_{DFTS-OFDM-PUCCH}$$

$$n_{PRB}$$ = $$f_1({\tilde{n}}_{PUCCH})$$ $$\begin{array}{ccc}& & \end{array}$$ (7)

$$n_{OC}$$ = $$f_2({\tilde{n}}_{PUCCH})$$ ,

где $$n_{PUCCH-sig}$$ - сигнализированный индекс ресурса или индекс ресурса, полученный, например, как сумма неявно или явно сигнализированных индексов ( $$n_{static\_resource}$$ + $$n_{dynamic\_resource}$$ + $$n_{implicit}$$ ), используемых в подкадре, и $$N_{DFTS-OFDM-PUCCH}$$ - полное число ресурсов формата 3 PUCCH, доступных в данном подкадре. Функции $$f_1(n)$$ и $$f_2(n)$$ отображают данный индекс ресурса $$n$$ в PRB и OCC, соответственно.

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

Способ содержит:

- 610: прием индекса ресурса из обслуживающей RBS;

- 620: идентификацию ресурса, чтобы использовать для передачи управляющей информации в подкадре на основе принятого индекса ресурса. Идентифицированный ресурс находится в одном и том же ограниченном наборе PRB, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре.

Фиг.6b - блок-схема последовательности этапов способа в UE, в соответствии с первым вариантом осуществления, описанным выше. Способ содержит первоначальный этап приема 610 индекса ресурса из обслуживающей RBS. Этап 620 идентификации ресурса, чтобы использовать для передачи управляющей информации в подкадре, на основе принятого индекса ресурса, содержит:

- 621: идентификацию PRB на основе принятого индекса ресурса, причем идентифицированный PRB является одним и тем же, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре. PRB в одном варианте осуществления может быть идентифицирован на основе $$n_{PRB}$$ , заданного уравнением (2) выше;

622: идентификацию ортогональной последовательности на основе индекса ортогональной последовательности $$n_{oc}$$ , заданного уравнением (3), приведенным выше.

Фиг.6с - блок-схема последовательности этапов способа в UE, в соответствии со вторым вариантом осуществления, описанным выше. Способ содержит первоначальный этап приема 610 индекса ресурса из обслуживающей RBS. Этап 620 идентификации ресурса, чтобы использовать для передачи управляющей информации в подкадре на основе принятого индекса ресурса, содержит:

- 623: вычисление модифицированного индекса ресурса на основе принятого индекса ресурса и полного числа PRB, доступных для формата 3 PUCCH;

- 624: идентификацию ресурса на основе модифицированного индекса ресурса, причем идентифицированный ресурс находится в одном и том же ограниченном наборе PRB, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре. Модифицированный индекс ресурса может быть вычислен как операция по модулю с принятым индексом ресурса в качестве делимого и полным числом PRB, доступных для формата 3 PUCCH, в качестве делителя. На основе модифицированного индекса ресурса PRB может быть идентифицирован на основе $$n_{PRB}$$ , заданного уравнением (5), приведенным выше. Кроме того, ортогональная последовательность может быть идентифицирована на основе индекса ортогональной последовательности $$n_{oc}$$ , заданного уравнением (6) выше.

UE 800 схематично проиллюстрировано на фиг.8а, в соответствии с вариантами осуществления. UE 800 сконфигурировано, чтобы быть использованным в беспроводной системе связи и чтобы идентифицировать ресурс, чтобы использовать для передачи управляющей информации в формате 3 PUCCH. UE содержит блок 810 приема, выполненный с возможностью принимать индекс ресурса из обслуживающей RBS, и блок 820 идентификации, выполненный с возможностью идентифицировать ресурс, чтобы использовать для передачи управляющей информации в подкадре на основе принятого индекса ресурса, причем идентифицированный ресурс находится в одном и том же ограниченном наборе PRB, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре.

В первом варианте осуществления, описанном выше, блок 820 идентификации выполнен с возможностью идентифицировать PRB на основе принятого индекса ресурса, причем идентифицированный PRB является одним и тем же, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре. Блок 820 идентификации может быть выполнен с возможностью идентифицировать PRB на основе $$n_{PRB}$$ , заданного уравнением (2), приведенным выше. Блок 820 идентификации также может быть выполнен с возможностью идентифицировать ортогональную последовательность на основе индекса ортогональной последовательности $$n_{oc}$$ , заданного уравнением (3), приведенным выше.

Во втором варианте осуществления, описанном выше, блок 820 идентификации выполнен с возможностью вычислять модифицированный индекс ресурса на основе принятого индекса ресурса и полного числа PRB, доступных для формата 3 PUCCH, и идентифицировать ресурс на основе модифицированного индекса ресурса. Идентифицированный ресурс в этом варианте осуществления находится в одном и том же ограниченном наборе PRB, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре. Блок 820 идентификации может быть выполнен с возможностью вычислять модифицированный индекс ресурса как операцию по модулю с принятым индексом ресурса в качестве делимого и полным числом PRB, доступных для формата 3 PUCCH, в качестве делителя. Блок 820 идентификации может быть выполнен с возможностью идентифицировать PRB на основе $$n_{PRB}$$ , заданного уравнением (5) выше. Кроме того, Блок 820 идентификации может быть выполнен с возможностью идентифицировать ортогональную последовательность на основе индекса ортогональной последовательности $$n_{oc}$$ , заданного уравнением (6), приведенным выше.

Блоки, описанные выше со ссылкой на фиг.8а, являются логическими блоками и необязательно соответствуют отдельным физическим блокам.

Фиг.8b схематически иллюстрирует вариант осуществления UE 800, который является альтернативным способом раскрытия варианта осуществления, проиллюстрированного на фиг.8а. UE 800 содержит блок 810 приема, предназначенный для приема индекса ресурса из обслуживающей RBS. UE 800 также содержит блок 854 обработки, который может быть одним блоком или множеством блоков. Кроме того, UE 800 содержит по меньшей мере один компьютерный программный продукт 855 в виде энергонезависимой памяти, например, EEPROM (электрически стираемой программируемой памяти, доступной только по чтению), флэш-памяти или накопителя на диске. Компьютерный программный продукт 855 содержит компьютерную программу 856, которая содержит средства кода, которые при выполнении в UE 800 заставляет блок 854 обработки в UE 800 выполнять этапы процедур, описанных ранее совместно с фиг.6а-с.

Следовательно, в описанных вариантах осуществления средства кода в компьютерной программе 856 UE 800 содержат модуль 856а идентификации для идентификации ресурса, чтобы использовать для передачи управляющей информации в подкадре на основе принятого индекса ресурса, причем идентифицированный ресурс находится в одном и том же ограниченном наборе PRB, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре. Таким образом, средства кода могут быть осуществлены как компьютерный программный код, структурированный в компьютерных программных модулях. Модуль 856а, в частности, выполняет этап 620 последовательности этапов на фиг.6а, чтобы эмулировать узел сети, описанный на фиг.8а. Иначе говоря, когда модуль 856а запущен в блоке 854 обработки, он соответствует блоку 820 фиг.8а.

Хотя средства кода в варианте осуществления, раскрытом выше совместно с фиг.8b, осуществлены как компьютерный программный модуль, который при выполнении в UE 800 заставляет UE выполнять этапы, описанные выше совместно с фиг.6а, одно или более из этих средств кода в альтернативных вариантах осуществления могут быть осуществлены, по меньшей мере, частично как схемы аппаратного обеспечения.

Фиг.7 - блок-схема устройства 700 в UE, которое может осуществлять способ, описанный выше. Будет понятно, что функциональные блоки, изображенные на фиг.7, могут быть объединены или переупорядочены множеством эквивалентных способов и что многие из функций могут быть выполнены посредством одного или более подходящим образом запрограммированных процессоров цифровых сигналов. Кроме того, соединения между функциональными блоками и информация, обеспечиваемая или обмениваемая посредством функциональных блоков, изображенных на фиг.7, могут быть изменены различными способами, чтобы дать возможность UE осуществлять другие способы, включенные в работу UE.

Как изображено на фиг.7, UE принимает радиосигнал DL через антенну 792 и обычно преобразует с понижением частоты принятый радиосигнал в аналоговый сигнал основной полосы в препроцессоре приемника (Fe RX) 704. Сигнал основной полосы спектрально формируют посредством аналогового фильтра 706, который имеет ширину полосы BW $${}_0$$ , и сформированный сигнал основной полосы, сгенерированный посредством фильтра 706, преобразуют из аналогового в цифровой вид посредством аналого-цифрового преобразователя (ADC) 708. Оцифрованный сигнал основной полосы дополнительно спектрально формируют посредством цифрового фильтра 710, который имеет ширину полосы BW $${}_{sync}$$ , которая соответствует ширине полосы сигналов или символов синхронизации, включенных в сигнал DL. Сформированный сигнал, сгенерированный посредством фильтра 710, предоставляют в устройство 712 поиска соты, которое выполняет один или более способов поиска ячеек, как задано для конкретной системы связи, например, LTE 3G. Обычно такие способы включают в себя обнаружение предварительно определенных первичных и/или вторичных сигналов канала синхронизации (P/S-SCH) в принятом сигнале.

Оцифрованный сигнал основной полосы также предоставляют посредством ADC 708 в цифровой фильтр 714, который имеет ширину полосы BW $${}_0$$ , и отфильтрованный цифровой сигнал основной полосы предоставляют в процессор 716, который осуществляет быстрое преобразование Фурье (FFT) или другой подходящий алгоритм, который генерирует представление в частотной области (спектральное представление) сигнала основной полосы. Устройство 718 оценки канала принимает сигналы из процессора 716 и генерирует оценку канала H $${}_{i,j}$$ для каждой из нескольких поднесущих i и ячеек j на основе управляющих сигналов и сигналов синхронизации, предоставленных посредством блока 720 управления, которое также предоставляет такие управляющие сигналы и сигналы синхронизации в процессор 716.

Устройство 718 оценки предоставляет оценку канала H $${}_i$$ в декодер 722 и устройство 724 оценки мощности сигнала. Декодер 722, который также принимает сигналы из процессора 716, подходящим образом сконфигурирован с возможностью извлечения информации из RRC или из других сообщений, как описано выше, и обычно генерирует сигналы, подлежащие дополнительной обработке в UE (не изображена). Устройство оценки 724 генерирует измерения мощности принятого сигнала (например, оценивает мощность принятого опорного сигнала (RSRP), мощность принятой поднесущей S $${}_i$$ , отношение сигнал-шум (SIR) и т.д.). Устройство 724 оценки может генерировать оценки RSRP, качество принятого опорного сигнала (RSRQ), указатель интенсивности принятого сигнала (RSSI), мощность принятой поднесущей $$$$ S $${}_i$$ , SIR и другие соответственные измерения различными способами в ответ на управляющие сигналы, предоставленные посредством блока 720 управления. Оценки мощности, сгенерированные посредством устройства 724 оценки, обычно используют в дополнительной обработке сигнала в UE. Устройство 724 оценки (или устройство 712 поиска для этого предмета) сконфигурировано с возможностью включения в себя подходящего устройства корреляции сигнала.

В устройстве, изображенном на фиг.7, блок управления 720 отслеживает по существу все необходимое, чтобы конфигурировать устройство 712 поиска, процессор 716, устройство 718 оценки и устройство оценки 724. Для устройства 718 оценки это включает в себя как способ, так и опознавательный код соты (для извлечения опорных сигналов и специфического для соты скремблирования опорных сигналов). Связь между устройством 712 поиска и блоком 720 управления включает в себя опознавательный код соты и, например, конфигурацию циклического префикса. Блок 720 управления может определять, какой из нескольких возможных способов оценки использован посредством устройства 718 оценки и/или посредством устройства 724 оценки для измерений в обнаруженной соте (сотах). Кроме того, блок 720 управления, который обычно может включать в себя устройство корреляции или осуществлять функции устройства корреляции, может принимать информацию, сигнализированную посредством сети, и может управлять моментами времени включения/выключения Fe RX 704.

Блок 720 управления предоставляет соответствующую информацию в кодер 726, который генерирует символы модуляции или аналогичную информацию, которую предоставляют в препроцессор входного каскада передатчика (Fe TX) 728, который генерирует сигнал передачи, подходящий для системы связи. Как изображено на фиг.7, сигнал передачи предоставляют в антенну 702. Блок 720 управления с кодером 726 подходящим образом сконфигурирован с возможностью генерации RRC и других сообщений, посылаемых UE в сеть, как описано выше.

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

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

Сокращения

3GPP Проект партнерства третьего поколения

ACK Подтверждение приема

CA Агрегирование несущих

CAZAC Нулевая автокорреляция с постоянной амплитудой

CC Компонентная несущая

CCE Элементы управляющего канала

CIF Поле указателя несущей

CN Базовая сеть

DCI Управляющая информация нисходящей линии связи

DFT Дискретное преобразование Фурье

DFTS Расширенное DFT

DL Нисходящая линия связи

eNB, eNodeB, развитой узел В

E-UTRAN Развитая UTRAN

UTRAN Универсальная наземная сеть радиодоступа

FDD Дуплексная связь с частотным разделением

HARQ Гибридный автоматический запрос повторения

LTE Долгосрочное развитие

МАС Управление доступом к среде

MГц Мегагерц

NACK Отрицательное подтверждение приема

OCC Ортогональный код покрытия

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

PCC Первичная компонентная несущая

PDCCH Физический управляющий канал нисходящей линии связи

PDSCH Физический совместно используемый канал нисходящей линии связи

PRB Блок физических ресурсов

PUCCH Физический управляющий канал восходящей линии связи

RE Элемент ресурса

Rel-10 Версия 10

Rel-8 Версия 8

RRC Конфигурация радиоресурса

SCC Вторичная компонентная несущая

SRS Зондирующие опорные сигналы

TPC Управление мощностью передачи

UE Пользовательское оборудование

UL Восходящая линия связи

UMTS Универсальная мобильная телекоммуникационная система

1. Способ идентификации ресурса, чтобы использовать для передачи управляющей информации в формате 3 физического управляющего канала восходящей линии связи, PUCCH, в пользовательском оборудовании беспроводной системы связи, причем способ содержит этапы, на которых:
- принимают (610) индекс ресурса из обслуживающей радио базовой станции и
- идентифицируют (620) ресурс, чтобы использовать для передачи управляющей информации в подкадре на основе принятого индекса ресурса, причем идентифицированный ресурс находится в одном и том же ограниченном наборе блоков физических ресурсов, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре.

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

3. Способ по п.2, в котором блок физических ресурсов идентифицируют на основе $$n_{PRB}$$ , заданного следующим уравнением:
$$n_{PRB}$$ = $$\lfloor \frac{n_{PUCCH}}{N_{SF\mathrm{,0}}^{PUCCH}}\rfloor$$
где $$n_{PUCCH}$$ - принятый индекс ресурса, а $$N_{SF\mathrm{,0}}^{PUCCH}$$ - число ортогональных последовательностей, доступных для блока физических ресурсов в первом слоте времени подкадра.

4. Способ по любому из предыдущих пунктов, в котором этап, на котором идентифицируют (620) ресурс, содержит идентификацию (622) ортогональной последовательности на основе индекса ортогональной последовательности $$n_{oc}$$ , заданного следующим уравнением:
$$n_{oc}$$ = $$n_{PUCCH}\mathrm{mod}{N}_{SF\mathrm{,1}}^{PUCCH}$$
где $$n_{PUCCH}$$ - принятый индекс ресурса, а $$N_{SF\mathrm{,1}}^{PUCCH}$$ - число ортогональных последовательностей, доступных для блока физических ресурсов во втором слоте времени подкадра.

5. Способ по п.1, в котором этап, на котором идентифицируют (620) ресурс, содержит этапы, на которых
вычисляют (623) модифицированный индекс ресурса на основе принятого индекса ресурса и полного числа блоков физических ресурсов, доступных для формата 3 PUCCH, и
идентифицируют (624) ресурс на основе модифицированного индекса ресурса, причем идентифицированный ресурс находится в одном и том же ограниченном наборе блоков физических ресурсов, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре.

6. Способ по п.5, в котором модифицированный индекс ресурса вычисляют как операцию по модулю с принятым индексом ресурса в качестве делимого и полным числом блоков физических ресурсов, доступных для формата 3 PUCCH, в качестве делителя.

7. Способ по любому из пп. 5, 6, в котором этап, на котором идентифицируют (624) ресурс на основе модифицированного индекса ресурса, содержит идентификацию блока физических ресурсов на основе $$n_{PRB}$$ , заданного следующим уравнением:
$$n_{PRB}$$ = $$\lfloor \frac{{\tilde{n}}_{PUCCH}}{N_{SF\mathrm{,1}}^{PUCCH}}\rfloor$$ + $$N_{start}$$
где $${\tilde{n}}_{PUCCH}$$ - модифицированный индекс ресурса, $$N_{SF\mathrm{,1}}^{PUCCH}$$ - число ортогональных последовательностей, доступных для блока физических ресурсов во втором слоте времени подкадра, и $$N_{start}$$ - начальная позиция ограниченного набора блоков физических ресурсов.

8. Способ по любому из пп. 5, 6, в котором этап, на котором идентифицируют (624) ресурс на основе модифицированного индекса ресурса, содержит идентификацию ортогональной последовательности на основе индекса $$n_{oc}$$ ортогональной последовательности, заданного следующим уравнением:
$$n_{oc}$$ = $${\tilde{n}}_{PUCCH}$$ $$\mathrm{mod}{N}_{SF\mathrm{,1}}^{PUCCH}$$
где $${\tilde{n}}_{PUCCH}$$ - модифицированный индекс ресурса, а $$N_{SF\mathrm{,1}}^{PUCCH}$$ - число ортогональных последовательностей, доступных для блока физических ресурсов во втором слоте времени подкадра.

9. Пользовательское оборудование (800) для беспроводной системы связи, сконфигурированное с возможностью идентификации ресурса, чтобы использовать для передачи управляющей информации в формате 3 физического управляющего канала восходящей линии связи, PUCCH, причем пользовательское оборудование содержит:
- блок (810) приема, выполненный с возможностью принимать индекс ресурса из обслуживающей радио базовой станции, и
- блок (820) идентификации, выполненный с возможностью идентифицировать ресурс, чтобы использовать для передачи управляющей информации в подкадре на основе принятого индекса ресурса, причем идентифицированный ресурс находится в одном и том же ограниченном наборе блоков физических ресурсов, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре.

10. Пользовательское оборудование (800) по п.9, в котором блок (820) идентификации выполнен с возможностью идентифицировать блок физических ресурсов на основе принятого индекса ресурса, причем идентифицированный блок физических ресурсов является одним и тем же, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре.

11. Пользовательское оборудование (800) по п.10, в котором блок (820) идентификации выполнен с возможностью идентифицировать блок физических ресурсов на основе $$n_{PRB}$$ , заданного следующим уравнением:
$$n_{PRB}$$ = $$\lfloor \frac{n_{PUCCH}}{N_{SF\mathrm{,0}}^{PUCCH}}\rfloor$$
где $$n_{PUCCH}$$ - принятый индекс ресурса, а $$N_{SF\mathrm{,0}}^{PUCCH}$$ - число ортогональных последовательностей, доступных для блока физических ресурсов в первом слоте времени подкадра.

12. Пользовательское оборудование (800) по любому из пп. 9-11, в котором блок (820) идентификации выполнен с возможностью идентифицировать ортогональную последовательность на основе индекса ортогональной последовательности $$n_{oc}$$ , заданного следующим уравнением:
$$n_{oc}$$ = $$n_{PUCCH}\mathrm{mod}{N}_{SF\mathrm{,1}}^{PUCCH}$$
где $$n_{PUCCH}$$ - принятый индекс ресурса, а $$N_{SF\mathrm{,1}}^{PUCCH}$$ - число ортогональных последовательностей, доступных для блока физических ресурсов во втором слоте времени подкадра.

13. Пользовательское оборудование (800) по п.9, в котором блок (820) идентификации дополнительно выполнен с возможностью вычислять модифицированный индекс ресурса на основе принятого индекса ресурса и полного числа блоков физических ресурсов, доступных для формата 3 PUCCH, и идентифицировать ресурс на основе модифицированного индекса ресурса, причем идентифицированный ресурс находится в одном и том же ограниченном наборе блоков физических ресурсов, независимо от того, используется ли обычный или укороченный формат 3 PUCCH в подкадре.

14. Пользовательское оборудование (800) по п.13, в котором блок (820) идентификации дополнительно выполнен с возможностью вычислять модифицированный индекс ресурса как операцию по модулю с принятым индексом ресурса в качестве делимого и полным числом блоков физических ресурсов, доступных для формата 3 PUCCH, в качестве делителя.

15. Пользовательское оборудование (800) по любому из пп. 13, 14, в котором блок (820) идентификации выполнен с возможностью идентифицировать блок физических ресурсов на основе $$n_{PRB}$$ , заданного следующим уравнением:
$$n_{PRB}$$ = $$\lfloor \frac{{\tilde{n}}_{PUCCH}}{N_{SF\mathrm{,1}}^{PUCCH}}\rfloor$$ + $$N_{start}$$
где $${\tilde{n}}_{PUCCH}$$ - модифицированный индекс ресурса, $$N_{SF\mathrm{,1}}^{PUCCH}$$ - число ортогональных последовательностей, доступных для блока физических ресурсов во втором слоте времени подкадра, и $$N_{start}$$ - начальная позиция ограниченного набора блоков физических ресурсов.

16. Пользовательское оборудование (800) по любому из пп. 13, 14, в котором блок (820) идентификации выполнен с возможностью идентифицировать ортогональную последовательность на основе индекса $$n_{oc}$$ ортогональной последовательности, заданного следующим уравнением:
$$n_{oc}$$ = $${\tilde{n}}_{PUCCH}$$ $$\mathrm{mod}{N}_{SF\mathrm{,1}}^{PUCCH}$$
где $${\tilde{n}}_{PUCCH}$$ - модифицированный индекс ресурса, а $$N_{SF\mathrm{,1}}^{PUCCH}$$ - число ортогональных последовательностей, доступных для блока физических ресурсов во втором слоте времени подкадра.