本帖最后由 micro_ufo 于 2016-12-13 11:04 编辑
半个月前左右，RAN1 #87会议过程中传来的Polar码与LDPC码平分天下的消息让无数人振奋，如今，热潮已经逐渐冷却，但是Polar码光辉高大的形象却已经渗入无数通信人的心中。如今，会议的正式报告已经出炉，那么，透过RAN1 #87的会议报告，又可以获取那些有用的信息哪，是否对大家全面理解5G系统eMBB场景下新空口的信道编码有更全面的认识哪？
RAN1 #87是eMBB场景下编码方式的决定性会议，其重要性不言而喻。为了更全面了解eMBB编码的讨论内容和决议，本文除了分析#87会议内容之外，对之前的几次会议也作了简单整理，希翼能够承上启下，首尾相顾，也希翼大家理解起来更顺畅。
1. RAN1 #87有关编码的决议 针对eMBB场景，本次RAN1#87会议中有关信道编码的决定为：
| 场景 | | | | | | | | | | | | | | | | | | | | | | | | | | 对于重复度/块编码优先的特别小的信息块，还有待进一步研究。 | 对于重复度/块编码优先的特别小的信息块，还有待进一步研究。 | | 性能、实施复杂度和灵活性等方面还有待2017年1月份RAN1会议上确认。 | | | | 性能、时延、功耗和实施复杂度等方面还有待2017年1月份RAN1会议确认。 |
详细描述如下：
- UL eMBB数据信道 • 对于小的数据块，采用灵活LDPC(flexibleLDPC)作为唯一的信道编码方式。(除非性能、实施复杂度和灵活性等方面发现重大问题，否则将有在1月份RAN1会议上确认) • 对于大的数据块，RAN1#86已经确定采用LDPC了。 - DL eMBB数据信道 对于所有大小的数据块，都采用灵活LDPC(flexible LDPC)作为唯一的信道编码方式。 - UL eMBB控制信息 采用Polar编码方式(对于重复度/块编码优先的特别小的信息块，还有待进一步研究)。
- DL eMBB控制信息 • 采用Polar编码方式(对于重复度/块编码优先的特别小的信息块，还有待进一步研究) • 除非在性能、时延、功耗和实施复杂度等方面发现重大问题，否则将在2017年1月份RAN1会议上确定。
2. RAN1 #84bis ~ #86bis会议回顾
为了全面了解eMBB场景下编码决策过程，本文首先从不同业务特性及其它们对信道编码类型的需求谈起，然后梳理RAN1 #84bis到#87次会议对编码的讨论和确认过程，并重点描述RAN1 #87会议的决策过程。
2.1. RAN1 #84bis会议
RAN1 #84bis会议上，大家对5G新编码方式的必要性已经提出了明确需求，并最终达成协议，提出了5G新空口中值得考虑的几类备选编码方案，从而为后续讨论和仿真等工作奠定了基础。
备选编码方式如下： • LDPC • Polar • 卷积码(LTE和/或者LTE增强卷积码) • Turbo码(LTE和/或者增强Turbo码) • 不排除上述各类编码的组合使用 • Outer erasure code也不排除
会议强调，需要从实施复杂度、编解码时延、灵活性(码长、码率和HARQ)等方面对新编码方式进行分析和评估。
2.2. RAN1 #85会议
但多数企业同意优先考虑eMBB场景，但是由于各企业的观点不同，，因此最终会议只在仿真评估方法等方面达成协议，对具体的编码方式并未达成决议。
不同编码方式各有不同的支撑阵营，简述如下： - eMBB编码算法： § 高通、Nokia、Intel、SAMSUNG和ZTE认为LDPC是唯一选择。 § Ericsson、Orange和CATT认为Turbo和LDPC可同时考虑。 § HUAWEI认为Polar是唯一选择。
- URLCC编码算法： § HUAWEI、高通、ZTE、Interdigital、Mediatek等支撑Polar码。 § Nokia和Ericsson支撑卷积码和LDPC/Turbo。 § SAMSUNG和Intel支撑LDPC。
- mMTC编码算法： § HUAWEI、高通、Interdigital、Mediatek等支撑Polar码。 § Nokia、Ericsson、Intek和SAMSUNG支撑TBCC。
2.3. RAN1 #86会议
此次会议上， eMBB场景下的编码方案主要集中在3种选项上；而控制信道、URLLC和mMTC等场景下的编码算法，则主要集中在2个选项上。
eMBB场景下的编码方式集中在3个方面，简单信息描述如下：
- LDPC：选择LDPC作为eMBB数据信道的编码方式，以便在高速和大数据块长度下体现性能和实施的优势。 - Turbo + LDPC (高吞吐量场景) ：对于eMBB、URLLC和mMT中低吞吐量场景，采用LTE Turbo码，对于高吞吐量继续研究。低速率采用Turbo码的原因是它可以提供信息块大小和码率的灵活性，且可以考虑对Turbo码进行增强。 - Polar：对于eMBB、URLLC和mMTC来说，Polar码都是候选方式。
控制信道、URLLC和mMTC编码算法集中在2个方面，即： - TBCC：对于eMBB的上下行控制信道，采用TBCC作为新空口的信道编码技术。有待继续研究LTE TBCC的增强。对于超出10~100比特范围的数据块，还有待研究是否其他编码技术也应当包含在控制信道中。 - Polar：将Polar码作为上下行控制信道的编码方式。
最终会议明确eMBB的数据信道的编码方式将在RAN1 #86bis选定。
2.4. RAN1 #86bis会议
初始提案中，eMBB下数据信道的编码方案集中在LDPC码、LDPC + Turbo、LDPC + Polar、Polar等4个方面。会议从性能、码率和码块长度支撑的灵活性、从CC-HARQ和IR-HARD的支撑性、实施复杂度和时延等方面对LDPC、Turbo和Polar进行了详细对比。
RAN1 #86bis会议初步确定了eMBB数据信道的编码方案。决定如下：
| 业务类型 | | | | | | | | | | | | | | | | 编码选项 | | | | | | | 128 <= X <= 1024，
X在RAN1 #87中确定 | | | |
会议结论详细描述如下： - eMBB中，信息块大小>X时，数据信道的编码方式为LDPC码。 - eMBB中，信息块大小<=X时，将在RAN1#87会议中决定选择Polar、LDPC和Turbo中的哪一个。选择将在所有观察点(Observation)的基础上进行，包括总体实施复杂度等。 - X在RAN1 #87中确定，128 <= X <= 1024比特，须考虑复杂度。 - 继续研究URLLC、mMTC以及控制信道的编码方式。
3.]RAN1 #87会议详细分析
这次会议对于eMBB的数据信道和控制信息的编码方式都作了决定。至此为止，eMBB的相关编码方案基本上已经明确了，所以会议尤为重要，内容简述如下。
下面从数据信道和控制信道2方面来分别讨论编码方式的取舍和决策过程。
3.1. eMBB数据信道编码选择
对于数据信道，此次会议讨论也比较激烈。一些企业强调eMBB数据信道支撑Polar码，一些则强调LDPC，还有考虑支撑2种编码方案的。 会议最终确定eMBB数据信道只考虑采用LDPC码。
不同观点陈述如下：
3.1.1 50多家企业支撑Polar码
提案认为，对于eMBB的上下行数据信道，码块大于1024比特时，支撑Polar码作为编码方式。 这显然是要推翻RAN1 #86bis的一些结论嘛，不过遭到了一些企业的反对，如Ericsson、 Qualcomm、Nokia、ASB、Samsung、LG、ETRI、KT、VzW、Intel、Docomo、IMT、KDDI和NEC。 从3GPP会议纪要上看，提案后来可能将1024修改为255比特(待确认具体情况)。
3.1.2 LDPC 码支撑率较低
提案建议采用LDPC作为eMBB数据信道的唯一编码方案。
3.1.3 2种码型考虑
R1-1613306 WF on hardware efficiency for 2-code eMBBdata channel
建议eMBB数据信道考虑2种编码方案。 2种编码方式下，硬件资源利用率较高，小的信息块的信道码的功率效率较好。因此，2种编码方式相配合，可以扬长避短。
3.1.4 Turbo码支撑者更少
R1-1613347 WF on channel codes for NR short block lengtheMBB data 建议eMBB数据块<1024时，采用Turbo码。 对于1024，如果后续发现设计问题，可以再做调整。
3.1.5 提案举例分析
针对eMBB数据信道所需要的编码方案，Nokia企业在R1-1612275中进行了仿真对比，三种选项分别为： - 只使用LDPC - LDPC (用于大的数据块) + Turbo (用于小的数据块) - LDPC (用于大的数据块) + Polar (用于小的数据块)
其优劣对比结果说明如下：
| 只使用LDPC | | | 作为编码，LDCP可以针对所有大小的码块提供eMBB所需的良好的性能以及码率。 HARQ: IR和CC都能提供建好的性能。 解码实施灵活，厂家可以根据意愿进行实施(如能效、低时延、area-efficiency，或者其他设计优先级等) 对于短码来说，理论分析表明是最好的选择，不像其它码一样还需要24位CRC比特。(Performance gains with OSD and list decoders). | 一个解码器通常处于空闲状态；解码器的area-effieciency较低。 多模解码器(同时解码Turbo和LDPC)还没有较好的实现方式。 2类码都支撑HARQ。 想对LDPC来说没有性能增益。 对于短码和长码的最优性能来说，不需要2类不同的编码。吞吐量性能需求不高的时候，有许多编解码算法来提升性能。 | 一个解码器通常处于空闲状态；解码器的area-effieciency较低。 在支撑IR HARQ方面，Polar有一些性能问题。 Polar的母本限定为2^N。比如，码率1/6且码块为1000时，需要8192块polar码，对于较低码块来说，不易实施。 支撑小吞吐量时，Polar list decoders的实施方面能耗较高。 相对LDPC来说没有性能增益。 对于短码和长码的最优性能来说，不需要2类不同的编码。 |
3.2. eMBB控制信道编码选择
对于控制信道，实际上选择只在Polar和TBCC（尾比特卷积码）这2类方案中进行选择，基本上没有考虑LDPC。最终会议决定选择Polar码作为eMBB控制信道的编码方式。
典型提案示例如下：
| 提案编号 | | | | | | | | | WF on coding technique for control channel for eMBB | | | | | | | | | | LDPC(数据) Polar(控制，UCI) TBCC(控制，DCI) |
3.2.1 Polar码
50多家企业支撑Polar作为上下行控制信道的编码方式。
3.2.2 TBCC码(尾比特卷积码)
R1-1613577 WF on coding technique forcontrol channel for eMBB 提议认为： - 对于DCI，TBCC作为新空口的信道编码。 - 对于UCI，编码输入大小 [16]<=K<=100比特时，采用TBCC作为信道编码。 - LTE TBCC的增强有待未来进一步研究。
3.2.3 LDPC(数据)和Polar(控制)
提议认为： - 采用LDPC作为信息块>1024比特的eMBB下行数据信道的编码方式。 - 采用Polar作为信息块>1024比特的eMBB上行数据信道的编码方式。 - 采用Polar作为上下行控制信道的编码方式。
3.2.4 LDPC和Polar以及TBCC
提议认为： - 采用LDPC作为eMBB数据上下行新到的唯一编码方式。 - 采用Polar作为上行控制信息(UCI)的编码方式。(对于重复度/块编码优先的特别小的信息块，还有待进一步研究。) - 采用TBCC作为下行控制信息(DCI)的信道编码方式。
4. 总结
通过RAN1 #84bis到RAN1 #87共5次会议，eMBB场景下业务信道和控制信道/信息的编码方案已经基本上讨论完成了。虽然2017年1月还有一次ad hoc会议，但是eMBB编码方案修改的可能性已经很小了。编写本文的目的也是想借助历次会议报告来澄清技术细节和讨论内容，从而更加清晰地了解结论背后的东西，相信能给大家一些帮助。
举例来说，实际上对于eMBB业务信道，候选编码方式包括LDPC、Polar以及Turbo，最终LDPC胜出；而控制信道/信息的编码方案只是在LTE原有的TBCC(尾比特卷积码)和Polar之间展开的，并没有涉及LDPC与Polar码之间的竞争，所以Polar是击败TBCC而荣登控制信道编码方式的宝座的。如果不区分控制信道和数据信道，而简单地说Polar战胜LDPC，就可能不太严谨。但是，Turbo的衰落却是必然的事实，当然，作为从3G时代一直沿用的传统编码方式，Turbo的地位无疑是举足轻重的，而它的退出也正表明技术的进步和发展，并且一些企业力挺Turbo，也表明Turbo仍有其可取之处。
总之，技术的进步是循序渐进的，而日前的技术选择也离不开大国的较量和政治的影响，所以一方面理解技术本身的内容，另一方面了解技术之外的东西，才能全面看清现实，增强认识。
欢迎大家关注公众号：5G通信技术
| 
2
发表于 2016-12-13 10:36:39