Main Content

NR Polar Decoder

Perform polar decoding according to 5G NR standard

Since R2020a

  • NR Polar Decoder block

Libraries:
Wireless HDL Toolbox / Error Detection and Correction

Description

The NR Polar Decoder block implements a streaming polar decoder with hardware-friendly control signals. The 5G NR standard uses polar codes for channel coding of the DCI, UCI, and BCH transmit channels.

You must specify the link direction because the coding scheme defined by the 5G NR standard is different for downlink and uplink messages. Downlink messages are encoded with interleaving and use a CRC length of 24 bits. Uplink messages do not use interleaving, and use a CRC length of 6 or 11.

This block implements a CRC-aided successive-cancellation list decoder. This implementation matches the performance of the nrPolarDecode (5G Toolbox) function. You can choose a list length of 2, 4, or 8. Increasing the list length increases the error correction performance but uses more hardware resources and increases the decoding latency. You can improve decoding performance for DCI messages by using the optional RNTI port to specify an expected RNTI value.

This block also performs CRC decoding of the message, equivalent to the nrCRCDecode (5G Toolbox) function. The block selects the CRC length based on your specification of the link direction and the K value you provide. The block detects DCI messages from the values of K and E, and automatically prepends 1s to the message, equivalent to the padCRC input argument of the nrPolarDecode (5G Toolbox) function.

Because the latency of the polar decoding operation can vary, the block provides an output signal, nextFrame, that indicates when the block is ready to accept new inputs. For more details, see the Latency section of this page.

Examples

Ports

Input

expand all

Input sample, specified as a scalar log-likelihood ratio (LLR). The block supports builtin types, and signed fixed-point values with a wordlength of 4 to 16 bits.

The software supports double and single data types for simulation, but not for HDL code generation.

Data Types: fixed point | int8 | int16 | double | single

Control signals accompanying the sample stream, specified as a samplecontrol bus. The bus includes the start, end, and valid control signals, which indicate the boundaries of the frame and the validity of the samples.

  • start — Indicates the start of the input frame

  • end — Indicates the end of the input frame

  • valid — Indicates that the data on the input data port is valid

For more details, see Sample Control Bus.

Data Types: bus

Length of information block in bits, specified as a positive integer. For downlink messages, K must be in the range 36 to 164. For uplink messages, K must be in the range 18 to 25 or 31 to 1023.

Dependencies

To enable this port, set the Configuration source parameter to Input port.

Data Types: fixdt(0,10,0)

Rate-matched output length in bits, specified as a scalar positive integer. Specify a value for E that is greater than K and less than or equal to 8192.

Dependencies

To enable this port, set the Configuration source parameter to Input port.

Data Types: fixdt(0,14,0)

Target RNTI, specified as a 16-bit unsigned integer. This value increases decoding accuracy for DCI messages. For example, when decoding SIB1 DCI messages, enable this port and set the target RNTI to 65,535. For MIB decoding, you can disable this port or set the target RNTI to 0.

Dependencies

To enable this port, set Link direction to Downlink and select the Enable target RNTI port parameter.

Data Types: uint16

Output

expand all

Decoded data bit, returned as a scalar. The output message length is A bits, where A = KCRCLen. For downlink messages, CRCLen is 24. For uplink messages, CRCLen is 11 or 6, as defined by the 5G NR standard.

Data Types: fixdt(0,1,0) | Boolean | double | single
Complex Number Support: Yes

Control signals accompanying the sample stream, returned as a samplecontrol bus. The bus includes the start, end, and valid control signals, which indicate the boundaries of the frame and the validity of the samples.

  • start — Indicates the start of the output frame

  • end — Indicates the end of the output frame

  • valid — Indicates that the data on the output data port is valid

For more details, see Sample Control Bus.

Data Types: bus

CRC result, returned as a scalar. If you clear the Full checksum mismatch parameter, this value is a Boolean. When you select the Full checksum mismatch parameter, this value is a ufix24 scalar for downlink messages and a ufix11 or ufix6 scalar for uplink messages.

If you enable the RNTI port, the block compares the internal CRC checksum against the target RNTI value. Otherwise, the block compares the CRC checksum against a value of 0.

Data Types: Boolean | ufix11 | ufix24

The block sets this signal to 1 when the block is ready to accept the start of the next frame. If the block receives an input start signal while nextFrame is 0, the block discards the frame in progress and begins processing the new data.

For more information, see Using the nextFrame Output Signal.

Data Types: Boolean

Parameters

expand all

Direction of 5G NR link, specified as Downlink or Uplink. When you choose Downlink, the block performs deinterleaving, as specified in the 5G NR standard. When you select Uplink, the block omits the deinterleaving logic.

Downlink decoding uses a CRC length of 24 bits. Uplink decoding uses a CRC length of 6 bits (K in the range 18 to 25) or 11 bits (K in the range 31 to 1023).

This parameter is the maximum number of parallel paths maintained in the decoding tree. Increasing the list length increases the error correction performance but uses more hardware resources and increases the decoding latency. When you use list lengths of 4 and 8, the latency can vary depending on the SNR of the input signal, and is not constant for given values of K and E. Use the nextFrame output signal to determine when the block is available for a new message.

