5G 為何採納華為力挺的 Polar 碼？一個通訊工程師的內心實話

Polar 碼被採納為 5G eMBB 場景的控制頻道編碼，這兩天連續被這條消息洗板，連吃瓜群眾都直呼好爽。

然而，隨著媒體報導的持續發酵，真相在口口相傳中變了形，不乏誇大不實之嫌，小編終於坐不住了，也想吐露點心裡話，希望盡可能站在客觀的角度，在這個浮躁的世界裡發出一點微不足道的聲音，一個通訊工程師的聲音。

事件經過我們再回溯一遍……

2016 年 11 月 14 日至 18 日期間，3GPP RAN1 #87 會議在美國 Reno 召開，本次會議其中一項內容是決定 5G 短碼塊的頻道編碼方案，其中，提出了 3 種短碼編碼方案：Turbo 碼、LDPC 碼和 Polar 碼。

關於這 3 種編碼方案之爭，這已經是 5G 標準的第二次較量。在 2016 年 10 月 14 日葡萄牙里斯本舉行的會議上，LDPC 碼戰勝了 Turbo 碼和 Polar 碼，被採納為 5G eMBB 場景的數據頻道的長碼塊編碼方案。

在這個背景下，這一次關於短碼塊編碼方案的爭論更為激烈。因為 LDPC 碼已經拿下一局，出於實施複雜性考慮，整個行動通訊系統採用單一的編碼方案更利於 5G 部署，比如，3G 和 4G 採用的是 Turbo 碼，估計會有更多人支持 LDPC 碼。

這樣一來，主要由美國企業主導的 LDPC 碼有可能一統 5G 天下，而華為等中國企業主導的 Polar 碼將前功盡棄。

由於拋棄 Turbo 碼的呼聲較大，在上次會議失利之後，可以說 Turbo 碼基本大勢已去，本次 5G 編碼之爭最終演變為 Polar 碼和 LDPC 碼之間的拳擊爭霸賽，一場中美拳擊爭霸賽。

最終，經過連續熬夜的激戰後，Polar 碼終於在 5G 核心標準上扳回一局，成為 5G eMBB 場景的控制頻道編碼方案。

自此，經過兩次激戰，在 5G eMBB 場景上，Polar 碼和 LDPC 碼二分天下，前者為信令頻道編碼方案，後者為數據頻道編碼方案。Polar 碼和 LDPC 碼一起歷史性的走進蜂窩行動通訊系統，而在 3G 和 4G 時代陪伴我們多年的 Turbo 碼再輸一局，留下了落魄而孤寂的背影。

這確實是一個令人振奮的消息，如果說用力挽狂瀾來形容，我覺得並不為過。

這對於主導 Polar 碼的華為和中國企業絕對利多，畢竟，多年在 Polar 碼上研發投入終於有了希望。

但是，我們看到有些媒體的報導，恕我直言，太過浮誇。

1 、不是「拿下 5G 時代」

在 5G eMBB 場景上，Polar 為信令頻道編碼方案，LDPC 碼為數據頻道編碼方案，最多叫平分秋色。同時，後面還有很多路要走。

我們在前文中提到的 eMBB 場景不過是 5G 應用的其中一個場景。3GPP 定義了 5G 三大場景：eMBB、mMTC 和 URLLC，eMBB 對應的是 3D / 超高清影像等大流量行動寬頻業務，mMTC 對應的是大規模物聯網業務，而 URLLC 對應的是如無人駕駛、工業自動化等需要低時延高可靠連接的業務。

本次採納的編碼方案是針對其中 eMBB 場景，後續還將決定 URLLC 場景下的頻道編碼方案，最後再決定 mMTC 場景（估計在 2017 年第一季）。儘管此次採納 Polar 碼為後續標準話語權打下了堅實的基礎，但革命還未成功，同志仍需努力。

2 、Polar 碼不是華為的，LDPC 也不是高通的

這要從頻道編碼的歷史說起。

Turbo 碼是由法國科學家 C.Berrou 和 A.Glavieux 發明。從 1993 年開始，通訊領域開始對其研究。隨後，Turbo 碼被 3G 和 4G 標準採納。

LDPC 碼是由 MIT 的教授 Robert Gallager 在 1962 年提出，這是最早提出的逼近香農極限的頻道編碼，不過，受限於當時環境，難以克服計算複雜性，隨後被人遺忘。直到 1996 年才引起通訊領域的關注。後來，LDPC 碼被 Wi-Fi 標準採納。

Polar 碼是由土耳其比爾肯大學教授 E. Arikan 在 2007 年提出，2009 年開始引起通訊領域的關注。

