最近聯(lián)想的煩心事可真是不少。昨天晚上知乎上一個題為《如何看待 5G 標準上聯(lián)想的投票？》的提問中，答主@范星.xfanplus的回答可謂是刷爆了網(wǎng)絡，但卻將聯(lián)想推向上“罪人”的十字架。

聯(lián)想被指5G標準投票戰(zhàn)隊高通

@范星.xfanplus 在回答中直指聯(lián)想在5G信道數(shù)據(jù)碼當中，聯(lián)想帶著收購的摩托羅拉站隊高通，沒有支持華為的方案，而是將兩票都投給了高通，導致最終華為以微弱的劣勢輸了。

這一下真是不得了，一時間眾多的自媒體紛紛轉(zhuǎn)起，全網(wǎng)閱讀量至少大幾百萬，昨晚某個頭條號只發(fā)了這個回答的截圖，幾個小時閱讀就上了53萬，評論近8000條，清一色都是罵聯(lián)想的。

來看下這辣眼睛的畫風：

而在這個知乎問題之下，除了@范星.xfanplus 的回答之外，還有眾多指責聯(lián)想5G標準投票沒有支持華為的回答。

另外在這篇帖子之前，近日，知乎、新浪微博等社交平臺上，就出現(xiàn)了多篇類似的貼子，比如《聯(lián)想為什么不給華為投票》、《聯(lián)想不支持Polar方案》、《為什么說聯(lián)想是“美帝良心”企業(yè)》等。

聯(lián)想回應：這完全是造謠

昨天（5月10日）晚間，北京商報記者向聯(lián)想集團求證。聯(lián)想回應稱，在該次投票表決中，其所投的是贊成票。相關(guān)材料也證實了聯(lián)想方面的說法。也就是說，網(wǎng)上流傳的關(guān)于聯(lián)想不支持Polar方案等議論，毫無事實依據(jù)。

針對這一事件，聯(lián)想集團對北京商報記者回應稱：一直以來，聯(lián)想都非常支持中國5G技術(shù)的發(fā)展，未來也會為推動5G技術(shù)和相關(guān)產(chǎn)品的研發(fā)而繼續(xù)努力。我們嚴厲譴責任何造謠行為，也吁請大家切勿相信謠言。對于惡意造謠者，我們保留相關(guān)法律權(quán)利，依法追究到底。”

與此同時，聯(lián)想已經(jīng)舉報了知乎平臺上近期出現(xiàn)多篇針對此事件的帖子，并發(fā)布了《關(guān)于聯(lián)想在3GPP投票事件中的說明》，聯(lián)想在該說明中表示，“聯(lián)想在3GPP舉行的5G標準portar短碼方案（此方案由華為等企業(yè)主導）投票中，是投贊成票的。其次，帖中關(guān)于聯(lián)想起初不支持portal方案的議論，沒有任何事實依據(jù)，是故意混淆視聽。”并要求知乎刪除全部涉事帖子，最大程度地降低對聯(lián)想的負面影響。

今天，聯(lián)想再次發(fā)布了《關(guān)于聯(lián)想在3GPP投票事件中的說明》，對此事進行了辟謠。聲明稱聯(lián)想及旗下的摩托羅拉移動在針對5G標準的Polar方案（中國移動、華為等中國企業(yè)主導）投票上，都投了贊成票。

事實究竟如何？

從聯(lián)想的回應和辟謠聲明來看，似乎是有人在故意造謠聯(lián)想！那么事實究竟如何呢？

在這之前我們先來了解下這次爭議的一些背景資料：

什么是中長碼、短碼、編碼信道、控制信道？

優(yōu)化的編碼致力于用最短的二進制位數(shù)表示一個指令，越短效率越高。在指令數(shù)量不變的情況下，越常用的指令當然越短越好，但是指令不等長將造成接收端沉重的處理負擔。然后用等長的編碼顯然會導致無效數(shù)據(jù)的大量傳輸，浪費帶寬。于是把指令編成兩個組（個別也有三個組的），常用的用相對短的二進制位數(shù)表示，不常用的用相對長的二進制位數(shù)表示。所以簡單理解，短碼代表常用的指令，長碼代表不常用的指令。

而在5G通信的標準中，包含有控制信道編碼標準和數(shù)據(jù)信道編碼標準。

眾所周知，信息通過網(wǎng)絡傳輸?shù)倪^程中由于會受到外界干擾可能產(chǎn)生錯誤。所謂的信道編碼，就是在發(fā)送端對原數(shù)據(jù)添加冗余信息，這些冗余信息是和原數(shù)據(jù)相關(guān)的，再在接收端根據(jù)這種相關(guān)性來檢測和糾正傳輸過程產(chǎn)生的差錯。控制信道和數(shù)據(jù)信道則是邏輯信道的兩個組成部分。

