3GPP关于5G新空口信道编码方法讨论(基于RAN1 #86和#86bis会议纪要提炼)

micro_ufo

上次对RAN1 84bis到RAN1 #85中的信道编码会议讨论的内容和提案进行了分析，本文对RAN1 86和RAN1 86bis作进一步说明。

一、        RAN1 #86会议

1.        会议总体情况

编码部分，处理了29个Tdoc和12个Way forward文稿，56个Tdoc未处理。

主要讨论的题目：
        eMBB编码的实施复杂度
        eMBB编码的性能比较
        小块编码
        控制信道编码机制
        outer erasure coding

1.1        eMBB编码算法

eMBB编码算法的支持性：

- LDPC :
Nokia, QC、Samsung、ASB、ZTE、MediaTek、Intel、Sharp、MTI、Interdigital、Verizon、KT、KDDI、IITH、CEWiT、Reliance-jio、Tejas Networks、Xinwei、Vivo、Potevio、WILUS、Sony、Xiaomi、Oppo

- Turbo + LDPC (高吞吐量场景) :
Ericsson、LG、CATT、NEC、Orange、IMT

- Polar :
Huawei、HiSilicon、CMCC、CUCC、Deutsche Telekom、Telecom Italia、Vodafone、China Unicom、Spreadtrum

实在是有点混乱啊，上述支持情况可以通过会议报告中3篇提案来表明。信息如下：

R1-167999        WF on Channel Coding Selection        (Qualcomm Incorporated, Samsung, Nokia, ASB, ZTE, MediaTek, Intel, Sharp, MTI, Interdigital, Verizon Wireless, KT Corporation, KDDI, IITH, CEWiT, Reliance-jio, Tejas Networks, Beijing Xinwei Telecom Technology, Vivo, Potevio, WILUS, Sony, Xiaomi，Also supported by Oppo.)
Revision of R1-166376
建议：选择LDPC作为eMBB数据信道的编码方式，以便在高速和大数据块长度下体现性能和实施的优势。

R1-168040        WF on channel coding selection        (Huawei, HiSilicon, CMCC, CUCC, Deutsche Telekom, Orange, Telecom Italia, Vodafone, China Unicom, Spreadtrum ，Not supported by Orange)。
建议：对于eMBB、URLLC和mMTC来说，Polar码都是候选方式。

R1-168164        WF on turbo code selection        LG Electronics, Ericsson, CATT, NEC, Orange, IMT
建议：对于eMBB、URLLC和mMT中低吞吐量场景，采用LTE Turbo码，对于高吞吐量继续研究。低速率采用Turbo码的原因是它可以提供信息块大小和码率的灵活性，且可以考虑对Turbo码进行增强。

对于eMBB，会议认为，eMBB的数据信道的编码方式将在RAN1#86bis选定。因此建议各公司继续对各种编码方式进行分析和比较，以便在下次会议上形成最终结论。各公司还需要提供针对一些设计细节，尤其针对LDPC(因为此次会议上LDPC呼声较高)，提供灵活性需求以及如何满足的细节，提供相应的实施复杂度和对性能影响的细节。并且不排除编码算法的混合使用。

1.2        控制信道、URLLC和mMTC编码算法

对TBCC和Polar的 支持性体现在2个提案中。

-TBCC(R1-168170)：
Ericsson、Nokia、ASB、LG、NEC、Orange、IMT

-Polar(R1-168024)：
Huawei、HiSilicon、CMCC、CUCC、Deutsche Telekom、Vodafone、MTK、Interdigital、Spreadtrum

2.        关键信息摘录

2.1        支持LDPC作为eMBB数据信道编码方式
参考提案：R1-167999：WF on Channel Coding Selection

R1-167999：实施复杂性比较结果表明LDPC比其他编码机制要好。一些提案对实施复杂性也有一些结论如下，因此建议LDPC用于eMBB数据信道，以便在高速和大数据块长度下体现性能和实施的优势。

Company         Tdoc number                Observations
Qualcomm        166372                        LDPC better than Turbo/Polar
ZTE                167896                        LDPC better than Turbo/Polar
Ericsson        166396                        Inflexible LDPC better than Turbo
                                                Flexible LDPC comparable to Turbo
                                                Polar list decoder little worse than Turbo

Intel                166557                        LDPC better than Turbo/Polar
Mediatek        167531                        LDPC better than Turbo

Nokia, ASB,
Verizon, Xilinx        167272                LDPC better than Turbo/Polar

Samsung                166774                LDPC better than Turbo
Interdigital        167567                        LDPC better than Turbo/Polar
LG                167884                        Some LDPC* comparable with Turbo
                                                (* Limited flexible LDPC)

修改版本为R1-166376，去除了上述表格。

2.2        支持Polar作为eMBB信道编码方式

参考提案： R1-168040：WF on channel coding selection
RAN1#85观察到对于大信息块，所有候选信道编码的链路性能具有可比性。

对于小块长度(80~1000比特)来说，Polar码优于卷积码、Turbo码和LDPC码。
•比卷积码优~2dB以上 [R1-167216]
•比Turbo码优0.5~1dB[R1-167212]
•比LDPC码优最多1dB[R1-167212](注：LDPC不支持1比特粒度)
Polar和LDPC在高速率时的实现都是可行的[R1-167213]
Polar码满足URLLC的延迟需求[R1-167213]

2.3        支持Turbo码作为eMBB数据信道编码方式

参考提案：R1-168164：WF on turbo code selection

主要是从应对不同码块长度和码率的灵活性和能效方面来考虑的。
低速率采用Turbo码的原因是它可以提供信息块大小和码率的灵活性，且可以考虑对Turbo码进行增强。

2.4        支持TBCC作为eMBB的控制信道编码方案

参考提案：R1-168170：WF on coding technique for control channel of eMBB

观察到对于10~100比特的数据块来说，TBCC性能优于其他编码方式。可以采用list decoding来提升TBCC解码器的性能，但是否采用取决于接收机如何实施。

因此，建议对于eMBB的上下行控制信道，采用TBCC作为新空口的信道编码技术。有待继续研究LTE TBCC的增强。对于超出10~100比特范围的数据块，还有待研究是否其他编码技术也应当包含在控制信道中。

2.5        支持Polar作为eMBB的控制信道编码方案

参考提案：R1-168024：WF on code selection for control channel

RAN1#86仿真结果表明，在相等的复杂度下，Polar比TBCC优1.5dB。对于较大的信息块长度，TBCC性能降低，而Polar性能提升。二者的alarm probability(如16比特CRC)都较差，因此，对二者来说，CRC都不用于错误校正，仅用作错误检测。

建议将Polar码作为上下行控制信道的编码方式。

二、        RAN1 #86b会议

1.        会议总体情况

此次会议将产生eMBB数据信道的编码方案的最终定论，因此讨论尤为激烈。中国和国外多家公司支持Polar码，这是华为努力的结果，因此避免了将Polar码排除掉。讨论证明，Polar码对于大数据块来说，性能不够好，因此对于数据块大于1024比特，同意选择LDPC。下次会议将考虑对于小码块所采用的信道编码方式。

初期提案集中在LDPC码、LDPC+Turbo、LDPC+Polar、Polar等4个方面。

[1]        支持LDPC作的厂家有(R1-1610767)：

Samsung、Qualcomm Incorporated、Nokia、Alcatel-Lucent Shanghai Bell、Verizon Wireless、KT Corporation、KDDI、ETRI、IITH、IITM、CEWiT、Reliance Jio、Tejas Network、Xilinx、Sony、SK Telecom、Intel Corporation、Sharp、MTI、National Instruments、Motorola Mobility、Lenovo、Cohere Technologies、Acorn Technologies、CableLabs、WILUS Inc、NextNav、ASUSTEK、ITL (also OK to Ericsson)

-LDPC码可以有效支持eMBB数据信道各种速率、码块长度，以及采用精细粒度的IR HARQ。
-LDPC码可以提供更好的area和能效，尤其在高高吞吐量条件下。
-LDPC码在并行处理方面经得住考验，且能提供更好的解码时延。

建议：eMBB数据信道考虑采用LDPC码。

[2]        同时支持LDPC + Turbo码的厂家(R1-1610604)：

dataAccelerComm、Ericsson、Orange、IMT、LG、NEC、Sony

-采用Polar码时，实施方面存在明显的风险。
-灵活LDPC实施方面存在疑问。
-LDPC码和Turbo码可以互补。
-LDPC码和Turbo码配合可以避免Polar码的风险和独立LDPC码的顾虑。
因此建议：采用LDPC和Turbo码，缓解LDPC灵活实施相关的顾虑。
       
[3]        同时支持LDPC + Polar的厂家(R1-1610607)：

ZTE、ZTE Microelectronics、Acer、Bell、CATR、China Unicom、China Telecom、CHTTL、Coolpad、Deutsche Telekom、Etisalat、Huawei、HiSilicon、InterDigital、III、ITRI、MediaTek、Nubia Technology、Neul、OPPO、Potevio、Shanghai Tejet、Spreadtrum、TD Tech、Telus、Vivo、Xiaomi、Xinwei、IITH、IITM、CEWiT、Reliance Jio、Tejas Network

-eMBB中，应当支持2类信道编码。
  • 信道编码类型1用于数据块 > X比特的场景。
  • 信道编码类型1用于数据块 <= X比特的场景。
-信道编码类型1建议采用LDPC码。
-信道编码类型2建议采用Polar码。

建议：对于eMBB，考虑2种信道编码方式。数据块大于X比特时，采用LDPC；数据块小于等于X比特时，采用Polar码。

[4]        支持Polar的厂家(R1-1610668)：

Huawei、HiSilicon、Acer、Bell、CATR、China Unicom、China Telecom、CHTTL、Coolpad、Deutsche Telekom、Etisalat、InterDigital、III、ITRI、MediaTek、Nubia Technology、Nuel、OPPO、Potevio、Spreadtrum、TD Tech、Telus、Vivo、Xiaomi、Xinwei、ZTE、ZTE Microelectronics、CATT

建议：eMBB数据信道考虑采用Polar码。


会议讨论过程中，对于eMBB数据信道的编码方案，也同样存在上述多种方案，RAN1 #86bis会议纪要中有一段描述，首先是Question: How many channel coding schemes should be specified for the NR eMBB data channel(eMBB数据信道需要规定几种信道编码方案)? 1种的选项为LDPC和Polar，Polar后面只列出了华为。而大于1种的方案就是Turbo+LDPC以及LDPC+Polar，各有多个拥护者。报告也同时说明上述问题给出了一个大致的结论，但是也很不全面。因此，可能的决议为：
-选择1：eMBB数据信道只采用LDPC编码。
-选择2：eMBB数据信道采用LDPC+Polar编码，根据数据块大小X确定。
-选择3：eMBB数据信道采用LDPC+Turbo编码，根据数据块大小X确定。

会议从性能、码率和码块长度支持的灵活性、对Chase-和IR-HARD的支持性、实施复杂度和时延等方面对LDPC、Turbo和Polar进行了详细对比，对比结果在会议纪要的Oberservation部分有详细描述。同时还提到，对于新的未经实践检验的编码方法，一些公司认为仍需要下大功夫来进行规范设计等工作。

最终决定为：
-eMBB中，信息块大小>X时，数据信道的编码方式为LDPC码。
-eMBB中，信息块大小<=X时，RAN1#87决定选择Polar、LDPC和Turbo中的哪一个。选择将在所有观察点(Observation)的基础上进行，包括总体实施复杂度等。
-X在RAN1#87中确定，128 <= X <= 1024比特，须考虑复杂度。
-继续研究URLLC、mMTC以及控制信道的编码方式。

但是对于最终决定，最后一天的讨论中各厂家仍然有很多看法，因此，会议纪要中最终注明“RAN1仍鼓励大家对信道性能提供更多的观察和结论(Conclusion: RAN1 is still encouraged to strive to draw additional observations and conclusions on the performance of channel coding)。关于这部分的各厂家的意见和讨论过程，在会议纪要中有详细论述，感兴趣的话可以去下载查看。

2.        关键信息摘录

2.1        支持LDPC作为eMBB数据信道编码方式

参考提案；
R1-1610690：Way forward on observations for eMBB data channel coding

[1]        总结：
-LDPC码可以有效支持eMBB数据信道各种速率、码块长度，以及采用精细粒度的IR HARQ。
-LDPC码可以提供更好的area和能效，尤其在高高吞吐量条件下。
-LDPC码在并行处理方面经得住考验，且能提供更好的解码时延。

[2]        速率灵活性：

LDPC码可以支持多种码率、HARQ，包括IR-HARQ。
Company                                Tdoc number                        Observations
Ericsson                        R1-1608875                        LDPC can support rate flexibility
LG                                R1-1609239                        LDPC can support rate flexibility
ZTE                                R1-166414/R1-1608974        LDPC can support rate flexibility
MediaTek                        R1-167532                                LDPC can support rate flexibility
Intel                                R1-166558/R1-1610377        LDPC can support rate flexibility
Nokia, ASB, Verizon, Xilinx        R1-167274                        LDPC can support rate flexibility
Qualcomm                        R1-1610137                        LDPC can support rate flexibility
Samsung                        R1-166770/R1-1609064        LDPC can support rate flexibility
National Taiwan University        R1-1609708                LDPC can support rate flexibility


[3]        长度灵活性：
Company                                Tdoc number                        Observations
Ericsson                        R1-1608875/R1-1608876        LDPC can support length flexibility
LG                                R1-1609242                        LDPC can support length flexibility
ZTE                                R1-166414/R1-1608974        LDPC can support length flexibility
MediaTek                        R1-167532                                LDPC can support length flexibility
Intel                                R1-166557/R1-1610377        LDPC can support length flexibility
Nokia, ASB, Verizon, Xilinx        R1-167273                        LDPC can support length flexibility
Qualcomm                        R1-1610137                        LDPC can support length flexibility
Samsung                        R1-166769/R1-1609065        LDPC can support length flexibility
National Taiwan University        R1-1609708                LDPC can support length flexibility

[4]        实施复杂度较好
Company                         Tdoc number        Observations
Qualcomm                        R1-1610139        LDPC better than Turbo/Polar
ZTE                                R1-1608971        LDPC* better than Turbo/Polar
Ericsson                        R1-1608879        Depends on how different parity check matrices
Intel                                R1-1609511        LDPC better than Turbo/Polar
Mediatek                        R1-1609337        A flexible barrel shifter supporting lifting factors up to 384 occupies only 7% of the decoder.
Nokia, ASB, Verizon, Xilinx        R1-1609582        LDPC better than Turbo/Polar
Samsung                                R1-1609067        LDPC better than Turbo
LG                                R1- 1609241         Flexible shift network (QSN) requires twice more multiplexer than single size shift network (SS-CS)
       
RAN1 #86中对于高吞吐量下的实施复杂度的分析提案：
Company         Tdoc number        Observations
Qualcomm        166372        LDPC better than Turbo/Polar
ZTE                167896        LDPC better than Turbo/Polar
Ericsson        166396        Inflexible LDPC better than Turbo
                                Flexible LDPC comparable to Turbo
                                Polar list decoder little worse than Turbo
Intel                166557        LDPC better than Turbo/Polar
Mediatek        167531        LDPC better than Turbo

Nokia, ASB, Verizon, Xilinx        167272        LDPC better than Turbo/Polar

Samsung        166774        LDPC better than Turbo
Interdigital        167567        LDPC better than Turbo/Polar
LG                167884        Some LDPC* comparable with Turbo

2.2        支持LDPC+Turbo作为eMBB数据信道编码方式

参考提案：
R1-1610544：Observations on channel codes for NR eMBB data

提案认为，在高吞吐量情况下，LDPC已经证明比Polar更为成熟，其BLER、吞吐量、时延、area效率和能效等方面都很好。

Turbo在灵活性和HARQ方面也较成熟，增强Turbo对于中低速率应该有优势，且在非独立部署的5G系统中，实现与LTE的互操作时，Turbo也是必需的。

由于此方案未预采纳，此处不再多加分析，感兴趣的话可以参看提案原稿。

2.3        支持Polar作为eMBB数据信道编码方式

参考提案：
R1-1610667：Way Forward on Channel Coding Observations

提案从性能、灵活性、实施复杂性和时延等方面进行了分析对比，包括Polar与LDPC、Polar与Turbo、Polar与TBCC等方面。由于此方案未预采纳，此处不再多加分析，感兴趣的话可以参看提案原稿。

三、        编码方式的比较和考虑

虽然RAN1 #86会议对eMBB场景下的数据信道编码方式进行了最终选择，但是各种编码方式的技术优劣等方面仍有许多值得深入研究的地方。而在已经闭幕的RAN1 #87会议上，Polar已经力排众议，被选为控制信道的编码方案，那么，首先借用RAN1 #86会议报告中的Observation，来看看不同编码方式技术和应用方面的顾虑。

RAN1 #86会议报告中关于信道编码的Observation：

[1]        性能方面：

LDPC、Polar和Turbo码的性能在R1-1610600 (更新为R1-1610423)中有总结。

R1-1610423中，包含各种编码方案进行仿真的相关提案信息，并提供了各种仿真结果，会议上大家进行了讨论和修正。可见，对于各种编码，都是在大量仿真和技术分析的基础上进行的取舍。

但是，会议认为，这个也不足以得出结论，实施难度等方面还有很多不同看法。

[2]        码率和码块大小支持的灵活性方面：

LDPC、Polar和Turbo码都能够支持一定的灵活性。

[3]        Chase-和IR-HARQ支持性

LDPC和Polar的拥护者表示它们都支持CC和IR HARQ。
- 一些公司对Polar码在HARQ的增量收敛方法(incremental freezing method)上有顾虑。
- 一个公司对LDPC码的IR-HARQ的复杂性有顾虑。
Turbo码对CC和IR HARQ的良好支持性众所周知。

[4]        实施复杂性

a)        LDPC：

