如何看待華為拿下5G短碼方案？

美國當地時間11月17日凌晨0點45分，在剛剛結束的3GPP RAN1 87次會議的5G短碼方案討論中，經過艱苦卓絕的努力和萬分殘酷的競爭，以中國華為公司主推的Polar Code（極化碼）方案，成為5G控制信道eMBB場景編碼方案。

編者按

「華為極化碼事件」內幕：

極化碼獲得的並非之前大肆炒作的「短碼」。

極化碼打敗的對手並不是LDPC，而是在控制信道上取代4G現有技術TBCC。

若非極化碼最終靠非技術手腕擠進控制信道，華為投資幾十億的5G「三神器」在5G NR第一階段業已全部打水漂。

整個5G信道編碼又經歷一番怎樣波瀾壯闊的爭鬥，這背後又隱藏著多少暗流洶湧的陰謀詭計。」為極解密「 為您最全方位的解析。

第一章 極之澄清

第一章 第一節 5G到底哪一部分碼會考慮使用極化碼？

第一章 第二節 極化碼在長碼上真的是幾票惜敗於LDPC么？

第一章 第三節 5G NR 極化碼到底打敗了誰？

第二章 極化之源

第二章 第一節 前5G -- 毫米波

第二章 第二節 「三神器」

第三章 極化過程

第三章 第一節 哥德堡會議（2016年8月）

第三章 第二節 「國標碼」

第三章 第三節 里斯本會議（2016年10月）

第三章 第四節 雷諾會議（2016年11月）

第四章 登峰「造」極，「為」我獨尊

跋

參考文獻

附錄1

附錄2

附錄3

近期有關「華為的」極化碼（polar
code）碾壓西方列強贏得5G信道編碼的新聞鋪天蓋地。作為幾次會議的觀戰者，僅作此文澄清一些事實，也兼談一些對5G的個人看法，以期拋磚引玉。

「為極」有兩方面含義：

字面意思即華「為」所推崇的「極」化碼。

同時也蘊含「所作所為以至極」的意思，隱喻此次事件對3GPP的影響。

有關polar code的報道可謂鋪天蓋地，各種名詞概念看得人頭暈目眩，到底polar碼會被5G哪部分採用，看了諸多報道可能還是一頭霧水。其實梳理一下，編碼應用主要集中在以下兩類信道：數據信道，控制信道。在3GPP的討論過程中，數據信道又有了長碼和短碼的討論。

先說一下結論：

Polar code被採用的是控制信道的編碼，既不是長碼也不是短碼，因為長短碼只屬於數據碼討論範疇。

我們首先解釋一下數據和控制信道的區別和聯繫：

所謂數據信道：傳輸的是用戶所要傳遞的數據，視頻瀏覽，微信簡訊，電話服務等等。

所謂控制信道：傳輸的是有關數據信道的信息，譬如，數據在哪裡傳，數據塊的大小，等一些控制信息。

通常來說，數據信道編碼所需要的碼長範圍遠遠大於控制信道，且數據信道編碼需要支持高速率數據傳輸，相對控制信道而言有更高的硬體要求。下面表格1總結了數據信道和控制信道比較常見的碼塊信息比特長度。

表格1：數據信道和控制信道碼塊信息比特長度的通常範圍

數據信道 Info Bit K From 40 to 6,000~8,000

控制信道 Info Bit K Up to 300 bits (極端場景)

這個表格的例子列舉了常見的數據信道和控制信道所要支持的信道編碼碼塊長度。一個數據信道碼塊長度從40-bit到6,000~8,000-bit。一個數據信道的傳輸塊可以包含幾十甚至成百上千的碼塊，換而言之，數據信道的數據量可以比控制信道高几個數量級。而控制信道的碼長一般在100以內便可以覆蓋大部分應用場景（此處數據參照4G LTE，5G的控制信道設計尚未完成，具體範圍是否變化還待定）。這並不意味著控制信道編碼不如數據信道編碼重要（而只是說明兩種信道需要的碼長範圍不同），事實上恰恰相反，控制信道編碼解碼對5G整個的延時，功耗等都有著深遠的影響。Polar在延時功耗上能否符合要求還有待驗證。

