明白的快来评评这个。


所有跟贴·加跟贴·新语丝读书论坛

送交者: 短江学者 于 2019-05-31, 08:40:11:

引用:
为极解密

  作者:见南山


  编者按
  “华为极化码事件”内幕:
  极化码获得的并非之前大肆炒作的“短码”。
  极化码打败的对手并不是LDPC,而是在控制信道上取代4G现有技术TBCC。
  若非极化码最终靠非技术手腕挤进控制信道,华为投资几十亿的5G“三神器”在5G NR第一阶段业已全部打水漂。

  整个5G信道编码又经历一番怎样波澜壮阔的争斗,这背后又隐藏着多少暗流汹涌的阴谋诡计。”为极解密“ 为您最全方位的解析。


  第一章 极之澄清

  第一章 第一节 5G到底哪一部分码会考虑使用极化码?

  第一章 第二节 极化码在长码上真的是几票惜败于LDPC么?

  第一章 第三节 5G NR 极化码到底打败了谁?


  第二章 极化之源

  第二章 第一节 前5G -- 毫米波


  第二章 第二节 “三神器”


  第三章 极化过程

  第三章 第一节 哥德堡会议(2016年8月)


  第三章 第二节 “国标码”

  第三章 第三节 里斯本会议(2016年10月)

  第三章 第四节 雷诺会议(2016年11月)


  第四章 登峰“造”极,“为”我独尊


  跋


  参考文献


  附录1

  附录2

  附录3


  序


  近期有关“华为的”极化码(polar code)碾压西方列强赢得5G信道编码的新闻铺天盖地。作为几次会议的观战者,仅作此文澄清一些事实,也兼谈一些对5G的个人看法,以期抛砖引玉。

  “为极”有两方面含义:

  字面意思即华“为”所推崇的“极”化码。

  同时也蕴含“所作所为以至极”的意思,隐喻此次事件对3GPP的影响。


  第一章 极之澄清

  第一章 第一节 5G到底哪一部分码会考虑使用极化码?


  有关polar code的报道可谓铺天盖地,各种名词概念看得人头晕目眩,到底polar码会被5G哪部分采用,看了诸多报道可能还是一头雾水。其实梳理一下,编码应用主要集中在以下两类信道:数据信道,控制信道。在3GPP的讨论过程中,数据信道又有了长码和短码的讨论。


  先说一下结论:
  Polar code被采用的是控制信道的编码,既不是长码也不是短码,因为长短码只属于数据码讨论范畴。

  我们首先解释一下数据和控制信道的区别和联系:

  所谓数据信道:传输的是用户所要传递的数据,视频浏览,微信短信,电话服务等等。

  所谓控制信道:传输的是有关数据信道的信息,譬如,数据在哪里传,数据块的大小,等一些控制信息。


  通常来说,数据信道编码所需要的码长范围远远大于控制信道,且数据信道编码需要支持高速率数据传输,相对控制信道而言有更高的硬件要求。下面表格1总结了数据信道和控制信道比较常见的码块信息比特长度。


  表格1:数据信道和控制信道码块信息比特长度的通常范围

  数据信道 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整个的延时,功耗等都有着深远的影响。Polar在延时功耗上能否符合要求还有待验证。

  控制信道的码长虽短,但却并不隶属于媒体近日一直热炒的“长码”和“短码”中的任何一类。因为被热炒的Turbo, LDPC和Polar 5G“短码”之争仅限于数据码范畴。

  其实3GPP标准中本无所谓长码短码的概念,时下报道中常见的长码短码来自于10月里斯本(3GPP RAN1)会议关于“增强型移动宽带(eMBB)的数据码”的讨论。10月里斯本RAN1的决议[2]摘录见附录1。四点决定非常清楚:


  a. 数据信道长码(information block size > X)用LDPC

  b. 数据信道短码(information block size ≤ X)用Turbo, LDPC or Polar 有待3GPP 十一月雷诺会议决定

  c. 长码短码载荷分界线 X 在128到1024 bit之间, X的具体值有待3GPP 十一月雷诺会议决定。

  d. 控制信道和URLLC(超可靠低时延通信)和mMTC(大规模物联网)的编码有待研究


  由此可见,最近一直被提及的长码短码指的都是数据信道编码(a和b)。控制编码的讨论是另外的研究课题(包含在d里面)。

  很多报道说polar被控制信道“短码”所采用,不知是对数据信道“长码短码”的讨论背景确实一无所知,亦或是有意无意地混淆了概念。

  在章节最后,重申一下结论:

  Polar code最终被采用的是控制信道的编码,既不是数据码中的“长码”也不是“短码”。


  第一章 第二节 极化码在长码上真的是几票惜败于LDPC么?


  有报道说在10月里斯本3GPP RAN1会议长码的决议中,polar code 以几票之差惜败于LDPC。是否有这回事呢,到底有多少家公司支持polar做eMBB的长码?

  察看一下10月里斯本会议的纪录[2],事实便很清晰(原始记录[2]可以在3GPP网站上下载,参考文献里提供了链接)。事实上在当时的讨论中,对于大多数公司来说,LDPC用于长码,几乎是无可争议,是为了达到高吞吐率和硬件的高效率所必需的。绝大多数公司都认可即便短码可能有其他选择,长码都必须要有LDPC。实际上,除了华为觉得polar code可以同时胜任长码和短码以外,其他没有任何一家公司表示长码不需要LDPC(其他所有支持turbo/polar的公司也都明确表示长码需要LDPC,即LDPC+Turbo或者LDPC+Polar)。然而在短码问题上,用LDPC, Polar还是Turbo几方争持不下。为了取得进展, 最终先采纳了大家都能够同意的LDPC作为eMBB长码,参见附录2中的详细分析。

  从结果来看,LDPC用于长码几乎是众望所归自然而然的结果。所谓polar的几票惜败LDPC于长码的说法,不知有何依据。

  第一章 第三节 5G NR 极化码到底打败了谁?


  首先列举一下5G主要的候选编码如下:

  1)Turbo code (turbo码)

  2)LDPC code(低密度奇偶校验码)

  3)Polar code (极化码)

  4)TBCC (咬尾卷集码)

  数据信道编码的竞争主要在Turbo/LDPC 和Polar三者之间展开。最终LDPC脱颖而出,成为数据信道编码(请参考前文)。

  而控制信道编码,主要的争夺其实是在TBCC和Polar之间展开,具体的技术讨论也只是在11月雷诺会议上才展开。控制信道编码本来不必在雷诺会议上决定,但作为数据控制信道编码一揽子妥协方案的一部分,最终决定以Polar code取代4G采用的TBCC。


  看看最终的决定和最后阶段的几个竞争方案便一目了然(详细分析参见附录3)。

  最终TBCC并未能成为下行控制信道的编码,但之前提到的“短码”属于数据码讨论范畴,跟控制码完全是风马牛不相及的两回事。说“polar在短码上击败了LDPC拿下控制信道”,至少有两处偷换了概念(a. 把控制信道编码混淆成之前所说的数据信道短码. b. 把polar击败的对手TBCC混淆成了LDPC)。再次简单总结一下最后的结果:

  1) 数据信道:长码,短码均采用了LDPC

  2) 控制信道:Polar击败的是TBCC而非LDPC


  第二章 极化之源


  “Polar事件” 极化过程并非一蹴而就,也非一个孤立的事件。把它的发展过程放到整个3GPP 5G发展的大背景下才能得见事件的全貌。要了解整个事件的来龙去脉,必须对之前5G的背景做一些简单的介绍。无线通信系统,从1G到2G是从模拟到数字的飞跃;2G到3G是从语音到数据的飞跃;3G到4G则是从移动窄带到宽带的飞跃。关于5G的技术重点近年来众说纷纭,各个国家地区的研究重点也因可用的5G频谱上的不同而因地制宜。

  第二章 第一节 前5G -- 毫米波


  早在3GPP 5G NR开始之前,Verizon Wireless早已迫不及待地搞了一个5G technical forum (5GTF),基于LTE标准的框架定了一套针对毫米波的pre-5G商业试用spec。

  毫米波是5G的一个发展方向,具有高频得天独厚超高宽带的优势,如果能有效结合波束赋形(beamforming),那在覆盖范围内能支持非常高的速率。然而高频毫米波真正要做到移动宽带,挑战也确实不小。高频覆盖范围小,对介质的穿透能力极其有限,移动应用中毫米波从室外到室内的覆盖问题始终是一个难点。

  Verizon在3G,4G时代都是率先尝试新技术,自然也希望在5G时代,继续保持技术领先。

  但这不是Verizon大张旗鼓投入毫米波作为其5G切入点的主要原因。Verizon选择上毫米波的根本原因在于频谱。放眼望去,美国的非毫米波频段(sub-6GHz)几乎没有可用于5G移动宽带的频谱(好容易有个3.5GHz的可能频段本,被Google 一番游说后变成shared licensed spectrum了),FCC刚刚批准的5G频谱全部在毫米波频段。

  还有一点很关键的是,Verizon面临的不单是移动服务上来自传统运营商(ATT, T-mobile, Sprint)的竞争。更要面对潜在新兴运营商在移动和固网上的双重挑战(比如Google之前一段炒得很热的Google Fiber对Verizon的固网业务就是潜在的威胁)。由于这两方面的原因,Verizon投入固网和移动都能支持的毫米波技术就势在必然了。

  其实Verizon想抢跑5G纯粹出于自身商业利益考虑,但有好事者就把Verizon的5GTF描绘成了美国想绕开3GPP在5G抢得了先机的阴谋。几个月前,当5GTF刚刚完成定标,网络上“美国抢跑5G”之类的新闻也是铺天盖地。其实5GTF是否与地域政治有关,只需看看美国其它运营商的反应。同为美国运营商的ATT对Verizon的抢跑显然非常不满,急吼吼地催促3GPP加速完成5G NR的定标(ATT公开宣称5G NR的第一版将在2017年底之前完成)。

  这个5G的战前小插曲本来与polar码丝毫不沾边。可我们后面将看到,这是如何被“国标定码”的阴谋论所利用,催生了整个polar极化事件。

  第二章 第二节 “三神器”


  所谓三神器,即华为主推的三种5G基础技术:

  一. filtered-OFDM

  二. SCMA (稀疏码分多址,sparse-code-multiple-access)

  三. polar code

  说起如今的移动通讯界,便不得不提到华为的大名。纵观通讯行业,老牌公司(无论是设备或是终端厂商)大多在保盈利与求发展的薄刃上徘徊挣扎。国际上传统通信设备供应商面临华为为首的中国企业的巨大挑战,兼并重组,整合不断,能够在这一产业生存的玩家逐步减少。手机终端产业则面临风云变幻的市场和惨烈的竞争。往往是你方唱罢我登场,几个月前还风光无限,稍有不慎便会深陷危机。即便是业界巨擘也是如履薄冰,时刻面临着发展停滞的潜在危险。

  就是在通讯行业这样的大环境下,华为却能在基站和终端业务上花开并蒂,多年保持百分之几十的增长,不得不令人叹服。华为也非满足于眼下发展的池中之物,有着包藏宇宙之机,吞吐天地之志的雄心,踌躇着要在5G时代有一番作为。单从技术层面看,华为有着世界上最大的4G LTE TDD(时分双工)市场,同时在基站与终端两端均享有巨大的份额,这在当今的通讯行业极为难得(绝大多数通讯企业只有基站或者终端一方面的业务,要基站终端联调必须与其他公司合作),这巨大的市场本身便是华为一个得天独厚的的研发和创新平台。


  笔者以为华为靠多年TDD的经验和研发便足以在5G增强型移动宽带上引领群雄,大展一番宏图:大规模MIMO天线阵和channel reciprocity相辅相成,恰如九阳神功结合乾坤大挪移足以实现高速率和高覆盖的移动宽带体验;凭借在TDD各类相关业务上多年的累积(LTE大/小/微型小区的经验),能在5G上赋予动态TDD和灵活双工模式(flexible Duplex)新的生命,甚至彻底颠覆传统FDD、TDD双工模式,把上下行的调度做得更为灵活高效,甚至可能在5G上豪赌,挑战全双工的系统实现。

  出乎意料的是,华为主推的所谓三神器与其TDD上的技术积累几乎没有任何关联性可循。每与同事/同行谈及三神器,都不觉莞尔。这三种技术实在是谈不上革命性,甚至不具有演进性的意义,因为已经有太多类似的技术可以达到类似或者更好的性能。更棘手的是,三神器的性能增益大部分仍停留在纸上谈兵的学术研究阶段。举几个简单的例子:


  fOFDM,在实际功放模型下(practical PA model),其性能与传统的“加窗”技术相比并无明显优势,却大大增加了发送和接收机的复杂度。

  SCMA,由于其稀疏的限制,在物联网应用上链路预算大打折扣。(题外话:即便是从信息论角度而言,在信道编码之外再多加一层多维短码实有房上加楼之嫌。在理论上毫无必要)。

  Polar码,现行的逐次消去列表解码法(successive cancellation list decoding)并不非常适合硬件并行实现。高效率低延时解码设计,IR-HARQ设计等诸多方面的成熟度相比LDPC,Turbo和TBCC仍相去甚远。考虑上延时,实现复杂度等因素,Polar码能否有任何可实现的性能优势也是见仁见智。然而Polar码所带来的实现风险却是无法回避的问题。


  三神器之于5G,着实让人有“食之无味,弃之可惜”的感慨。令人费解的是,华为竟然会举全公司的5G研发资源专注于如此三个初创公司的课题。抑或是我辈见识浅薄,管中窥豹,未见全璧?然则三神器到底是何等的无可替代,它们又能在5G开启怎样的新功能、新服务实在是让人说不上来。有人甚至揣测,华为大肆宣传“三神器”莫非是效仿当年韩信“明修栈道,暗渡陈仓”的战略。一旦3GPP正式开始,图穷匕见,华为便会拿出真正的5G方案蓝图,所谓的三神器不过掩人耳目罢了。

  之后3GPP的会议历程验证了上述一半的猜测,但是后来事态的极化恐怕远远超出了所有人的意料。
