MATLAB Examples

LTE HDL Cell Search and MIB Recovery

This example shows the design of a LTE cell search and MIB recovery system optimized for HDL code generation and hardware implementation.



The model presented in this example can be used to decode the Master Information Block (MIB) from baseband LTE waveforms such as data synthesized by LTE Toolbox™ or captured off the air. The design is optimized for HDL code generation and can be implemented and executed in real time on hardware. The architecture is extensible, allowing additional processing stages to be added, such as indexing and decoding for the PCFICH, PDCCH and PDSCH (see LTE HDL SIB1 Recovery example).

Design Challenges

The LTE Toolbox Cell Search, MIB, and SIB1 Recovery example can be used to detect, demodulate and decode eNodeB signals in MATLAB. It was used as a reference throughout the development of the present example. Several design challenges were encountered while implementing this functionality on hardware.

Architecture and Algorithm

The algorithms used in LTE Toolbox are optimized to run in MATLAB on a desktop, where it is possible to store a large waveform and obtain random access to its samples. For example, LTE Toolbox starts by resampling the waveform to 1.92 Msps to perform cell search and MIB decoding. Once the MIB data has been recovered and the cell bandwidth is known, the original I/Q waveform is resampled a second time to match the actual cell bandwidth.

Applying the same architecture to the hardware design is not desirable for several reasons. First, a large amount of data would need to be stored in memory. Second, the FFT operation inside the OFDM demodulator would need to support six different FFT lengths. Designing a variable length FFT is a complex and time consuming task. Deploying one FFT for each required length is straightforward but consumes more hardware resources.

In addition, the algorithms used in LTE Toolbox functions could require a large number of resources if implemented in the same way on hardware. For example, the 2-D interpolation methods used in the channel estimation function lteDLChannelEstimate require a more hardware-friendly implementation. The use of fixed-point arithmetic makes it harder to achieve the accuracy of the original algorithm, hence careful selection of fixed point data types is required, and hardware friendly algorithms need to be investigated.

Streaming Data

LTE Toolbox functions use frame based processing; the resource grid is passed from one function to another during the decoding process. Hardware implementation requires a different approach: using sample based data streams, control signals, and data buffers.

Fixed Point

Fixed-point data types are required for efficient hardware implementation. A balance must be found between numerical accuracy and hardware resource utilization.

Architecture and Configuration

The architecture of the LTE HDL Cell Search and MIB Recovery implementation is shown in the diagram below.

The input to the receiver is baseband I/Q data, sampled at @ 30.72 Msps. A 2048-point FFT is used for OFDM demodulation, and is sufficient to decode all of the supported LTE bandwidths. The resource grid buffer is capable of storing one subframe of LTE data. Once the receiver has synchronized to a cell, data from the OFDM demodulator is written into the grid buffer. The PBCH indexing block then generates the indices of the resource elements which carry the PBCH. Those resource elements are then read out of the grid buffer and equalized, before being passed through the PBCH decoder. This architecture is designed to be extensible and scalable so that additional channel indexing and decoding functions can be inserted as needed. For example it can be extended to perform SIB1 recovery as shown in the LTE HDL SIB1 Recovery example.

Structure of the Example Model

The top level of the ltehdlMIBRecovery model is shown below. HDL code can be generated for the HDL LTE MIB Recovery subsystem.

The ltehdlMIBRecovery_Init.m script is executed automatically by the model's InitFcn callback. This script generates the dataIn and startIn stimulus signals as well as all of the constants needed to initialize the model. Input data can be loaded from a file, which can contain either synthesized LTE data or signals captured off the air. Alternatively, an LTE waveform can be synthesized using LTE Toolbox functions. To select an input source, change the loadfromfile parameter in ltehdlMIBRecovery_init.m.

loadfromfile = false;
SamplingRate = 30.72e6;
simParams.Ts = 1/SamplingRate;
if loadfromfile
    dataIn = resample(rxWaveform,SamplingRate,fs);
    dataIn = generateDLRXWaveform(SamplingRate,'R.3',10,'Off',70.0,0.0,40,2);