控制信道的碼長雖短，但卻並不隸屬於媒體近日一直熱炒的「長碼」和「短碼」中的任何一類。因為被熱炒的Turbo,
LDPC和Polar 5G「短碼」之爭僅限於數據碼範疇。

其實3GPP標準中本無所謂長碼短碼的概念，時下報道中常見的長碼短碼來自於10月里斯本（3GPP RAN1）會議關於「增強型移動寬頻（eMBB）的數據碼」的討論。10月里斯本RAN1的決議[2]摘錄見附錄1。四點決定非常清楚：

a.
數據信道長碼(information
block size &> X)用LDPC

b.
數據信道短碼(information
block size ≤ X)用Turbo, LDPC
or Polar 有待3GPP 十一月雷諾會議決定

c.
長碼短碼載荷分界線 X 在128到1024 bit之間, X的具體值有待3GPP
十一月雷諾會議決定。

d.
控制信道和URLLC（超可靠低時延通信）和mMTC（大規模物聯網）的編碼有待研究

由此可見，最近一直被提及的長碼短碼指的都是數據信道編碼（a和b）。控制編碼的討論是另外的研究課題（包含在d裡面）。

很多報道說polar被控制信道「短碼」所採用，不知是對數據信道「長碼短碼」的討論背景確實一無所知，亦或是有意無意地混淆了概念。

在章節最後，重申一下結論：

Polar code最終被採用的是控制信道的編碼，既不是數據碼中的「長碼」也不是「短碼」。

第一章 第二節 極化碼在長碼上真的是幾票惜敗於LDPC么？

有報道說在10月里斯本3GPP RAN1會議長碼的決議中，polar code 以幾票之差惜敗於LDPC。是否有這回事呢，到底有多少家公司支持polar做eMBB的長碼？

察看一下10月里斯本會議的紀錄[2]，事實便很清晰（原始記錄[2]可以在3GPP網站上下載，參考文獻里提供了鏈接）。事實上在當時的討論中，對於大多數公司來說，LDPC用於長碼，幾乎是無可爭議，是為了達到高吞吐率和硬體的高效率所必需的。絕大多數公司都認可即便短碼可能有其他選擇，長碼都必須要有LDPC。實際上，除了華為覺得polar code可以同時勝任長碼和短碼以外，其他沒有任何一家公司表示長碼不需要LDPC（其他所有支持turbo/polar的公司也都明確表示長碼需要LDPC，即LDPC+Turbo或者LDPC+Polar）。然而在短碼問題上，用LDPC,
Polar還是Turbo幾方爭持不下。為了取得進展，主席最終先採納了大家都能夠同意的LDPC作為eMBB長碼，參見附錄2中的詳細分析。

從結果來看，LDPC用於長碼幾乎是眾望所歸自然而然的結果。所謂polar的幾票惜敗LDPC於長碼的說法，不知有何依據。

首先列舉一下5G主要的候選編碼如下：

1）Turbo code (turbo碼)

2）LDPC code（低密度奇偶校驗碼)

3）Polar code (極化碼)

4）TBCC (咬尾卷集碼)

數據信道編碼的競爭主要在Turbo/LDPC
和Polar三者之間展開。最終LDPC脫穎而出，成為數據信道編碼（請參考前文）。

而控制信道編碼，主要的爭奪其實是在TBCC和Polar之間展開，具體的技術討論也只是在11月雷諾會議上才展開。控制信道編碼本來不必在雷諾會議上決定，但作為數據控制信道編碼一攬子妥協方案的一部分，最終決定以Polar
code取代4G採用的TBCC。

看看最終的決定和最後階段的幾個競爭方案便一目了然（詳細分析參見附錄3）。

最終TBCC並未能成為下行控制信道的編碼，但之前提到的「短碼」屬於數據碼討論範疇，跟控制碼完全是風馬牛不相及的兩回事。說「polar在短碼上擊敗了LDPC拿下控制信道」，至少有兩處偷換了概念（a. 把控制信道編碼混淆成之前所說的數據信道短碼. b. 把polar擊敗的對手TBCC混淆成了LDPC）。再次簡單總結一下最後的結果：