其中，控制信道主要是用于傳送信令或同步數(shù)據(jù)的信息通道，主要用于傳輸指令操作下級網(wǎng)絡設備。而數(shù)據(jù)信道則不言而喻，是用于傳輸具體內(nèi)容的。兩種信道編碼中，編碼也分為短碼和長碼，因為各個指令的使用頻率不一樣，所以把經(jīng)常使用的指令用比較短的編碼實現(xiàn)，使用頻率很低的用長編碼實現(xiàn)，這樣可以提高傳輸效率。

而參與控制信道編碼標準和數(shù)據(jù)信道編碼標準競爭的候選信道編碼主要是Turbo碼、LDPC碼以及Polar碼。

Turbo碼、LDPC碼和Polar碼

Turbo碼是1993年由C. Berrou與A. Glavieux發(fā)明的一種數(shù)字解碼方案。Turbo碼的2個核心標志是卷積碼和迭代譯碼，這種編碼的思想引領(lǐng)了一個新的時代，Turbo碼的出現(xiàn)可以作為古典編碼理論與現(xiàn)代編碼理論的分水嶺。由于其出色的解碼性能，3G與4G均采用了turbo碼的信道編碼方案。

LDPPC碼由R. Gallager于1962年提出，是分組碼的一種。一般通用的分組碼譯碼算法是伴隨式譯碼，非常復雜，循環(huán)碼因此應運而生。而LDPC碼是想通過比特翻轉(zhuǎn)的譯碼算法來簡化分組碼的譯碼。LDPC碼的應用非常廣泛，并且可以進行并行化譯碼，非常適合高速率處理的場景。

Polar碼可以說是編碼理論的新貴，于2010年由土耳其科學家Arikan發(fā)明。Polar碼主要是基于信道極化現(xiàn)象和串行譯碼方式提升信息比特的可靠性。雖然Polar碼的理論優(yōu)美，并且在3種譯碼方案中的性能最好，然而在實踐應用上還有待成熟。

其中，美國主推的是LDPC碼，代表企業(yè)有高通、NOKIA、Intel和三星；法國主推的是Turbo碼，代表企業(yè)有Orange和愛立信；中國主推的是Polar碼，代表企業(yè)有華為等。

在3GPP制定的5G通信標準當中，分為3大場景：eMBB：3D/超高清視頻等大流量移動寬帶業(yè)務；mMTC：大規(guī)模物聯(lián)網(wǎng)業(yè)務；URLLC：需要低時延、高可靠連接的業(yè)務，如無人車等。目前，商用價值最高的場景是eMBB。

3GPP對于eMBB場景下的數(shù)據(jù)信道和控制信道的編碼標準分別開了兩次會議來投票決定，分別是：2016年10月14日的葡萄牙里斯本3GPP RAN1#86會議和2016年11月17日美國里諾3GPP RAN1#87會議。

葡萄牙里斯本3GPP RAN1#86會議

2016年10月14日，在葡萄牙里斯本，阿爾蒂斯大酒店，3GPP RAN1#86會議將投票決定采用何種編碼作為eMBB業(yè)務數(shù)據(jù)信息的長碼塊編碼方案。

美國以高通領(lǐng)隊，法國派出了最強團隊（94年 Turbo 元老級 Claude Berrou 團隊），中國則以華為為首。這是一場美、歐、中三方的通信標準之爭。

LDPC碼陣營認為，Turbo碼譯碼時延大，不適用于5G高速率、低時延應用場景。Turbo碼陣營反駁，Turbo碼已使用于3G、4G，在應用中不斷改進的Turbo碼是能夠滿足5G極端場景的。Polar碼則似乎有些弱勢，當時也還沒有大規(guī)模應用采納。

根據(jù)3GPP官網(wǎng)的資料顯示，在3GPP RAN1#86會議上，支持LDPC碼方案作為5G eMBB場景下數(shù)據(jù)信道編碼（但不排除對編碼方案的組合的考慮）的企業(yè)名單包括：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。

可以看到，聯(lián)想和摩托羅拉移動正是在支持名單之中。

另外一份資料顯示，支持LDPC成為eMBB數(shù)據(jù)信道的單一編碼的企業(yè)包括：Ericsson，Sony，Sharp，Nokia，ASB，Samsung，Intel，Qualcomm，VzW，KT，IITH，IITM，F(xiàn)ujistu，Motorola Mobility，Lenovo，KDDI。

而支持Polar碼成為eMBB數(shù)據(jù)信道的單一編碼只有華為。