打赏


点赞

主帖获得的天涯分:0 举报 | 分享 | 楼主 楼主发言:5次 发图:0张 |
赏金最多 | 打赏最多按照全社区用户收到的赏金数排行
1

翻云手回忆录

549人打赏 赏金122.82万

严格执行获利计划,承载‘翻云大军’实盘!王者归来!!

2

见仁见智2019

55人打赏 赏金87.72万

半路被洗下车?200万再次干入金力永磁!!!

3

佩伭

250人打赏 赏金61.01万

异人启示录

相关阅读
关键词:华为 极化 事件 内幕
重磅内幕:华为MediaPad 10 FHD又在玩大事件?比飞马还牛么?(转载)[业内传闻]华为员工自曝内幕: 7亿元竞标C网不是自杀是谋杀[职场人生]华为招聘内幕,大家不要再上当!!!(转载)[通信]华为真是TMD的烂公司,有感于读《胡新宇后事处理内幕》[通信]华为的无耻 无耻的华为 —— 胡新宇后事处理内幕(转载)互联网新闻报道任正非:NSA监控事件对华为没有任何影响(转载)[风流人物]前IBM副总裁"内幕交易门"事件认罪[业内传闻榜]2XCN事件内幕非独家紧急跟踪(NEW HOT转载


楼主:cloudcj1Lv 2 时间:2016-12-11 12:24:44
  第三章 极化过程

  第三章 第一节 哥德堡会议(2016年8月)


  要了解Polar码极化事件的极化过程就有必要跟踪整个“华为三神器”在3GPP的历程。

  5G NR自从2016年4月在釜山正式拉开帷幕,经过了釜山(2016年4月)和南京(2016年5月)两次会议的讨论与研究后,在8月的哥德堡RAN1 86会议上,对频谱约束(spectral confinement)的波形技术做了总结。RAN1决定不在标准中指定spectrum confinement technique,发送端波形技术做到对接收机透明。具体的频谱特性需求则移交RAN4继续讨论[1]:


  Agreement:

  • From RAN1 perspective, spectral confinement technique(s) (e.g. filtering, windowing, etc.) for a waveform at the transmitter is transparent to the receiver

  这标志着三神器之一的fOFDM至此已结束了5G在3GPP RAN1的历程。这样的结果实际上并不意外,一方面正如前面章节所说的有太多的实现方法来达到不同的性能取舍,RAN1很难定标某一个具体的实现方案;另一方面,定标对接收机透明,可以留给实现更多的空间来不断创新和演进波形技术。

  此时信道编码的情况怎样呢?关于eMBB数据信道采用LDPC已经获得了大多数公司的认可。从下面的提案中可以看出,非但是后来的所谓LDPC阵营的公司,该提案也获得了大多数当红中国手机OEM公司的支持。理由无他,支持高速率用LDPC是非它不可,大势所趋。

  R1-167999 WF on Channel Coding Selection Qualcomm Incorporated, Samsung, Nokia, ASB, ZTE, MediaTek, Intel, Sharp, MTI, Interdigital, Verizon Wireless, KT Corporation, KDDI, IITH, CEWiT, Reliance-jio, Tejas Networks, Beijing Xinwei Telecom Technology, Vivo, Potevio, WILUS, Sony, Xiaomi

  Also supported by Oppo.

  Revision of R1-166376

  Proposal:

  • LDPC should be selected for eMBB data channel to provide performance and implementation advantages at high rate and large blocklength

  从下面的提案中就可以看出,此时看好polar的公司实在是寥寥无几。即便把polar作为一个候选代码,范围扩展到所有5G的应用领域eMBB, URLLC, mMTC支持公司也只有几个与华为合作多年的中国和欧洲运营商们:

  R1-168040 WF on channel coding selection Huawei, HiSilicon, CMCC, CUCC, Deutsche Telekom, Orange, Telecom Italia, Vodafone, China Unicom, Spreadtrum

  Not supported by Orange.

  Proposal:

  • Polar code is a candidate channel coding technique for NR for eMBB, URLLC, mMTC

  可见在8月的哥德堡会议上,极化过程尚未发生。

  第三章 第二节 “国标码”


  “国标码”是“国家制定标准编码”的缩写,而非汉字国家标准代码GB码(笑)。

  在10月里斯本会议前,5G信道编码不知不觉被披上一层了地域政治的外衣。一些媒体就把围绕5G eMBB数据信道编码在Turbo、LDPC和Polar之间的选择描述成了法国、美国和中国的“三国演义”。信道编码本是纯技术的东西,不应有国界。一种信道编码能否代表一个国家?可以从技术背景和3GPP主推公司两方面来分析一下:


  1) Turbo码设计和解码方法均由法国人Berrou发明并实现。Turbo码对信息论和通信领域产生了深远的影响,无可争议的是法国人引以为豪的独家发明。在3GPP 5G NR的讨论中,,法国电信公司Orange主推Turbo码。


  2) LDPC最初由信息论大牛MIT教授Robert Gallager发明于60年代,由于计算机仿真能力的局限,Gallager本人并没有意识到LDPC的强大威力,LDPC沉寂江湖三十余载。在Turbo码发明几年之后,LDPC才被英国剑桥大学教授David MacKay于1996年左右重新发现,此后学术界和工业界百花齐放,LDPC的应用几乎遍布除了移动通信的其他各个领域均(刚刚发射成功的嫦娥二号上也有LDPC的身影)。在3GPP支持LDPC的公司分散于五海三洲:三星,高通,诺基亚,夏普,索尼,英特尔,在10月里斯本会议之前甚至包括了大多数中国OEM和亚洲芯片制造商。


  3) 最有意思的是polar码,观其成长发展历史,polar码由Robert Gallager的学生土耳其教授Arikan于2008年左右发明,最初只具有理论价值。后polar码的译码算法经由UCSD教授Vardy的突破性改进而开始具有实用价值。在3GPP研究polar码的公司不少,但真正看好而全力推行polar码的公司华为只此一家。由于其解码延时,复杂度,以及技术成熟度不及Turbo/LDPC,其他公司(包括10月里斯本会议之前的大多数中国公司)都不甚看好polar。


  仔细分析一下,码与国之间无必然联系,把LDPC和polar之间的选择描绘成中美之战是惟恐天下不乱的说法。然而一旦有了如此联系,“国标”之“码”的意义便远远超出编码本身。更有甚者,把对编码的甄选渲染成对手为“国标”争霸而耍的阴谋。

  说起这阴谋论又要回溯到之前提到的Verizon pre-5G毫米波的标准,即所谓的“5GTF”。5GTF的定标,绝大部分标准以LTE为基础,在特定细节上,做了一些针对毫米波和高速率的更改。其中数据信道编码采用了LDPC码(究其原因,也还是为了要支持高速率)。而阴谋论者的理解则不然,他们指3GPP会在信道编码的选择上倾向LDPC,从而让3GPP NR标准与5GTF更靠近,好让美国版的pre5G标准有先发优势,是彻头彻尾的美帝阴谋!

  如此阴谋论在熟知技术内情的人看来简直贻笑大方。一方面Verizon的5GTF为了保证能够大干快上,跳过了LDPC设计过程,直接拿了WiFi 802.11ac的LDPC码。另一方面NR对峰值速率,解码延时等要求与5GTF不可同日而语。其性能、灵活性、IR-HARQ的支持等方面都将远远超过WiFi LDPC。更况且让3GPP直接用IEEE标准中采用的编码,就好比让Apple iPhone里面默认自带Internet Explorer浏览器,可能性几乎为零。

  这看似荒诞的阴谋论,却着实耸人听闻,且涉及“国标”大事,不由得人不信。最终,在这个阴谋论的推波助澜之下,polar码事件在3GPP掀起了一股惊涛骇浪。