簡而言之，頻道編碼是數學家們原創出理論，通訊就是跟著數學家們跑，在他們的理論基礎上不斷研究試驗，使之落地於實際應用。

為什麼有些公司力挺 Polar 碼，有些公司力挺 LDPC 碼？這就像下賭注，看中了某種編碼技術，就開始對其研究，一旦賭贏了，那麼我的研究成果就能快速落地應用，一旦輸了，只能從頭再來。比如，華為選擇了 Polar 碼，5G 也選擇了 Polar 碼，這就意味著華為在 5G 領域更具影響力。當然，在研究中，一定也累積了不少專利。

所以，儘管這次 Polar 碼贏了，但個人以為，媒體們不能因為太過興奮而忽略了數學家們的貢獻，更不能張冠李戴，有些東西是沒有國界的。

3 、為何 5G 採納了 Polar 碼？

這個小標題應該叫：5G 為何採納了 Polar 碼和 LDPC 碼？又為何放棄了 Trubo 碼？

先從什麼叫頻道編碼說起。當我們拿起手機滑臉書時，數據透過無線訊號在手機和基地台間傳送。由於受到無線干擾、弱覆蓋等原因影響，我們手機發送的數據和基地台接收到的數據有時會不一致，比如，我們手機發送 1 0 0 1 0，而基地台接收到的卻是 1 1 0 1 0，為了糾錯，行動通訊系統就引入了頻道編碼技術。

頻道編碼，簡單的講，就是我們在有 K 比特的數據塊中插入冗餘比特，形成一個更長的碼塊，這個碼塊的長度為 N 比特位，N>K，N-K 就是用於檢測和糾錯的冗餘比特，編碼率 R 就是 K/N。一個好的頻道編碼，是在一定的編碼率下，能無限接入頻道容量的理論極限。

在過去幾十年裡，出現了兩種接近容量極限的頻道編碼技術：LDPC 和 Turbo 碼，分別被 3G 和 4G 通訊標準和 Wi-Fi 標準採納。2007 年，土耳其教授 E. Arikan 提出了 Polar 碼，被稱為是迄今發現的唯一一類能夠達到香農限的編碼方法。

所以，這 3 種優秀的編碼技術均進入 5G 編碼標準的法眼，並引發了一場爭奪賽。

為何這場爭奪賽這麼激烈？都是 KPI 惹的禍。

5G NR（New Radio）的 KPI 裡，明確規定：峰值速率 20Gbps、用戶面時延 0.5ms（URLLC）。

這個 KPI 定得太高，在 4G 基礎上提升了 20 倍。報告長官，不好完成。

有多難呢？5G NR 的下行峰值速率要求是 20Gbps，由於手機（或基地台）接收到的每一 bit 都要經過頻道譯碼器，20Gbps 就相當於譯碼器每秒鐘要處理幾十億 bit 數據。

舉個例子，20 Gbps 就意味著譯碼吞吐量 T 為 20 Gbps，假設譯碼迭代次數 I 為 10 次，處理器的時鐘頻率 F 為 500 MHz，那麼，I *T /F = 10*20G/500M=400，也就是說需要 400 個處理器並行工作（註：譯碼器是頻道編碼最難實現的一環）。

這也是為何很多人選擇放棄 3G 和 4G 時代使用 Turbo 碼的原因之一，因為 4G 的最大速率不過 1Gbps，傳統 Turbo 碼透過迭代譯碼，本質上源於串行的內部結構，所以，有人認為 Turbo 遇上更高速率的 5G 時就遇到了瓶頸。比如 LDPC 譯碼器是基於並行的內部結構，這意味著譯碼的時候可以並行同時處理，不但能處理較大的數據量，還能減少處理時延。儘管可以採用外部並行的方式，但又帶來了時延問題。

對於時延，出於技術宅的本能，也請容許我再囉嗦一下。

5G NR 的 URLLC 應用場景要求用戶面時延為 0.5ms，這是 4G 10ms 的二十分之一。之所以要求這麼高的時延，是因為我們在體驗擴增實境、遠程控制和遊戲時，需要傳送到雲端處理，並即時傳回，這一來回的過程時延一定要夠低，低到用戶無法察覺。另外，機器對時延比人類更敏感，對時延要求更高，尤其是 5G 的車聯網、自動工廠和遠程機器人等應用。

空口 0.5ms 時延意味著物理層的時延不能超過 50μs，而物理層時延除了受譯碼影響，還受其他因素影響（比如同步），這就需要譯碼的處理時延一定要低於 50μs，越低越好。

