為何一樁舊案，會引發如此大的關注？

原因之一，當然是5G標準的重要性。通道編碼是5G通訊標準中重要的組成部分之一，對於晶片複雜度，終端成本，功耗，以及專利費用都有很大影響。所以各個公司都對此給予了很大關注，這牽涉到5G商用後專利費的問題。而且，掌握5G標準的主導權，對於相關產業的發展也意義重大。

一、5G編碼方案簡介

在 3GPP 制定 5G 標準的過程中，有三種編碼方式被推出，分別為 Turbo code（渦輪碼）， LDPC code（低密度奇偶校驗碼）， Polar code （極化碼）。 三種碼的基本情況如下:

1. Turbo code: 3G和4G標準採用了 Turbo 碼。Turbo碼最初由法國人Claude Berrou發明，但3G標準裡最終採用的是以美國休斯公司(Hughes Network Systems)為主導的方案(此專利後來被LG收購)。4G沿用了3G的編碼方式。透過在3G、4G中的應用，Turbo code技術變得非常成熟。但面對5G的高效能，尤其是高速率的要求，Turbo code開始顯得力不從心。
2. LDPC：由MIT教授RobertGallager在1963年的博士論文中發明，其基礎專利早已失效。LDPC在上世紀90年代被MacKay重新發現，隨後學術界和工業界都進行了深入的 研究，其技術已經十分成熟，專利也比較分散。近二十年來被廣泛應用於深空探測， 衛星和地面數字電視、WiFi、以及 HDD、SSD儲存系統等，透過不同的設計最佳化可以滿足各種不同的需要。
3. Polar code：這是由學術界最近幾年升起的一顆新星，土耳其的Erdal Arikan教授於2008年發明，是近年來資訊理論學術界在編碼領域繼LDPC之後的最大突破。包括華為在內的各大公司對Polar碼也都有研究。最終華為在5G編碼上選擇了Polar方案。

澎湃新聞記者從聯想集團獲悉，聯想因為摩托羅拉移動（下稱摩托羅拉）對LDPC進行了大量的研究，產生和擁有40多個專利。 透過和谷歌公司的協議，聯想獲得了這些專利的保護，其中包括標準基礎專利(SEP)。但聯想（包括摩托羅拉）沒有任何Polar code專利。

二、5G編碼標準投票始末

1.在講投票之前，先來了解下3GPP的工作流程。

據瞭解，3GPP RAN1工作組負責無線接入網物理層設計，包括通道編碼。 RAN1有一位主席和兩到三位副主席。理論上主席應該公正公平，權衡各方利益，最終綜合各個公司的方案，使之達成共識，推進標準化程序的順利進行。會場討論由RAN1主席或者副主席（特殊情況下由主席指定一名參會代表）主持。

每次工作組開會，針對既定的議題，各個公司都會提交自己的技術方案，以文稿（contribution）的形式提交。由主席全權決定哪些文稿在會上宣讀。主席對會場討論的問題和方向有很強的引領作用。根據文稿和會場討論情況，一個公司可以聯合其他公司在會場上隨時提出提案（Way forward），並由代表們當場討論。根據會場的情況，主席可以提出對一個提案進行正向表決或者反向表決，也可以直接提出問題和幾個選項，要求在場的代表們當場進行表決。會場討論只能從技術的角度進行，各個公司經常需要對某一項提案進行表態，當場表示支援或反對。所有技術性的討論，無論是在一個提案上署名錶示贊同（可稱之為正向表態）， 還是對一個提案表示反對（可稱之為反向表態），都只是表示立場，都不是3GPP的正式投票，雖然現在外界把這個稱作“投票”。

2. 投票背景簡介

據瞭解，技術討論表決的結果，並不根據對其支援或者反對的公司的多少做出最後決定。3GPP的工作方式是以達到共識（consensus）為目的，甚至並不要求所有公司都對一個提案表態。一個提案得以透過，惟一的要求是沒有任何公司反對，而不在於有多少公司贊同。如果一個提案即使只由一個公司提出，而沒有任何公司反對，這個提案也將得以透過。相反，如果有一個公司反對一個提案，其他所有的公司都支援，按照3GPP的章程，這個提案也不會透過。

因此，各個公司為了使自己的方案透過，經常會在開會現場對自己的方案進行修改，與其他公司的方案融合，共同提出新的、符合更多公司利益的提案，以期得到更多的支援，而更重要的目的是減少對這一提案的反對。會場上對於一個提案感興趣的公司都會發表自己的看法。有些公司因其技術實力強大，技術方案更先進或者更全面，或者由於在3GPP的影響力，其觀點更有說服力，他們的意見會得到更多公司的尊重；而技術實力薄弱， 或者在這個領域根本沒有技術的公司，人微言輕，他們的意見也無足輕重。單純從一個提案得到的支援或者反對的數量（“支援票”或者“反對票”）來看，說明不了問題，也沒有什麼意義。而絕大多數公司，考慮到自己的形象和以後在3GPP裡面的其他工作，也不會在一個提案獲得了絕大多數公司的支援的時候，獨自堅定地進行反對，以免引起眾怒，讓日後的工作變得被動。