HDL Optimized LTE MIB Recovery

This section describes the operation of the HDL LTE MIB Recovery subsystem. The structure of the subsystem is shown below. The Downlink Sync Demod block performs frequency and time synchronization, PSS/SSS signal detection, and OFDM demodulation. The MIB Decoder block stores subframe0 after the PSS is detected, performs channel estimation, equalization and recovers the MIB information.

Downlink Synchronization and Demodulation

The Downlink Sync Demod block takes in raw I/Q data at 30.72 Msps, and outputs the unequalized downlink resource grid data. This block references the ltehdlDownlinkSyncDemod model, which implements the following functions:

  • Frequency recovery
  • Primary Synchronization Signal (PSS) detection
  • Secondary Synchronization Signal (SSS) detection
  • Timing recovery, based on the PSS and SSS signals
  • OFDM demodulation (using a 2048 point FFT)
  • Cell ID calculation, based on PSS and SSS detection results

For details of the structure and formation of LTE synchronization signals, see Synchronization Signals (PSS and SSS). The structure of the ltehdlDownlinkSyncDemod model is shown below.

The input is complex 16-bit data sampled at 30.72 Msps. The signal is passed to two signal processing data paths; one at 1.92 Msps and one at 30.72 Msps. Frequency recovery and PSS detection are performed on the 1.92 Msps data path. 1.92 Msps is used for two reasons. First, the cell bandwidth is not known at this stage therefore the smallest LTE bandwidth of 1.4 MHz is assumed for the purpose of frequency recovery. This approach works irrespective of the actual cell bandwidth. Second, the PSS signal only occupies the 6 central resource blocks (1.4 MHz). Therefore, PSS detection can be performed effectively and efficiently at 1.92 Msps.

The frequency offset is also corrected on the 30.72 Msps data path (using the frequency estimate from the 1.92 Msps data path). The timing estimate from PSS detection is used to determine the position of the OFDM symbols. This allows the samples of each OFDM symbol to be extracted from the signal and passed to the 2048 point FFT; in effect performing OFDM demodulation. Finally, SSS detection is performed in the frequency domain and used, along with PSS, to determine the cell ID. The SSS detection process also yields the subframe number in which SSS was decoded. This information is fed to the final output masking stage, which starts to output the resource grid data on the next radio frame boundary.

In the Simulink model, these operations are split into two subsystems: FrequencyTimingPSS and OFDMDemodSSS, as shown below. Applying a one cycle pulse to the start input triggers a new cell search.

Frequency Recovery, Timing Recovery, and PSS Detection

Inside the FrequencyTimingPSS subsystem, the start signal is resampled to 1.92 Msps by the Pulse Resync block. When a start pulse occurs, the Start Controller subsystem then asserts the unlockFreqRec signal for 15 ms (28800 samples @ 1.92 Msps) to allow enough time for the frequency estimator's internal filters to settle. unlockFreqRec is then deasserted, locking the frequency estimate to its last value. This means that the frequency estimate remains constant for the remainder of the cell search procedure, avoiding the introduction of phase noise by the frequency recovery process.

The PSS Detection subsystem is held in reset while the frequency estimator is settling, and then brought out of reset once the frequency estimate is locked. Once a PSS has been detected, the PSS Detection detected output is asserted for one 1.92 Msps cycle. The timing of this pulse corresponds to the first sample of the first slot after the PSS. This is either the second slot of subframe 0, or the second slot of subframe 5, however it is not known which one at this point. This ambiguity is resolved during SSS detection. The detected signal is upsampled to 30.72 Msps and used to trigger the OFDM Symbol Timing block, a state machine which generates the FFTWin signal for extracting the samples of each OFDM symbol.

The detected output of Frequency Timing PSS indicates that a PSS has been detected and that FFTWin will start to mark OFDM symbols sometime within the next 15 ms. dataOut is the frequency corrected time domain data at 30.72 Msps. NCellID2 indicates which of the three possible PSS sequences was detected.