總得來說，這就好比春節的航班，人流太多，要把幾億中國人從南到北、從東向西轉移一次，「數據量」太大，這就需要多開航班，並且加快航行速度。

「航班公司」5G NR 表示鴨梨山大，而頻道編碼表示壓力更大，層層傳遞嘛。

但是，這點壓力還不夠，5G 表示還能對抗。

剛才我們講了，3GPP 定義了 5G 三大場景：eMBB、mMTC 和 URLLC，這些場景對應 5G 的 AR、VR、車聯網、大規模物聯網、高清影像等等各種應用，較之 3 / 4G 只有語音和數據業務，5G 可繁忙多了。

這就對 5G 頻道編碼提出了更高要求，需支持更廣泛的碼塊長度和更多的編碼率。比如，短碼塊應用於物聯網，長碼塊應用於高清影像，低編碼率應用於基地台分布稀疏的農村站點，高編碼率應用於密集區域。如果大家都用同樣的編碼率，這就會造成數據比特浪費，進而浪費頻譜資源，這叫編碼的靈活性。

另外，5G 還得保障更高可靠性的通訊。LTE 對一般數據的空口誤塊率要求初始傳輸為 10%，經過幾次重傳後，誤塊率如果低於 1% 即可。但是，5G 要求誤塊率要降到十萬分之一。這就意味著，10 萬個碼塊中，只允許頻道譯碼器犯一次錯，最多只能有一個碼塊不能糾錯。

綜上，決定 5G 採用哪種編碼方式的因素就是：譯碼吞吐量、時延、糾錯能力、靈活性，還有實施複雜性、成熟度和後向相容性等。

比較一下 3 種編碼的譯碼吞吐量、時延、糾錯能力、靈活性和實施複雜性，誰更強呢？

小編查閱了最新的大量文獻，結果是：被搞得暈頭轉向，一臉懵逼。這個問題太複雜了，公說公有理、婆說婆有理。

比如，有人認為，Turbo 碼達到了瓶頸，無法處理 20Gbps 高速率，然而，有廠商證明，基於全並行設計的 Turbo 譯碼器的譯碼吞吐量能到 21.9 Gbps，處理時延可達 0.24μs，這也能滿足 5G NR 的 20Gbps 速率需求。

比如，如果用譯碼器在譯碼每一 bit 時執行的 Max、Min 和 Add 操作的總次數來衡量計算複雜度，有人認為 Polar 碼和 LDPC 碼在計算複雜度上優於 Turbo 碼。

比如，有人說 Turbo 不夠靈活，然而有人指出，LTE Turbo 碼的碼塊長度從 40 到 6,144，一共有 188 種，可以支持不同的業務，而採用多個並行處理器來同時完成碼塊譯碼的 Turbo 碼，能更靈活支持不同的碼塊長度。

……

小編試圖從技術的角度去找到 5G 選擇 Polar 碼或者 LDPC 碼的理由，然而，能力有限，把自己搞得灰頭土臉。

那麼，我們從成熟度和向後相容性方面看吧。

Turbo 碼被 3 / 4G 標準採用，LDPC 被 Wi-Fi 標準採用，而 Polar 碼出現較晚，在 5G 之前還沒有任何標準採用。從這方面講，Polar 碼的成熟度較低。

然而，華為表示不服，5G 編碼標準之爭前，海外通訊圈就有一篇文章瘋傳，華為表示，採用 Polar 碼完成了 5G 速率達到 27Gbps，表示滿足 5G 需求沒問題。

至於向後相容性。5G NR 是一種全新的無線技術，是更新換代，不是像 2G→2.5G 或 4G→4.5G 那樣，現網升級即可，這是要營運商買新基地台設備的，所以，其實不用考慮後向相容性。

不過，對於終端就是另外一回事了。現在的 4G 手機支持 2G 和 3G，同樣，以後 5G 手機也要支持 3G 和 4G。3G 和 4G 採用 Turbo 碼，如果 5G 也採用 LDPC 或 Polar 碼，這就意味著手機要採用兩套硬體設計，而譯碼器是整個基頻處理器的重要組成部分，佔據了近 72% 的基頻處理硬體資源和功耗，這可能會導致 5G 終端成本稍高一點，也可能會稍微拉長一點 5G 商用化的時間。

但是，有句老話叫磨刀不誤砍柴工。如果這一編碼方案夠優秀，極具潛力，那麼，5G 晚到一點又有什麼關係呢，無非是為了更好的體驗多花一點時間而已。

所以，關於 5G 為何採納 Polar 碼，我們的結論是：