1） 數據信道：長碼，短碼均採用了LDPC

2） 控制信道：Polar擊敗的是TBCC而非LDPC

「Polar事件」 極化過程並非一蹴而就，也非一個孤立的事件。把它的發展過程放到整個3GPP
5G發展的大背景下才能得見事件的全貌。要了解整個事件的來龍去脈，必須對之前5G的背景做一些簡單的介紹。無線通信系統，從1G到2G是從模擬到數字的飛躍；2G到3G是從語音到數據的飛躍；3G到4G則是從移動窄帶到寬頻的飛躍。關於5G的技術重點近年來眾說紛紜，各個國家地區的研究重點也因可用的5G頻譜上的不同而因地制宜。

早在3GPP 5G NR開始之前，Verizon Wireless早已迫不及待地搞了一個5G technical forum （5GTF）,基於LTE標準的框架定了一套針對毫米波的pre-5G商業試用spec。

毫米波是5G的一個發展方向，具有高頻得天獨厚超高寬頻的優勢，如果能有效結合波束賦形（beamforming），那在覆蓋範圍內能支持非常高的速率。然而高頻毫米波真正要做到移動寬頻，挑戰也確實不小。高頻覆蓋範圍小，對介質的穿透能力極其有限，移動應用中毫米波從室外到室內的覆蓋問題始終是一個難點。

Verizon在3G，4G時代都是率先嘗試新技術，自然也希望在5G時代，繼續保持技術領先。

但這不是Verizon大張旗鼓投入毫米波作為其5G切入點的主要原因。Verizon選擇上毫米波的根本原因在於頻譜。放眼望去，美國的非毫米波頻段（sub-6GHz）幾乎沒有可用於5G移動寬頻的頻譜（好容易有個3.5GHz的可能頻段本，被Google
一番遊說後變成shared licensed spectrum了），FCC剛剛批准的5G頻譜全部在毫米波頻段。

還有一點很關鍵的是，Verizon面臨的不單是移動服務上來自傳統運營商（ATT,
T-mobile, Sprint）的競爭。更要面對潛在新興運營商在移動和固網上的雙重挑戰（比如Google之前一段炒得很熱的Google Fiber對Verizon的固網業務就是潛在的威脅）。由於這兩方面的原因，Verizon投入固網和移動都能支持的毫米波技術就勢在必然了。

其實Verizon想搶跑5G純粹出於自身商業利益考慮，但有好事者就把Verizon的5GTF描繪成了美國想繞開3GPP在5G搶得了先機的陰謀。幾個月前，當5GTF剛剛完成定標，網路上「美國搶跑5G」之類的新聞也是鋪天蓋地。其實5GTF是否與地域政治有關，只需看看美國其它運營商的反應。同為美國運營商的ATT對Verizon的搶跑顯然非常不滿，急吼吼地催促3GPP加速完成5G NR的定標（ATT公開宣稱5G NR的第一版將在2017年底之前完成）。

這個5G的戰前小插曲本來與polar碼絲毫不沾邊。可我們後面將看到，這是如何被「國標定碼」的陰謀論所利用，催生了整個polar極化事件。

所謂三神器，即華為主推的三種5G基礎技術：

一．
filtered-OFDM

二．
SCMA (稀疏碼分多址，sparse-code-multiple-access)

三．
polar code

說起如今的移動通訊界，便不得不提到華為的大名。縱觀通訊行業，老牌公司（無論是設備或是終端廠商）大多在保盈利與求發展的薄刃上徘徊掙扎。國際上傳統通信設備供應商面臨華為為首的中國企業的巨大挑戰，兼并重組，整合不斷，能夠在這一產業生存的玩家逐步減少。手機終端產業則面臨風雲變幻的市場和慘烈的競爭。往往是你方唱罷我登場，幾個月前還風光無限，稍有不慎便會深陷危機。即便是業界巨擘也是如履薄冰，時刻面臨著發展停滯的潛在危險。

