Введение

Модель, представленная в этом примере, может использоваться, чтобы найти и декодировать MIB из сигналов нисходящей линии связи LTE. Он основан на примере LTE HDL Cell Search, добавляя этапы обработки для декодирования MIB. Сообщение главного информационного блока (MIB) передается в физическом широковещательном канале (PBCH) и содержит необходимую системную информацию:

Проект оптимизирован для генерации HDL-кода, и архитектура расширяется, позволяя добавлять дополнительные этапы обработки, такие как индексация и декодирование для PCFICH, PDCCH и PDSCH (см. LTE HDL SIB1 Recovery). Этот проект может быть реализована на платформах SoC с помощью аппаратно-программных пакетов совместного проектирования и аппаратной поддержки. См. раздел Развертывание примеров готовых узлов LTE HDL на СнК.

Этапы обработки MIB

В порядок декодирования сообщения MIB этот пример выполняет следующие операции:

Поиск камеры и демодуляция OFDM

Обнаружение сигнала LTE, синхронизация по времени и частоте и демодуляция OFDM выполняются по принятым данным. Это формирует данные сетки и предоставляет информацию о номере подкадра и идентификаторе камеры принятой формы волны. Сообщение MIB всегда передается в подкадре 0, и cellID используется для определения местоположения специфичных для ячейки опорных сигналов (CRS) для оценки канала, а также используется для инициализации последовательности дескремблирования для декодера PBCH.

Буферизация данных сетки

Когда сообщение MIB всегда передается в подкадре 0 нисходящего сигнала, субкадр 0 буферизуется в банке памяти. В то же время, когда субкадр записывается в банк памяти, местоположение CRS вычисляется с использованием cellID, и CRS отправляется в блок оценки канала.

Оценка канала

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

Индексация PBCH

PBCH всегда выделяется центральным 6 ресурсным блокам (RB) субкадров 0 в пределах первого 4 OFDM символов 2-го паза. Он занимает все элементы ресурса (RE) в этой области, исключая местоположения, назначенные CRS. Местоположения CRS вычисляются с помощью cellID, затем адреса RE, занятых PBCH, могут быть вычислены (всего 240 местоположений), и данные, извлеченные из банка сетевой памяти.

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

Когда данные PBCH считываются из банка сетевой памяти, они выравниваются с использованием оценки канала. 240 выравниваемых символов PBCH буферизуются, и предпринимаются попытки декодирования PBCH и BCH для каждой из 4 возможных версий MIB в транспортном блоке PBCH. Каждая из этих версий требует различной последовательности дескремблирования, поэтому для каждой должна быть предпринята попытка дескремблирования, демодуляции, восстановления скорости, сверточного декодирования и проверки CRC. При успешном декодировании значение CRC задает значение cellRefP - количество передающих антенн, и биты MIB могут быть проанализированы, чтобы задать системные параметры.

Архитектура модели

Архитектура реализации LTE HDL Cell Search и MIB Recovery показана на схеме ниже.

Вход приемника является данными I/Q основной полосы, дискретизированными на 30.72 Msps. БПФ с 2048 точками используется для демодуляции OFDM и достаточен для декодирования всех поддерживаемых полос LTE. Ресурсный сетчатый буфер способен хранить один подкадр данных LTE. Как только приемник синхронизируется с камерой, данные от демодулятора OFDM записываются в сеточный буфер. Блок индексации PBCH затем генерирует индексы ресурсных элементов, которые несут PBCH. Эти ресурсные элементы считываются из буфера сетки и выравниваются, перед передачей через декодер PBCH. Эта архитектура спроектирована так, чтобы быть расширяемой и масштабируемой, так что дополнительные функции индексации и декодирования каналов могут быть вставлены по мере необходимости. Например, его можно расширить для выполнения восстановления SIB1, как показано на примере LTE HDL SIB1 Recovery.

Верхний уровень модели ltehdlMIBRecovery показан ниже. HDL-код может быть сгенерирован для подсистемы восстановления LTE MIB HDL.

The ltehdlMIBRecovery_init.m скрипт выполняется автоматически моделью InitFcn коллбэк. Этот скрипт генерирует сигналы стимулирования dataIn и startIn, а также любую из констант, необходимых для инициализации модели. Входные данные могут быть загружены из файла, который, для этого примера, является сигналом LTE, захваченным вне воздуха. Для получения информации о захвате сигналов LTE вне эфира смотрите AD9361/AD9364 LTE Receiver Using Analog Devices (Пакет поддержки Communications Toolbox для Xilinx Zynq-Based Radio). Альтернативно, сигнал LTE может быть синтезирован с использованием функций LTE Toolbox. Чтобы выбрать источник входа, измените loadfromfile параметр в ltehdlMIBRecovery_init.m.