Select Input port to enable the K and E ports. Select Property to use the Message length (K) and Rate-matched length (E) parameters.

For downlink messages, K must be in the range 36 to 164. For uplink messages, K must be in the range 18 to 25 or 31 to 1023.

Dependencies

To enable this parameter, set the Configuration source parameter to Property.

Specify a value for E that is greater than K and less than or equal to 8192.

Dependencies

To enable this parameter, set the Configuration source parameter to Property.

When you clear this parameter, the block returns a Boolean scalar on the err port that indicates whether the CRC was successful. When you select this parameter, the block returns the full CRC checksum on the err port. If your design decodes DCI messages and makes use of the RNTI remainder, select this parameter.

If you enable the RNTI port, the block compares the internal CRC checksum with the target RNTI value. Otherwise, the block compares the CRC checksum against a value of 0.

The nrPolarDecode (5G Toolbox) function returns a decoded message that includes the CRC bits. This block returns the decoded message without the CRC bits, and returns the CRC status separately on the err port. This behavior is equivalent to calling the nrCRCDecode (5G Toolbox) function after using the nrPolarDecode function. Not recomputing the CRC bits saves hardware latency and resources.

Select this parameter to enable the RNTI input port. Providing a target RNTI value increases decoding accuracy for DCI messages. For example, when decoding SIB1 DCI messages, enable this port and set the target RNTI to 65535. For MIB decoding, you can disable this port or set the target RNTI to 0.

Enabling this port also changes how the block computes the err output port value. If you enable the RNTI port, the block compares the internal CRC checksum with the target RNTI value. Otherwise, the block compares the CRC checksum against a value of 0.

Dependencies

To enable this parameter, set the Link direction parameter to Downlink.

Algorithms

expand all

This block implements a CRC-aided successive-cancellation list decoder. It can use a list length of 2, 4, or 8 as configured by the List length parameter. The decoder iterates over all LLRs in the tree to reach a decision for a bit and then uses that decision to decode the next bit. The deinterleaving step is included only when you set the Link direction parameter to Downlink.

This diagram shows the architecture of the polar decoder.

The block uses the Configuration stage when the K and E input port values change. The block computes the locations of the information bits and passes them to the Decision stage. Because the mapping patterns are computed as needed, rather than stored in hardware, the block supports all K and E values within the supported range. The Configuration stage also computes the interleave pattern when you set the Link direction parameter to Downlink.

When you set the Configuration source parameter to Property, the K and E values are constants, so the decoder does not implement the Configuration stage. In this case, the block includes static lookup tables that contain the precomputed configuration.

To minimize computations for each decode, the Tree Memory stores the probability of each node being a one or a zero. Each iteration updates only the LLRs that have changed. The Core decoding stage uses the LLR update equations from [3].

The Decision stage checks the LLR value against the expected locations of information bits and frozen bits and returns a hard decision to the Tree Memory. If the bit is expected to be frozen, the Decision stage returns a hard decision of zero and updates the probabilities of related paths. The Path Memory reconstructs the most likely paths from the hard decision results and passes the paths and scores to the next stage.

Tree Memory and Path Memory contain up to List length paths. If all frozen bits on a path are zeros (as expected), then the block discards the other parallel paths. This optimization results in variable latency in the decoding operation for list lengths greater than two. For signals with a high noise level, the decoder must increase the number of parallel paths and the cycles for decoding. For low-noise signals, the decoder can use only two parallel paths and reduce the decoding latency.

The Path Selection stage computes the CRC for all paths and then chooses the path that passes the CRC. When you use the RNTI input port, the block compares the internal CRC checksum with the target RNTI value. Otherwise, the block compares the CRC checksum against a value of 0. If all CRCs fail, the block returns the path that has the higher score.

This implementation matches the performance of the 5G Toolbox™ function nrPolarDecode (5G Toolbox) with the same list length. Because the block uses fixed-point internal types, any differences are a result of quantization.

This plot shows the block error rate performance with the three possible list lengths. The input is 6-bit LLR values.

A plot showing the increase in performance for higher list lengths.

References

[1] 3GPP TS 38.212. "NR; Physical channels and modulation." 3rd Generation Partnership Project; Technical Specification Group Radio Access Network. URL: https://www.3gpp.org.

[2] Arikan, Erdal. "Channel Polarization: A Method for Constructing Capacity-Achieving Codes for Symmetric Binary-Input Memoryless Channels." IEEE Transactions on Information Theory 55, no. 7 (July 2009): 3051–73. https://doi.org/10.1109/TIT.2009.2021379.

[3] Balatsoukas-Stimming, Alexios, Mani Bastani Parizi, and Andreas Burg. "LLR-Based Successive Cancellation List Decoding of Polar Codes." IEEE Transactions on Signal Processing 63, no. 19 (October 2015): 5165–79. https://doi.org/10.1109/TSP.2015.2439211.

Extended Capabilities

Version History

Introduced in R2020a

See Also

(5G Toolbox) |