華為的polar碼主要貢獻者萬蕾博士曾經在2016年11月87次會後針對3GPP的流程也發過言。“參與其中，深刻理解這只是3GPP作為國際標準化組織為電信產業貢獻的又一個5G特性，這裡是業界眾多公司的共同貢獻。技術是沒有國界的，3GPP之所以成功，就是歸功於它的國際化，它的羅馬論壇式的技術辯論是推動技術最佳化趨於完善的核心機制。NR通道編碼機制LDPC+Polar的決策是5G標準的一個里程碑，進一步鞏固了3GPP全球5G統一標準的地位，夯實了產業運營商、網路廠商、晶片和終端廠商各方共同合作的決心。衷心祝願3GPP的全球化的民主精神源遠流長。”

RAN1工作組一年有6至9次（甚至更多）會議。每次會議為期五天（週一到週五）， 會議進行時由主席實時更新並全程公開主席記錄（chairman’s notes）。主席記錄為會議正式檔案，每天都上傳到會場的內部網上（同時也對外網公開）。會議結束後上傳本次會議的最終版本。

2016年RAN1主席是日本DOCOMO的Satoshi Nagata，但主持編碼方案討論的是Alcatel-Lucent的副主席Mathew Baker。此人是RAN1裡最資深的人士之一，曾擔任RAN1主席，在3GPP的經驗非常豐富，可謂老謀深算。

3.第86次會議投票。

在3GPP進行5G標準化的程序中，關於通道編碼方案最重要的決定，是在兩次會議上分階段作出的。

（1）先說2016年10月，在葡萄牙里斯本舉辦的86次會議。

5G系統包含了三種設計場景（eMBB、URLLC、mMTC），各自都需要資料通道和控制通道編碼。里斯本86次會議只對eMBB（增強型移動寬頻）場景下的資料通道編碼進行了充分的討論。在這次會上有三種資料通道的編碼方案備選，分別是LDPC方案，Polar code方案，和LDPC+Turbo code的組合方案。每個方案都有多個公司支援。會議開始，隨著技術方案的陳述和討論，大家都提出了自己的提議。

根據3GPP的記錄看，支援LDPC(R1-1610607)方案的陣容最為豪華。此提案由三星牽頭（並非網上傳說的高通），包括三星、高通、諾基亞、Intel 這樣的通訊技術強大的供應商，也包括SK、 KT、KDDI、 Verizon 等運營商。聯想、摩托羅拉移動、阿朗-上海貝爾也在LDPC隊伍裡，一共有29 家公司共同簽署了這個提案。

Polar 方案(R1-1610850) 由華為牽頭，以中國公司（包括中興、信威、普天、小米、OPPO、vivo、Coolpad、展訊等）為主體。其中在編碼方面技術積累較深的公司有華為、 中興、MediaTek。還包括了中國聯通、中國電信，以及中國臺灣的中華電信、德國電信等運營商。一共27家公司簽署了此提案。中國移動並沒有支援這個提案。

LDPC+Turbo(R1-1610604)組合方案，(資料通道編碼)採用LDPC和Turbo code的組合。此提案簽署的公司最少，由Ericsson、LG、NEC、Sony、Orange(法國電信)等7家公司聯名簽署，主要是日本和歐洲的企業。

上述這三個方案是最開始的原始方案。這是一次正向表決 ，即只記錄對各個方案支援的公司。由於各個公司彼此互不相讓，這次表決哪個提案也沒有出線。

聯想稱，第一輪投票之所以支援LDPC方案，是出於對LDPC方案技術能力和成熟度的認可，以及專利方面的考慮，“摩托羅拉對LDPC進行了大量的研究，產生和擁有40多個專利。 透過和谷歌公司的協議，聯想獲得了這些專利的保護，其中包括標準基礎專利(SEP) ”，“與Turbo和LDPC相比，Polar code顯得不夠成熟。在 5G 之前，還沒有被商業系統採納的先例。 ”

由於各個公司對三個提案意見各異相持不下，無法達成共識，第一次表決沒有產生任何決定（agreement）。

這時，由中興牽頭提出了一個LDPC+Polar 的混合方案(R1-1610607)， 以資料通道資料塊大小分為長碼塊和短碼塊，其中資料通道長碼塊用LDPC，資料通道短碼塊用Polar code。這是第一次提出長短碼概念，之前並沒有。自始至終，長碼短碼的概念僅限於資料通道，不適用於控制通道。