SamplingRate = 30.72e6;
simParams.Ts = 1/SamplingRate;

loadfromfile = true;

if loadfromfile
    load('eNodeBWaveform.mat');
    dataIn = resample(rxWaveform,SamplingRate,fs);
else
    dataIn = hGenerateDLRXWaveform();
end

Оптимизированное восстановление LTE MIB на HDL

Структура подсистемы восстановления LTE MIB HDL представлена ниже. Блок Demod синхронизации нисходящей линии связи выполняет частотную и временную синхронизацию, обнаружение сигнала PSS/SSS и демодуляцию OFDM. Подсистема декодера MIB буферизует подкадр 0 входящих данных, выполняет оценку канала и пытается декодировать PBCH, чтобы восстановить информацию MIB.

Нисходящая синхронизация и демодуляция

Подсистема Demod синхронизации нисходящего канала принимает данные I/Q на 30.72 Msps и выводит неэквализованные данные сетки ресурса нисходящего канала. Это экземпляр модели-ссылки ltehdlDownlinkSyncDemod, который реализует следующие функции:

Операция ltehdlDownlinkSyncDemod описана более подробно в примере LTE HDL Cell Search.

Декодер MIB

Подсистема декодера MIB показана ниже. Он состоит из четырех подсистем: PBCH Indexing, Resource Grid Memory, Channel Equalization и PBCH Decoder. Порядок операций следующий:

Ресурсная сетчатая память

Блок Resource Grid Memory содержит банк памяти, логику для управления чтением и записью банка сетевой памяти и логику для определения местоположения и вывода CRS. Емкость банка памяти является одним субкадром демодулированных данных OFDM при самой большой поддерживаемой полосе пропускания LTE (20 МГц).

MemoryBank Write Controller отвечает за запись подкадров данных в банк памяти. Вход writeSubframe включает контроллер записи для соответствующих подкадров; подрамник 0 в случае настоящего примера. LTE Memory Bank содержит ОЗУ размерностей 14 x 2048 x 16 битовых комплексных чисел; то есть 14 символов ODFM, каждый из которых содержит 2048 комплексные числа. Подсистема rsOutputGen вычисляет местоположения опорных символов камер, извлекает их из данных во время записи в память сетки и выводит их через выходной сигнал gridData.

Выходной порт gridData содержит сигналы CRS от rsOutputGen, когда данные записываются в память сетки (порт gridWriteDone выхода низок) и содержит данные из банка памяти LTE, когда запись в память сетки завершена (порт gridWriteDone выхода высокий).

Индексация PBCH

Блок индексации PBCH вычисляет адреса памяти, необходимые для извлечения PBCH из буфера памяти сетки. Это эквивалентно LTE Toolbox ltePBCHIndices функция. Затем данные, извлеченные из памяти сетки, выравниваются и передаются в декодер PBCH для обработки. Подсистема индексации PBCH становится активной после записи данных для подкадра 0 в память сетки, как показано выходом gridWriteDone Подсистемы памяти сетки ресурса. PBCH всегда составляет 240 символов в длину, с центром в средних поднесущих, в первых 4 символах в пределах 2-го паза подкадра 0.

Оценка и эквализация канала

Блок Эквализация содержит три основные подсистемы. cellRefGen генерирует символы опорного сигнала (CRS) для конкретной ячейки с помощью генератора Последовательности Голда. chEst выполняет оценку канала, принимая две передающие антенны, используя простой, удобный для аппаратных средств алгоритм оценки канала. TxDivDecode выполняет декодирование разнесения передачи, чтобы выровнять фазу принятых данных, используя оценки канала.

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

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

После вычисления оценок канала для каждой из передающих антенн они используются для выравнивания gridData по мере считывания из Ресурсной Сетки Памяти. TxDivDecode выполняет обратное предварительное кодирование для разнесения передачи (как описано в TS 36.211 Раздел 6.3.4.3 [1]) и выдает выравниваемый выходной сигнал, который затем передается в декодер PBCH.

Декодер PBCH

Декодер PBCH выполняет демодуляцию QPSK, дескремблирование, восстановление скорости и декодирование BCH. Затем он извлекает выходные параметры MIB с помощью функционального блока MIB Interpretation. Эти операции эквивалентны ltePBCHDecode и lteMIB функционирует в LTE Toolbox.

