PDCCH «Слепой поиск» и декодирование DCI

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

Введение

Для поддержки передачи транспортных каналов нисходящей линии связи и восходящей линии связи требуется управляющая сигнализация совместно используемого канала нисходящей линии связи (DL-SCH) и общего канала восходящей линии связи (UL-SCH). Эта управляющая сигнализация позволяет UE успешно принимать, демодулировать и декодировать DL-SCH. Downlink Control Information (DCI) передана через Физический Канал Контроля за Передачей информации из космоса (PDCCH) и включает информацию о распределении ресурсов DL-SCH (набор блоков ресурса, содержащих DL-SCH), транспортный формат и информация, связанная с Гибридным Автоматическим Повторным запросом DL-SCH (ARQ).

Для формирования полезной нагрузки PDCCH DCI подвергается канальному кодированию: сложение приложения CRC с последующим сверточным кодированием и согласованием скорости в соответствии с пропускной способностью формата PDCCH. Закодированные биты DCI, т.е. полезная нагрузка PDCCH, затем преобразуются в элементы канала управления (CCE) в соответствии с форматом PDCCH. Эти закодированные биты затем преобразуются в комплексные модулированные символы после выполнения операций, включая скремблирование, QPSK модуляцию, отображение слоя и предварительное кодирование. Наконец, модулированные символы перемежаются и преобразуются в физические ресурсные элементы (RE).

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

Область управления

