Генерация сигналов нисходящего канала NB-IoT

Открыть скрипт

В этом примере показано, как сгенерировать Усовершенствованный LTE Pro Узкополосные формы волны IOT Релиза 13 (NB-IOT) для теста и приложений измерения с помощью LTE Toolbox™.

Введение

3GPP ввел новый воздушный интерфейс, Узкополосная IOT (NB-IOT), оптимизированная для низкой машины скорости передачи данных, вводят коммуникации, Усовершенствованные LTE Pro Релиз 13. NB-IoT предоставляет стоимость и улучшения КПД степени, когда это избегает потребности в сигнализации комплекса, наверху требуемой для основанных на LTE систем.

LTE Toolbox может использоваться, чтобы сгенерировать комплексные основополосные формы волны нисходящего канала стандартного совместимого NB-IoT, представляющие узкополосную несущую на 180 кГц, подходящую для приложений измерения и теста. Форма волны состоит из отдельных каналов физического уровня и сигналов и класса значения MATLAB, NBIoTDownlinkWaveformGenerator может использоваться для полной сетки элемента ресурса (RE) и генерации сигналов временного интервала. LTE Toolbox поддерживает все режимы работы NB-IoT - автономная, защитная полоса и внутриполосный.

  • Автономный: несущая NB-IoT развертывается вне спектра LTE, e.g. спектр используется для GSM или спутниковой связи

  • Защитная полоса: несущая NB-IoT, развернутая в защитной полосе между двумя несущими LTE

  • Внутриполосный: несущая NB-IoT, развернутая в блоках ресурса несущей LTE

Внутриполосный режим может быть далее сгруппирован в зависимости от физической идентичности ячейки (PCI), используемой, Внутриполосной-SamePCI и Внутриполосной-DifferentPCI. Если Внутриполосный-SamePCI, идентичность ячейки физического уровня и PCI являются тем же самым, и UE может сделать предположения о портах и образовать канал от сигналов LTE. Режим работы обозначается в ведущем блоке информации NB-IoT (MIB-NB), который предоставляет важную информацию для оборудования пользователя (UE). Сеть может использовать радио-информацию об управлении ресурсами, чтобы выделить несущую непривязки UE, действующему в несущей привязки, видеть TS 36.331 6.7.3.2 [5] и разделить 7.3.2.4 в [9].

Этот пример создает нисходящий канал NB-IoT, где соответствующие каналы физического уровня и сигналы:

  • Узкополосный первичный сигнал синхронизации (NPSS)

  • Узкополосный вторичный сигнал синхронизации (NSSS)

  • Узкополосный опорный сигнал (NRS)

  • Узкополосно передайте физический канал телевизионного вещания (NPBCH)

  • Узкополосно передайте физический нисходящий канал совместно использованный канал (NPDSCH)

  • Узкополосно передайте физический нисходящий канал управления (NPDCCH)

NB-IoT поддерживает две настройки несущей:

  • Привязка: несущая, используемая UE для начального выбора ячейки NB-IoT, получая блоки информации ведущего устройства/системы и произвольный доступ в нерабочем режиме. NPSS, NSSS, NPBCH и информация о системе передаются на несущей

  • Непривязка: несущая только используется для фактического обмена данными в связанном режиме. NPSS, NSSS, NPBCH и информация о системе не передаются на несущей

В этом примере мы демонстрируем, что NB-IoT передает в нисходящем направлении сетку RE и генерацию сигналов. Разделы ниже объясняют физические сигналы и каналы, которые формируют сетку наряду с ключевыми концепциями включая повторение подкадра, логические и транспортные отображения канала и соответствующие сетки для различных настроек. Кроме того, параметры, вовлеченные в генерацию сигналов, как показывают, создают формы волны согласно требованиям пользователя.

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