而以中興、華為終端、小米、展訊、聯(lián)發(fā)科等為代表的中國廠商，希望在5G eMBB場景下，數(shù)據(jù)信道采用長碼LDPC+短碼Polar的組合方案。

從3GPP官方下載的另外一份文檔也顯示，以中興、華為、中國移動、中國聯(lián)通、展訊、聯(lián)發(fā)科等為代表的中國廠商認為，數(shù)據(jù)信道應該支持兩種類型的信道編碼。大于X長度的長碼用LDPC碼，而小于X長度的短碼用Polar碼。

完整支持名單如下：

ZTE, ZTE Microelectronics, Acer, Bell, CATR, China Unicom, China Telecom, CHTTL, Coolpad, Deutsche Telekom, Etisalat, Huawei, HiSilicon, InterDigital, III, ITRI, MediaTek, Nubia Technology, Neul, OPPO, Potevio, Shanghai Tejet, Spreadtrum, TD Tech, Telus, Vivo, Xiaomi, Xinwei, IITH, IITM, CEWiT, Reliance Jio, Tejas Network

另外，以LG、NEC、Orange等為代表的廠商則支持長碼用Turbo碼，短碼用LDPC碼。

顯然，從上面的資料綜合來看，中國廠商整體更傾向于eMBB數(shù)據(jù)信道采用長碼LDPC+短碼Polar的組合方案。而華為同時兩邊下注，但想推動的Polar碼成為eMBB數(shù)據(jù)信道單一編碼的方案不太現(xiàn)實。

在經(jīng)過幾百份提案和無數(shù)次討論之后，最終3GPP經(jīng)過投票選定5G eMBB場景下數(shù)據(jù)信道編碼方案，大于X長度的長碼用LDPC碼，小于等于X長度的編碼下次再開會討論確定是用Polar還是LDPC還是Turbo；X值的確定也是下次討論；控制信道的編碼也是后續(xù)再討論。而5G UURLC、MMTC場景下的控制信道的信道編碼方案則確定是FFS。

從上面這張圖上可以看到，中興、華為等中國廠商都反對單獨采用LDPC碼方案，同時也沒有支持長碼LDPC+短碼Turo的方案，而是主推長碼LDPC+短碼Polar的方案。但是聯(lián)想和摩托羅拉卻沒有支持中興、華為等國產(chǎn)廠商支持的LDPC+短碼Polar的方案，而是支持了高通的單獨采用LDPC碼的方案。

如果從投票行為來看，聯(lián)想沒有支持中興、華為等中國廠商主推的LDPC+短碼Polar方案的行為確實會令很多國人不滿。

不過，如果單從結(jié)果來看，最終3GPP是確定了5G eMBB場景下數(shù)據(jù)信道編碼方案，大于X長度的長碼用LDPC碼，小于等于X長度的編碼并未確定。而中興、華為支持的方案當中，也選擇了LDPC碼作為長碼。所以，聯(lián)想和摩托羅拉移動的兩票似乎并未最終影響到這次會議的結(jié)果。

美國里諾3GPP RAN1#87會議

而對于隨后的2016年11月17日美國里諾3GPP RAN1#87會議對5G短碼方案討論的結(jié)果，想必大家都已經(jīng)比較清楚了。華為等中國公司主推的Polar Code（極化碼）方案，從美國主推LDPC碼，法國主推Turbo碼中脫穎而出，成為5G控制信道eMBB場景下的短碼方案。

而在這次會議的5G eMBB場景下上下行控制信道編碼方案投票環(huán)節(jié)當中，華為等中國公司主推的Polar碼方案受到了眾多廠商的支持，其中就包括有聯(lián)想以及旗下的摩托羅拉移動的投票支持。

雖然華為等主推Polar碼成為了5G eMBB場景下的控制信道編碼方案，但是需要指出的是，上次葡萄牙里斯本3GPP RAN1#86會議中懸而未決的eMBB場景下的數(shù)據(jù)信道短碼方案，在這次會議上也被確定為LDPC碼。LDPC碼成為了數(shù)據(jù)信道的上行和下行短碼方案。

有消息稱，華為主推的Polar碼之所以能夠順利拿下控制信道的上下行編碼，是基于利益交換的結(jié)果，華為也加入了LDPC的討論，所以這也使得高通主導的LDPC碼能夠成為數(shù)據(jù)信道上下行短碼方案。