Нисходящая управляющая сигнализация расположена в начале каждого нисходящего субкадра (вплоть до первых трех символов OFDM). Одно из преимуществ передачи канала управления в начале каждого субкадра заключается в том, что если UE не запланировано, то он может выключить свою схему приемника для большей части субкадра, что приводит к снижению потребления степени. Нисходящая управляющая сигнализация передается тремя физическими каналами. Канал индикатора формата физического управления (PCFICH) для указания количества символов OFDM, используемых для сигнализации управления в этом подкадре, Физический канал индикатора гибридного ARQ (PHICH), который содержит подтверждение нисходящей линии связи (ACK )/отрицательное подтверждение (Nack

PDCCH содержит назначения планирования и другую управляющую информацию в форме сообщений DCI. PDCCH передается на одном CCE или агрегировании нескольких последовательных CCE, где CCE соответствует 9 группам ресурсных элементов (REG). В передаче PDCCH используются только те REG, которые не назначены PCFICH или PHICH. Каждый REG содержит 4 ресурсных элемента (RE). Таким образом, REG используются для определения отображения каналов управления на ресурсные элементы.

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

PDCCH и форматы DCI

Количество CCE в PDCCH-передаче зависит от формата PDCCH, который может быть 0, 1, 2 и 3 в зависимости от количества бит, подлежащих передаче. Биты PDCCH создаются из сообщения DCI после выполнения присоединения CRC, кодирования канала и согласования скорости. Несколько PDCCH могут быть переданы в подкадре, таким образом, UE должно контролировать все PDCCH в данной области управления подкадром.

Сообщение DCI передает информацию планирования восходящей или нисходящей линии связи или команду управления степенью передачи (TPC) восходящей линии связи. В зависимости от цели управляющего сообщения определяются различные форматы DCI. Предоставленная информация содержит все необходимое для того, чтобы UE могло идентифицировать ресурсы, необходимые для приема физического канала нисходящих данных (PDSCH) в этом подкадре и декодировать его. Форматы DCI:

  • Формат 0 для передачи распределения UL-SCH

  • Формат 1 для передачи выделения DL-SCH для операции Single Input Multiple Output (SIMO)

  • Формат 1A для компактной передачи выделения DL-SCH для операции SIMO или выделения специальной подписи преамбулы в UE для произвольного доступа

  • Форматируйте 1B для информации управления передачей Multiple Input Multiple Output (MIMO), оцените компактное назначение ресурса 1

  • Формат 1C для очень компактной передачи назначения PDSCH

  • Форматируйте 1D так же, как format1B с дополнительной информацией о смещении степени

  • Формат 2 и Формат 2A для передачи выделения DL-SCH для операции MIMO в закрытом и разомкнутых контурах, соответственно

  • Формат 2B для планирования передачи с двух слоев (порты антенны 7 и 8)

  • Формат 2C для планирования передачи до 8 слоев (порты антенны с 7 по 14) с помощью TM9

  • Формат 2D для планирования передачи до 8 слоев (порты антенны с 7 по 14) с помощью TM10

  • Формат 3 и Формат 3A для передачи команды TPC для канала восходящей линии связи

  • Формат 4 для планирования PUSCH с режимом передачи портов с несколькими антеннами

Пространство поиска и кандидаты PDCCH

После формирования сообщения DCI и кодирования канала в соответствии с требуемым форматом DCI и PDCCH выполняется мультиплексирование PDCCH, скремблирование, модуляция, предварительное кодирование, перемежение и отображение слоя для формирования сложных символов. Эти сложные символы теперь готовы к отображению на RE. RE определяются в терминах REG/CCE, выделенных для передачи. Количество выделенных КЦВ определяется форматом PDCCH. Область управления подкадра является набором CCE и может содержать PDCCH для нескольких UE, таким образом, UE должно контролировать большую область, чтобы извлечь свою собственную управляющую информацию. Поскольку UE не информируется явно о подробной структуре канала управления, он должен слепо пытаться декодировать область управления. К сожалению, это может налагать существенную нагрузку на UE, так как при больших полосах пропускания область управления может быть очень большой. Это может превысить практические аппаратные ограничения и привести к увеличению стоимости и/или снижению эффективности UE.

Для упрощения задачи декодирования в UE вся область управления подразделяется на общие и специфичные для UE пространства поиска, которые UE должно контролировать (попытка декодировать каждый из PDCCH). Каждое пространство содержит 2, 4 или 6 кандидатов PDCCH, длина данных которых зависит от формата PDCCH; каждый PDCCH должен передаваться на 1, 2, 4 или 8 CCE (s) (1 CCE = 9 REGs = 9 * 4 RE = 72 битах).

Кандидаты PDCCH состоят из последовательных КЦВ. Кандидаты в наборе кандидатов PDCCH не должны быть уникальными, особенно для небольших полос пропускания. Общие и специфичные для UE пространства поиска могут перекрываться друг с другом. Размер пространства поиска определяется количеством кандидатов PDCCH и размером уровня агрегирования CCE. То есть размер пространства поиска целочисленно превышает размер уровня агрегирования CCE или количества кандидатов PDCCH.

Общее пространство поиска

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

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

Специфическое для UE пространство поиска

Пространство поиска UE содержит управляющую информацию, специфическую для конкретного UE, и контролируется, по меньшей мере, одним UE в камере. В отличие от поиска в общем пространстве, начальное местоположение пространства поиска UE может изменяться для каждого субкадра или UE. Начальное местоположение пространства поиска UE определяется в каждом подкадре с помощью хеш-функции, как указано в TS36.213, пункт 9 [1].

В специфичном для UE пространстве поиска UE находит свой PDCCH путем мониторинга набора кандидатов PDCCH (набора последовательных CCE, на которых PDCCH может быть отображен) в каждом подкадре. Если ошибка CRC не обнаруживается, когда UE использует свой RNTI для демаскирования CRC (16-битовое значение также относится к C-RNTI) в PDCCH, UE определяет, что PDCCH содержит свою собственную управляющую информацию. Наборы кандидатов PDCCH соответствуют различным форматам PDCCH. Существует 4 формата PDCCH: 0, 1, 2 или 3. Если UE не может декодировать какие-либо кандидаты PDCCH для данного формата PDCCH, он пытается декодировать кандидаты для других форматов PDCCH. Этот процесс повторяется для всех возможных форматов PDCCH до тех пор, пока все ориентированные PDCCH не будут успешно декодированы в специфическом для UE пространстве поиска.

Пример генерации, передачи и восстановления DCI

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

Настройки всей ячейки

Структурный enbConfig используется для конфигурирования eNodeB.

enbConfig.NDLRB = 6;                % No of Downlink RBs in total BW
enbConfig.CyclicPrefix = 'Normal';  % CP length
enbConfig.CFI = 3;                  % 4 PDCCH symbols as NDLRB <= 10
enbConfig.Ng = 'Sixth';             % HICH groups
enbConfig.CellRefP = 1;             % 1-antenna ports
enbConfig.NCellID = 10;             % Physical layer cell identity
enbConfig.NSubframe = 0;            % Subframe number 0
enbConfig.DuplexMode = 'FDD';       % Frame structure

Генерация сообщений DCI

Сгенерируйте сообщение DCI, которое должно быть сопоставлено с PDCCH.

dciConfig.DCIFormat = 'Format1A';   % DCI message format
dciConfig.Allocation.RIV = 26;      % Resource indication value

% Create DCI message for given configuration
[dciMessage, dciMessageBits] = lteDCI(enbConfig, dciConfig);

Кодирование канала DCI

Кодирование канала сообщения DCI включает в себя следующие операции: вставка CRC, сверточное кодирование с уклоном хвоста и согласование скорости. Полевые PDCCHFormat указывает, что один элемент канала управления (CCE) используется для передачи PDCCH, где CCE состоит из 36 полезных ресурсных элементов.

C_RNTI = 100;                         % 16-bit UE-specific mask
pdcchConfig.RNTI = C_RNTI;            % Radio network temporary identifier
pdcchConfig.PDCCHFormat = 0;          % PDCCH format

% DCI message bits coding to form coded DCI bits
codedDciBits = lteDCIEncode(pdcchConfig, dciMessageBits);

Генерация бит PDCCH

Емкость области управления зависит от полосы пропускания, индикатора формата управления (CFI), количества портов антенны и групп HICH. Общее количество ресурсов, доступных для PDCCH, может быть рассчитано с помощью ltePDCCHInfo.

Не все доступные биты в области PDCCH обязательно используются. Поэтому принятая конвенция состоит в том, чтобы установить неиспользованные биты равными -1, в то время как используются местоположения битов со значениями 0 или 1. Первоначально все элементы инициализируются с помощью -1, чтобы указать, что все биты не используются.

pdcchDims = ltePDCCHInfo(enbConfig);

% Initialize elements with -1 to indicate that all the bits are unused
pdcchBits = -1*ones(pdcchDims.MTot, 1);

% Perform search space for UE-specific control channel candidates.
candidates = ltePDCCHSpace(enbConfig, pdcchConfig, {'bits', '1based'});

% Map PDCCH payload on available UE-specific candidate. In this example the
% first available candidate is used to map the coded DCI bits.
pdcchBits ( candidates(1, 1) : candidates(1, 2) ) = codedDciBits;

PDCCH, комплексно-оцененная, модулированная генерация символов

Из набора бит, используемых в pdcchBits (значения, не установленные на -1) генерируются комплексные символы PDCCH. Требуются следующие операции: скремблирование, QPSK модуляция, отображение слоев, предварительное кодирование и перемежение.

pdcchSymbols = ltePDCCH(enbConfig, pdcchBits);

Сложение шума

Комплексные символы PDCCH затем передаются через канал AWGN. Канал генерируется с помощью randn; его отклонение можно настроить путем nVariance. Изменение количества повторных передач может быть моделировано с помощью широкой области значений nVariance параметр.

nVariance = 0.01; % Noise power
noise = complex(randn(size(pdcchSymbols))*sqrt(nVariance/2), ...
        randn(size(pdcchSymbols))*sqrt(nVariance/2));  % Generate noise
pdcchSymbolsNoisy = pdcchSymbols + noise;    % Add noise to PDSCH symbols

Декодирование PDCCH

Выполните обработку приемника PDCCH, включая удаление перемежения, циклическую перемену, амортизацию, демпфирование слоя, мягкую демодуляцию QPSK и дескремблирование.

recPdcchBits = ltePDCCHDecode(enbConfig, pdcchSymbolsNoisy);

Слепое декодирование с использованием поиска DCI

UE информируется только о количестве символов OFDM в области управления подкадра и не обеспечивается местоположением соответствующего PDCCH. UE находит свой PDCCH путем мониторинга набора кандидатов PDCCH в каждом подкадре. Это называется слепым декодированием. UE отключает CRC каждого кандидата управления с помощью временного идентификатора радиосети (RNTI). Если ошибка CRC не обнаружена, UE рассматривает ее как успешную попытку декодирования и считывает управляющую информацию в пределах успешного кандидата.

eNodeB определяет формат PDCCH, который должен быть передан в UE, создает соответствующий DCI и присоединяет CRC. CRC затем маскируется RNTI в соответствии с владельцем или использованием PDCCH. Если PDCCH предназначен для определенного UE, CRC будет маскироваться с помощью уникального идентификатора UE, например Cell-RNTI (C-RNTI). Если PDCCH содержит информацию пейджинга, CRC будет замаскирован идентификатором индикации пейджинга, т.е. Paging-RNTI (P-RNTI). Если PDCCH содержит системную информацию, для маскировки CRC будет использоваться идентификатор системной информации, т.е. системная информация-RNTI (SI-RNTI).

При наличии возможностей различных форматов RNTI, PDCCH, DCI и PDCCH может потребоваться значительное количество попыток для успешного декодирования PDCCH. Чтобы преодолеть эту сложность, UE сначала пытается вслепую декодировать первый CCE в наборе кандидатов канала управления субкадра. Если слепое декодирование прекращается, UE пытается вслепую декодировать первые 2, 4, а затем 8 CCE последовательно, где начальное местоположение фиксируется для общего случая поиска и задается хеш-функцией, как определено в TS36.213, пункт 9 [1], для конкретного случая UE.

ltePDCCHSearch сначала пытается декодировать PDCCH в общем пространстве поиска, прежде чем пытаться в специфичном для UE пространстве поиска. При поиске в общем пространстве поиска он итерирует только два уровня агрегации, то есть 4 и 8, и пытается декодировать все кандидаты PDDCH для всех возможных форматов DCI общего пространства. Специфический для UE поиск осуществляется на четырех уровнях агрегации, то есть 1, 2, 4 и 8. Кандидаты PDCCH генерируются с помощью ltePDCCHSpace. Если ошибка CRC не обнаружена во время попытки декодирования, UE рассматривает ее как успешное декодирование и считывает декодированное сообщение DCI.

decDCI - массив ячеек структур, содержащий поля, сопоставленные с одним или несколькими декодированными сообщениями DCI. Поскольку несколько PDCCH могут быть переданы в подкадре, UE должно контролировать все возможные PDCCH, направленные на него.

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

ueConfig.RNTI = C_RNTI;
ueConfig.ControlChannelType = 'PDCCH';
ueConfig.EnableCarrierIndication = 'Off';
ueConfig.SearchSpace = 'UESpecific';
ueConfig.EnableMultipleCSIRequest = 'Off';
ueConfig.EnableSRSRequest = 'Off';
ueConfig.NTxAnts = 1;
[rxDCI, rxDCIBits] = ltePDCCHSearch(enbConfig, ueConfig, recPdcchBits);
decDCI = rxDCI{1};          % Decoded DCI information
decDCIBits = rxDCIBits{1};  % Decoded DCI bits

Отображение восстановленного RIV

fprintf(['\n\n Blind Decoding successful, the recovered resource '...
       'allocation is ' num2str(decDCI.Allocation.RIV) ' \n\n']);

 Blind Decoding successful, the recovered resource allocation is 26 

Избранная библиография

  1. 3GPP TS 36.213 «Процедуры физического слоя»