Выделение подкадра нисходящего канала NB-IoT

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

  • Нисходящий битовый массив: логический вектор, чтобы сконфигурировать NB-IoT передает в нисходящем направлении подкадры. Подкадры нисходящего канала NB-IoT заданы как подкадры, используемые для NPDCCH и NPDSCH, не несущего SIB1-NB, это не включает подкадры, несущие NPSS, NSSS, NPBCH и системный тип 1 (SIB1-NB) блока информации NB-IoT. Подкадры нисходящего канала NB-IoT могут быть сконфигурированы с помощью параметра Config.DownlinkBitmap в классе NBIoTDownlinkWaveformGenerator.

  • NPSS & NSSS: Как проиллюстрировано в рисунке ниже, NPSS передается в подкадре 5 в каждой системе координат, и NSSS передается в подкадре 9 в системах координат с номером системы координат nf выполнение nf mod 2 = 0. NPSS и NSSS позволяют UE синхронизироваться с ячейкой NB-IoT.

  • NPBCH: NPBCH используется, чтобы нести MIB-NB на 34 бита (TS 36.212 6.4.1 [2]). MIB-NB закодирован, чтобы сформировать кодовую комбинацию на 1 600 битов (TS 36.211 10.2.4.1 [1]). Кодовая комбинация равномерно сегментируется на 8 подблоков, у каждого есть 200 битов, которые передаются на подкадре 0 и повторяются в 7 после последовательных систем координат (TS 36.211 10.2.4.4 [1]). Отображение битов кодовой комбинации проиллюстрировано в рисунке ниже.

  • NPDSCH: ключевая возможность NPDSCH является повторением подкадра. NB-IoT задает две схемы повторения случая, когда NPDSCH несет широковещательный канал управления (BCCH) или нет. BCCH является логическим каналом, чтобы нести SIB1-NB, системные информационные сообщения, и т.д. Не перенос BCCH подразумевает, что NPDSCH может нести Канал Управления Разбивкой на страницы (PCCH), Канал Общего контроля (CCCH), Специализированный Канал Управления (DCCH), Специализированный Канал Трафика (DTCH), и т.д. (TS 36.300 6.1.3.2 и 5.3.1a [6]). Две схемы повторения проиллюстрированы в рисунке ниже. Параметры повторения NPDSCH включают количество подкадров в кодовой комбинации NSF и количество повторений NRep. Пример на рисунке показывает шаблон повторения с NRep = 4 для случая, когда NPDSCH несет BCCH и NRep = 8 для случая, когда NPDSCH не несет BCCH и NSF = 3 для обоих случаев. Для случая при переносе BCCH все подкадры кодовой комбинации передаются прежде, чем повторить кодовую комбинацию. Для случая, если не несущего BCCH, подкадр в кодовой комбинации повторяется min(NRep,4) прежде, чем выполнить то же повторение для других подкадров. После того, как кодовая комбинация повторяется min(NRep,4) времена, та же процедура выполняется, пока полное повторение не завершено, т.е. повторенное NRep \times. Подробная спецификация схемы повторения может быть найдена в TS 36.211 10.2.3 [1].

Повторные подкадры, показанные на вышеупомянутом рисунке, сопоставлены с доступными подкадрами, выделенными для передачи NPDSCH. Как типичный пример, следующая фигура иллюстрирует, как выполнить отображение для подкадров NPDSCH, несущего SIB1-NB, который содержит самую важную информацию о системе для UE (TS 36.331 6.7.2 [5]).

SIB1-NB несут в 8 подкадрах (NSF = 8), и сопоставленный с подкадром 4 в любой системе координат в 16 непрерывных системах координат, которые являются повторным NRep времена (NRep = 4, 8 или 16, см. таблицу 16.4.1.3-3 [3] TS 36.213 16.4.1.3). Повторения равномерно распределены в период 256 систем координат (TS 36.331 5.2.1.2a [5]). Стартовый номер системы координат для первой передачи NPDSCH в период зависит от узкополосной физической идентичности ячейки NNCellID а также количество повторений NRep (Таблица 16.4.1.3-4 [3] TS 36.213 16.4.1.3).

