当前位置: 首页 > article >正文

5G三大应用场景中的URLLC

5G三大应用场景中的URLLC
5G三大应用场景中的URLLC
1 Urllc不是一个独立的技术,更不是一张独立的网络,他是5G所谓的新空口标准NR(New Radio)中,涉及大规模降低时延、提高可靠性的相关技术;
2 Urllc在目前的5G标准演进中,尚未有可以落地(即完成标准化仿真和认证指标确立)的技术细项,截至2018年底的R15,基本都是协议草稿和原始提案,乱得一B,别说外行了,我看得都头晕;
3 Urllc如果说相比较于之前的R14版本(LTE evolution)有些体现,主要是两点,一个是随着NR标准确立之后,一些明显能改善空口时延的特性,比如短符号周期Short Symbol,短的调度周期TTI等等,这是NR敢说自己空口时延能落到5ms以下(1ms最佳理论)的资本;另一个是发源于R14的LTE-v2x技术体系(注意这里是基于LTE的V2X,还不是NR-V2X),这个引人注目的车联网技术虽然实际没有落地,但是他要解决的问题和实际面临的部署场景,还是在他那个阶段(2016-17年)提出了不少具体的对于空中接口的增强需求,比如:
3.1 低时延,更短的调度周期;
3.2 低时延,提供直接的V to V的无线接口(广播),放弃寻址,放弃基站转发,直接实现车辆到车辆的信息互通;
3.3 低时延,提供新的调度方法,尽可能压缩因为调度所导致的时延;
3.3 高可靠性,更好的对抗多普勒频率偏移的机制,满足相对速度300km/h需求;
3.4 高可靠性,更可靠的空中接口,采用更高密度的DMRS(一种参考解调信号),会让空中接口的解调质量更高,误码率更低;
3.5 高可靠性,更好的数据重传机制,可以针对这种高速复杂电磁空间,尽可能快地把误码重传在更低的网络层次上完成;

4 因为去年的主标准版本R15,主要是针对eMBB设计,主要还是满足超宽带的需求,因为这个时期中,这个比较博人眼球,也比较利于5G的尽快推广和落地(所以才有美国Verizon的换标5G),所以其它关于urllc,和其最典型应用的V2X,就几乎没进展,很可惜;但是今年的R16,一定会在这方面发力的,去年的欠账都会加倍奉还;
5 至于你提到的其他方面,比如对抗恶劣环境的具体措施,标准内包含完善的评估手段提供给运营商和设备厂家做benchmark,但相对具体的标准措施,还会再晚一些,有个先后次序的问题;
6 最后说几句关于自动驾驶中,5G应该扮演何种角色的问题。这个是仁者见仁智者见智的问题,从标准角度看我们确实给出了…
computer restarting
OK for restarting-----
从现在的标准看,从LTE-V2X开始,3GPP一直是现有应用需求,再在应用需求所对应的技术边界之内找具体的实现方法的,这是个严谨的思路,也基本避免了“闭门造车”的情况出现,这个系统的方法论,一直工作的很好,毕竟网络投资是非常惊人的,慎重总是没错的;但我觉得现在的问题是,无线网络的发展终于来到了一个分水岭,3GPP在互联世界当中扮演的角色,管道化越来越严重,具体体现就是对于无线网络应用的距离感越来越强,也越来越外行了。无数例证已经可以证明这一点,3GPP和其背后的运营商和设备制造商,最终会回归“管道商”的基础定位,而无法继续兼职扮演“应用提供商”的角色。现在当下最直白的就是车联网,别说3GPP为代表的通讯界,就是汽车行业自己也没有一个明确的目标,整体感觉就是一个乱字了得,各说各道理,听起来都有点道理,但实际上未必就是最终答案。就比如老杨同志(杨学志同志),也只是一个固定通讯人对于车联网的思考,有他的价值,但肯定不全面,更显武断。
我举个栗子,NR-V2X的车联网应用建议里,上来就是车辆编队(plantooning)和远程驾驶(RC),这些企图彻底旁路目前单车智能的粗暴替代,看起来很美好,但确实很难落地,那这种应用来作为车联网的当下目标来讨论,吵过来吵过去的,没有任何意义。车联网的部署成本,包括设备成本、覆盖难度、优化难度、IOT难度…等等这些巨大的成本,可能不会被传统的无线网络模式所分担多少,毕竟标准的5G网络还是沿着住宅区和办公区进行建立和优化的。在这个基础上漫山遍野跨山跨海去覆盖各级公路体系,你当国家财政是太平洋里捞出来的,取之不尽用之不竭吗?
所以更现实的需求,还是交通整体流量信息的泛化普及、紧急路况信息的跨视距周知…等等类似弥补传感器不足的辅助性需求,最多能在单车的自动控制算法里做一个带系数的参数,数据融合之后被用作最终决策。这是最佳落地。
大一统的大心脏,通过车联网’的单点指挥全局,这种王道,现在看,真的还早。
编辑于 2019-03-12 16:47
​赞同 46​​11 条评论
​分享
​收藏​喜欢