The PBCH Controller сохраняет уравненные данные в памяти для итерационных попыток сверточного декодирования. 4 попытки декодирования MIB соответствуют 4 повторениям данных MIB на транспортный блок PBCH.

Декодер BCH

Декодер BCH квантует мягкие решения и затем декодирует данные с использованием блоков LTE Convolutional Decoder и LTE CRC Decoder. Рекомендуемая словесная длина мягких решений на входе в сверточный декодер составляет 4 бита. Однако блок BCH Decoder принимает 20-битовые мягкие решения как вход. Поэтому блок softBitScalingUnit динамически масштабирует данные так, чтобы он использовал полную динамическую область значений 4 бит мягких решений. Блок декодера CRC сконфигурирован, чтобы вернуть полное значение несоответствия контрольной суммы. Маска CRC, после проверки на соответствие допустимым значениям, обеспечивает cellRefP; количество портов антенны опорного сигнала для конкретной ячейки в передатчике. Если контрольная сумма CRC не соответствует одному из принятых значений, то MIB не был успешно декодирован, и контроллер PBCH решает, инициировать или нет другую попытку декодирования.

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

Анализ эффективности

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

Применение cellQualitySearch функцию к захваченной форме волны eNodeBWaveform.mat используется в ltehdlMIBRecovery_init.m возвращает следующий отчет:

FrequencyOffset: 536.8614
NCellID: 76
TimingOffset: 12709
RSRQdB: -5.3654
ReportedRSRQ: 29

FrequencyOffset: 536.8614
NCellID: 160
TimingOffset: 3108
RSRQdB: -18.1206
ReportedRSRQ: 3

В захваченной форме волны имеются две камеры, одна с идентификатором 76 камеры и одна с идентификатором 160 камеры. Камера с NCellID = 76 имеет намного более высокий ReportedRSRQ, что указывает на то, что это более сильный сигнал. В этом примере модель Simulink декодирует MIB для NCellID = 76.

Результаты и отображение

Область возможностей ниже показывает ключевые сигналы управления для этого примера. После того, как импульс введен в сигнал запуска, начинается процесс поиска камеры. Успешное обнаружение камеры обозначается сигналом cellDetected. Когда сигнал cellDetected утверждается, сигнал NCellID и TDDMode становится активным, указывая идентификационный номер камеры и использует ли камера TDD (1) или FDD (0). После того, как камера обнаружена, демодулятор OFDM ожидает, пока подкадр 0 следующие системы координат не начнет выводить данные сетки, следовательно, существует зазор между cellDetected, идущим высоко, и данными сетки, выводимыми, как показано сигналом gridDataValid. Когда gridDataValid впервые заявлен, subfameNum будет нулем и будет увеличиваться для последующих подкадров. Симуляция останавливается на заданных сигналах MIBDetected или mibError.

После обнаружения MIB все сигналы NDLRB, PHICH, Ng, nFrame и CellRefP становятся активными, указывая ключевые параметры камеры. Эти параметры отображаются в модели, так как они являются статическими значениями, когда симуляция остановлена.

Следующая информация MIB декодируется при декодировании захваченной формы волны:

NCellID (Cell ID): 76
TDDMode (0 = FDD, 1 = TDD) : 0
NDLRB (Number of downlink resource blocks): 25
PHICH (PHICH duration) index: 0
Ng (HICH group multiplier): 2
NFrame (Frame number): 262
CellRefP (Cell-specific reference signals): 2

Это указывает, что дуплексный режим, используемый камерой, является FDD, MIB был декодирован в номере 262 системы координат, длительность PHICH является 'Normal', а значение множителя группы HICH - 'One'.

Генерация HDL-кода и верификация

Чтобы сгенерировать HDL-код для этого примера, вы должны иметь лицензию HDL- Coder™. Используйте makehdl и makehdltb команды для генерации HDL-кода и HDL-теста для подсистемы восстановления LTE MIB HDL. Поскольку форма волны входа в этом примере содержит по меньшей мере 40 подкадров для завершения поиска камеры и восстановления MIB, генерация испытательного стенда занимает много времени.

HDL LTE MIB Recovery подсистема была синтезирована на плате оценки ZC706 Xilinx ® Zynq ® -7000. Результаты использования почтовых и маршрутных ресурсов показаны в таблице ниже. Тайминг проекта встретил с тактовой частотой 140 МГц.

       Resource        Usage
    _______________    _____

    Slice Registers    51582
    Slice LUTs         29859
    RAMB18                38
    RAMB36                39
    DSP48                134

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

Ссылки