为极解密，华为 5G Polar 码之争真相（三）

第四章 登峰“造”极，“为”我独尊

“华为独霸 5G ”，“华为碾压高通”，“华为碾压爱立信”，“华为制定 5G 标准”，“ 5G 标准中国制定”， RAN87 刚刚结束，这样的标题在微信朋友圈内便铺天盖地而来。

诚然华为在任教主的带领下，商业上已经接近“千秋万载，一统江湖”的状态。在 5G 的技术和标准制定方面，是否也已是天上地下，“为”我独尊的境界了呢？

首先，从技术本身来看， polar 码既非华为发明或者发现，突破性的解码方法亦非华为的创新。把 polar 等价成华为的技术甚至说成是中国制造实有混淆视听、指鹿为马之嫌。

其次，从 3GPP 的决议来看， polar 仅仅被同意用在 eMBB 的控制信道上。正如前文中所澄清过的几点：

Polar 最终获得的是 eMBB 的控制信道编码，既非之前媒体提到的“长码”亦非“短码”（长码短码均属于 5G eMBB 数据信道讨论范畴，最终都采用了 LDPC ）。

Polar 码作为长码从未得到 3GPP 大多数公司认可。

Polar 码在控制信道上取代的是 TBCC 而非 LDPC 。

控制信道码长一般情况不超过 100 比特，支持的范围远小于数据信道编码码长。

也就是说 Polar code 本身都只是 5G 信道编码中的一小部分。枉称独霸 5G 未免过于大言无当。

Polar 码到底是否有可实现增益，到底有多大的风险，仁者见仁（一年半载之后，有产品上市便会见分晓）。但有一点可以非常肯定地说，换其他任何一家公司想要推类似 polar code 或者任何一个类似三神器进 5G NR 在今天的 3GPP 都是绝无可能的。没有明显优势于类似技术却在实现上存在较大风险的东西是非常难以获得多数公司真心支持达成共识的。

Polar 码极化事件于 3GPP 是史无前例的：华为在自己主推的三神器在 3GPP 全面受阻的情况下，孤注一掷倾尽整个公司甚至是举国之力在小小的 polar 上。在此事件中，华为到底碾压了谁？美国的高通或者瑞典的爱立信？诺基亚，阿朗，三星， Intel ， LG ，索尼， DoCoMo 等等众多资深 3GPP 跨国企业，大多数需要承担 5G 硬件实现的公司都遭遇了碾压。

3GPP 的现行决议机制也在此事件中遭遇了前所未有的挑战。在会议进程中，我们看到有多少公司迫于压力，投鼠忌器而无法直抒己见；又有多少代表先抑后扬，却无可奈何。这一幕幕，或为各大公司代表亲眼目睹，或留在各个公司文稿和会议记录中，这些细节自会由后来的读者慢慢发掘以明真相。

Polar 码极化事件尘埃落定之后，有三个问题需要解答：

1 ． 华为是会以“三神器危局”为鉴，重归大道引领群雄。亦或是食髓知味，继续剑走偏锋“为”我独尊，希冀在明年三月 mMTC “多址”的讨论中上再次上演一幕 SCMA 版“皇帝的新衣”。

2 ． “ Huawei, no way until I get my way ”，如果华为今后故伎重演， 3GPP 及其生态圈内的诸多公司又将如何应对？

3 ． 如何应对在通信生态圈经历大规模整合之后， 3GPP 的决议机制所遭遇的空前挑战。当一家公司的强大足以威慑到足够数量的中小会员、而相关的决定未必对这些会员产生任何实质上的影响时，极化现象便极可能被促成。在这种情况下，传统意义上的决议机制还能否遵从尊重共识的初衷？

Polar 码极化事件的时间点也相当微妙。如果类似的极化事件今后在 3GPP 频频发生，必然催生更多 3GPP 之外的 5G forum 以规避此类风险。由此而造成的 5G 市场进一步碎片化可能是业界没有一个人希望看到的结果。

跋

笔者也曾是热血青年，在成长的道路上被一个又一个的爱国故事激励过，振奋过。然而亲历过这几十年一遇的 polar 码事件，特别是看到相关报道与所经历的事件本身的落差时，不禁想给大家分享一下不同的视角下整个事件的起承转合。不敢说绝对的客观公正，但从不同的视角来看同一个事件至少可以给读者更多元化的解读空间。

中华民族大国崛起乃大势所趋，任何人都无法阻挡的历史潮流。中国现在有相当多的优秀民族企业（并非只靠一个大托拉斯级的公司支撑整个经济命脉的国家），在当今世界的各个领域，互联网，生物科技，航空航天，引领潮流，走在前端。媒体实在没有必要在一个有争议事件上如此炒作一个公司。在这个信息高度开放的年代，“历史”很难再是一个百般顺从，任人打扮的小姑娘。爱国“故事”固然让人热血沸腾，但中国的年轻一代的奋发不能光靠着味精勾兑的鸡汤或鸡血来提神。

中华民族企业想能够屹立于世界舞台引领群雄，也应当着眼于大局，顺势而有为也。中华民族伟大复兴的重担不必要也不应该把宝押在几个虫篆之技上面。

