【原创连载】URLLC小剧场

全兜是榨菜

    从事标准研究一年了，时间说长真不长，说短….嗯，其实蛮短的，正好这段时期是R16立项（6月中旬RAN#80全会）后，各个研究课题处于起步阶段（其实也是标准研究最重要的阶段吧），但因为R15的结题，我想借这个交接期回顾一下这一年一直在跟的URLLC与eMBB复用专题，回头再看一下之前看过的东西，说不定会萌发一些新的想法或者新发现。另外，我在标准研究中也遇到了不少问题，因此写下并分享这些东西，希望与大家进行技术交流并得到大家的指点。

    整个内容暂定为四个部分，第一部分追本溯源，看看URLLC到底是什么时候提出来并立项的（RAN全会）。第二部分研究开展，看看我关注的物理层（RAN1）是如何一步步设置课题并开始研究的。第三部分复用技术，分享一下我理解的URLLC与eMBB复用技术的细节。第四部分标准解读，计划将所有已经写进标准的URLLC协议进行解读。由于我对标准和技术的理解有限，或是对3GPP项目流程的了解不够，亦或是书写错误，在内容中如果发现有疑问或者错误的地方，希望大家可以提出来，一起讨论交流（开心脸），另外需要说明的是，我从2017年7月才开始研读提案并参加一些会，这之前的内容和结论是查看每一次会的chairman notes得出来的，如果存在问题，欢迎指正。   

全兜是榨菜

通信技术你问我答 (积分兑奖)

第一部分：追本溯源，看看URLLC到底是什么时候提出来并立项的

    2015年6月，在ITU-R WP5D第22次会议上确定了5G通信的愿景，其中就包括了URLLC业务场景。但是在同年的3GPP RAN全会上并没有URLLC相关的立项建议提出来。

    直到16年的1月，在Barcelona 3GPP RAN next generation access会上，有两个关于URLLC应用场景研究的提案提出，但是不幸被驳回了。接着在3月举办的RAN 71次全会上更是没有见到URLLC的踪影。（嗯，3GPP对URLLC好像没有一眼相中，慢性子来的）

    在16年6月，于韩国釜山举行的RAN 72次全会上，好像有了点起色，会上有提案提到Way forward on NR URLLC timeline，但这个并没有被讨论（not treated）；而在另一个邮件讨论的报告中，提到了TR.38.913在URLLC使用场景的KPI问题（Proposal 1: The combinations of KPIs for verticalsURLLC use cases in TR.38.913 are covered by the generic URLLC reliabilityrequirement proposed as outcome of email discussion），关于URLLC的也就是这些了，立项就先别想了吧。

    2016年9月，在新奥尔良举行的RAN 73次全会上，有提案提到以下的研究内容不会包括在Rel-15中，且这些研究内容将被推迟到2017年3月（这些内容中就包括了Reliability aspect for URLLC课题）。这里很多公司就此进行了反抗或是议论，CATT：“为什么要将URLLC排除在外”，Nokia：“URLLC没有明确的使用场景”，MTK：“URLLC的内容需要进一步确定”，Telecom Italia：“不要移出mMTC和URLLC的内容”。看得出，大家还是蛮关心URLLC成长的。此次会议华为有个提案RP-161695：“Discussion on RAN2 questions about 5G requirementson URLLC and LTE-NR interworking”，但是直接被withdraw了。然后是RP-161647：“TP for TR 38.913: Requirement for URLLC Reliability”，因为高通表示更加倾向于保持现有的需求不做TP更改，爱立信也表示支持高通，然后这个提案被驳回了。最后还有中兴的提案RP-161686：“Reliability requirement for use case in High speedscenario”其在URLLC基础上对NR提出了新的需求，这个文档被讨论了。在讨论提案RP-161763: “Acceleration of LTE “shortened TTI andprocessing time” work item”中，T-Mobile说“这个专题对将来NR的URLLC是非常重要的”（嗯，T-Mobile有见识，后来的URLLC传输方式就是用的mini-slot，跟sTTI类似，不过可能其他公司也是这么认为的，只不过没抢到话筒。）这次全会上关于URLLC的讨论也就是这样了。（老板，URLLC立项的事，您看….急什么，还早呢）

    2016年12月，维也纳RAN 74次全会，提案RP-162565：“Way forward on mMTC”中提到一句“NOMA for NR will be studied in Rel-15 time framefor eMBB, URLLC, and mMTC”，还有在“Critical communications/URLLC”专题下的RP-162205：“ New WIproposal: study on LTE enhancements for high reliability with low latency”，这个其实不属于NR-URLLC了，但这个提案还是被往后推了。（老板，年底了，URLLC立项的事，您看….）

    咦，等等，都到16年年底了，还没有立项？还没有开始研究？并不是！！要是跟着全会的脚步走，那就落后几个世纪了（夸张了一点，但是从URLLC这里我的感觉是这样）。我这里追溯全会的立项进度是为了看一下全会立项和RAN1开展研究是不是一定有对应的联系，从URLLC来看貌似并没有。这里我就有一些疑问，不应该是在全会立项后才在RAN1中设置研究课题（章节）吗？怎么RAN1自己就开始了呢？是否可以自己先立项研究，再去全会报一下也行？

    是的，RAN1开始URLLC的研究已经很久了，具体什么时候开始的如何进展的，且等第二部分（研究开展，看看我关注的物理层（RAN1）是如何设置课题并开展研究的）的更新。