-LDPC码在支持几个Gbps吞吐量的商用硬件中广泛应用，但是在5G新空中也还是有些顾虑：
  •码率低时，area效率会降低。
  •灵活性增加时，LDPC的复杂度也会增加。
  •支持者认为LDPC的有限灵活性可以提供最有吸引力的area效率和能效，这种特性对于支持全面灵活性有好处，而有些公司则认为应当限制适当的灵活性，因为太灵活的话会导致功耗、时延和area增加。
  •LDPC经验证可以提供并行解码，一次有利于降低解码时延。
  •其他等等(还有一些好处未加翻译，请参看原文)。

b)        Polar：

-Polar码可以实施，虽然目前没有商用产品，但是对于5G新空口来说，有以下考虑：
  •对于更短的码块程度和更低的码率来说，area效率会降低。
  •对于list解码器来说，随着list size的增加，尤其是更大的块大小的增加，实施复杂度也会增加。(以下4小点具体细节未加翻译，请参看原文)
  •解码硬件能够获得可接受的时延、性能和灵活性，不过对于area效率和能效方面有些顾虑。

c)        Turbo:

-Tuubo码商用广泛，支持新空口所需的HARQ和灵活性，但是对于高速数据速率或者低时延的支持性方面存在疑问。
(下面从10个方面进行了分析说明，具体细节未加翻译，请参看原文)

[5]        时延：

-3种编码的支持者都认为有其编码算法能够新空口的时延需求。
  •一些支持者认为，Latency-wise，高度并行化，有助于LDPC和Turbo降低时延。
•虽然Polar不是高度并行化的，但是支持者也认为有其他设计技术可以帮组降低Polar解码的时延。
•一些公司认为，如果大包不考虑采用Polar码，那么至少小数据块(~1000比特)还是可以获取低时延的。然而，一些公司认为Polar比Turbo的解码时延要大。

[6]        其它考虑：

-Turbo和LDPC已经广泛应用了，而Polar码作为3个中最新的一个，还缺乏应用。所有码都需要进行规范设计，以便满足5G新空口的需求。一些公司认为尚未广泛应用的技术需要花费的力气更大。

       
四、        编后语

有关更多Polar码被批准的内容我们还需要借助RAN1 #87会议报告了解，希望本文能有助于大家对不同编码方式的技术特点、会议过程增加认识，也希望在RAN1 #87会议报告发布后，我们对Polar码和编码讨论过程有更深入的理解和解读。

欢迎大家关注公众号：5G通信技术