参考文献

[1] RAN1 86 final minutes report:

http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_86/Report/Final_Minutes_report_RAN1%2386_v100.zip

[2] RAN1 86b final minutes report:

http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_86b/Report/Final_Minutes_report_RAN1%2386b_v100.zip

[3] RAN1 87 Chairman ’ s Notes and draft minutes report: http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN1/Inbox/Chairman%20Notes/Chairman's%20Notes%20RAN1_87_final.doc

http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_87/Report/Draft_Minutes_report_RAN1%2387_v010.zip

[4] R1-1611255, “ HARQ scheme for polar codes ”, Huawei, HiSilicon

[5] RAN1 87 contribution list:

http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_87/Docs/TDoc_List_Meeting_RAN1%2387.xlsm

附录 1

Agreement:

• “ The channel coding scheme for eMBB data is LDPC, at least for information block size > X

• FFS until RAN1#87 one of Polar, LDPC, Turbo is supported for information block size of eMBB data <= X

• The value of X is FFS until RAN1#87, 128 <= X <= 1024 bits, taking complexity into account

• The channel coding scheme(s) for URLLC, mMTC and control channels are FFS ”

附录 2

以下摘录于[2](3GPP RAN1 86bis chairman ’ s notes: Section 8.1.3.1):

“ Question: How many channel coding schemes should be specified for the NR eMBB data channel:

• 1:

o LDPC: Ericsson, Sony, Sharp, Nokia, ASB, Samsung, Intel, QC, VzW, KT, IITH, IITM, Fujitsu, MotM, Lenovo, KDDI

o Polar: HW

• 1:

o T+L Accelercomm, IMT, LG, NEC, Fujitsu, Orange

o L+P ZTE, Etisalat, Mediatek, Nubia, Xiaomi, Coolpad, Neul, HW devices, OPPO, CATR, TDTech, Spreadtrum, Potevio, ITRI, IDC, DT, NTU

Note that the above questions give an approximate picture, though not necessarily complete.

Possible Agreements:

Alt 1:

• The channel coding scheme for eMBB data is LDPC

Alt 2:

• The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X

• Polar coding is supported for eMBB data for blocks smaller than X

Alt 3:

• The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X

• Turbo coding is supported for eMBB data for blocks smaller than X

Agreement:

• The channel coding scheme for eMBB data is LDPC, at least for information block size > X

• FFS until RAN1#87 one of Polar, LDPC, Turbo is supported for information block size of eMBB data <= X

o The selection will focus on all categories of observation, including overall implementation complexity, regardless of the number of coding schemes in the resulting solution (except if other factors are generally roughly equal)

• The value of X is FFS until RAN1#87, 128 <= X <= 1024 bits, taking complexity into account

• The channel coding scheme(s) for URLLC, mMTC and control channels are FFS ”

限于篇幅，这里没有列举对 Alt 1~3 反对的公司（大家可以参见[2]大致上是 24 家反对 Alt 1, 27 家反对 Alt 2, 33 家反对 Alt 3 ）。但是要澄清的关键是，无论是哪种选择，一致的意见都是长码必须用 LDPC 。

附录 3

先来看最后的决定：

Agreement:

• UL eMBB data channels:

o Working Assumption to adopt flexible LDPC as the single channel coding scheme for small block sizes (to be confirmed unless significant issues are identified by the RAN1 Jan adhoc in relation to performance, implementation complexity and flexibility)

o (Note that it is already agreed to adopt LDPC for large block sizes)

• DL eMBB data channels:

o Adopt flexible LDPC as the single channel coding scheme for all block sizes

• UL control information for eMBB

o Adopt Polar Coding (except FFS for very small block lengths where repetition/block coding may be preferred)

• DL control information for eMBB

o Working Assumption to adopt Polar Coding (except FFS for very small block lengths where repetition/block coding may be preferred)

§ To be confirmed unless significant issues are identified by the RAN1 Jan adhoc in relation to performance, latency, power consumption and implementation complexity

两个 working assumptions 基本就是达成一致意见（除非发现现行方案有严重设计缺陷）。假设这些 working assumptions 都最终被采纳，对 eMBB 来说，数据信道长码短码都采用了 LDPC ，而 Polar code 被控制信道所采用。但击败的对手并非 LDPC ，而是之前提到的 TBCC 。

从最后阶段的几个竞争提案中（参见[3]中的提案 R1-1613211, R1-1613577, R1-1613248 ），很明显地可以看出：

1 ） 提到 LDPC 的都只是和数据信道有关

2 ） polar 在控制信道上的竞争对其实是咬尾卷集码 (TBCC) 而非 LDPC 。

为了避免过大篇幅的引用，这里仅附上其中一个提案：

R1-1613248 WF on NR channel coding

Proposal:

• Adopt LDPC as the single channel code for uplink and downlink eMBB data channels for all relevant info block sizes

• Adopt Polar as the channel code for the uplink control information

– FFS for very small block lengths where repetition/block coding may be preferred

• Adopt TBCC as the channel code for the downlink control information ”