檀香木小鬼

全兜是榨菜 发表于 2018-7-25 21:19
第一部分：追本溯源，看看URLLC到底是什么时候提出来并立项的

    2015年6月，在ITU-R WP5D第22次会议上 ...

写的很详细，感谢作者的分享。如果把会议中是哪些人或者公司提出来这个方案的讨论的就更好了

jethrowang13

牛掰，厉害，崇拜，加油！

jethrowang13

第一部分列出的信息足够全面了，只要我们按照楼主给出提案号，已经可以直接找到具体讨论内容了，节省了九成以上时间，感谢！

全兜是榨菜

檀香木小鬼 发表于 2018-7-25 21:58
写的很详细，感谢作者的分享。如果把会议中是哪些人或者公司提出来这个方案的讨论的就更好了

    16年1月在Barcelona举行的会上，提出提案的公司分别是CATT（大唐电信）和华为，提案号分别为：RPa160007（Discussions on deployment scenarios for mMTC and URLLC）和RPa160044（Discussion on M-MTC and URLLC deployment scenarios），RAN72次会上RP-161198 Way forward on NR URLLC timeline是CATR（中国信通院）提的;然后邮件讨论的报告是：RP-160982 Report of email discussion [RAN#71-09] Harmonization of verticals，这个是华为公司整理的。

全兜是榨菜

jethrowang13 发表于 2018-7-26 09:48
牛掰，厉害，崇拜，加油！

感谢

全兜是榨菜

jethrowang13 发表于 2018-7-26 09:49
第一部分列出的信息足够全面了，只要我们按照楼主给出提案号，已经可以直接找到具体讨论内容了，节省了九成 ...

我后面尽量把提案号标出来，便于大家查看讨论

全兜是榨菜

第二部分：研究开展，看看我关注的物理层（RAN1）是如何设置课题并开展研究的

    这部分依然不会讨论技术细节，如果对URLLC与eMBB复用技术感兴趣的朋友可以等待后续第三、四部分的内容更新，我会尽快整理发出来。第一部分讲到全会并没有对URLLC立项，但是RAN1很早就开展URLLC研究了，所以我想回看一下RAN1是如何对URLLC设置课题并开展研究的。

    追溯RAN1的URLLC研究历史，我一直往回翻到2015年11月的RAN1-83次会议（这个是碰碰运气，看看有没有公司早在这个时候就开始URLLC的提案了，答案是否定的）。时间往后，来到16年4月在韩国釜山举行的RAN1 84b上，见到了URLLC的身影，这次会议上在NR研究（chairman notes第8章）部分，8.1.1节“Overview of new radio（NR） interface”的概述中，提到了“高级别的设计方案，解决所有使用场景、需求和部署场景，例如，eMBB，MTC和URLLC。”这里，RAN1的设计就将URLLC作为一个必做的部分了。Fujitsu(R1-162332)提到“建立一个统一的上行传输框架对mMTC和URLLC是有益的”；联想(R1-162741)的意见是：“帧结构应该要足够灵活以支持eMBB/mMTC/URLLC”；MTK(R1-162791)：“对于ULLLC，专注于密集城市场景中或低于40GHz的室内场景的小小区优化设计”；CATA（R1-163129）：“eMBB, mMTC and URLLC在研究和标准化方面应该有着同样的优先级”等等。另外，此次会议上在候选编码上确定了URLLC可能采用的信道编码方案，包括卷积码，LDPC码，Polar码和turbo码（额，这有点草率了吧，能用的都写上的既视感，嗯，我相信是有道理的）。这次会议上有一些提案直接对URLLC进行了专题研究，如：R1-162926 Design considerations on URLLC for New Radio systems INTERDIGITAL COMMUNICATIONS，R1-162898 Channel coding for URLLC Nokia, Alcatel-Lucent Shanghai Bell，但是它们在会上都没有被讨论。

    这一次RAN1 84b会议是在16年的1月RAN-Barcelona 3GPP RAN next generation access会之后的第一次RAN1会议，虽然在RAN会上两个关于URLLC场景研究的提议被驳回了，但是在RAN1的NR研究中，URLLC是被作为一个必须考虑的场景在进行讨论。

    2016年5月，在南京举行的RAN1 85次会议上，URLLC依然不是重头戏，在NR研究章节中只有一些URLLC的KPI和评估方法的研究，当然这次形成了一些关于URLLC评估的结论：URLLC的容量定义为在（L，R）（其中，L是时延，R是可靠性）条件下的传输量，URLLC和eMBB复用的容量定义为URLLC（L和R约束条件下）容量和eMBB容量之和。另外未被讨论的提案中有8篇是直接讨论URLLC的，分别是R1-164002 Design aspects of URLLC for NR Samsung，R1-165028 URLLC U-plane latency analysis Nokia, Alcatel-Lucent Shanghai Bell；R1-165083 Consideration on URLLC in NR frame structure ZTE；R1-164378 Performance of channel coding schemes for mMTC and URLLC scenarios Huawei, HiSilicon；R1-165059 Performance Evaluation of Channel Coding for URLLC and mMTC INTERDIGITAL COMMUNICATIONS；R1-165358 Performance of mMTC and URLLC channel coding candidates Nokia, Alcatel-Lucent Shanghai Bell ；R1-165359  Latency considerations for URLLC channel coding candidates Nokia, Alcatel-Lucent Shanghai Bell；R1-165064 Design considerations on URLLC for New Radio systems INTERDIGITAL COMMUNICATIONS；从数量上来看，进步很大，打开市场了，赞！其实可以看到，这些在非常早的时期就开始URLLC提案的公司都是有着深厚实力的，他们也往往较早作技术铺垫，规模小一些的公司起步会晚一些，从这点上还需要向大公司学习。

全兜是榨菜

审核时间好长

全兜是榨菜

    在RAN1-87次会议前，URLLC的研究都是在NR研究的各章节下附带的，比如控制信道，信道编码，多天线中都会包含一些URLLC研究的内容，但是到了RAN1-87次会议，URLLC终于独立出来了，形成了新的章节“7.1.4.4 URLLC specific aspects”，此次会议上将所有NR中跟URLLC有关的研究转至该目录下，包括URLLC的控制信道设计，下行URLLC与eMBB复用，下行URLLC-HARQ设计，上行URLLC调度，HARQ设计等等。里程碑，URLLC终于小C位出道了（URLLC在5G里可是要做主角的好不好）。

    但是好景不长，在URLLC specific aspects这一章节在RAN1-88次会上再一次出现后，后面的RAN1-89次会上（杭州2017.05），这个章节就没得咯，活不过两集系列？取而代之的是“7.1.3.3.6 Multiplexingdata with different transmission durations”，虽然其他NR章节包括DCI设计，上下行调度等中有出现URLLC身影，但是都不被待见（没有被讨论），声量也可以忽略不计（提案数量很少）。而留下的这个“7.1.3.3.6 Multiplexingdata with different transmission durations”章节是什么？就是URLLC与eMBB数据复用的问题，因为URLLC数据对时延要求较高，其传输时长一定是相对短促的，eMBB需要传输大量的数据，其资源块在时域上是相对较长的。这一课题要解决的是，在URLLC与eMBB数据复用情况下，如何提升eMBB数据在终端处的解调成功率的问题，这里可以看到一个转变，就是R15要做的是把eMBB跑起来，URLLC延后吧，也就是在R15中，eMBB才是主角，URLLC只是配角。

    然而，到了3GPPRAN1-NR#2次会议（青岛 2017.06，我也是从这次会后开始URLLC与eMBB数据复用技术的研究的），在调度章节（5.1.3 Scheduling/HARQ aspects）中又出现了“5.1.3.1.5 Ultra-reliablepart of URLLC for DL control”和“5.1.3.2.6Ultra-reliable part of URLLC for UL control”，“5.1.3.3.8 Ultra-reliablepart of URLLC for scheduling/HARQ procedure”三个新的章节专题，what？所以URLLC的内容还是要做起来？我没有去参会，我看到这个是崩溃的，到底要怎样？好吧，我目前也不做这块，任你变吧。另外“Multiplexing data with different transmissiondurations”分成了两个子课题“Pre-emptionindication for downlink”和“Possible enhancementsfor uplink”。“Pre-emption indicationfor downlink”这个稍微解释一下，就是URLLC在下行传输时是在eMBB数据块上打孔进行传输，那么URLLC对eMBB数据的传输是有干扰的，因此设置了一个Pre-emption indication(翻译为占用指示吧，简称PI)，告知eMBB终端哪些资源块被URLLC打孔了，把打孔位置的数据块去掉补0可以提高解调成功率。这一课题就是去研究这个PI的配置、发送和指示的问题。“Possibleenhancements for uplink”就是解决如何在上行链路中进行URLLC和eMBB复用的问题。这次会议后，我觉得URLLC的其他内容又可以关注了。

    然而2.0，在3GPP RAN1-NR#3次会议（名古屋 2017.9），Ultra-reliable part of URLLC for DL control”和“5.1.3.2.6 Ultra-reliable part of URLLC for ULcontrol”，“5.1.3.3.8 Ultra-reliable part of URLLC for scheduling/HARQprocedure”又给删了，果断举白旗投降，惹不起惹不起。

全兜是榨菜

在RAN1的90b会议上（布拉格 2017.10），只有Multiplexing data withdifferent transmission durations保留了，子课题删除了，研究重心转移至PI设计，关于URLLC的其他内容都移到了其他课题下的other分类里面，从这次会议后，局势算是稳定了，R15中的URLLC，咱们就研究PI，其他的先搁一下，但是！！！在LTE R15这一章节中，出现了“6.2.9 Ultra Reliable Low Latency Communication forLTE - WID in RP-171489”这一子节，也就是说URLLC要在LTE中做了，这次会上讨论了URLLC在LTE中的可靠性和时延需求，以及评估场景，形成了一些结论，可参考90b的chairman notes，至于为什么要在LTE中做URLLC，我认为5G-NR的部署频段相对于LTE高，其覆盖性不会很好，尤其针对无人机和自动驾驶场景，需要广覆盖。另外，LTE中的sTTI是可以支持这一业务的。

在RAN1的91次会议上，“Multiplexing data with different transmissiondurations”基本处于尾声了（这会儿我都还没弄清楚URLLC课题开展规律，囧），PI设计的一些参数细节也基本在这次会议上提出，这次会议后，Multiplexing data with different transmissiondurations就没有多少公司关注了，在RAN1-92次会上，PI的内容就没有专门的章节了，下行复用和PI的提案也几乎看不到了，但是在chairmannotes中出现了一个新的章节“7.2  NR URLLC in Release 15”，还是想去研究点东西吧，大家对URLLC的热情都很高，每次other目录中全是URLLC的内容，这个章节中就包括URLLC的MCS/CQI、DCI、PDCCH重复传输以及上行复用问题。我也是从这次会之后开始了上行复用的研究（我觉得上行复用也是要考虑eMBB的数据传输问题，R15需要让eMBB顺利传输，上行复用问题就需要解决，应该稳定，所以选了这个课题跟进。）。

cc河马

之前也学习了一些5G的内容，看了LZ的帖子，又了解到一些内容，谢谢。
感觉URLLC就是一个很理想的目标，但到实际商用又有很多过不去的坎，至少还需要垂直行业的技术更上几层楼。

全兜是榨菜

    但在RAN1-92b会上，这个时候时间已经到了2018年4月了，离SA的5G标准冻结只剩2个月时间，NR URLLC in Release 15课题下的研究内容还有非常多的不确定，因此在此次会上这一课题下的内容基本就宣告不做了，留了一个“7.2.1        Support of separate CQI and MCS table(s) for URLLC”课题还在讨论研究。其他内容直接下结论了，如：“Study of necessity of a new DCI format”和“Study of necessity of PDCCH repetition”的结论是：“There is no consensus in Rel-15 to support: Defining a new DCI format(s) that has a smaller DCI payload size than DCI format 0-0 and DCI format 1-0 unicast data, and/or For a given carrier, PDCCH repetitions over same or multiple PDCCH monitoring occasion(s) of the same or multiple CORESET and search space”也就意味着在R15中，关于DCI for URLLC以及PDCCH repetition的内容不再继续。“Study of handling UL multiplexing of transmissions with different reliability requirements”的结论是“There is no concensus in Rel-15 to support handling inter-UE UL multiplexing of transmission with different reliability requirements (including the potential need for UL UE pre-emption)”终端间的复用干扰问题也不继续在R15中讨论。

    2018年5月，在釜山RAN1-93次会议上，NR-URLLC in R15中只有“Support of separate CQI and MCS table(s) for URLLC”课题了，会上对一些参数进行了确认。其他方面就没有再讨论，至此，NR-URLLC就要等到R16再见啦。其实从这些章节变换的情况来看，URLLC真的不是5G第一阶段的研究主角，5G首先要做的是让eMBB顺利运行，如果其他业务对eMBB有潜在影响，就解决这个潜在影响。

    到这个位置，第二部分就写完啦，下一部分我将对URLLC与eMBB复用技术在每次RAN1会议上研究的内容和形成的结论进行讨论，可能我的理解不够深入，所以这部分希望能和大家多多交流..

Part 3,comming soon...

全兜是榨菜

cc河马 发表于 2018-7-27 09:48
之前也学习了一些5G的内容，看了LZ的帖子，又了解到一些内容，谢谢。
感觉URLLC就是一个很理想的目标，但到 ...

是啊，很多物理层的东西要针对URLLC重新设计，虽然每次会上都有很多URLLC的提案，但是需要研究确定的内容太多R15中来不及完成。另外URLLC对终端的处理能力提出了很高的要求，尤其是对那些同时支持URLLC和eMBB业务的终端来说，需要符号级的上下行切换，需要处理自身URLLC数据和eMBB数据发送和干扰的问题，等待R16看3GPP怎么做这块吧~

trendslover

非常专业的讲解！

fzz111000

讲技术，继续期待！！！

zjuwangwei

全兜是榨菜 发表于 2018-7-26 18:52
我后面尽量把提案号标出来，便于大家查看讨论

造福众生

diaochong

URLLC要看最新的进展，看哪个提案。谢谢

514224202

期待！