张学勇移民公司
微信扫一扫 分享朋友圈

已有 108 人浏览分享

开启左侧

详细揭秘:两年前的“5G投票”,联想究竟做了什么?

[复制链接]
108 0

  来源:微信公众号三易生活

  一件已经在2016年就被盖棺定论的事情,近日随着几篇知乎上的文章,再度吸引了大量“吃瓜群众”的关注,诸如“5G标准上,联想为什么不给华为投票”一类的“惊悚”标题,也成为了外界关注的源头。

  但是我们在详细阅读了这些文章之后,却发现作者有大量使用专有技术名词的情况下,有着“带节奏”的嫌疑。

  而在这篇文章的准备阶段,我们三易生活也专门联系了高通、华为、联想三方。截至发稿前,高通和华为并未就此事件进行回应,联想方面相关人士则表示,“希望业界不要在这个狭隘的层面上评价创新技术”。

  首先,3GPP不是霸权组织,更没有阴谋论

  首先,和某些“阴谋论者”的看法不同,5G标准的制定组织3GPP,在华为无线网络标准专利部部长万蕾博士(她同时也是华为5G标准Polar码方案主要贡献者之一)看来,是一个公正、透明、团结和技术性极强的组织。

  万博士曾这样评价3GPP:“技术是没有国界的,3GPP之所以成功,就是归功于它的国际化,它的罗马论坛式的技术辩论是推动技术优化趋于完善的核心机制。衷心祝愿3GPP的全球化的民主精神源远流长……”



  作为这种“透明公开”的直接体现,3GPP每一次的会议都有详细的记录可供公开查询――当然,会议纪要是全英文的,而且动辄数万字之多。这确实给了一些人断章取义的机会,但作为一家合格的IT媒体,我们三易生活的编辑也是耐着性子仔仔细细地看完了2016年8月(第86次)、2016年10月(第86次b)和2016年11月(第87次)三次英文会议纪要……终于得以将整场事件以较为明晰的顺序,呈现在大家眼前。

  2016年8月第一次会议:三种标准被提出,技术争论很激烈

  关于5G移动宽带 信道编码的三大标准,争论的源头来自于2016年8月的3GPP第86次会议。在这次大会上,LDPC、Polar和Turbo三种编码方案被正式提出。



  从官方会议纪要中,我们可以看到此时三大阵营的支持方和后来流传的并不一样。为了让大家看得更清楚,我们稍微统计了一下:

  LDPC方案(第一次会议):高通牵头,支持者包括三星、诺基亚、中兴、联发科、英特尔、夏普、vivo、OPPO、小米,以及美日韩的主要电信运营商。

  Polar方案(第一次会议):华为牵头,支持者包括华为海思、中国移动、中国联通、展讯、以及少数欧洲和美国的电信运营商

  Turbo方案(第一次会议):LG牵头,支持者包括爱立信、NEC、法国橘子电信(这货在Turbo和Polar上两头下注)等少数代表

  值得一提的是,很多人以为3G、4G时代是高通独霸天下,其实不然――3G、4G时代采用的反而是5G时代“小众”的Turbo编码方案,当时的LDPC还处于完善期,而Polar更是还在理论阶段……

  在这场被很多媒体忽视了的第一次会议上,各方并没有进行表决。但却发生了非常热烈的技术讨论。

  有趣的是,从3GPP的会议记录来看,实际上高通、三星、华为、中兴、LG等也都并非固执于自己的“阵地”,而是同时参与了多个方案的技术评估和讨论。这背后的原因,除了3GPP本身浓厚的技术氛围外,其实也因为在5G时代,大家基本上都是在技术和专利上“多方下注”。

  比如高通既有LDPC的部分专利,也有Polar的部分专利,反之,华为主导Polar,也同样参与了LDAC的建设。“你中有我。我中有你”,并不像3G、4G时代那样存在着明确的专利墙或者独占情况。

  2016年10月第二次会议:投票开始,联想出场?

  在这次的会议上,上次提出的三种5G编码方案的技术争论仍然在持续,但是和第一次会议相比,第二次会议发生了大量的“变故”。