举报 | 1楼 | 点赞 | 打赏 | 回复 | 评论
楼主:cloudcj1Lv 2 时间:2016-12-11 12:25:16
  作者:相逢何必曾相识
  链接:https://www.zhihu.com/question/52732376/answer/134887339
  来源:知乎
  著作权归作者所有,转载请联系作者获得授权。

  第三章 第三节 里斯本会议(2016年10月)


  在10月里斯本RAN1 86b开始之前,9月的RAN #73已经决定把大规模务联网(mMTC)课题的优先级降低,推迟到2017年3月再继续研究。RAN1之前已经有决定,eMBB的多址方式应基于正交的多址方式,非正交方式多址先只限于mMTC的研究中。因此,10月里斯本会议成为5G 第一阶段的最后一次会议讨论多址。

  这个结论也同样并不出人意料,整个NR的多址讨论各种非正交提案五花八门,但对eMBB一般场景下增益所得有限。只做一个大框架的结论,把其余细节都留待明年三月Rel-15再继续研究确是明智之举。然而,这一决定同时意味着三神器之二的SCMA也被排除在了NR的第一阶段标准之外(平心而论,即便明年三月mMTC多址再开展,SCMA在链路预算和PAPR上的硬伤也让它很难在mMTC的多址方案中占据一席之地。)


  这样一来,Polar 码成了华为三神器中最后的一根稻草,如果polar码不能进NR,华为所大肆宣传的三神器在5G NR中将颗粒无收。

  此时“码”定“国标”阴谋论的蛊惑,将整个事件升级到了一个远远超越华为一家公司的层面。光从会议WF提案的支持公司来看,此时polar的极化已经在3GPP发生了(Polar的支持公司显示出了相当的地域和业务相关性)。有兴趣的可以对照之前8月哥德堡会议的提案。

  R1-1610767 Way forward on eMBB data channel coding 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

  Revision of R1-1610689

  Also acceptable to Ericsson

  Proposal:

  • Adopt LDPC code for eMBB data channel as single coding scheme

  R1-1610850 WF on channel codes Huawei, HiSilicon, Acer, Bell, CATR, China Unicom, China Telecom, CHTTL, Coolpad, Deutsche Telekom, Etisalat, InterDigital, III, ITRI, MediaTek, Nubia Technology, Nuel, OPPO, Potevio, Spreadtrum, TD Tech, Telus, Vivo, Xiaomi, Xinwei, ZTE, ZTE Microelectronics

  Revision of R1-1610668

  Also acceptable to CATT

  Proposal:

  • Polar code is supported as a channel coding scheme for NR eMBB data channel

  (注: Way-forward (WF)是3GPP当前公司在技术讨论完之后的提案)

  至今回想10月里斯本会场的场景仍令人感慨不已。某公司的一位代表在周二还慷慨激昂地批评polar码技术上不够成熟,存在巨大的商用风险并与华为代表多番论战。到了周三却噤若寒蝉,无奈苦笑。到了最近一次雷诺(Reno)会议上同样是这个公司甚至同签了polar的提案。个中原因,值得深味。而这样的例子发生在不止一家公司一位代表的身上。

  经历了漫长的讨论,最终在(数据信道)短码上是用turbo,LDPC或是polar各大公司无法达成一致。作为一个妥协方案,10月里斯本会议同意了eMBB数据码长码采用LDPC这个大家都能接受的方案。Polar没能在NR锁定一席之地,华为再次空手而回。然而在阴谋论的推波助澜之下,极化过程已经开始势必难以逆转了。

  第三章 第四节 雷诺会议(2016年11月)


  会前,就有消息说华为这次为了polar码立了军令状,决意破釜沉舟,不成功便成仁。更有危言耸听,说此次polar如果在5G NR再无一席之地,三神器彻底出局,则华为多年经营的运作模式也将随之土崩瓦解。面对如此荒谬言论,大多数人也只能是一哂了之。现今华为如日中天,岂会因为一个小小的polar码而有毫发之损(若当真势如类卵,华为在研发投入上也是该重新审视一番了。此又是题外话。)

  这次会议上的极化达到了巅峰。有些公司未卜先知地知道了华为最新的polar设计(发布在本次会议的最新提案 [4]),做了穿越时空的引用不说,并且还做了非常细致的仿真。与此相对应,另外一些公司却发现该提案中新设计的描述都是含混不清,甚至似有自相矛盾之处。这公司研发人员之间的认知水平差别未免太大,抑或是有side information导致了这种认知和实现速度上的巨大差别?这里不想指名道姓哪些公司,信道编码提案在R1-87 的文稿中 [5](R1-1611107~R1-1613027), 有兴趣的读者可以自行索引。

  有人或许会辩解说,从8月的哥德堡会议到11月的雷诺会议,Polar码技术上越变越好了,所以支持的公司越来越多?首先,华为研究polar已经4~5年,从8月哥德堡到11月雷诺短短3个月时间。如此短时间做出如此大规模的基于直觉经验的编码设计更改,何以保证能好过之前经过多年锤炼的设计。其临阵修改设计的结果,往往是按下葫芦起了瓢(降低了BLER却升高了false alarm rate (FAR))。更可怕的是,这些新的基于直觉经验的编码构造一无学术论文做理论支持,二无对此编码构造优势和隐患的透彻分析。如此多问题,现在无人能给予任何肯定的答复,一概留给了具体实现公司和将来5G的性能测试;怕只怕到那时要回头已经太难了。

  在激烈的技术讨论结束后,讨论提案的时刻到了,华为终于在赌城亮出了底牌,Polar码WF有超过50家公司的同签 [3]。甚至包括了电子商务巨擘阿里巴巴。有代表戏言“阿里巴巴携四十大盗夜袭3GPP”。可能更确切点来说,是华为携手阿里巴巴和五十余大盗在诸多基站、终端供应商和电信运营商反对的情况下,硬是把polar码塞进了3GPP 5G NR的控制信道。

  其实控制信道的讨论在11月雷诺3GPP RAN1会议刚刚开始讨论,这本是一个重要而值得多花一些时间讨论的议题。本可以在下次2017年1月 NR Ad-hoc会议上做进一步的性能和复杂度的研究,尤其是针对下行控制性道(由于其对手机终端功耗的影响)。相比TBCC,Polar在控制信道上并没有显著的性能优势却在解码延时和实现复杂度上有很大的风险。但为了能在11月雷诺会议上取得进展,妥协方案让polar取代TBCC被选为上下行控制信道的编码,以保证数据信道不会有polar码(从而不至于浪费太多硬件资源在polar码上)。

  11月雷诺会议上华为主推的polar WF [3],有兴趣的读者可以自行再跟前面会议的提案相比较。这时候极化达到了最顶峰。对于11月雷诺会议的polar码极化事件,几个问题值得思考:

  1) 诸如阿里巴巴这样的公司,其业务跟信道编码几无任何干系,却能够在决议中起到关键作用。

  2) 这些几十个同签公司在3GPP的活跃程度怎么样,在过去的几年内又有多少篇独立的关于信道编码的提案?

  3) 作为最终要做实现的芯片供应商,在最后阶段考虑的问题已经是怎样把polar码的风险和损害降到最低。哪个信道上放polar码风险最小。Polar若真是王师,既入NR已成定局,大家怎得不箪食壶浆以相迎,却反而人人避之唯恐不及?

  最终,基于polar码控制信道的功耗和解码延时是否能满足5G的需求,我们还将拭目以待。