就是在通訊行業這樣的大環境下，華為卻能在基站和終端業務上花開並蒂，多年保持百分之幾十的增長，不得不令人嘆服。華為也非滿足於眼下發展的池中之物，有著包藏宇宙之機，吞吐天地之志的雄心，躊躇著要在5G時代有一番作為。單從技術層面看，華為有著世界上最大的4G LTE
TDD（時分雙工）市場，同時在基站與終端兩端均享有巨大的份額，這在當今的通訊行業極為難得（絕大多數通訊企業只有基站或者終端一方面的業務，要基站終端聯調必須與其他公司合作），這巨大的市場本身便是華為一個得天獨厚的的研發和創新平台。

筆者以為華為靠多年TDD的經驗和研發便足以在5G增強型移動寬頻上引領群雄，大展一番宏圖：大規模MIMO天線陣和channel reciprocity相輔相成，恰如九陽神功結合乾坤大挪移足以實現高速率和高覆蓋的移動寬頻體驗；憑藉在TDD各類相關業務上多年的累積（LTE大/小/微型小區的經驗），能在5G上賦予動態TDD和靈活雙工模式（flexible Duplex）新的生命，甚至徹底顛覆傳統FDD、TDD雙工模式，把上下行的調度做得更為靈活高效，甚至可能在5G上豪賭，挑戰全雙工的系統實現。

出乎意料的是，華為主推的所謂三神器與其TDD上的技術積累幾乎沒有任何關聯性可循。每與同事/同行談及三神器，都不覺莞爾。這三種技術實在是談不上革命性，甚至不具有演進性的意義，因為已經有太多類似的技術可以達到類似或者更好的性能。更棘手的是，三神器的性能增益大部分仍停留在紙上談兵的學術研究階段。舉幾個簡單的例子：

fOFDM，在實際功放模型下（practical PA model），其性能與傳統的「加窗」技術相比並無明顯優勢，卻大大增加了發送和接收機的複雜度。

SCMA，由於其稀疏的限制，在物聯網應用上鏈路預算大打折扣。（題外話：即便是從資訊理論角度而言，在信道編碼之外再多加一層多維短碼實有房上加樓之嫌。在理論上毫無必要）。

Polar碼，現行的逐次消去列表解碼法（successive cancellation list decoding）並不非常適合硬體並行實現。高效率低延時解碼設計，IR-HARQ設計等諸多方面的成熟度相比LDPC，Turbo和TBCC仍相去甚遠。考慮上延時，實現複雜度等因素，Polar碼能否有任何可實現的性能優勢也是見仁見智。然而Polar碼所帶來的實現風險卻是無法迴避的問題。

三神器之於5G，著實讓人有「食之無味，棄之可惜」的感慨。令人費解的是，華為竟然會舉全公司的5G研發資源專註於如此三個初創公司的課題。抑或是我輩見識淺薄，管中窺豹，未見全璧？然則三神器到底是何等的無可替代，它們又能在5G開啟怎樣的新功能、新服務實在是讓人說不上來。有人甚至揣測，華為大肆宣傳「三神器」莫非是效仿當年韓信「明修棧道，暗渡陳倉」的戰略。一旦3GPP正式開始，圖窮匕見，華為便會拿出真正的5G方案藍圖，所謂的三神器不過掩人耳目罷了。

之後3GPP的會議歷程驗證了上述一半的猜測，但是後來事態的極化恐怕遠遠超出了所有人的意料。

要了解Polar碼極化事件的極化過程就有必要跟蹤整個「華為三神器」在3GPP的歷程。

5G NR自從2016年4月在釜山正式拉開帷幕，經過了釜山（2016年4月）和南京（2016年5月）兩次會議的討論與研究後，在8月的哥德堡RAN1
86會議上，對頻譜約束（spectral confinement）的波形技術做了總結。RAN1決定不在標準中指定spectrum confinement
technique，發送端波形技術做到對接收機透明。具體的頻譜特性需求則移交RAN4繼續討論[1]：

Agreement:

?
From RAN1
perspective, spectral
confinement technique(s) (e.g. filtering,
windowing, etc.) for a waveform at the transmitter is transparent to the receiver

