5G低延时的误区和机会——从理论到工程落地的数据差异

Posted 2021-06-15 LiveVideoStack

我们有幸请到虎牙直播的5G首席架构师——林正显老师，为我们介绍5G低延时的误区和机会。本文从介绍5G低延时原理开始，一步步解开大众对5G低延时的5个误区，最后分享了虎牙直播在建设低延时确定性网络技术的想法以及5G在其他场景的应用。

 

大家好，我叫林正显，来自虎牙直播，今天一起聊聊5G低延迟相关的一些问题。想起谈这个话题是因为虎牙在做一些5G的落地实践时候，发现工程上的数据和宣传上、媒体上的数据有很大差别。我们做了很多的探索和分析。今天把我们所思，所想，所见分享给大家。

我们想先讲一下何为5G低延时？它是如何实现的，我会剖析一下5G低延时的误区；另外包括MEC（多接入边缘计算），它和5G是密切相关的；还有虎牙在5G低延时或MEC上的一些实践；最后聊一聊虎牙在5G低延时方面的思考，以及未来的挑战与机会。

 

 关于5G的一些报(wu)道(dao) 

在过去的一两年，5G一直都是比较热门的一个话题，很多媒体都做了大量的报道。左边这个图告诉我们，Wi-Fi在人多的时候带宽不怎么样，4G马马虎虎，但是5G非常迅速；5G另一个应用是——远程驾驶，号称可以利用5G超低延时，足不出户驾驶千里之外的汽车；还有一些说5G可以大大提高下载的速度。以上这些报道，真真假假，大家听完今天我的讲解后会有自己的理解和认知。

5G延时的定义

什么是5G的低延时？在3GPP里对5G低延迟有非常明确的定义：对于URLLC（高可靠、低延时通讯场景）上下行的标准值为0.5毫秒（RTT 1毫秒）。对于eMBB（增强型移动宽带场景）上下行的延迟各4毫秒。我们平时上网、直播、刷视频等几乎都是eMBB服务。

 

 5G为何能做到低延时 

 

5G是如何做到低延时的？在无线方面，也就是手机端到基站采用了哪些措施？在核心网内侧5G和3G、4G有什么区别？
我们简单讲一下这个图。不管是5G、4G还是3G，如果之前没发送过数据，我们的手机要上行数据到公网或者基站，这和我们在课堂上举手回答问题类似。首先要向基站申请一个上行的无线资源，基站根据当前负载情况合理分配，并提供一个可以发送的时间及无线资源返回给用户，随后用户再完成数据发送。这个举手的时间是一个周期性窗口，不是随时待命的，我们称这叫做——调度请求。

调度请求引入了延时，它在整个无线方面的延时中占比是不低的。在5G需要低延时，我们通过配置把调度的过程去除，可以认为，只要有数据抵达，在配置的时间窗口就可以直接发送，不再需要额外的申请。

另外就是Slot，5G支持的是mini-slot。Slot中文翻译为时隙，在4G和5G中，一个时隙可以分为7个或14个symbol，一个symbol对应一个正弦波的波长周期。对于4G来说，子载波的频宽是15khz，所以一个symbol就是1/15毫秒，整个slot就是大约1毫秒，这是4G调度基本单位。

在5G中也是如此，Slot始终是一个基本的调度单位。但是到了5G呢，它的子载波的频宽可以更宽，达到30khz、60khz、120khz甚至240khz，那么它一个symbol的时长也会成比例下降，因此整个调度的周期就可以变得更短。所以在极端情况下，5G完整的调度周期可以低至几十微秒。更进一步，5G可以支持mini-slot，可以只用2个symbol来做调度基本单位，这时调度周期可以控制在微秒级别。另一种情况，在使用eMBB服务时，因为调度单位是1毫秒，我正在发送eMBB的数据时，URLLC（更高优先级）的数据来了，这时可以暂停eMBB的发送，在原来无线资源的信道上，先发送URLLC的数据，这个叫做抢占式调度。这样可以保证更高优先度的数据可以更快的发送出去。