Сетка нисходящего канала NB-IoT

В дополнение к выделению подкадра, описанному выше, сгенерированные сетки ниже далее объясняют выделение RE в подкадре. Сетка для двух систем координат несущей привязки, содержащей NPSS, NSSS, NRS, NPBCH, SIB1-NB и подкадры нисходящего канала NB-IoT, несущие NPDSCH и NPDCCH. Сетки сравнены в Standalone и Inband-SamePCI режимы работы. Сетка может быть сгенерирована с помощью метода отображения сетки в классе NBIoTDownlinkWaveformGenerator, т.е. создав объект ngen из типа NBIoTDownlinkWaveformGenerator и вызов ngen.displayResourceGrid.

  • NRS: положения RE могут быть сконфигурированы количеством портов NRS и узкополосной физической идентичности ячейки, т.е. полей NBRefP параметра и NNCellID в структуре ngen.Config, соответственно.

  • NPSS & NSSS: первые 11 поднесущих используются для NPSS, все 12 поднесущих в физическом блоке ресурса используются для NSSS. Первые 3 символа OFDM в подкадре не используются для NPSS/NSSS. NRS не передается ни в каком подкадре, содержащем NPSS/NSSS. REs NPSS/NSSS проколот специфичным для ячейки опорным сигналом (CRS) LTE только во внутриполосных режимах. Количество портов CRS, которое влияет на прокалывание, может быть сконфигурировано полем CellRefP параметра в структуре ngen.Config (TS 36.211 10.2.6 и 10.2.7 [1]).

  • NPBCH: REs проколоты NRS и CRS с помощью максимального количества NRS и портов антенны CRS (2 и 4, соответственно), для обоих режимов работы (TS 36.211 10.2.4 [1]). Это вызвано тем, что UE не знает о количестве используемых портов антенны и режима работы.

  • NPDSCH: Для режимов работы Standalone и Guardband, REs проколот NRS только; для внутриполосных режимов работы REs проколот и NRS и CRS. Когда режим работы является внутриполосным, первые 3 символа OFDM в подкадре не используются для NPDSCH, несущего SIB1-NB, первый ControlRegionSize Символы OFDM в подкадре не используются, когда NPDSCH несет подкадр нисходящего канала NB-IoT. ControlRegionSize поле параметра в структуре ngen.Config чтобы сконфигурировать LTE управляют размером области для выделений NPDSCH RE (TS 36.211 10.2.3.4 [1], TS 36.213 16.4.1.4 [3] и TS 36.331 6.7.2 [5]). Размер области управления LTE конфигурирует запуск положение символа OFDM в подкадре нисходящего канала NB-IoT, несущем NPDSCH и NPDCCH во внутриполосных режимах работы.

  • NPDCCH: NRS и прокалывание CRS совпадают с этим в NPDSCH, описанном выше. Когда режим работы является внутриполосным, первый ControlRegionSize Символы OFDM в подкадре не используются для NPDCCH. То же самое как это для NPDSCH, ControlRegionSize используется, чтобы сконфигурировать выделения NPDCCH RE (TS 36.211 10.2.3.4 [1], TS 36.213 16.4.1.4 [3] и TS 36.331 6.7.2 [5]).

ngen = NBIoTDownlinkWaveformGenerator;

figure;
% Display the resource grid with default 'Standalone' operation mode
ngen.displayResourceGrid;
figure;
% Change the operation mode to 'Inband-SamePCI'
ngen.Config.OperationMode = 'Inband-SamePCI';
ngen.displayResourceGrid;

Объект ngen содержит следующее:

  • Распределение ресурсов и таблицы транспортного размера блока (TBS) для NPDSCH (см. TS 36.213 16.4.1.3 и 16.4.1.5 [3]),

  • Структура ngen.Config с настройкой NB-IoT eNodeB, где поля NPBCH параметра, SIB1NPDSCH, NPDCCH и NPDSCH сконфигурируйте NPBCH, NPDSCH, несущий SIB1-NB, NPDCCH и NPDSCH, не несущий SIB1-NB (i.e., NPDSCH, которые несет NB-IoT, передают в нисходящем направлении подкадры), соответственно.