举报 | 2楼 | 点赞 | 打赏 | 回复 | 评论
楼主:cloudcj1Lv 2 时间:2016-12-11 12:26:06
  作者:相逢何必曾相识
  链接:https://www.zhihu.com/question/52732376/answer/134887339
  来源:知乎
  著作权归作者所有,转载请联系作者获得授权。

  第四章 登峰“造”极,“为”我独尊


  “华为独霸5G”,“华为碾压高通”,“华为碾压爱立信”,“华为制定5G标准”,“5G标准中国制定”,RAN87刚刚结束,这样的标题在微信朋友圈内便铺天盖地而来。

  诚然华为在任教主的带领下,商业上已经接近“千秋万载,一统江湖”的状态。在5G的技术和标准制定方面,是否也已是天上地下,“为”我独尊的境界了呢?

  首先,从技术本身来看,polar码既非华为发明或者发现,突破性的解码方法亦非华为的创新。把polar等价成华为的技术甚至说成是中国制造实有混淆视听、指鹿为马之嫌。

  其次,从3GPP的决议来看,polar仅仅被同意用在eMBB的控制信道上。正如前文中所澄清过的几点:

  Polar最终获得的是eMBB的控制信道编码,既非之前媒体提到的“长码”亦非“短码”(长码短码均属于5G eMBB数据信道讨论范畴,最终都采用了LDPC)。

  Polar码作为长码从未得到3GPP大多数公司认可。

  Polar码在控制信道上取代的是TBCC而非LDPC。

  控制信道码长一般情况不超过100比特,支持的范围远小于数据信道编码码长。

  也就是说Polar code 本身都只是5G信道编码中的一小部分。枉称独霸5G未免过于大言无当。

  Polar码到底是否有可实现增益,到底有多大的风险,仁者见仁(一年半载之后,有产品上市便会见分晓)。但有一点可以非常肯定地说,换其他任何一家公司想要推类似polar code或者任何一个类似三神器进5G NR在今天的3GPP都是绝无可能的。没有明显优势于类似技术却在实现上存在较大风险的东西是非常难以获得多数公司真心支持达成共识的。

  Polar码极化事件于3GPP是史无前例的:华为在自己主推的三神器在3GPP全面受阻的情况下,孤注一掷倾尽整个公司甚至是举国之力在小小的polar上。在此事件中,华为到底碾压了谁?美国的高通或者瑞典的爱立信?诺基亚,阿朗,三星,Intel,LG,索尼,DoCoMo等等众多资深3GPP跨国企业,大多数需要承担5G硬件实现的公司都遭遇了碾压。

  3GPP的现行决议机制也在此事件中遭遇了前所未有的挑战。在会议进程中,我们看到有多少公司迫于压力,投鼠忌器而无法直抒己见;又有多少代表先抑后扬,却无可奈何。这一幕幕,或为各大公司代表亲眼目睹,或留在各个公司文稿和会议记录中,这些细节自会由后来的读者慢慢发掘以明真相。

  Polar码极化事件尘埃落定之后,有三个问题需要解答:

  1. 华为是会以“三神器危局”为鉴,重归大道引领群雄。亦或是食髓知味,继续剑走偏锋“为”我独尊,希冀在明年三月mMTC“多址”的讨论中上再次上演一幕SCMA版“皇帝的新衣”。

  2. “Huawei, no way until I get my way”,如果华为今后故伎重演,3GPP及其生态圈内的诸多公司又将如何应对?

  3. 如何应对在通信生态圈经历大规模整合之后,3GPP的决议机制所遭遇的空前挑战。当一家公司的强大足以威慑到足够数量的中小会员、而相关的决定未必对这些会员产生任何实质上的影响时,极化现象便极可能被促成。在这种情况下,传统意义上的决议机制还能否遵从尊重共识的初衷?

  Polar码极化事件的时间点也相当微妙。如果类似的极化事件今后在3GPP频频发生,必然催生更多3GPP之外的5G forum以规避此类风险。由此而造成的5G市场进一步碎片化可能是业界没有一个人希望看到的结果。


  跋


  笔者也曾是热血青年,在成长的道路上被一个又一个的爱国故事激励过,振奋过。然而亲历过这几十年一遇的polar码事件,特别是看到相关报道与所经历的事件本身的落差时,不禁想给大家分享一下不同的视角下整个事件的起承转合。不敢说绝对的客观公正,但从不同的视角来看同一个事件至少可以给读者更多元化的解读空间。

  中华民族大国崛起乃大势所趋,任何人都无法阻挡的历史潮流。中国现在有相当多的优秀民族企业(并非只靠一个大托拉斯级的公司支撑整个经济命脉的国家),在当今世界的各个领域,互联网,生物科技,航空航天,引领潮流,走在前端。媒体实在没有必要在一个有争议事件上如此炒作一个公司。在这个信息高度开放的年代,“历史”很难再是一个百般顺从,任人打扮的小姑娘。爱国“故事”固然让人热血沸腾,但中国的年轻一代的奋发不能光靠着味精勾兑的鸡汤或鸡血来提神。

  中华民族企业想能够屹立于世界舞台引领群雄,也应当着眼于大局,顺势而有为也。中华民族伟大复兴的重担不必要也不应该把宝押在几个虫篆之技上面。