不過，中興這個提案沒有得到透過，但在主席的記錄上並沒有顯示出有哪些公司反對。

此時，會議主席主動詢問了各個公司的意向，是否願意接受在資料信道里同時使用多種編碼方式，是哪個編碼方案或者哪些方案的組合。這只是主席對各個公司態度的一種試探，可視為一次意向性表態，沒有正式的提案。

聯想在內部調查報告列出：“愛立信、索尼、夏普、諾基亞、阿朗上海貝爾、三星、 英特爾、高通、 Verizon、 KT、 IITH、 IITM、 Fujitsu、KDDI、華為、聯想、摩托羅拉移動都表示，資料通道只能使用一種編碼方式，其中只有華為一家支援Polar code，而其他各家公司都支援 LDPC。 ”

聯想稱，出於對兩種碼的顧慮（手機晶片成本提高、耗電量增加，面臨額外的專利費），聯想對LDPC作為唯一編碼方案進行了支援。

支援LDPC的企業沒有變，但這個時候最初支援Polar碼的公司發生了分化。包括華為終端在內的很多公司，都轉而支援LDPC+Polar的混合方案，只有華為仍在堅持用Polar code作為資料通道編碼的唯一方案。支援LDPC+Turbo混合方案的公司基本沒有變化，只是此時愛立信已經改為支援LDPC唯一。

到目前為止的兩次表態，並沒有對資料通道編碼做出最終決定。

此時，各家公司又分別進行了更多的技術陳述和討論。透過討論，LDPC的技術優勢，特別是在資料通道長碼上的優勢，得到了更多公司的肯定。

會議主席隨後又發起了第三次表決。華為看到Polar code作為資料通道的唯一編碼方案得不到其他公司的支援，提出針對大小兩種碼塊分別進行表決。在主席提出供表決的三個選項中，資料通道僅使用Polar code一種編碼的方案已經被排除在外。這是一次反向表決，即對幾個選項只記錄那些反對的公司。

反對“資料通道長碼用LDPC，資料通道短碼用Polar”的公司有：英特爾、高通、LG、Nokia、ASG、MotorolaMobility。

由於每個提案都有很多公司反對，三個提案都無法原封不動地透過。按照3GPP的工作原則，會場主席可以把三個提案裡的共同點（即無人反對的部分）作為最終決議決定下 來。由於在這次表決裡，所有公司對LDPC用於資料通道長碼均無異議，而對於資料通道短碼的三種意見仍然相持不下，所以長碼達成了決議 。會議同時也確認，針對其他場景（URLLC、mMTC）的編碼方式，和eMBB控制通道編碼方式，都留給後續會議解決。

87次會議

2016年11月份，3GPP在美國召開了RAN1#87會議（以下稱87次會議），主要討論的是5G資料通道短碼方案以及5G控制通道方案。

在這次會議上，聯想出於戰略上的考慮，改變了對Polar code的看法，給予了華為Polar code方案全面支援。對華為Polar碼用於資料通道短碼，和Polar 碼用於控制通道的方案，都投了贊成票。 華為兩次發起關於資料通道短碼的提案均有聯想簽署:

——eMBB資料通道使用兩種編碼方式。由於 86bis 會議已經決定將 LDPC 用於資料通道長碼，這個提議實際要求資料通道短碼使用 LDPC以外的 方式，即 Polar code。以華為為首的33家公司聯署了這個提案，包括聯想和 Motorola Mobility。 另有2家公司表示了支援(非聯署)。

——eMBB資料通道短碼使用Polar code。以華為為首的57家公司聯署了這個提案，包括聯想和MotorolaMobility。 不過，這兩個提案都遭到了很多公司的反對。在主席記錄裡面沒有顯示哪些公司對第一個提案表示了反對，對第二個提案表示反對的公司有 Ericsson、高通、Nokia、阿朗-上海貝爾、三星、 LG、 ETRI、KT、Verizon、英特爾、Docomo、IMT、KDDI、NEC共14家。這時這些公司主要的反對意見是，如果在資料通道上同時使用兩種不同的編碼方式，在晶片裡必須同時實現兩種譯碼器，而導致晶片成本增加，功耗增大。由於這些公司的強烈反對，Polar作為資料通道短碼已經沒有可能。

雖然Polar作為資料通道短碼已無可能，但根據3GPP規程，此時LDPC作為資料通道短碼並沒有自動得以透過。最終，LDPC拿下資料通道短碼，是LDPC支持者和Polar支持者妥協的結果。

而在5G控制通道編碼方案中，Polar方案優勢較為明顯。

最終，兩次會議的結果是，5G資料通道編碼採用 LDPC方案，5G控制通道編碼採用Polar方案。

作者：重劍無鋒
連結：https://www.zhihu.com/question/277709038/answer/395811876