收起​

吃西兰花王
不拘一格
​ 关注
32 人赞同了该回答
URLLC究竟U到了什么程度?我也来强答一波。
结论先行,在我看来,URLLC空口的可靠性来自于以下几点:
1.偏保守的自适应编码调制
URLLC采用与eMBB不同的低频谱效率编码调制映射表,简单来说,相同的信道条件下,URLLC的自适应编码调制结果更趋保守,比如相同的MCS,eMBB的调制方式可能为64QAM,而URLLC就可能为16QAM甚至QPSK,更低的调制方式带来了更粗犷的星座粒度,增强了物理层调制解调的容错性,提升了可靠性。调制方式相同的情形下,URLLC的编码效率也更低,通过加入更多的冗余,增强了编解码过程的纠错与合并能力,提升了可靠性。此外,URLLC对调制编码方式MCS的升阶迟钝而降阶敏感、动态调整TA测量与TAC调整周期,支持受限的传输模式等,都对可靠性产生或多或少的增益。
2.URLLC承载高于eMBB专有传输的优先级
URLLC的调度优先级高于eMBB的专有传输,当两者空口时频域资源发生冲突时,优先保证URLLC业务的传输,并通过特殊的下行控制指示(DCI2-1)通知用户设备(UE)。这种资源抢占机制使URLLC数据以相当高的优先级发送,在不得已的情况下,牺牲eMBB的传输也要保障URLLC数据稳定发送,提升可靠性。
除了空口抢占,对无线带宽的半静态复用也可以作为保障URLLC高可靠的手段之一,在配置中直接预留好一定的时频域资源划拨给URLLC,就算URLLC工作的占空比低导致预留资源空闲,也不会将这部分带宽提供给eMBB,充分考虑URLLC业务的突发特性,使其能够在Minislot级别的时间粒度上高速响应调度需求。
另外,5G中URLLC作为一种特殊承载,通常采用独立的基带切片进行部署,与eMBB隔离,从软硬件资源上保证URLLC业务的调度不受挤压,最大程度保障应用可靠性。
3.高密度分布的导频
eMBB场景中支持单符号或双符号的前置解调参考信号(Front-Load DMRS),支持2符号的附加解调参考信号(Additional DMRS),可以在一个调度间隙(TTI/Slot)中同时存在3个符号的DMRS,帮助物理层解调。DMRS作为一种辅助解调的参考信号,本身会占用一定的空口资源,部署的多了,自然会导致可用带宽下降。之所以会配置如此多的DMRS,是因为信道的时变特性,一个调度间隙有14个可用符号,前面的DMRS无法准确地体现后面符号的信道特征,不利于物理层解调,因此就有了一个调度间隙中后面符号嵌入的附加DMRS,协助后方符号的解调处理。
对于URLLC,通过配置密度更大的DMRS导频,来保证其可靠性。以2符号(可变)组成的Minislot为例,给每个Minislot的第一个符号都配置DMRS,本符号交织的PDSCH资源自不必说,对一个Minislot级别的调度而言,感知影响解调的信道特征变化的时间延迟,缩短为一个符号,提了物理层解调的能力,保证可靠性。
4.传输的重复机制
在LTE的eMTC中,已经引入了重复的机制,重复与重传不同,没有(混合)前向纠错机制(HARQ/ARQ)的参与,每次重复也就没有RV版本的差异,重复是对同一份数据多次的传输,通过这种方式,保证收端可以正确接受。URLLC场景也引入重复机制,这种传输方式非常适合URLLC高可靠、小数据包的应用特性,能够在重复中尽最大可能完成数据的正确收发。
5.URLLC应用频点低
电磁波的频点越低,那么波长就越长,衍射散射反射能力越高,空口对信道恶化的容忍能力就越好,否则反之。5G的频点可以在数百MHZ到数GHZ之间部署,URLLC为了追求更大的可靠性,考虑配置在更低的频段中,获取更加平坦的信道衰落特征,在相同的外部环境中,拿到低频点带来的空口可靠性增益。低频点还可以提升覆盖范围,毕竟不停的在小区间切换带来的不可控因素也是URLLC不能容忍的。
但是,更低的频点,意味着时间更长的调度间隙,这在一定程度上会带来时延的增加,对于URLLC的时延和可靠性,不仅在频点高低部署上是一对矛盾体,在其他很多方面都需要权衡舍得的过程,这是无法避免的。
6.无线资源频选
5G应用带来了更大的带宽,以Sub-3.5G常见频段为例,可能拥有超过270个RB,跨越100MHZ的带宽,信道(包括干扰、衰落、信噪比)在频域上的差异会比LTE体现得更加显著,那么是否可以通过频选的方式,把最干净、信道条件最好的RB资源留给URLLC呢?答案是肯定的,这种手段从一定程度上会保证URLLC的可靠性,代价就是基带处理的复杂度上升,对于URLLC这种时延敏感的应用模型可能存在负面影响,不过总有办法可以通过在线、离线计算分离的方式进行实现,总体来说是可以考虑的。
大概先想了这几点,其实提升URLLC可靠性的手段还有很多,这算是抛砖引玉,后面我也会继续补充。
最后,URLLC的U到底有多U?
99.999%的接入终端在99.999%的时间内以99.999%可靠性进行通信。
这,是一个梦想。
发布于 2019-04-02 13:22
​赞同 32​​8 条评论
​分享
​收藏​喜欢