OFDM Demodulation and SSS Detection

There are four inputs to the OFDMDemodSSS subsystem. dataIn is the frequency corrected time domain samples at 30.72 Msps; FFTWin is a 1-bit control signal indicating the FFT window for each OFDM symbol; NCellID2 is the component of the cell ID which comes from PSS detection (the position within the cell group); reset resets the subsystem, starting a new SSS search.

FFT operations are applied to the incoming data to perform OFDM demodulation, resulting in unequalized downlink resource grid data. SSS detection is performed in the frequency domain, allowing physical layer cell identification and radio frame timing recovery to be completed.

After reset, the OFDM Demod SSS subsystem assumes that the first OFDM symbol it receives is the first symbol of a subframe that contains SSS. The subframe number is encoded in the SSS, therefore decoding it allows the actual subframe number (0 or 5) to be determined. The SSS is located in OFDM symbol #5 of the subframe, and occupies the central 62 subcarriers. The SSS Detection block must therefore locate the SSS subcarriers and extract their complex values. The received SSS sequence is stored and compared to every possible SSS candidate. There are 336 SSS candidates, since there are 168 cell groups and 2 possible SSS locations within the radio frame.

The comparison metric used is the magnitude of the dot product of the received sequence with the candidate sequence. However, the magnitude squared is used in practice to simplify the HDL implementation. The SSS is decoded by choosing the candidate which maximizes this metric. The SSS Detection subsystem outputs the final cell ID, and a 1-bit value indicating whether the SSS was detected in subframe 0 or 5.

The Grid Mask Generation subsystem enables the outputs of the OFDM Demod SSS subsystem by generating the gridEn signal. This signal is initially false. Once the frame timing has been established, the Grid Mask Generation subsystem asserts the gridEn signal to activate the outputs of the OFDM Demod SSS subsystem at the start of the next radio frame. gridData is the FFT shifted output of the FFT, and is qualified by the gridValid output. The subframe output indicates which subframe is currently being sent out. The NCellID output is the final cell ID of the detected cell.

MIB Decoder

The MIB Decoder subsystem is shown below. It consists of four Model Reference blocks: PBCH Indexing, Resource Grid Memory, Channel Equalization, and PBCH Decoder. The order of operations is as follows:

  1. The rst input is asserted, preparing the subsystem to receive and process data.
  2. OFDM data starts to flow into the block, and subframe 0 is stored in the Resource Grid Memory.
  3. The PBCH Indexing block starts generating the indices of the resource elements which carry the PBCH.
  4. Those resource elements are then read out of the Resource Grid Memory and equalized by the Channel Equalization block.
  5. Finally the equalized PBCH data is passed through the PBCH Decoder block and the MIB is extracted.

Resource Grid Memory

The Resource Grid Memory block contains a memory bank, a write controller and a read controller. The memory bank capacity is one subframe of demodulated OFDM data at the largest supported LTE bandwidth (20MHz).

The memory write controller is responsible for writing subframes of data to the memory bank. The writeSubframe input enables the write controller for the appropriate subframes; subframe 0 in the case of the present example. The LTE Memory Bank contains RAM of dimensions 14 x 2048 x 16 bit complex values; that is 14 ODFM symbols, each containing 2048 complex values. The MemoryBank Write Controller startChest output is used to start the channel estimation process once the last reference symbol for the current subframe has been written to the memory bank. The refSymbol Read Controller calculates the indices required to read cell reference symbols from the grid, which is equivalent to the LTE Toolbox function lteCellRSIndices.

The memory bank always outputs the data from all 14 OFDM symbols. However not all of this data is needed for the channel estimation or for the PBCH decode. The refSymbolSelect and gridBankSelect subsystems select the appropriate OFDM symbols for channel estimation (reference symbols) and data respectively.

PBCH Indexing

The PBCH Indexing block computes the memory addresses required to retrieve the PBCH from the grid memory buffer. This is equivalent to the LTE Toolbox ltePBCHIndices function. The data retrieved from the grid memory is then equalized and passed to the PBCH Decoder for processing. The PBCH Indexing subsystem becomes active after the channel estimate for subframe 0 is ready, as indicated by the hestRdy output of the Channel Equalization subsystem.