ngen                                      % Show all available properties
nsfTable = ngen.NSFTable                  % Display number of subframe table in TS 36.213 16.4.1.3
enbConfig = ngen.Config                   % Display NB-IoT eNodeB configuration
npbchConfig = ngen.Config.NPBCH           % Display NPBCH configuration
sib1npdschConfig = ngen.Config.SIB1NPDSCH % Display the configuration of NPDSCH when carrying SIB1-NB

ngen = 

  NBIoTDownlinkWaveformGenerator with properties:

           Config: [1x1 struct]
         NSFTable: [8x2 table]
        NRepTable: [16x2 table]
         TBSTable: [112x3 table]
    NRepTableSIB1: [12x2 table]
     TBSTableSIB1: [12x2 table]


nsfTable =

  8x2 table

    ISF    NSF
    ___    ___

     0      1 
     1      2 
     2      3 
     3      4 
     4      5 
     5      6 
     6      8 
     7     10 


enbConfig = 

  struct with fields:

          TotSubframes: 20
              NNCellID: 0
                NBRefP: 1
              CellRefP: 4
     ControlRegionSize: 3
                NFrame: 0
         OperationMode: 'Inband-SamePCI'
        DownlinkBitmap: [1 1 1 1 1 1 1 1 1 1]
           CarrierType: 'Anchor'
        DLGapThreshold: 32
      DLGapPeriodicity: 64
    DLGapDurationCoeff: 0.1250
             NPSSPower: 0
             NSSSPower: 0
                 NPBCH: [1x1 struct]
            SIB1NPDSCH: [1x1 struct]
                NPDCCH: [1x1 struct]
                NPDSCH: [1x1 struct]


npbchConfig = 

  struct with fields:

           Power: 0
    EnableCoding: 'On'
     DataBlkSize: 34
      DataSource: 'PN9'


sib1npdschConfig = 

  struct with fields:

          Enable: 'On'
           Power: 0
            NRep: 4
    EnableCoding: 'On'
     DataBlkSize: 208
      DataSource: 'PN9'

Настройка NPDCCH/NPDSCH

Сгенерированная сетка RE ниже объясняет, как сконфигурировать подкадры, используемые для подкадров нисходящего канала NB-IoT с помощью нисходящего битового массива, и как сконфигурировать параметры NPDCCH/NPDSCH, который несут подкадры нисходящего канала NB-IoT. Подкадры нисходящего канала NB-IoT могут быть сконфигурированы полем DownlinkBitmap параметра в структуре ngen.Config. В примере несущая непривязки используется, чтобы отключить NPSS, NSSS, NPBCH и SIB1-NB в сетке.

Генератор формы волны поддерживает несколько NPDCCH и NPDSCH. Каждый NPDSCH и NPDCCH содержат один транспортный блок и сообщение нисходящей управляющей информации (DCI), соответственно. Параметры NPDCCH/NPDSCH заданы структурой, и несколько NPDCCH/NPDSCH описываются как вектор структуры.