這標誌著三神器之一的fOFDM至此已結束了5G在3GPP RAN1的歷程。這樣的結果實際上並不意外，一方面正如前面章節所說的有太多的實現方法來達到不同的性能取捨，RAN1很難定標某一個具體的實現方案；另一方面，定標對接收機透明，可以留給實現更多的空間來不斷創新和演進波形技術。

此時信道編碼的情況怎樣呢？關於eMBB數據信道採用LDPC已經獲得了大多數公司的認可。從下面的提案中可以看出，非但是後來的所謂LDPC陣營的公司，該提案也獲得了大多數當紅中國手機OEM公司的支持。理由無他，支持高速率用LDPC是非它不可，大勢所趨。

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

Proposal:

?
LDPC should be selected for eMBB data channel to
provide performance and implementation advantages at high rate and large
blocklength

從下面的提案中就可以看出，此時看好polar的公司實在是寥寥無幾。即便把polar作為一個候選代碼，範圍擴展到所有5G的應用領域eMBB, URLLC, mMTC支持公司也只有幾個與華為合作多年的中國和歐洲運營商們：

R1-168040 WF on channel coding selection Huawei, HiSilicon, CMCC, CUCC, Deutsche
Telekom, Orange,
Telecom Italia, Vodafone, China Unicom, Spreadtrum

Not supported by Orange.

Proposal:

?
Polar code is a candidate channel coding technique for
NR for eMBB, URLLC, mMTC

可見在8月的哥德堡會議上，極化過程尚未發生。

「國標碼」是「國家制定標準編碼」的縮寫，而非漢字國家標準代碼GB碼（笑）。

在10月里斯本會議前，5G信道編碼不知不覺被披上一層了地域政治的外衣。一些媒體就把圍繞5G eMBB數據信道編碼在Turbo、LDPC和Polar之間的選擇描述成了法國、美國和中國的「三國演義」。信道編碼本是純技術的東西，不應有國界。一種信道編碼能否代表一個國家？可以從技術背景和3GPP主推公司兩方面來分析一下：

1） Turbo碼設計和解碼方法均由法國人Berrou發明並實現。Turbo碼對資訊理論和通信領域產生了深遠的影響，無可爭議的是法國人引以為豪的獨家發明。在3GPP 5G NR的討論中，，法國電信公司Orange主推Turbo碼。

2） LDPC最初由資訊理論大牛MIT教授Robert Gallager發明於60年代，由於計算機模擬能力的局限，Gallager本人並沒有意識到LDPC的強大威力，LDPC沉寂江湖三十餘載。在Turbo碼發明幾年之後，LDPC才被英國劍橋大學教授David MacKay於1996年左右重新發現，此後學術界和工業界百花齊放，LDPC的應用幾乎遍布除了移動通信的其他各個領域均（剛剛發射成功的嫦娥二號上也有LDPC的身影）。在3GPP支持LDPC的公司分散於五海三洲：三星，高通，諾基亞，夏普，索尼，英特爾，在10月里斯本會議之前甚至包括了大多數中國OEM和亞洲晶元製造商。

3） 最有意思的是polar碼，觀其成長發展歷史，polar碼由Robert
Gallager的學生土耳其教授Arikan於2008年左右發明，最初只具有理論價值。後polar碼的解碼演算法經由UCSD教授Vardy的突破性改進而開始具有實用價值。在3GPP研究polar碼的公司不少，但真正看好而全力推行polar碼的公司華為只此一家。由於其解碼延時，複雜度，以及技術成熟度不及Turbo/LDPC，其他公司（包括10月里斯本會議之前的大多數中國公司）都不甚看好polar。

仔細分析一下，碼與國之間無必然聯繫，把LDPC和polar之間的選擇描繪成中美之戰是惟恐天下不亂的說法。然而一旦有了如此聯繫，「國標」之「碼」的意義便遠遠超出編碼本身。更有甚者，把對編碼的甄選渲染成對手為「國標」爭霸而耍的陰謀。