收起​

赤道羽绒服
敬畏工作和生活
​ 关注
2 人赞同了该回答
前面两位答主已经从协议标准层面上做了阐述。我从网络覆盖和环境的角度来说说这个“U”是有多困难。
无线是不可靠的
无线网络天生就被认定是不可靠的,所以在网络传输协议设计的时候会充分考虑空口重传,所谓的“空口重传”就是无线网络层单独考虑一套重传机制,比如使用TCP/IP进行网络报文传输时,除了TCP的重传外,空口链路也有一套重传机制,以保障报文的成功传输。无论是NR还是LTE都会有这一套机制。无线网络的不可靠源于无线环境的不稳定。
1.传输链路的影响
从基站到终端,无线链路受到慢衰落和快衰落的影响。慢衰落可以在链路预算增加余量来考虑抵消,但终端大部分都是移动的,遇到信号突变的情况经常遇到,这个对移动终端的超低时延往往是致命的。而且现在这个阶段对多基站无切换组网还没有实质的进展,切换带来的影响也要考虑在内。
至于问题中问到的低时延相对采取的策略和一些评估手段,目前来看,大部分的NR商用网络规划中都没有拿URLLC来做规划指标的,现在来看商用网络中,还是eMBB这个层面的应用,故大多数NR网络覆盖规划还是老一套以边缘速率和平均速率的衡量为主。
2.干扰的影响
无线网络是一个“开放”的网络,尽管NR应用MASSIVE MIMO技术,波束应用比起4G时代有了很大的创新,但是波束之间的干扰,基站之间的干扰,终端之间的干扰,不同系统之间的干扰依然是很头痛的问题。