最后一张图描述的是传输的可靠性。低延时和传输可靠性有密切的关系，由于传输不可靠导致丢包重传，客观上会导致延时的升高。5G的做法是冗余，一份数据包作多份拷贝，通过不同的子载波，不同的信道把相同的数据发出去，这里不同的载波可能是同属一个基站的两个载波，甚至可能是两个基站的不同载波，通过冗余来保证发送可靠性从而做到稳定性。此外，在极端情况下保证可靠性时，可能需要牺牲一部分无线的效率，采用抗干扰性更强的调制方式来做传输。比如原本可以用16QAM的调制方式，但是为了稳定性，我选择了QPSK。在空口上大致就这些措施。

在核心网上，从3G开始，移动网络要上公网的话会经过网关（移动网络和公网之间的数据网关）。在WCDMA里我们叫GGSN，在4G里我们叫P-GW，而5G里叫UPF，名字虽不同，但都是网关。在3G、或4G时，网关在每个省只会在1、2个地方部署，比如在广东省大概率就部署在广州或深圳或东莞，其他地方即使访问同城的服务器，也会经过基站，经过核心网以及刚才提到的网关，绕一圈之后再回到原来的服务器，过程非常曲折。

但是5G就可以把网关下沉到离我们访问基站较近的地方，甚至就在同一个机房，我们称为UPF的下沉。参看右图的绿线，我们通过基站，基站连接本地UPF，直接到城域网，然后就可以访问到本地的服务器了。不需要像黄线一样千里迢迢跑到广州，经过骨干网，再到城域网最后才能访问。

如何进行分流，运营商是有策略的，通过上行分流器来做到这一点，这里我们不细讲。

听起来5G在低延时方面还是做了很多事情的，感觉上也很靠谱，5G低延时特效也被大众津津乐道。但是非常遗憾的是大家在讨论这个话题的时候，很多人的理解还是有一些偏差的。

 

 

理解误区 #01： 理论极延时与实际延时混为一谈 

第一，我们很容易把5G理论延时和实际延时混为一谈，尤其是媒体的朋友们，有意无意地在做一些引导。

     

我们来详细看看之前提到的“调度”的过程。当我们有一项数据在手机上即将产生的时候，我们并不能马上发送出去，我们需要等一个周期性配置的“调度请求”（SR）的窗口（比如1毫秒、80毫秒），发送SR请求之后（可以理解为在红绿灯路口按下想要通行那个按钮的过程）基站收到请求后会判断用户的优先级、空口的占用状况如何等来决定何时给手机发送“授予”grant（在何时在哪个信道上传数据）授予的信道有可能很小，也许只够用户发送一个BSR（缓冲状态报告），手机会告诉基站现在有20k的数据需要发送，基站收到后知道你有很多数据会授予更多的信道供用户发送，这是在空口发生的一个事情，也是大部分情况会经历的过程，无论是4G还是5G。5G的免调度只是把申请SR的过程去掉了，但是对eMBB服务来说不太可能实现，因为需要付出很大的代价。上行的调度请求周期越长，延时就会越大，因为这个过程引入的延时平均是SR周期的一半，运气好会快一些，运气不好SR刚过，需要等待下个周期。

如果我们周期配置的足够小，我们的延时依然能够保证。理论上来说，即使是4G，延时也可以到几毫秒。

很遗憾，虽然4G延时数据理论上也能到几毫秒，但是我们4G实测数据并不理想，虎牙在高峰时期4G用户到同城服务器RTT超过了40毫秒，同一时刻Wi-Fi用户到同城服务器RTT大概率在20秒以内。

去年有一份白皮书，列举了很多5G to B的场景，5G在结合了UPF下沉了以后，端到端的基本延时在16~20毫秒之间，这和我们虎牙现网5G的数据也差不多。
为什么现实和理想差距那么大？我们在谈论延时的时候，其实包含了处理延时、排队延时、发送延时和传播延时。处理延时是指对包进行有效性校验等操作引入的延时，这时间基本可以忽略不计。传播延时取决于光速，从A发送到B，通过光纤传送过去，这一速度我们无法干预，距离足够短时，这一时间也可以忽略不计。剩下的问题就在于排队延时和发送延时，这两个延时我们在后面会详细展开，在做一般的理论分析时，往往会把它们忽略掉，这是造成我们现实与理想差距的主要原因。还有一个问题是丢包重传，很多时候不是网络RTT不好，而是偶尔的丢包导致的重传，使得实际的延时变高。

 

理解误区 #02  不同技术与不同应用场景的延时混为一谈 

      

第二个误区也能在媒体中经常见到。5G有很多不同的场景和技术，但是报道时，总是挑最领先的技术来说。