Channel Estimation and Equalization

The Channel Equalization block contains three subsystems. cellRefGen generates the cell-specific reference signal (CRS) symbols using a Gold Sequence generator. chEst performs channel estimation using a simple but hardware friendly channel estimation algorithm. Equalization performs phase correction by multiplying grid data with the complex conjugate of the appropriate channel estimate value. The channel estimator generates a single complex-valued channel estimate for each subcarrier of the subframe using the following algorithm.

  1. Estimate the channel at each CRS resource element by dividing the received value by the transmitted symbol (generated by cellRefGen).
  2. Average these channel estimates across time (for the duration of the subframe) to generate a single complex-valued channel estimate for each subcarrier that contains CRS symbols.
  3. Use linear interpolation to estimate the channel for subcarriers which do not contain CRS symbols.

The input to the chEst subsystem is a vector of 4 QPSK symbols, corresponding to OFDM symbols 0, 4, 7 and 11 of the subframe. This allows chEst to extract the CRS resource elements and estimate the channel as described above.

PBCH Decoder

The PBCH Decoder performs QPSK demodulation, descrambling, rate recovery, and BCH decoding. It then extracts the MIB output parameters using the MIB Interpretation function block. These operations are equivalent to the ltePBCHDecode and lteMIB functions in the LTE Toolbox.

The PBCH Controller stores the equalized data in memory for iterative convolutional decoding attempts. The 4 attempts made at decoding the MIB correspond to the 4 repetitions of the MIB data per PBCH transport block.

BCH Decoder

The BCH Decoder quantizes the soft decisions and then decodes the data using the LTE Convolutional Decoder and LTE CRC Decoder blocks. The recommended wordlength of soft decisions at the input to the convolutional decoder is 4 bits. However, the BCH Decoder block receives 16-bit soft decisions as input. Therefore the softBitScalingUnit block dynamically scales the data so that it utilizes the full dynamic range of the 4 bit soft decisions. The CRC decoder block is configured to return the full checksum mismatch value. The CRC mask, once checked against the allowed values, provides cellRefP; the number of cell-specific reference signal antenna ports at the transmitter. If the CRC checksum does not match of the accepted values then MIB has not been successfully decoded and the PBCH Controller decides whether or not to initiate another decoding attempt.

When a MIB has been successfully decoded, the MIB Interpretation subsystem extracts and outputs the fields of the message.

Performance Analysis

This section analyzes factors that could impact the cell search and MIB recovery performance of this model.

Quality of Input Waveform

Quality of the input waveform is an important factor that impacts the decoding performance. Signal to noise ratio and channel attenuation are common factors that determine the signal quality. For off the air signals, it is possible that there are multiple cells in one captured waveform and the quality of each cell may vary. If the downlink detector picks a weak cell, MIB information might not be recovered. The quality of the input waveform can be measured using the cellQualitySearch function. This function detects LTE cells in the input waveform with sampling rate and returns a structure per LTE cell containing the following fields:

  • FrequencyOffset: Frequency offset obtained by lteFrequencyOffsets function
  • NCellID: Physical layer cell identity
  • TimingOffset: Timing offset of the first frame in the input waveform
  • RSRQdB: Reference Signal Received Quality (RSRQ) value in dB per TS 36.214 Section 5.1.3 [ 1 ]
  • ReportedRSRQ: RSRQ measurement report (integer between 0 and 34) per TS 36.133 Section 9.1.7 [ 1 ]

Applying the cellQualitySearch function to the waveform generated using LTE Toolbox configured in LTEMIBRecovery_Init function returns the following information:

FrequencyOffset: 68.1909
NCellID: 10
TimingOffset: 0
RSRQdB: -7.0116
ReportedRSRQ: 25

The ReportedRSRQ number shows that this is a relatively strong signal. This example successfully decodes MIB information from this signal.