說起這陰謀論又要回溯到之前提到的Verizon
pre-5G毫米波的標準，即所謂的「5GTF」。5GTF的定標，絕大部分標準以LTE為基礎，在特定細節上，做了一些針對毫米波和高速率的更改。其中數據信道編碼採用了LDPC碼（究其原因，也還是為了要支持高速率）。而陰謀論者的理解則不然，他們指3GPP會在信道編碼的選擇上傾向LDPC，從而讓3GPP NR標準與5GTF更靠近，好讓美國版的pre5G標準有先發優勢，是徹頭徹尾的美帝陰謀！

如此陰謀論在熟知技術內情的人看來簡直貽笑大方。一方面Verizon的5GTF為了保證能夠大幹快上，跳過了LDPC設計過程，直接拿了WiFi
802.11ac的LDPC碼。另一方面NR對峰值速率，解碼延時等要求與5GTF不可同日而語。其性能、靈活性、IR-HARQ的支持等方面都將遠遠超過WiFi LDPC。更況且讓3GPP直接用IEEE標準中採用的編碼，就好比讓Apple
iPhone裡面默認自帶Internet Explorer瀏覽器，可能性幾乎為零。

這看似荒誕的陰謀論，卻著實聳人聽聞，且涉及「國標」大事，不由得人不信。最終，在這個陰謀論的推波助瀾之下，polar碼事件在3GPP掀起了一股驚濤駭浪。

在10月里斯本RAN1 86b開始之前，9月的RAN
#73已經決定把大規模務聯網（mMTC）課題的優先順序降低，推遲到2017年3月再繼續研究。RAN1之前已經有決定，eMBB的多址方式應基於正交的多址方式，非正交方式多址先只限於mMTC的研究中。因此，10月里斯本會議成為5G 第一階段的最後一次會議討論多址。

這個結論也同樣並不出人意料，整個NR的多址討論各種非正交提案五花八門，但對eMBB一般場景下增益所得有限。只做一個大框架的結論，把其餘細節都留待明年三月Rel-15再繼續研究確是明智之舉。然而，這一決定同時意味著三神器之二的SCMA也被排除在了NR的第一階段標準之外（平心而論，即便明年三月mMTC多址再開展，SCMA在鏈路預算和PAPR上的硬傷也讓它很難在mMTC的多址方案中佔據一席之地。）

這樣一來，Polar 碼成了華為三神器中最後的一根稻草，如果polar碼不能進NR，華為所大肆宣傳的三神器在5G NR中將顆粒無收。

此時「碼」定「國標」陰謀論的蠱惑，將整個事件升級到了一個遠遠超越華為一家公司的層面。光從會議WF提案的支持公司來看，此時polar的極化已經在3GPP發生了（Polar的支持公司顯示出了相當的地域和業務相關性）。有興趣的可以對照之前8月哥德堡會議的提案。

R1-1610767 Way forward on eMBB data channel coding 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 Instrument, Motorola Mobility, Lenovo, Cohere
Technologies, Acorn Technologies, CableLabs, WILUS Inc, NextNav, ASUSTEK, ITL

Revision of R1-1610689

Also acceptable to Ericsson

Proposal:

?
Adopt LDPC code for eMBB data channel as single coding
scheme

R1-1610850 WF on channel codes 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

Revision of R1-1610668

Also acceptable to CATT

Proposal:

?
Polar code is
supported as a channel coding scheme for NR eMBB data channel