比如，5G有三大应用场景，eMBB（增强型无线宽带）对应大带宽，URLLC对应高可靠低延时的业务，还有一个mMTC海量机器类型通讯，对应物联网的广连接。通常来说，只有自动驾驶等场景需要用到URLLC这种极端的低延时保障，这种端到端的延时可能只有2、3毫秒。

但是有一点不能忽略，为了能够获得超低延时需要付出相当大的代价，坦白来说很多场景极端低延时不是必须的，比如浏览一个网页，是否需要一个端到端3毫秒的低延时？因为成本差别很大，我们不可能在所有场景覆盖低延时。另外除了成本较高的冗余、调制方式等方面的无线措施，还有端到端的低延时也需要非常严苛的端到端QoS保障。

4G的QoS是怎么样的？4G在传输数据时有2种承载，一种叫默认承载，一种叫专有承载。默认承载有数据就有可能建立。专有承载针对不同的QoS所要求的流来建立额外的通道。这个承载本身的建立是有一定限定的消耗的。另外它的粒度比较大，因为一个手机通常只能建立几个到十几个专有承载。所以在日常生活中很少听到有对4G QoS的利用，因为它往往只会出现在运营商内部业务，比如给VoLTE这类业务来做一些高优先级的保证，但现在运营商正在慢慢放开。

     

5G的QoS相对来说更灵活，我们可以根据不同流设置不同PCC的规则，对应不同包的计费和质量保证的规则。它不是基于承载而是基于流，流的标识通常是三元组或是其他特征。

上图和其他5G QoS图不太一样，因为它有涉及多接入技术的QoS。多接入（Multi-Access），比如在3GPP AN里面，5G除了通过空口来连接到目标地址以外，还可以通过非5G，如Wi-Fi等介质同时形成多接入通道，以此保证数据接入可靠性。但是3GPP毕竟代表的是运营商或是设备商的利益，所以这一特性未必能得到广泛的运用，比如我们在做传输时通常会考虑同时使用Wi-Fi、4G、5G或是MP-TCP这种特性来做多路的传输，这些我们通常在应用层实现。3GPP试图在底层将这套方式封装起来，但就我和其他应用厂商的讨论，似乎没有人愿意为这一方式买单，应用厂商更愿意自己把控这方面内容。另一个与QoS有对应关系的是切片。

这部分内容我不会详细展开，因为内容过多。切片的目的是为了保证不同业务不同的优先级，但这项技术对手机来说是个“坑”，因为目前市面上5G手机对URSP的支持非常不足，几乎没有。虽然3GPP定义出来了，但是短期内，这项技术只能在to B场景应用，比如根据不同的DNN做一些不同切片的接入。对于目前的手机来说，很难从一个切片切换到另一个切片：理论上我们可以给不同的APP或是不同的流特性，映射到不同的切片享受不同的QoS保证，但是目前终端并不支持这项技术。

 

理解误区 #03： 空口延时与网络全链路混为一谈 

 

还有一个更为常见的误区，我们讨论的5G低延迟，其实说的是它空口的延迟，但很多人会把网络的端到端延时与之混为一谈，更有甚者会把业务的端到端混在一起。

我们一直在说的5G低延时，其实说的就是手机到基站的这段低延时。而端到端的过程会经过空口到承载到核心网，从核心网再到公网，经过若干个IDC有可能换到另外一个运营商的核心网，再到接入网最后抵达空口。坦白来说，即使5G的空口可以做到零或一毫秒延时，最多也就是打平了和固网的差距。如果用有线接入的话，事实上空口这个环节怎么样都是比不过的。我们真正需要的是端到端的低延时，剩下的部分怎么办？

我们可以参考一下TSN（时间敏感型网络），它在工业互联网中是会被用到的网络，通过这个网络我们希望能够得到5G来实现端到端、高稳定的超低延时方案。
最核心的点——冗余。从图中可以看到，控制器希望控制远端设备的时候，中间加入了5G网络。在END STATION，我们就分成了2路，接入2个终端，分别通过不同的传输通道进行传输。在5G中有不少类似于多链路、多路径的处理，这是值得我们借鉴的方式，鉴于时间原因，我无法展开更多。我想强调的是，端到端的低延时比整个空口的低延时更重要，我们可以从工业互联网中寻找灵感。

 