Applying the cellQualitySearch function to the captured waveform eNodeBWaveform.mat returns the following report:

FrequencyOffset: 536.8614
NCellID: 76
TimingOffset: 12709
RSRQdB: -5.5429
ReportedRSRQ: 28
FrequencyOffset: 536.8614
NCellID: 160
TimingOffset: 3108
RSRQdB: -18.5365
ReportedRSRQ: 2

There are two cells in the captured waveform, one with cell ID 76 and one with cell ID 160.

Design Trade-offs

There are a few design trade-offs that could impact the decoding performance.

First, the channel estimation algorithm employs a simple time average based on the assumption of low channel mobility. Therefore, the algorithm may not be possible to decode waveforms that were transmitted through fast fading channels.

Second, the model only exploits one transmit antenna to simplify decoder complexity. That is, the receiver only estimates and equalizes the channel from transmit antenna port 0, and does not implement transmit diversity decoding. As a result, decoding results may not be correct if the transmitter uses 2 or 4 transmit antennas (cellRefP = 2 or 4).

Results and Display

The scope below shows the key input and output signals of the Downlink Sync Demod block. After a pulse is asserted on the start signal, the frequency estimator is allowed to settle for 15 ms before its output is locked (see freqEstHz plot). PSS search then begins, and successful detection is indicated by a pulse on the PSSDetected output signal. SSS detection is then performed to complete the frame timing recovery and cell identification process, hence the NCellID signal becomes active. The block starts outputting demodulated OFDM data on the next frame boundary, as indicated by the gridDataValid and subFrameNum signals.

The scope below shows the output signals of the MIB Decoder block. MIB is successfully decoded in subframe 0, shortly after OFDM data starts being passed in from the Downlink Sync Demod block. Once MIB has been detected the NDLRB, PHICH, Ng, nFrame and cellRefP signals all become active, indicating the key parameters of the cell. The mibAllZeros and mibError diagnostic signals also become active at this time.

The following MIB information is decoded when running the LTE Toolbox synthesized waveform through the receiver.

NDLRB (Number of downlink resource blocks): 50
PHICH (PHICH duration) index: 0
Ng (HICH group multiplier): 0
NFrame (Frame number): 3
cellID (Cell ID): 10
CellRefP (Cell-specific reference signals): 2

PHICH value 0 means that PHICH duration is 'normal' (a value of 1 implies 'Extended'). Similarly, Ng value 0 indicates the HICH group multiplier value is 'Sixth'. The other possible value could be 'Half', 'One', or 'Two' if the Ng index is 1, 2, or 3 respectively.

The following MIB information is decoded when decoding the captured waveform:

NDLRB (Number of downlink resource blocks): 25
PHICH (PHICH duration) index: 0
Ng (HICH group multiplier): 2
NFrame (Frame number): 261
cellID (Cell ID): 76
CellRefP (Cell-specific reference signals): 2

This implies that the PHICH duration is 'Normal' and the HICH group multiplier value is 'One'.

Sending the same inputs to the LTE Toolbox Cell search, MIB, and SIB1 Recovery example returns the same MIB information.

HDL Code Generation and Verification

To generate the HDL code for this example you must have an HDL Coder™ license. Use the makehdl and makehdltb commands to generate HDL code and HDL testbench for the HDL LTE MIB Recovery subsystem. Because the input waveform in this example contains at least 40 subframes to complete the cell search and MIB recovery, test bench generation takes a long time. This example is configured to use System Verilog DPI test bench to speed up the test bench generation.

The HDL LTE MIB Recovery subsystem was synthesized on a Xilinx® Zynq®-7000 ZC706 evaluation board. The post place and route resource utilization results are shown in the table below. The design met timing with a clock frequency of 160 MHz.

       Resource        Usage
    _______________    _____

    Slice Registers    43541
    Slice LUTs         26414
    RAMB18                34
    RAMB36                42
    DSP48                133

For more information see Prototype LTE Algorithms on Hardware.


1. 3GPP TS 36.214 "Physical layer"