聯想投票
這篇文章不是洗白文。個人對聯想討厭了，不會再擁護它的產品了。
最近聯想發表了一篇新聲明，個人以為：真是愚蠢！
-----------------------------
將幾篇文章放在一起，有編輯。
作者：波了個波 @波了個波
https://www.zhihu.com/question/275922735/answer/388545834
作者：卿仔菌 @卿仔菌
https://www.zhihu.com/question/275922735/answer/389096774
5G標準會議聯想投票事件的真相是怎樣的，是惡意公關戰還是確有其事？-惡意,聯想,真相,公關
按照高通給出的專利許可計劃，全球範圍內使用高通移動網路核心專利的5G手機都必須依照下列條款繳納專利費：單模5G手機：2.275％；多模5G手機(3G/4G/5G)：3.25％。而對於那些同時使用了高通移動網路標準核心專利、非核心專利的5G手機，收費標準為：單模5G手機：4％；多模5G手機(3G/4G/5G)：5％。什麼概念？一部手機賣1000塊，最少交給高通32.5元。2017中國國產智能手機銷售4.36億部。如果手機出貨量不變，就算全是千元機，銷售額也有4000多億，高通就算啥也不幹，至少能拿走130億。
前一次會議#86b時間為2016年10月，後一次#87時間為2016年11月。華為發表聲明稱聯想投贊成票，點明了是【2016年11月】的會議，與下面兩個圖並無矛盾之處。
名詞說明：
1、長碼：information block size of eMBB data> X（X值待定，128 <= X <=1024 bits）。
2、短碼：information block size of eMBB data <= X。
3、FFS：有待決定。
4、WF：Way-forward ，是3GPP在技術討論完之後的提案。
5、Turbo code (turbo碼，以歐洲公司為主)
6、LDPC code（低密度奇偶校驗碼，以高通為主)
7、Polar code (極化碼，以華為為主)
8、TBCC (咬尾卷集碼，以歐洲公司為主)
9、Possible Agreements（會議打算通過的決議）
10、 Agreements（會議通過的決議，一般不會改）
第一節
先說一下結論：Polar code被採用的是控制信道的編碼，既不是長碼也不是短碼，因為長短碼只屬於數據碼討論範疇。
數據和控制信道的區別和聯繫：
所謂數據信道（也就是有長短碼區別的）：傳輸的是用戶所要傳遞的數據，視頻瀏覽，微信簡訊，電話服務等等。
所謂控制信道（這個沒有長短碼之分）：傳輸的是有關數據信道的信息，譬如，數據在哪裡傳，數據塊的大小，等一些控制信息。
通常來說，數據信道編碼所需要的碼長範圍遠遠大於控制信道，且數據信道編碼需要支持高速率數據傳輸，相對控制信道而言有更高的硬體要求。下面總結了數據信道和控制信道比較常見的碼塊信息比特長度。
數據信道和控制信道碼塊信息比特長度的通常範圍：
數據信道 ：Info Bit K From 40 to 6,000~8,000
控制信道 ：Info Bit K 20~100 (一般場景)
控制信道 ：Info Bit K Up to 300 bits (極端場景)
上面列舉了常見的數據信道和控制信道所要支持的信道編碼碼塊長度。一個數據信道碼塊長度從40-bit到6,000～8,000-bit。一個數據信道的傳輸塊可以包含幾十甚至成百上千的碼塊，換而言之，數據信道的數據量可以比控制信道高几個數量級。而控制信道的碼長一般在100以內便可以覆蓋大部分應用場景（此處數據參照4G LTE，5G的控制信道設計尚未完成，具體範圍是否變化還待定）。這並不意味著控制信道編碼不如數據信道編碼重要（而只是說明兩種信道需要的碼長範圍不同），事實上恰恰相反，控制信道編碼解碼對5G整個的延時，功耗等都有著深遠的影響。
控制信道的碼長雖短，但卻並不隸屬於「長碼」和「短碼」中的任何一類。
其實3GPP標準中本無所謂長碼短碼的概念，報道中常見的長碼短碼來自於2016年10月里斯本（3GPP RAN1）會議關於「增強型移動寬頻（eMBB）的數據碼」的討論。
2016年10月里斯本RAN1的決議[2]摘錄見附錄1。四點決定非常清楚：
a. 數據信道長碼(informationblock size > X)用LDPC
b. 數據信道短碼(informationblock size ≤ X)用Turbo, LDPC或者是Polar 有待3GPP 2016年
11月份雷諾會議上再做決定
c. 長碼短碼載荷分界線 X 在128到1024 bit之間, X的具體值有待3GPP十一月雷諾會議決定。
d. 控制信道和URLLC（超可靠低時延通信）和mMTC（大規模物聯網）的編碼有待研究.
-------------------------------------------------------------
Agreement:
a. The channel coding scheme for eMBB datais LDPC, at least for informationblock
size > X
b. FFS until RAN1#87 one of Polar, LDPC, Turbo is supportedfor information block size
of eMBB data <= X
c. The value of X is FFS until RAN1#87, 128 <= X <=1024 bits, taking complexity into
account
d. The channel coding scheme(s) for URLLC, mMTC and control channels are FFS
-------------------------------------------------------------
由此可見，長碼短碼指的都是數據信道編碼（a和b）。
控制編碼的討論是另外的研究課題（包含在d裡面）。
也就是說Polar code最終被採用的是控制信道的編碼，既不是數據碼中的「長碼」也不是「短碼」。
而且控制信道編碼，主要的爭奪其實是在TBCC和Polar之間展開，具體的技術討論也只是在2016年11月雷諾會議上才展開。
第二節、Polar與LDPC之爭
對於大多數公司來說，LDPC用於長碼，幾乎是無可爭議，也是為了達到高吞吐率和硬體的高效率所必需的。絕大多數公司都認可即便短碼有其他選擇，長碼都必須要用LDPC。
爭議的地方在於短碼，也就是最終的數據信道編碼到底採用LDPC+LDPC、LDPC+Turbo還是LDPC+Polar？這也是這次聯想投票的主要焦點！
1、長短碼投票（2016年10月10日-14日 里斯本會議）：
-------------------------------------------------------------
Question: How many channel coding schemes should be specified for the NR eMBB data channel:
（1）單一編碼方案:
① LDPC（長碼和短碼都用LDPC，LDPC+LDPC）: Ericsson, Sony, Sharp, Nokia, ASB, Samsung, Intel, QC, VzW, KT, IITH, IITM, Fujitsu, MotM, Lenovo（聯想在這裡）, KDDI
② Polar（長碼和短碼都用Polar，Polar+Polar）: HW（HUAWEI）
（2）組合編碼方案:
①T+L（長碼用LDPC，短碼用Turbo，LDPC+Turbo） Accelercomm, IMT, LG, NEC, Fujitsu, Orange
②L+P （長碼用LDPC，短碼用Polar，LDPC+Polar）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（打算通過，也就是初步的決定，這裡Polar+Polar就出局了）:
Alt 1（LDPC+LDPC）:
- The channel coding scheme for eMBB data is LDPC（長短編碼都為LDPC）
No（反對票24個）: HW, IDC, HiSi, DT, NEC, CMCC, LG, Spreadtrum, Neul, CATR, Xinwei, TDTech, OPPO, Coolpad, Xiaomi, HW Devices, ITRI, Mediatek, Accelercom, Nubia, IMT, Orange, ZTE, ZTE Microelectronics
Alt 2（LDPC+Polar）:
- The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X（長碼方案為LDPC）
- Polar coding is supported for eMBB data for blocks smaller than X （短碼編碼為Polar）
No（反對票27個）: Sams, NEC, Intel, QC, LG, Nokia, ASB, MotM, Lenovo（聯想在這裡）, KT, Ericsson, CableLabs, ITL, Sequans, Acorn, Asustek, Mitsubishi, KDDI, Wilus, Accelercom, IMT, Orange, Sony, Sharp, Fujitsu, VzW, Docomo
Alt 3（LDPC+Turbo）:
- The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X（長碼編碼為LDPC）
- Turbo coding is supported for eMBB data for blocks smaller than X（短碼編碼為Tubor）
No（反對票33票）: HW, IDC, HiSi, Sams, Nok, ASB, KT, QC, Asustek, Spreadtrum, Mitusbishi, CATR, Xinwei, TDTech, OPPO, Intel, Coolpad, Neul, Wilus, Xiaomi, ITRI, Mediatek, Nubia, ZTE, ZTE Microelectronics, HW Devices, CableLabs, ITL, DT, VzW, KDDI, Acorn, Docomo
-----------------------------------------------------------
里斯本會議最終結果：
Agreement:（最終通過）
①、The channel coding scheme for eMBB data is LDPC, at least for information
block size > X（長碼編碼最終選用LDPC，這個無異議）
②、 FFS until RAN1#87 one of Polar, LDPC, Turbo is supported for information
block size of eMBB data <= X（短碼編碼待定，決定在2016年11月14日-18日的雷諾
會議上再從Polar，LDPC和Turbo中挑一個作為最終的短碼編碼）
③、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
-------------------------------------------------------------
這裡可以看到，聯想在選長短碼的時候確實選了高通的方案，而且明確反對了華為的方案。
這裡可以看到，聯想在選長短碼的時候確實選了高通的方案，而且明確反對了華為的方案。
這裡可以看到，聯想在選長短碼的時候確實選了高通的方案，而且明確反對了華為的方案。
2、短碼投票（2016年11月14日-18日 雷諾會議）
（1）R1-1613342（LDPC的主要提案），31個支持
R1-1613342 WF on channel coding for eMBB data Samsung, Acorn Technologies, Alcatel-Lucent Shanghai Bell, Ceragon Networks, Cohere Technologies, Ericsson, ETRI, European Space Agency, HCL Technologies limited, IAESI, Intel Corporation, ITL, KDDI, KT Corporation, Mitsubishi Electric, Motorola Solutions, NextNav, NEC, Nokia, Nomor Research, NTT Docomo, Prisma telecom testing, Qualcomm Incorporated, Reliance Jio, Sharp, SK Telecom, Sony, Straight Path Communications, T-Mobile USA, Verizon Wireless, WILUS Inc
Proposal:
? Adopt LDPC code as the single code for eMBB data channels
Proposal:
? Adopt LDPC code as the single code for eMBB data channels at least for blocks >=256 bits
Proposal:
? Adopt LDPC code as the single code for eMBB data channels
? It is not precluded to adopt Polar code as an additional code for small eMBB data blocks if the concerns on IR HARQ are resolved（不排除接受Polar作為替補短碼編碼，前提是IR HARQ的問題得到解決。）
Proposal:
? Adopt LDPC code as the single code for eMBB data channels
? Adopt Polar code for a physical layer control channels
-------------------------------------------------------------
（2）R1-1613307 （Polar的主要提案），58個支持
數據信道編碼提案（主要是Polar和TBCC競爭，並沒有看到LDPC）：
R1-1613307 （Polar的主要提案） WF on channel coding Huawei, HiSilicon, Acer, ADI, Aeroflex, Alibaba, Bell Mobility, Broadcom, CATR, CATT, Coolpad, Coherent Logix, CHTTL, CMCC, China Telecom, China Unicom, Dish Network, ETISALAT, Fiberhome, Hytera, IAESI, III, Infineon, InterDigital, ITRI, Irdeto, Lenovo（聯想在這裡）, Marvell, MediaTek, Motorola Mobility, National Taiwan University, Netas, Neul, Nubia Technology, OOREDOO, OPPO, Potevio, SGS Wireless, Skyworks, Sporton, Spreadtrum, SRTC, Starpoint, STMicroelectronics, TD-Tech, Telekom Research & Development Sdn. Bhd, Telus, Toshiba, Turk Telekom, Union Telephone, Vivo, Xiaomi, Xilinx, Xinwei, ZTE, ZTE Microelectronics
Bureau Veritas withdrew their support.
Proposal:
? Polar is supported as the channel coding scheme for DL and UL eMBB data with information block up to 1024 bits
Objections（反對票）: Ericsson, Qualcomm, Nokia, ASB, Samsung, LG, ETRI, KT, VzW, Intel, Docomo, IMT, KDDI, NEC
Proposal:
? Polar is supported as the channel coding scheme for DL and UL eMBB data with information block up to 255 bits
------------------------------------------------------------
（3）R1-1613211 （推動Polar控制編碼的提案，這也是聯想官網貼出來的那張圖的出處）
WF on Channel Coding Huawei, HiSilicon, Acer, ADI, Aeroflex, Alibaba, Bell Mobility, Broadcom, CATR, CATT, Coolpad, Coherent Logix, CHTTL, CMCC, China Telecom, China Unicom, Dish Network, ETISALAT, Fiberhome, Hytera, IAESI, III, Infineon, InterDigital, ITRI, Irdeto, Lenovo（聯想在這裡）, Marvell, MediaTek, Motorola Mobility, National Taiwan University, Netas, Neul, Nubia Technology, OOREDOO, OPPO, Potevio, SGS Wireless, Skyworks, Sporton, Spreadtrum, SRTC, Starpoint, STMicroelectronics, TD-Tech, Telekom Research & Development Sdn Bhd, Telus, Toshiba, Turk Telekom, Union Telephone, Vivo, Xiaomi, Xinwei, ZTE, ZTE Microelectronics
Bureau Veritas and CGC withdrew their support.
Proposal:
? Polar is supported as the channel coding scheme for DL and UL control channels for eMBB (except FFS for very small payloads)
---------------------------------------------------------------
（4）R1-1613577（推動TBCC的提案）
WF on coding technique for control channel for eMBB LGE, AT&T, Ericsson, NEC, Qualcomm
Proposal:
? For DCI, tail-biting convolutional code (TBCC) is adopted as a channel coding technique for NR
? For UCI with encoder input size [16]<=K<=100 bits, TBCC is adopted as a channel coding technique for NR
? FFS: enhancements to LTE TBCC including generator polynomials with larger constraint length, lower native code rate
--------------------------------------------------------------
（5）R1-1613248 （這個感覺像和稀泥的提案）
WF on NR channel coding 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-Mobile USA
Proposal:
? Adopt LDPC as the single channel code for uplink and downlink eMBB data channels for all relevant info block sizes（接受LDPC成為唯一的數據信道編碼，包括長碼和短碼）
? Adopt Polar as the channel code for the uplink control information（接受Polar作為上行信道控制編碼）
– FFS for very small block lengths where repetition/block coding may be preferred
Adopt TBCC as the channel code for the downlink control information（接受TBCC作為下行信道控制編碼）
--------------------------------------------------------------
（6）雷諾會議最終結果：
--------------------------------------------------------------
Agreement:
①UL eMBB data channels（上行數據信道編碼最終採用LDPC，包括長碼和短碼）:
a、 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)
b、 (Note that it is already agreed to adopt LDPC for large block sizes)
②、DL eMBB data channels（下行數據信道編碼最終採用LDPC，包括長碼和短碼）:
a、 Adopt flexible LDPC as the single channel coding scheme for all block sizes
③、UL control information for eMBB（上行信道控制編碼採用Polar）
a、 Adopt Polar Coding (except FFS for very small block lengths where repetition/block coding may be preferred)
④、DL control information for eMBB（下行信道控制編碼採用Polar）
a、 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
綜上，
（1）在#86b會議上，聯想在長短碼編碼上有過兩次投票，一次是長短碼編碼方案的選擇上投了高通LDPC+LDPC的贊成票；另外一次是在華為的LDPC+Polar上投了反對票，兩次投票對華為都不利。
（2）在#87會議上，聯想在信道控制編碼上倒是投了華為的Polar，但這個確實對Polar最終贏得信道控制編碼的結果影響不大。
下面貼出兩次會議記錄文件下載地址（主要看Report）：
1、里斯本會議（2016年10月）：
www.3gpp.org - /ftp/tsg_ran/WG1_RL1/TSGR1_86b/
2、雷諾會議（2016年11月）：
www.3gpp.org - /ftp/tsg_ran/WG1_RL1/TSGR1_87/
推薦閱讀：