理解误区 #04： 空载延时与带载延时混为一谈 

 

另一个误区是，大家会把空载（网络较为空闲时段）的延时和带载甚至重载时的延时混为一谈。

     

比如在节假日时，我们的高速路口车流拥挤，这个时候我们不会指望能够快速通行。在网络中这对应的是排队延时，排队等待资源，等待上一个用户排空缓冲，这是我们延时的一大来源。对于无线用户来说，每个人都想上传数据，作为一个基站需要调度数据，那就势必会造成排队的现象。除非我的“车道”特别宽（多），每个人都有足够的车道，但这是难以实现的。

举一个例子，如果大家对无线网络感兴趣，在很多地方是可以进行测试的。最经典的是在地铁站，尤其是高峰期的地铁站，比如北京的西二旗地铁站。这个车站如果在高峰期测量，同城RTT有可能在200，300毫秒。即使是空载的状态，清早或大半夜测量，会发现延时也有80毫秒。这和基站的设置是有关系的，回到前面提到的“调度周期”，通常运营商会根据基站的忙闲来对该值做些调整如果我需要保证很多人能同时接入基站，我必须在有限的控制信道内让更多用户接入。如此一来，调度周期一定会被拉长，这样每个用户才能有接入的机会。我猜想，运营商对于那个点的调度周期设置就是不低于80毫秒，这时平均的RTT就有额外的40毫秒的引入，这也是出现在地铁站的一个非常有意思的现象。

 

理解误区 #05： 忽略带宽对延时的影响 

 

     

最后一个误解，我们往往会忽略带宽对延时的影响。比如我们处理一些小包的时候，延时还是很低的，一旦加载业务，延时就变成15毫秒甚至40毫秒，100毫秒。

在座的很多同行应该是做视频的，除了无限GOP场景，对视频进行编码的时候存在I帧，后面紧接着P帧，可能还有B帧，依次循环。一个I帧很大，可能是P帧的很多倍，这取决于编码时的参数设定。假设可用带宽的平均码率是10兆，如果给我们一个10兆带宽的平滑流，我们确实可以很快的传输出去，但是视频是突发的，尤其对于I帧来说。最后我们会发现，I帧的传输会花费很多时间，甚至阻碍了下一帧，B帧或者P帧的传输。这里我列举一个数据，比如我上传一个10兆的视频流I帧可能会达到200kb，这时哪怕使用100兆的带宽去传输，可能也需要16毫秒，这是什么概念？如果在云游戏里，假设帧率是60，2帧的间隔就是16毫秒。也就是说10兆码流的视频我需要使用100兆的带宽传输才能让它不影响下一帧的传输。

所以为什么我们说5G对于云游戏的发展是个有利优势，因为大带宽带来的是低延迟。4G很难做到很大的下行速率，而现在很多云游戏的厂商会用到20兆或25兆的带宽。

 

 低延时与“5G+边缘计算” 

现在我们可以把前面讲的所有东西串起来，来聊聊MEC。狭义的MEC我们成为移动边缘计算，后来3GPP可能觉得不够酷，把M改成Multi-Access（多接入边缘计算）把它的范围扩大了，不再仅仅针对移动。最开始的想法，是利用UPF下沉（拉近出口网关和基站的距离），这时候可以在UPF所在的机房把计算资源和存储资源放在那里，其优势在于在与终端用户距离很短的时候延时会很低。把计算资源放在UPF机房和把计算资源放在中心机房，两者的延时差距还是挺大的，特别中心机房可能和UPF机房不是同省。

虎牙在边缘计算方面曾经做过一个尝试，我们在直播时希望给主播的形象做一些漫画风格的转换。但是我们发现很多主播的直播设备性能并不是特别优异，特别是一些低端或中端的手机，所以很难在手机做一些困难的AI风格转换。这时候我们想，能不能把计算这部分放到云端，利用低延时技术来实现。

大致过程如下，主播的头像通过镜头到CMOS感光之后通过ISP的处理，然后在送到APP，APP做一些前处理，随后编码，通过网络传过去。边缘机房的AI节点必须先解码，随后在做一些相应的AI处理，这时又要重新编码一路流，随后分发给观众，另外一路流返回给主播，主播收到流后经过解码和渲染，这才能看到自己被变换过图像；这个过程对于主播的感受来说，就像是在手机上完成的一个处理。这是一个非常美好的想法。