（註：
Way-forward (WF）是3GPP當前公司在技術討論完之後的提案）

至今回想10月里斯本會場的場景仍令人感慨不已。某公司的一位代表在周二還慷慨激昂地批評polar碼技術上不夠成熟，存在巨大的商用風險並與華為代表多番論戰。到了周三卻噤若寒蟬，無奈苦笑。到了最近一次雷諾（Reno）會議上同樣是這個公司甚至同簽了polar的提案。箇中原因，值得深味。而這樣的例子發生在不止一家公司一位代表的身上。

經歷了漫長的討論，最終在（數據信道）短碼上是用turbo，LDPC或是polar各大公司無法達成一致。作為一個妥協方案，10月里斯本會議同意了eMBB數據碼長碼採用LDPC這個大家都能接受的方案。Polar沒能在NR鎖定一席之地，華為再次空手而回。然而在陰謀論的推波助瀾之下，極化過程已經開始勢必難以逆轉了。

會前，就有消息說華為這次為了polar碼立了軍令狀，決意破釜沉舟，不成功便成仁。更有危言聳聽，說此次polar如果在5G NR再無一席之地，三神器徹底出局，則華為多年經營的運作模式也將隨之土崩瓦解。面對如此荒謬言論，大多數人也只能是一哂了之。現今華為如日中天，豈會因為一個小小的polar碼而有毫髮之損（若當真勢如類卵，華為在研發投入上也是該重新審視一番了。此又是題外話。）

這次會議上的極化達到了巔峰。有些公司未卜先知地知道了華為最新的polar設計（發布在本次會議的最新提案 [4]），做了穿越時空的引用不說，並且還做了非常細緻的模擬。與此相對應，另外一些公司卻發現該提案中新設計的描述都是含混不清，甚至似有自相矛盾之處。這公司研發人員之間的認知水平差別未免太大，抑或是有side
information導致了這種認知和實現速度上的巨大差別？這裡不想指名道姓哪些公司，信道編碼提案在R1-87 的文稿中 [5]（R1-1611107~R1-1613027）， 有興趣的讀者可以自行索引。

有人或許會辯解說，從8月的哥德堡會議到11月的雷諾會議，Polar碼技術上越變越好了，所以支持的公司越來越多？首先，華為研究polar已經4~5年，從8月哥德堡到11月雷諾短短3個月時間。如此短時間做出如此大規模的基於直覺經驗的編碼設計更改，何以保證能好過之前經過多年錘鍊的設計。其臨陣修改設計的結果，往往是按下葫蘆起了瓢（降低了BLER卻升高了false alarm rate （FAR））。更可怕的是，這些新的基於直覺經驗的編碼構造一無學術論文做理論支持，二無對此編碼構造優勢和隱患的透徹分析。如此多問題，現在無人能給予任何肯定的答覆，一概留給了具體實現公司和將來5G的性能測試；怕只怕到那時要回頭已經太難了。

在激烈的技術討論結束後，討論提案的時刻到了，華為終於在賭城亮出了底牌，Polar碼WF有超過50家公司的同簽 [3]。甚至包括了電子商務巨擘阿里巴巴。有代表戲言「阿里巴巴攜四十大盜夜襲3GPP」。可能更確切點來說，是華為攜手阿里巴巴和五十餘大盜在諸多基站、終端供應商和電信運營商反對的情況下，硬是把polar碼塞進了3GPP 5G NR的控制信道。

其實控制信道的討論在11月雷諾3GPP RAN1會議剛剛開始討論，這本是一個重要而值得多花一些時間討論的議題。本可以在下次2017年1月 NR Ad-hoc會議上做進一步的性能和複雜度的研究，尤其是針對下行控制性道（由於其對手機終端功耗的影響）。相比TBCC，Polar在控制信道上並沒有顯著的性能優勢卻在解碼延時和實現複雜度上有很大的風險。但為了能在11月雷諾會議上取得進展，妥協方案讓polar取代TBCC被選為上下行控制信道的編碼，以保證數據信道不會有polar碼（從而不至於浪費太多硬體資源在polar碼上）。

11月雷諾會議上華為主推的polar
WF [3]，有興趣的讀者可以自行再跟前面會議的提案相比較。這時候極化達到了最頂峰。對於11月雷諾會議的polar碼極化事件，幾個問題值得思考：

1） 諸如阿里巴巴這樣的公司，其業務跟信道編碼幾無任何干係，卻能夠在決議中起到關鍵作用。

2） 這些幾十個同簽公司在3GPP的活躍程度怎麼樣，在過去的幾年內又有多少篇獨立的關於信道編碼的提案？

3） 作為最終要做實現的晶元供應商，在最後階段考慮的問題已經是怎樣把polar碼的風險和損害降到最低。哪個信道上放polar碼風險最小。Polar若真是王師，既入NR已成定局，大家怎得不簞食壺漿以相迎，卻反而人人避之唯恐不及？

最終，基於polar碼控制信道的功耗和解碼延時是否能滿足5G的需求，我們還將拭目以待。

「華為獨霸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

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](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。

先來看最後的決定：

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」