NPDCCH сконфигурирован следующими параметрами в структуре ngen.Config.NPDCCH:

  • Enable: Включая или отключение NPDCCH ('On', 'Off').

  • Power: Относительная степень для символов NPDCCH в частотном диапазоне с предположением, что степень NRS равняется 1.

  • NCCE: Выбранные узкополосные элементы канала управления (NCCEs), чтобы нести NDPCCH. Значение может быть или скаляром или вектором из двух записей. Скаляр или вектор указывают на формат 0 или 1 NPDCCH, соответственно. Входное значение 0 (или 1) указывает на NCCE 0 (или NCCE 1). NCCE 0 занимает поднесущие от 0 до 5, и NCCE 1 занимает поднесущие 6 - 11, соответственно. (TS 36.211 10.2.5.1 [1]).

  • NRep: Количество повторений для кандидата NPDCCH (TS 36.213 16.6 [3]). Позволенные значения$2^n$, где n = 1... 10.

  • Rmax: Максимальное количество повторений для NPDCCH (TS 36.213 16.6 [3]). Это влияет на разрыв передачи NPDCCH. Позволенные значения$2^n$, где n = 1... 10.

  • RNTI: Радиосеть временный идентификатор используется для скремблирования.

  • StartSubframe: Стартовый индекс подкадра на основе 0 NPDCCH в сгенерированной сетке RE.

  • DataBlkSize: Длина информационных битов DCI.

  • DataSource: Биты информации о DCI. Параметр может быть задан непосредственно как немного вектора или использования случайного типа данных e.g., 'PN9-ITU', 'PN9', 'PN11', 'PN15', 'PN23'. Для последнего случая случайный битовый вектор сгенерирован для выбранного типа.

NPDSCH сконфигурирован следующими параметрами в структуре ngen.Config.NPDSCH:

  • Enable: Включая или отключение NPDSCH ('On', 'Off').

  • Power: Относительная степень для символов NPDSCH в частотном диапазоне с предположением, что степень NRS равняется 1.

  • NPDSCHDataType: Тип данных, которые NPDSCH несет, позволенные значения, является или 'BCCHNotSIB1NB' или 'NotBCCH'. Это значение влияет на схему повторения, аналогичную описанному выше.

  • NRep: Количество повторений (TS 36.211 16.4.1.3 [1]).

  • NSF: Количество подкадров в кодовой комбинации NPDSCH (TS 36.211 16.4.1.3 [1]).

  • Rmax: Максимальное количество повторений для NPDCCH, сопоставленного к NPDSCH, его значение должно быть равно значению того же поля в соответствующем NPDCCH.

  • StartSubframe: Стартовый индекс подкадра на основе 0 NPDSCH в сгенерированной сетке RE.

  • DataBlkSize: Транспортный размер блока.

  • DataSource: Информационные биты транспортного блока. Использование совпадает с тем же полем в структуре ngen.Config.NPDCCH.

ngen = NBIoTDownlinkWaveformGenerator;
ngen.Config.CarrierType = 'NonAnchor'; % Anchor or NonAnchor
ngen.Config.DownlinkBitmap = [1 0 1 1 1 1 1 1 0 1];
ngen.Config.TotSubframes = 30;

% Configure the parameters of the first NPDCCH
npdcch1.Enable = 'On';
npdcch1.Power = 0;
npdcch1.NCCE = 1;  % NPDCCH format 0 with NCCE 1
npdcch1.NRep = 2;
npdcch1.Rmax = 16;
npdcch1.RNTI = 0;
npdcch1.StartSubframe = 0;
npdcch1.DataBlkSize = 23;
npdcch1.DataSource = randi([0 1],npdcch1.DataBlkSize,1); % Users can define their own information bits

% Configure the parameters of the second NPDCCH
npdcch2.Enable = 'On';
npdcch2.Power = 0;
npdcch2.NCCE = 0;  % NPDCCH format 0 with NCCE 0
npdcch2.NRep = 4;
npdcch2.Rmax = 16;
npdcch2.RNTI = 1;
npdcch2.StartSubframe = 3;
npdcch2.DataBlkSize = 23;
npdcch2.DataSource = 'PN9';

% Configure the parameters of the first NPDSCH
npdsch1.Enable = 'On';
npdsch1.Power = 0;
npdsch1.NPDSCHDataType = 'BCCHNotSIB1NB';
npdsch1.NSF = 3;
npdsch1.NRep = 2;
npdsch1.Rmax = npdcch1.Rmax;
npdsch1.RNTI = 0;
npdsch1.StartSubframe = 10;
npdsch1.DataBlkSize = 616;
npdsch1.DataSource = 'PN15';