主播能感受到的延时就是图上1~4的步骤。那么大家觉得我们每个阶段，比如采集，编码，传输，解码，渲染延时最高的是哪个阶段？其实是采集阶段。安卓手机端或iphone11以下的机型，大家拿着摄像头对着自己，敏感的人是可以感受到延迟的，即使是自己的摄像头做本地的预览，延迟的时间在80~120毫秒之间。手机的操作无非就是成像，成像完成以后从传感器中读出来，然后送到ISP处理，处理完以后送去做渲染。安卓摄像头的管线深度和整个架构处理决定了延时的高低，这点当时被我们忽略了。在某些场景下，网络未必是瓶颈。网络可以做到很低延时，特别是在传输上，RTT20~30毫秒是可以达到的。对于一般的1080P手机编码就需要30~40毫秒，但是采集很有可能花费3帧的时间。所以我们在尝试边缘计算的时候，我们要想我们的瓶颈真的是在网络上吗？

 

 5G与Wi-Fi的区别 

现在我想讲一讲虎牙对于5G低延时的思考，我们内部讨论了很多关于Wi-Fi和5G的关系。通过全网数据你会发现用户的两个通道，一个是Wi-Fi，一个是4G，坦白来说大部分流量还是来自于Wi-Fi，来自于家庭宽带的流量。对于手机4G用户来说，也很少会用到运营商提供的超低延时的服务。即使到了5G，我们大概率也不会用到URLLC，也不会用MTC这种物联网专用网络，我们使用更多的还是eMBB的业务。

在空口中，eMBB的RTT是8毫秒，而好一点的Wi-Fi可以做到2毫秒。市面上质量较差的Wi-Fi是因为还在使用2.4G频段（易被干扰）或Wi-Fi 4或较差的AP网关。坦白来说，如果在座各位能够让自己平台所有用户的Wi-Fi及时升级，相信能减少不少视频卡顿率。eMBB的理论延时比Wi-Fi的实际延时还会高一些，甚至现在的Wi-Fi 6以及抗干扰的Wi-Fi 6E（使用新频段，不会受到2.4G或5G的影响），有可能更加拉大了Wi-Fi和5G的延时差距。

我们能做的就是等待，看看5G在现网优化的情况如何，以及毫米波的应用。毫米波并未在我国广泛使用，我们使用的是SUB-6G的频段。毫米波覆盖范围有限，但是可用的频宽资源很多，所以可以达到很大的带宽，在未来会在我国一些热点技术作为补强的应用。一旦毫米波进入市场，我认为有可能缩小5G和Wi-Fi低延时上的差距，当然能做的只是缩小差距，当然这只是我一家之言。那这时候有个问题就出现了，如果在延时上比不过Wi-Fi，我们如何定位5G？5G在移动性、广域覆盖方面比Wi-Fi有优势，我们不可能背着Wi-Fi到处走，尤其是户外场景。所以我们需要自己判断，哪些业务、场景适合使用5G。5G在广域覆盖上的优势值得被关注，我们需要考虑它和我们的业务是否有亲和性。
我个人认为类似于AR，AR眼镜，户外直播等这种业务和5G就有比较好的亲和性。顺带一提，我不会为5G+VR这类产品买单，因为VR和5G并没有什么关系，VR更多的是在室内的应用，在室内Wi-Fi不比5G更好用吗？同时5G还存在流量资费的问题。但是AR就不同了，因为我必须要走，必须和现场结合，户外直播同理。

 

 10毫秒级互动时代 

我们还有一个思考，随着5G技术的进步， 10毫秒级的互动时代即将到来。我们现在还有另一种5G叫F5G，就是所谓的第五代固网，也就是光纤到房间和Wi-Fi 6。它的延时一定是非常低的，而且覆盖强，带宽高。说回我们的5G，理论上我们布网布的好，10~20毫秒的RTT还是可以满足的。即使到了野外，没有Wi-Fi和5G的覆盖，我们哪怕用低轨道卫星（300km~500km距离）也能做到20~30毫秒的RTT，也就是说整个世界都能包围在相对低延时的网络中。整个链条如果能够建成，我们完全可以做到百毫秒级以内的端到端的延迟。如果说之前我们考虑的更多的是秒级，百毫秒级上的直播的话，现在我们就需要考虑更广泛的10毫秒级的问题。所以未来Wi-Fi主要是在室内，5G可能主要应用在户外、商场等。至于野外，以前我们一直很想去西藏直播，有了低轨道卫星后，这也能成为一种选择。