举报 | 3楼 | 点赞 | 打赏 | 回复 | 评论
楼主:cloudcj1Lv 2 时间:2016-12-11 12:27:47
  作者:相逢何必曾相识
  链接:https://www.zhihu.com/question/52732376/answer/134887339
  来源:知乎
  著作权归作者所有,转载请联系作者获得授权。


  参考文献


  [1] RAN1 86 final minutes report:

  http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_86/Report/Final_Minutes_report_RAN1%2386_v100.zip...

  [2] RAN1 86b final minutes report:

  http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_86b/Report/Final_Minutes_report_RAN1%2386b_v100.zip...

  [3] RAN1 87 Chairman’s Notes and draft minutes report: http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN1/Inbox/Chairman%20Notes/Chairman's%20Notes%20RAN1_87_final.doc...

  http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_87/Report/Draft_Minutes_report_RAN1%2387_v010.zip...

  [4] R1-1611255, “HARQ scheme for polar codes”, Huawei, HiSilicon

  [5] RAN1 87 contribution list:

  http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_87/Docs/TDoc_List_Meeting_RAN1%2387.xlsm...

  附录1


  Agreement:

  - “The channel coding scheme for eMBB data is LDPC, at least for information block size > X

  - FFS until RAN1#87 one of Polar, LDPC, Turbo is supported for information block size of eMBB data <= X

  - 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


  以下摘录于[2](3GPP RAN1 86bis chairman’s notes: Section 8.1.3.1):

  “Question: How many channel coding schemes should be specified for the NR eMBB data channel:

  - 1:

  o LDPC: Ericsson, Sony, Sharp, Nokia, ASB, Samsung, Intel, QC, VzW, KT, IITH, IITM, Fujitsu, MotM, Lenovo, KDDI

  o Polar: HW

  - >1:

  o T+L Accelercomm, IMT, LG, NEC, Fujitsu, Orange

  o L+P 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:

  Alt 1:

  - The channel coding scheme for eMBB data is LDPC

  Alt 2:

  - The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X

  - Polar coding is supported for eMBB data for blocks smaller than X

  Alt 3:

  - The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X

  - Turbo coding is supported for eMBB data for blocks smaller than X


  Agreement:

  - The channel coding scheme for eMBB data is LDPC, at least for information block size > X

  - FFS until RAN1#87 one of Polar, LDPC, Turbo is supported for information block size of eMBB data <= X

  o 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”

  限于篇幅,这里没有列举对Alt 1~3反对的公司(大家可以参见[2]大致上是24家反对Alt 1, 27家反对Alt 2, 33家反对Alt 3)。但是要澄清的关键是,无论是哪种选择,一致的意见都是长码必须用LDPC。

  附录3


  先来看最后的决定:


  Agreement:

  - UL eMBB data channels:

  o 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)

  o (Note that it is already agreed to adopt LDPC for large block sizes)

  - DL eMBB data channels:

  o Adopt flexible LDPC as the single channel coding scheme for all block sizes

  - UL control information for eMBB

  o Adopt Polar Coding (except FFS for very small block lengths where repetition/block coding may be preferred)

  - DL control information for eMBB

  o 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


  两个working assumptions基本就是达成一致意见(除非发现现行方案有严重设计缺陷)。假设这些working assumptions 都最终被采纳,对eMBB来说,数据信道长码短码都采用了LDPC,而Polar code被控制信道所采用。但击败的对手并非LDPC,而是之前提到的TBCC。

  从最后阶段的几个竞争提案中(参见[3]中的提案R1-1613211, R1-1613577, R1-1613248),很明显地可以看出:

  1) 提到LDPC的都只是和数据信道有关

  2) polar在控制信道上的竞争对其实是咬尾卷集码 (TBCC) 而非 LDPC。

  为了避免过大篇幅的引用,这里仅附上其中一个提案:

  R1-1613248 WF on NR channel coding

  Proposal:

  &#8226; Adopt LDPC as the single channel code for uplink and downlink eMBB data channels for all relevant info block sizes

  &#8226; Adopt Polar as the channel code for the uplink control information

  – FFS for very small block lengths where repetition/block coding may be preferred

  &#8226; Adopt TBCC as the channel code for the downlink control information”





所有跟贴:


加跟贴

笔名: 密码: 注册笔名请按这里

标题:

内容: (BBCode使用说明