雖然芯智訊并未查到具體的投票名單，但是3GPP的會議資料顯示，以下這些廠商都有支持LDPC成為數(shù)據(jù)信道上下行編碼方案：Verizon Wireless, AT&T, CGC, ETRI, Fujitsu, HTC, KDDI, KT,Mitsubishi Electric, NextNav, Nokia, Alcatel-Lucent Shanghai Bell, NTT, NTT DOCOMO, Samsung, Sierra Wireless, T-MobileUSA。

而Vodafone, CMCC, Ericsson, Deutsche Telekom, TELUS, Bell Mobility,China Unicom, China Telecom等廠商則支持Flexible LDPC（F-LDPC）作為數(shù)據(jù)信道上下行編碼方案，但是不排除其他編碼方案可以在以后的版本中添加。

可以看到，當中并未出現(xiàn)聯(lián)想及其旗下摩托羅拉移動的身影。

真相

前面介紹了這么多，我們總結(jié)一下，對于此次事件的事實情況就是：在葡萄牙里斯本3GPP RAN1#86會議上，聯(lián)想及旗下摩托羅拉移動確實沒有投票支持華為等中國廠商主推的eMBB場景下數(shù)據(jù)信道采用長碼LDPC+短碼Palar的方案。但是，聯(lián)想的投票也并未影響到最終的結(jié)果。而在3GPP RAN1#87會議上，聯(lián)想及旗下摩托羅拉移動確實投票支持了華為等中國廠商主推的eMBB場景下控制信道短碼Palar碼的方案，也并未支持LDPC碼成為數(shù)據(jù)信道上下行短碼方案。

所以對于網(wǎng)上的眾多指責聯(lián)想的帖子，也需要一分為二來看，很多指責聯(lián)想沒有投票支持華為等主推的Palar碼的帖子是完全搞混了兩次會議。而且聯(lián)想也確實投票支持了華為等主推的Palar碼。從這個角度來看，聯(lián)想的辟謠也沒問題。

但是實際上，聯(lián)想在葡萄牙里斯本3GPP RAN1#86會議上確實沒有支持華為等主推的eMBB場景下數(shù)據(jù)信道采用長碼LDPC+短碼Palar的方案，這一點聯(lián)想應該心知肚明。所以可以看到，聯(lián)想的聲明及回應當中，針對5G標準中華為等中國廠商主導的Polar方案的投票上，都投了贊成票，但是并未明確是那一次會議。

那么為何聯(lián)想在葡萄牙里斯本3GPP RAN1#86會議上沒有支持華為等助推的eMBB場景下數(shù)據(jù)信道采用長碼LDPC+短碼Palar的方案呢？

對此很多業(yè)內(nèi)人士分析認為，首先相對于Palar碼來說，LDPC碼更為成熟。LDPC碼于1962年就已經(jīng)提出，現(xiàn)在已經(jīng)發(fā)展的非常成熟。而Palar碼2010年才被提出，實際應用環(huán)節(jié)還不太成熟。其次，在高效率低延時解碼、IR-HARQ設計等諸多方面，Palar成熟度相比LDPC，Turbo和TBCC仍相去甚遠。考慮上延時，實現(xiàn)復雜度等因素，Polar碼優(yōu)勢并不明顯。在里斯本會議之前，甚至很多的中國公司都不甚看好Polar碼。另外需要指出的是，根據(jù)聯(lián)想最新的財報數(shù)據(jù)顯示，目前聯(lián)想70%的營收均來自海外。所以不論是從當時的技術(shù)角度還是市場角度來看，聯(lián)想的選擇或許是可以理解的。但是如果從民族情感上來看，聯(lián)想的行為則是令人失望。

不過，最后還是需要強調(diào)一下，聯(lián)想及旗下的摩托羅拉移動雖然沒有在葡萄牙里斯本3GPP RAN1#86會議上支持中興、華為等主推的eMBB場景下數(shù)據(jù)信道采用長碼LDPC+短碼Palar的方案，在那次的會議上并未導致“華為的方案輸了”，因為會上只確定了LDPC碼作為eMBB數(shù)據(jù)信道的長碼方案（符合中國廠商預期），根本就沒有確定eMBB數(shù)據(jù)信道究竟是采用哪個短碼方案。所以，聯(lián)想及摩托羅拉的那兩票并未造成實質(zhì)的不利結(jié)果。

雖然大家確實可以指責聯(lián)想在葡萄牙里斯本3GPP RAN1#86會議上沒有支持中興、華為等主推的長碼LDPC+短碼Palar的方案，但是也要看到美國里諾3GPP RAN1#87會議上其對于華為等主推的Palar碼方案的支持，事情還是要一分為二來理性看待。我們不能單純的為了罵而罵，更不要被那些無腦瞎噴的人牽著鼻子走。即使要罵，我們也應該罵在點子上，讓被罵之人心服口服！