虎牙的实践主要是往两个方向发力发展，实时内容操作和直播互动。我们认为延时会慢慢降低，互动能表现出不一样的体验。所以我们投入到大家熟悉的云游戏，还有多人的互动，甚至多人互动游戏结合直播场景，还有虚实结合的互动直播我们也一直在探索。

但在技术层上，我需要一张优秀的端到端的网络来保证超低延时的互动。除了Wi-Fi（但是它的空口仍有很多优化的空间），运营商也会加大5G QoS开放的力度。我们也会依赖于5G QoS加上多接入（双链路，Wi-Fi 5G同时接入）以及公网多路径，加上类似于SDWAN的手段来构建一张LDDN的网络（低延时确定性网络）。

 

 5G低延时其他落地方向 

抛开直播，抛开虎牙，我们来看一看5G低延时有没有其他场景的落地方向。to B方面我非常看好车路协同的应用，还有边缘智能；比如视频应用，上传视频到边缘，边缘做完处理后做一些结构化或抽取处理，做完后视频就不会再被送到远在千里之外的云的中心机房。不管是对于计算还是对于网络，这都是一个比较好的资源卸载（offloading）。还有一些远程的控制和协作，工业上AR的应用，举个例子，我们可以坐在家里能指导欧洲的一个工人修车。当然，还有包括自动驾驶方面。

在to C上有一点要能抓住，就是要明晰5G和Wi-Fi的区别。Wi-Fi能够做到的事情，没有人愿意用5G。在国内90%以上家庭是拥有宽带的，这其中94%还是光纤，所以在中国应该很少在室内需要用5G做一些宽带的接入。我们要关注哪些应用与5G有亲和性。也许未来，自动驾驶进入市场以后，无人驾驶了，那坐在车上可能需要一些娱乐，汽车只能通过无线连接，那就只能用5G。

但是5G低延时仍然存在不少问题，整个国家的5G网络是在轻载的，现在的延迟还是马马虎虎，等到重载之后延迟能维持在多少需要拭目以待。毫米波有自己的优势，但在国内何时上线？另外我们更关注业务中端到端的低延时，这依赖于整个生态链的成熟，我在之前举过例子，摄像头的采集，如果一直存在2~3帧的延迟，那端到端的延时瓶颈就很难突破。还有操作系统本身，摄像头的延时也和操作系统本身密不可分，比如安卓手机对于相机的设置，整个pipeline的深度决定了延时的高低。另外有一个例子，安卓11 Media Codec2.0对低延时解码做了一些增强，后面类似的案例会出现的更多。另外，我们编写应用程序的时候是否为低延时做好了准备，我和很多开发者交流，他们的音频播放用的还是Java层的API，如果不用openSL ES或AAudio，java那层的音频播放延迟在手机上会达到200毫秒，这样前面在网络层面的一切努力都是徒劳了。

对于技术挑战来说，前面RTC也提到过。对于虎牙来说，我们想跟进无线接入网的QoS，我们可能依赖于运营商给我们开放的QoS；同时，因为空口的优化在整个链路的优化上是远远不够的，我们还会采用多接入（Wi-Fi 5G或Wi-Fi 4G双链路）包括公网上多接入的路由，甚至是多径的低相关的路由来保证我可靠性的传输。这时我构建的不是电信级的确定性的网络，我们只需要简配版的，足够支撑我超低延时的就够了。市场运营层面上，运营商不停在宣传5G，但是5G的费用相比Wi-Fi没有价格优势，还存在着套餐流量不够用的问题；此外，未来一定会有延时差异化的产品（低延时和超低延时和一般延时），这涉及到QoS如何推广的问题。因此，运营商的策略对5G的发展影响很深。

 

 总结 

简单做个总结：5G的延时在理论上和工程数据上是有相当的差距的，我们需要正视这个问题；我们更多的不只是需要空口的超低延时，而是端到端的低延时；5G不是万能的，它更多的只是从空间维度扩大了你的业务，把你之前无法做到的业务扩展开来；从技术上来说，为了迎接我们的10毫秒级低延时时代，我们需要自建一条累加的低延时确定性网络。

今天的分享先到这，谢谢大家！