% Configure the parameters of the second NPDSCH
npdsch2.Enable = 'On';
npdsch2.Power = 0;
npdsch2.NPDSCHDataType = 'NotBCCH';
npdsch2.NSF = 2;
npdsch2.NRep = 4;
npdsch2.Rmax = npdcch2.Rmax;
npdsch2.RNTI = 1;
npdsch2.StartSubframe = 20;
npdsch2.DataBlkSize = 616;
npdsch2.DataSource = 'PN23';

% Prepare NPDSCH and NPDCCH structure vectors
ngen.Config.NPDCCH = [npdcch1 npdcch2];
ngen.Config.NPDSCH = [npdsch1 npdsch2];

figure;
ngen.displayResourceGrid;

Сгенерированная сетка RE ниже объясняет, как сконфигурировать разрыв передачи для NPDSCH/NPDCCH согласно TS 36.211 10.2.3.4 и 10.2.5.5 [1]. Разрыв задан полем Rmax параметра упомянутый выше, а также следующие параметры в структуре ngen.Config:

  • DLGapThreshold: Порог, чтобы инициировать разрыв передачи, т.е. нет никаких разрывов в передаче NPDSCH если Rmax <DLGapThreshold. Позволенные значения равняются 32, 64, 128, 256 (TS 36.331 6.7.1 [5]).

  • DLGapPeriodicity: Периодичность разрыва в количестве подкадров. Это также задает стартовый подкадр разрыва, т.е. стартовый номер подкадра sf удовлетворяющее условие (sf ультрасовременный DLGapPeriodicity) = 0. Позволенные значения равняются 64, 128, 256, 512 (TS 36.331 6.7.1 [5]).

  • DLGapDurationCoeff: Используемый, чтобы вычислить длительность разрыва в количестве подкадров, вместе с DLGapPeriodicity. Длительность разрыва дана DLGapPeriodicity $\times$ DLGapDurationCoeff. Позволенные значения являются 1/8, 1/4, 3/8, 1/2 (TS 36.331 6.7.1 [5]).

Следующее использование в качестве примера, принимающее значение по умолчанию параметры DLGapThreshold = 32, DLGapPeriodicity = 64 и DLGapDurationCoeff = 1/8, чтобы объяснить разрыв передачи NPDSCH. Рисунок ниже иллюстрирует что 96 (NRep $\times$ NSF) Подкадры NPDSCH разрушены двумя разрывами с длительностью 8 подкадров, и два разрыва запускаются в подкадре 0 и подкадре 64, соответственно.

ngen = NBIoTDownlinkWaveformGenerator;
ngen.Config.CarrierType = 'NonAnchor'; % Anchor or NonAnchor
ngen.Config.TotSubframes = 150;
ngen.Config.NPDCCH.Enable = 'Off';     % Disable the NPDCCH
ngen.Config.NPDSCH.StartSubframe = 0;
ngen.Config.NPDSCH.Rmax = ngen.Config.DLGapThreshold; % Minimum value to trigger the transmission gap based on given DLGapThreshold
ngen.Config.NPDSCH.NRep = 32;
ngen.Config.NPDSCH.NSF = 3;

figure;
ngen.displayResourceGrid;

Генерация сигналов нисходящего канала NB-IoT

Сгенерируйте форму волны временного интервала ссылочного канала измерения (RMC) для требований к производительности NPDSCH, согласно TS 36.101 3.12 [7], или Тестовая модель NB (N-TM), заданный в TS 36.141, разделяет 6.1.3-6.1.6 [8]. Форма волны может быть сгенерирована с помощью метода генерации сигналов в классе NBIoTDownlinkWaveformGenerator, чтобы вызвать метод, объект ngen создается и метод может быть назван при помощи ngen.generateWaveform.