▲三个阵营相互“挑刺”的密密麻麻的记录……

  其一,是三种方案的支持者开始相互攻讦,从单纯炫耀自身技术的先进性,变成了指责其他方案的技术短板,在这个过程中,LDPC的确在技术层面上占据了上风。

  其二,是三种方案本身的支持者阵营发生了很大的改动,具体来说如下:

  LDPC方案(第二次会议):华为、高通、NTT、三星、爱立信、LG、NEC、索尼都为之站台

  Polar方案(第二次会议):只剩下了华为、华为海思

  Turbo方案(第二次会议):已经基本没有支持者了

  在各方唇枪舌剑一番之后,会议的议题就此发生了关键性的改变:从到底是要哪一种5G数据编码方案,变成了大家到底需要几种5G数据编码方案。而这一次,也正是在网上被传得神乎其神的“第一次投票”。

  这个时候,各方阵营再次发生了奇怪的分裂:



  1.只需要LDPC:爱立信、索尼、夏普、诺基亚、三星、英特尔、高通、联想、富士通、摩托罗拉移动,再加上几家日韩为主的电信运营商

  2.只需要Polar:华为

  3.需要LDPC,但也兼顾Turbo码:LG、IMT、NEC、富士通、法国橘子电信

  4.需要LDPC,但也兼顾Polar码:中兴、联发科、努比亚、小米、OPPO、展讯、再加上其他几家。

  由于“唯Polar派”只有华为一家,到了实际的投票阶段,华为主动弃权。此时阵营1和阵营4几乎旗鼓相当,最终的结果是两边暂时各让一步:初步决定在5G数据传输的“长码”部分使用LDPC,同时留下了一部分“短码”空间待定。至此,LDPC可说是小胜一场。

  在这次的投票中,联想是否有表态支持LDPC?显然是有的,但是从整个阵营分部来看,这种表态对于投票结果是否有决定性影响呢?应该说,没有。至于为什么笔者敢肯定没有,大家只要知道3GPP的投票并不是“一人一票”,而是有权重的概念,应该就能明白了。

  2016年11月第三次会议:尘埃落定,团结的胜利

  在上一次的会议中,已经决定了5G移动宽带的数据传输部分部分采用LDPC方案,从而留下了两件事待定,一是数据信道中,“剩下的部分”采用何种方案,另一点则是除了数据传输之外,用于网络控制的信道采用何种方案。

  由于LDPC在前一次的会议中,已经拿下了5G移动宽带数据信道的大部分份额,因此,在剩余的“短码”部分,竞争就变得异常激烈了。这一次,除了没什么存在感的Turbo码阵营之外,LDPC和Polar码阵营都拉上了大量“盟友”,概括如下:



  LDPC方案(第三次会议):三星、阿尔卡特朗讯、上海贝尔、爱立信、英特尔、三菱电子、摩托罗拉解决方案、NEC、诺基亚、KDDI、高通、夏普、SK电信、NTT Docomo、T-Mobile、Verizon……总共约33家

  Polar方案(第三次会议):华为、华为海思、宏?、ADI、贝尔移动、博通、中国移动、中国电信、中国联通、联想、Marvell、联发科、摩托罗拉移动、努比亚、OPPO、东芝、vivo、小米、中兴……总共59家

  可以看到,由华为主导的Polar方案这次明显是有备而来,而且联想也的确在这一轮投票给了华为没错。但是,由于Polar的支持者们所占的投票权重不够高,因此最终结果还是由LDPC码拿到了5G移动宽带数据信道的全部份额。

  这样一来,Polar码唯一的希望就只剩下5G移动宽带控制信道一途。在最终的这一次表述和投票中,中国企业(包括联想以及其他的全球盟友们)展现了真正的团结。对于这段历史,来自中国台湾省的数名参会代表有着生动的描述:





  其实,从技术上来讲,5G数据信道追求的是传输速率,主要都是大型封包,这一块LDPC的性能的确有明显优势(这也是为何第一次投票,LDPC极其顺利拿下数据信道长码部分的原因)。

  而对于5G控制信道来说,本身传输的数据量小,比起速度更注重可靠性,就恰好是Polar码的拿手部分了。

  最终,Polar码在本身有技术优势,加上中国厂商们的集体支持下,成功被确立为5G移动宽带控制信道的国际编码标准。

  这,就是近日又被炒作起来的,2016年3GPP三场会议的完整过程。

  关键问题来了,联想扮演了怎样的角色?

  用最简单的一句话概括的话,其实联想在整个三场会议中,基本上没起到什么作用。它并没有独自发表技术成果。也没有独自为某一个标准站台。

  而从三次投票的结果来看,联想参加了全部的三次投票,在第一次投票(究竟一种还是多种编码制式)的时候投给了LDPC,之后的两次投票(数据信道短码制式、控制信道制式)中则全部投给了Polar。

  总结一下就是:联想在大家都不看好Polar的时候,选了高通和华为当时都力挺的LDPC,而在中国企业团结起来支持Polar的时候,也跟着一起挺了一把华为。



  这个结果,其实就能看出和互联网上疯传的某些说法,其实是有着很大的差异的。

  就在今日早间,联想官方发表了正式回应,主要表明两点:

  ① 联想及旗下的摩托罗拉移动,在相关投票上所投的都是赞成票;

  ② 联想一直支持中国5G技术的发展,并全力推动5G技术和相关产品的研发。

  或许,比起单纯的diss联想或者旧事重提,这样的结论更加真实客观,无疑也更加有趣。

举报 使用道具

回复
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

9

关注

15

粉丝

42462

主题
精彩推荐
热门资讯
网友晒图
图文推荐

维权声明:本站有大量内容由网友产生,如果有内容涉及您的版权或隐私,请点击右下角举报,我们会立即回应和处理。
版权声明:本站也有大量原创,本站欢迎转发原创,但转发前请与本站取得书面合作协议。

Powered by Discuz! X3.4 Copyright © 2003-2020, WinnipegChinese.COM
GMT-5, 2024-11-18 09:46 , Processed in 0.026241 second(s), 31 queries .