Поиск вслепую PDCCH и декодирование DCI

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

Введение

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

Чтобы сформировать полезную нагрузку PDCCH, DCI подвергается кодированию канала: сложение прикрепления CRC сопровождается сверточным кодированием и уровнем, соответствующим согласно способности формата PDCCH. Закодированные биты DCI т.е. полезная нагрузка PDCCH, затем сопоставлены, чтобы Управлять Элементами Канала (CCEs) согласно формату PDCCH. Эти закодированные биты затем преобразованы, чтобы объединить модулируемые символы после выполнения операций включая скремблирование, модуляцию QPSK, отображение слоя и предварительное кодирование. Наконец, модулируемые символы чередованы и сопоставлены с физическими Элементами Ресурса (REs).

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

Управляйте областью

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

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

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

PDCCH и форматы DCI

Количество CCEs в передаче PDCCH зависит от формата PDCCH, который может быть 0, 1, 2, и 3 в зависимости от количества битов, которые будут переданы. Биты PDCCH создаются из сообщения DCI после выполнения прикрепления CRC, кодирования канала и соответствия уровня. Несколько PDCCHs могут быть переданы в подкадре таким образом, 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 для управляющей информации передачи Нескольких входов нескольких выходов (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, скремблирование, модуляция, предварительное кодирование, перемежение и отображение слоя выполняются, чтобы сформировать комплексные символы. Эти комплексные символы теперь готовы быть сопоставленными на REs. REs заданы в терминах REGs/CCEs, выделенного передаче. Количество выделенного CCEs дано форматом PDCCH. Область управления подкадра является набором CCEs и может содержать PDCCHs для нескольких UEs таким образом, UE должен контролировать большую площадь, чтобы извлечь ее собственную управляющую информацию. Когда UE явным образом не сообщают о подробной структуре канала управления, это должно вслепую попытаться декодировать область управления. К сожалению, это может наложить существенную нагрузку на UE как в большой пропускной способности, область управления может быть очень большой. Это может превысить практические аппаратные ограничения и привести к увеличенной стоимости и/или уменьшаемой производительности UE.

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

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

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

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

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

Пространство поиска UE-Specific

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

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

Пример генерация 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 включая устранение чередования, циклическую перемену, deprecoding, слой demapping, 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 будет замаскирован с идентификатором индикации разбивки на страницы т.е. Разбивкой-на-страницы-RNTI (P-RNTI). Если PDCCH будет содержать информацию о системе, идентификатор информации о системе т.е. информация-RNTI о системе (SI-RNTI) будут использоваться, чтобы замаскировать CRC.

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

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

decDCI массив ячеек структур, содержащих поля, сопоставленные с одним или несколькими, декодировал сообщение (сообщения) DCI. Когда несколько PDCCHs могут быть переданы в подкадре таким образом, UE должен контролировать весь возможный PDCCHs, направленный на него.

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 "Процедуры физического уровня"

Для просмотра документации необходимо авторизоваться на сайте