rc = 'R.NB.5-1'; % Allowed values are 'R.NB.5','R.NB.5-1','R.NB.6','R.NB.6-1','R.NB.7','N-TM'
ngen = NBIoTDownlinkWaveformGenerator(rc);
[waveform,grid,ofdmInfo] = ngen.generateWaveform;
ofdmInfo         % Display OFDM configuration
spectrumAnalyzer = dsp.SpectrumAnalyzer(ngen.Config.NBRefP);
spectrumAnalyzer.ShowLegend = true;
spectrumAnalyzer.SampleRate = ofdmInfo.SamplingRate;
if ngen.Config.NBRefP == 1
    spectrumAnalyzer.ChannelNames = {['Signal for RMC ' rc ' (Port 2000)']};
    spectrumAnalyzer(waveform);
else % NBRefP == 2
    spectrumAnalyzer.ChannelNames = {['Signal for RMC ' rc ' (Port 2000)'], ...
        ['Signal for RMC ' rc ' (Port 2001)']};
    spectrumAnalyzer(waveform(:,1),waveform(:,2));
end

ofdmInfo = 

  struct with fields:

            SamplingRate: 1920000
                    Nfft: 128
               Windowing: 6
     CyclicPrefixLengths: [10 9 9 9 9 9 9 10 9 9 9 9 9 9]
    SubframeChannelTypes: ["NPDCCH"    "Unused"    "Unused"    ...    ]

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

% Set up a standalone, non-anchor carrier, disable the NPDCCH and make the
% REs grid fully occupied by NPDSCH/NRS.
ngen = NBIoTDownlinkWaveformGenerator;
ngen.Config.CarrierType = 'NonAnchor';
ngen.Config.NPDCCH.Enable = 'Off'; % Disable the NPDCCH
ngen.Config.NPDSCH.StartSubframe = 0;
ngen.Config.NPDSCH.NRep = 8;
ngen.Config.NPDSCH.NSF = 5;

% Display the grid and generate the time-domain signal
figure;
ngen.displayResourceGrid;
[waveform1,~,ofdmInfo1] = ngen.generateWaveform;

% Set up a standalone, anchor carrier, disable the NPDSCH and NPDCCH so
% that it contains NPSS/NSSS/NPBCH/SIB1-NB/NRS only.
ngen = NBIoTDownlinkWaveformGenerator;
ngen.Config.NPDCCH.Enable = 'Off'; % Disable the NPDCCH
ngen.Config.NPDSCH.Enable = 'Off'; % Disable the NPDSCH

% Display the grid and generate the time-domain signal
figure;
ngen.displayResourceGrid;
waveform2 = ngen.generateWaveform;

% Plot the signal spectrums of the generated two waveforms.
spectrumAnalyzer = dsp.SpectrumAnalyzer(2);
spectrumAnalyzer.ShowLegend = true;
spectrumAnalyzer.ChannelNames = {'Non-Anchor carrier fully occupied by NPDSCH/NRS (Port 2000)', ...
    'Anchor carrier with NPSS/NSSS/NPBCH/SIB1-NB/NRS only (Port 2000)'};
spectrumAnalyzer.SampleRate = ofdmInfo1.SamplingRate;
spectrumAnalyzer(waveform1,waveform2);

Приложение

Этот пример использует класс помощника:

Выбранная библиография

  1. 3GPP TS 36.211 "Физические каналы и модуляция"

  2. 3GPP TS 36.212 "Мультиплексирование и кодирование канала"

  3. 3GPP TS 36.213 "Процедуры физического уровня"

  4. 3GPP TS 36.321 "Среднее управление доступом (MAC); спецификация Протокола"

  5. 3GPP TS 36.331 "Радио-управление ресурсами (RRC); спецификация Протокола"

  6. 3GPP TS 36.300 "Полное описание; Этап 2 дюйма

  7. 3GPP TS 36.101 "Передача радио оборудования пользователя (UE) и прием"

  8. 3GPP TS 36.141 "Проверка на соответствие стандарту базовой станции (BS)"

  9. О. Либерг, М. Зундберг, Y.-P. Ван, Дж. Бергман и Дж. Сакс, сотовый Интернет вещей: технологии, стандарты и эффективность, Elsevier, 2018.

Документация LTE Toolbox

Поддержка

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