未来的低时延网络我认为应该是在低频段网络中单独划出一段频率,做全网的超级小区,解决覆盖、切换等问题。
发布于 2020-04-06 09:44
​赞同 2​​添加评论
​分享
​收藏​喜欢

开元大叔叔

信息技术行业 从业人员
​ 关注
1 人赞同了该回答
前面文章介绍过,5G的初期定义的应用场景包括了3类,这里也重申一下:
eMBB:即为enhanced mobile broadband,提供高速率长的数据传输,可以看做是当前LTE网络的升级换代系统。
mMTC:即massive Machine Type Communications ,也就是物联网技术,用户数量庞大,延迟要求不高,数据量通常不大,但是要求电池的寿命比较长,覆盖的强壮性比较好。
URLLC:即Ultra-reliable low latency communication ,要求极低延迟,极高可靠性。延迟需要小于1ms,可靠性为99.99%甚至更高。
从长远看,三类场景中mMTC与URLLC才是蜂窝通信的未来,光靠eMBB的话这个产业已经是日薄西山了。而且5G作为平台,还可能开发出其他更为精彩的应用场景。
URLLC的用途很多,主要有下面列出的几种。随着各垂直行业的参与,期待更多的相关应用也在人们的想象过程中出现:
VR/AR:即虚拟现实与增强现实,这类业务应用需要极低的延迟,URLLC在这类应用中将扮演非常重要的角色以增强最终用户的业务感知。
自动驾驶汽车:自驾汽车将使用CV2X进行相互通信,这一功能在4G中也存在,但延迟是其主要的问题。而5G将通过提供非常低的延迟和非常高的可靠性来提供网络基础设施。R15中定义了一些基本的V2X的协议,而在R16版中,我们看到了CV2X的一些增强功能。
自动工厂与自动库房。
那么URLLC是如何做到低延迟且高可靠性的呢?这需要底层的多个方面的共同合作。本文就根据资料及3GPP R15、R16规范的基础做个小结供大家参考。
首先是5G定义了丰富的帧结构,具体可参见本号文章,本文不再赘述:
当前尘埃初定的5G空口基本帧结构和物理层骨架
5G NR 物理层协议结构小结(准冻结部分)
5G无线帧结构与空口物理层资源
在4G LTE网络中使用1ms作为TTI,对于某些业务来说延迟稍大,同时n+4的HARQ反馈周期也进一步增大了延迟。为了在4G的基础上改善延迟需要做的可以有如下思路:
.使用更短的TTI;
.在短于4ms的时间内发送HARQ反馈信息。


http://www.kler.cn/a/374926.html

相关文章:

  • 吞吐量最高飙升20倍!破解强化学习训练部署难题
  • 责任链模式:解耦请求处理的设计模式
  • 项目_Linux_网络编程_私人云盘
  • computed拦截v-model
  • 3D人体建模的前沿探索:细数主流模型与技术进展
  • Java中的JVM(Java虚拟机)是什么?
  • 全新大模型框架Haystack,搭建RAG pipeline
  • 从零开始的C++之旅——string类的模拟实现
  • 【Git】Git常用命令
  • (蓝桥杯C/C++)——常用库函数
  • 【Deno运行时】深入解析Deno:下一代JavaScript和TypeScript运行时
  • cisco网络安全技术第4章测试及考试
  • 高效扶贫:SpringBoot精准扶贫系统
  • 笔记整理—linux驱动开发部分(4)驱动框架
  • 【Nginx】编译安装(Centos)
  • Windows下Jenkins自动启动jar包
  • 技术总结(十九)
  • unity后端kbengine用DOTween让 移动同步丝滑
  • HJ106 字符逆序
  • 发布 NPM 包时,终端显示发布成功但实际上版本并没有更新,可能是由于以下原因
  • 基于 Postman 和 Elasticsearch 测试乐观锁的操作流程
  • Java的多态
  • LEADTOOLS 版本 23 现已发布,引入了 Excel API等众多新功能!
  • 就业市场变革:AI时代,我们将如何评估人才?
  • Python之groupby()及aggregate()方法
  • 手机实时提取SIM卡打电话的信令声音-新的篇章(三、Android虚拟声卡探索)