内容来源：2021年10月23日，由边缘计算社区主办的全球边缘计算大会·上海站圆满落幕。会上，虎牙5G首席架构师林正显受邀发表了主题为《浅谈5G及边缘计算接入网络的治理》的演讲。经过整理后，分享给大家。
整理编辑：上海大学 刘含
出品：边缘计算社区
小枣君注：
以往，我们都是以通信人的视角看待5G。今天，我们转换一下角色，看看互联网厂商的大佬，是如何看待5G，以及网络体验优化的。
文章有点长，有9000字，但干货满满，值得耐心阅读一下。
浅谈5G及边缘计算接入网络的治理
——无线环境下APP网络质量调优思考与实践
林正显：
边缘计算网络无非就是边缘计算节点下沉到边缘之后，我们的端和边缘节点之间联系的网络，或者是边缘节点之间的网络，或者是边缘节点到云之间的网络。
我今天主要讲的是端到边之间的那段网络，而且侧重的是无线侧的东西。
我个人是在2C行业做的，虎牙直播。
这两年虎牙一直在实时内容创作和直播互动等领域发力，做了很多拓展和研究工作。
虎牙采用的是端-边-云的网络架构。端边之间通过有线或者是无线的接入，今天谈的主要是无线接入那一块，包括WIFI、4G和5G。
SD-WAN也好，还是云边通讯也好，这一块大家讲得比较多。但是我发现对于接入侧，不管是边缘计算社区还是我之前参加的其他社区，大家都讲得比较少。
今天我会把虎牙今年在做的一些实践经验和教训跟大家分享一下。
1.
一些常见问题
我们来看一些常见的问题，如果是做网络的同行应该比较清楚我在上面列的是什么。
图1-场景1
如场景1所示，看起来杂乱无章的图，整个来说它的RTT会非常低，但是它的丢包比较高，而且看起来没有任何规律可言；其实没有规律也是一种规律，它对应了一种场景。
图1-场景2
第二种是什么呢？第二种是一个很怪异的现象，你会发现它的RTT一会儿高一会儿低，但是它的可用网络前面切得很平，后面掉下去，这个代表的是另外的模式。
图1-场景3
第三种是丢包非常低，几乎没有丢包，但是RTT一直在抖。
图1-场景4
第四种是RTT和丢包都非常非常糟糕。
事实上这几种情况都代表着在线上的一些不同的故障模式。
2.
五花八门的原因
会有什么样的原因呢？
我们先看两个图，图2是抓取的一个在西藏做户外直播的主播的RSRP，也就是他的参考信号接收强度，这代表的就是他的无线接收强度的信息。
可以看得到，有一半的情况下，这个主播一定是开播质量非常糟糕。因为它的RSRP很多时候都低于-110dBm，这个时候的网络会很差。
图2: 主播RSRP显示图
图3是在公司找的一个角落里测的一个图。
那个角落的信号强度不是特别好，而且不知道为什么，还存在很强的上行的干扰，所以会导致上行的传输误码比会很高。
然后呢，手机肯定会把发送功率调大。一直增大、增大，最后到了23dBm，也就大概对应着200毫瓦的功率，几乎已经是国家规定的手机最大发射功率。
这个时候最大上行带宽是多少呢？才0.1mbps。
图3: 测试信号相关结果图
这是两个例子，对于我们的接收网络来说还有很多不同原因。
比如大家在地下室里面就会体会得到，信号很弱。还有一种信号不弱但是周围干扰比较强，噪声比较大，这是强干扰的情况。
还有就是我们可能信号也很好，也没有干扰，但是网络是拥塞的。比方说在一个万人演唱会或者是几万人的体育场，那么多观众，这个时候就几个基站的覆盖，往往不能支持几万人的正常使用。
还有一种是限速，很多主播或者观众用的流量非常夸张。哪怕是无限流量套餐，它也会有一个流量阈值。过了这个阈值，就会被运营商限速，很多时候每秒钟不能超过1Mbps。
最后是一个乱序的问题，乱序是怎么产生的？
比如5G、4G用了MIMO和HARQ的技术；如果我们的RLC层或者PDCP层没有做一些按序递送的操作，那最后上层拿到的东西就有可能是乱序的。
上述这些五花八门的原因导致什么结果？
导致了业务需求和可用带宽的供给两者之间存在比较大的矛盾，简单来讲就是供需矛盾。
既然存在供需矛盾，我们的解决方案是什么呢？要么扩大供给，要么就是把需求给缩减。
3.
应对思路一：扩大供给（开源）
3.1 多接入（Multi-Access）
现在看一下扩大供给，就是开源节流的开源逻辑，会有哪些方案？
一个是多链路的接入，还有QoS机制，再一个就是网络切片（大家可能多多少少听说过这个名词，叫5G网络切片）。
还有另外一种，虽然成本很低但是见效非常好的，那就是简单升级一下你的设备和通讯标准。
我们会一个个去稍微讲细一点。
图4是5G的ATSSS（ Access Traffic Steering, Switching and Splitting，接入流量转向、交换和分担）的一个示意图。
图4: ATSSS示意图
实际上更多想表现的是，针对一个终端，我可以通过WIFI和运营商的5G网络或者4G网络同时接入运营商的网关，再通过一些去重的操作，再达到一个比较可靠的传输链路。
这个在实现上本身分了两种，一个是Low Layer，另一个是基于MP-TCP（MultiPath-TCP），但是这两个东西实际来说对应用层是不可见的。
我跟很多运营商的朋友有交流过，因为其实我自己也挺想用那个技术。
但是挺遗憾，我得到的反馈是，运营商不太可能会去开放这个能力给我们用。
但是，我们不妨参考这个3GPP定义的能力，去把这个想法转移到我们的应用上去。
在3GPP定义之前，很多人也已经做过了一些MIFI设备、多链路聚合的设备或者WIFI、4G聚合的设备，这样做的好处是什么呢？
就是一路如果不行了，不管是它的网络不通还是带宽不够，两路三路四路总归是OK的。
利用APP主导的多链路接入，以保证上行的稳定性，是比较常见的做法。
比如说，如果传输的要求比较高，从一路移动的线路再加上电信、联通的线路，三路上去传输的是同一份数据，总比单路传输可靠的。
还有就是通过厂商提供的API，在应用层调用Wi-Fi/4G/5G双链路接入技术。
图5: ATSSS的多链路聚合
3.2 无线QoS
QoS（服务质量）是一个比较古老的话题，我大概2000年的时候做IP QoS的时候就接触过这个东西。
下图这个是3GPP定义的5G的一个QoS的架构。和4G不同的地方在于：4G需要建立多个专用承载为UE提供具有不同QoS保障的业务。
图6: 无线QoS图
但是5G里面不同的QoS，会把它放在同一个PDU的会话里面。然后再通过PCC的QoS rules，把不同的IP流映射到不同的QoS Flow里面，然后不同的QoS Flow再映射到不同的DRB里面，不同的DRB有不同的优先级的处理。
大家会想QoS的效果怎么样？先拿两个五六月份做的例子看一下。
这个例子是一个主播，这是它的帧率。额定帧率大概是每秒24帧，但这个主播开始启用QoS之前，它的上行帧率非常糟糕，这个情况下视频基本不可用，卡得非常厉害。
图7: 上行帧率
当把QoS打开了之后，整个上行的帧率变得比较理想，这是一个例子。
还有一个例子：在打开QoS之前，这个主播上行的RTT非常非常的差。
理论上来讲，我们会觉得百毫秒以下是比较理想的上行延迟，而这个用户是几秒钟的级别。
可以看到，当我们打开了QoS之后，整个传输质量得到比较明显的改善。
图8: 启用QoS对比图
● 无线QoS：存在的问题
你可能会想，QoS这么好的效果，为什么没有听到业界说有非常大规模的应用呢？特别是无线的QoS。是因为它其实还是存在一些问题。
什么问题呢？
就是接下来的第一个图所示，我刻意没有标哪个是成功率，哪个是失败率或者失败是什么原因。
我只想告诉大家说，现在成功率还是一个问题。这个成功率里面，失败率里面有一个非常大的占比，就是右边那个图的橙色部分，某些运营商在某些省或者城市里面它的支持还不够。这是一个QoS现在使用的失败率很高的主要原因。
图9: 成功率饼状图
第二个原因是什么呢？
我们使用了QoS之后，如果发现了网络的问题，我们想去排查，发现困难非常大，因为链条很长，我得去跟运营说我这个QoS打开了，你也反馈说开通成功了，最后为什么质量还是那么差；但查了半天，有可能会不了了之。
所以说这个排查难度比较大，因为它不完全受控于应用层。
大规模应用的另一个障碍是网络本身负载就高，特别是在4G的时候，5G可能还好，5G整个网络还是比较轻载。
比如说4G在广州地区，整个网络负载就非常重，这个时候如果要求把一部分流量再分给要求更高的视频，对于运营商来说非常吃力。
此外，如果大家是做网络，也会比较好理解，那就是无线的覆盖对QoS的效果会有比较大的影响。
如果我的信号很差，就算你给我最高的优先级，我也没有办法传更多的数据。
另外一个，就是GBR和MBR关系的问题。
这里GBR是指保证比特速率，MBR是最大比特速率。理论上说我开通QoS服务，运营商应该给我保底的GBR，比如说4M每秒的流量给我，MBR的流量应该更高，网络一旦空闲，给我10M、20M理论上都是不过分的。
但是，往往在实践中运营商给的GBR和MBR是一样的！
这会导致什么呢？
导致我的一些应用特别是视频应用在有码率突变的时候，这个GBR和MBR的限定就特别难受。比如我的编码是VBR，我的编码码率抖动是非常厉害的。
所以说，QoS这个东西在概念上已经说了很多年，在实现上特别是无线的实现上在应用上，还是有一些不太成熟的地方，当然用还是可以慢慢用起来的。
3.3 5G网络切片
再来说一下大家应该听到比较多的5G网络切片。
下图也是3GPP定义的一个示意图。
切片的概念是什么呢？无非是把一个物理的网络把它隔离成多个逻辑上相互独立的网络，使得可以独立运维，质量也互不影响，比如说切片A不会受切片B的影响，这是切片的概念。
这在2B的场景大家听得比较多，例如我们可以给政府机关，或者军方、警方单独开放一个切片出来。
图10: 网络切片示意图
但是在我们2C的场景会怎么样？
在2C场景下，我们用到一个URSP的规则，这个规则URSP是用户设备路由选择策略的规则。
它是根据流量的特征来把你的流量映射到相应的PDU会话。简单来讲符合流量特征A的映射到切片A，符合流量特征B的映射到切片B。
这个映射关系怎么确定呢？通常是根据我的APPID或者是访问的域名或者是IP的三元组或者是APN（在5G我们叫DNN），我不知道大家在有没有在手机上设过APN，现在中国移动大概能用的就是Internet或者MMS的APN。
图11: URSP规则
我们在2B的时候可以讲切片讲得比较多，2C的时候基本上没法去用。问题是什么呢？
因为到现在为止，我的手机操作系统和MODEM、还有应用层之间根本没有打通。
所以如果有人跟你吹，说他在2C的时候很好的用了切片，不管是云游戏还是其它场景，大概率是在吹牛。
比如说APPID的定义，现在都没搞清楚，对于安卓来说到底APPID是一个PackageName，还是PackageName加签名，还是应用市场APPID，现在都没有统一起来。
此外，操作系统也没有任何接口给你设置这些东西，操作系统就算提供了接口，操作系统和MODEM之间的传递谈妥了吗？好像也没有完全谈妥。
这是现在导致我们在2C领域，比如我们用一个手机想去接入某个切片的时候很大的问题。
然后我附这个图是什么呢？是前段时间我突然发现，安卓12冒出了对URSPRule的支持，也许意味着对安卓来说，安卓12才有机会把5G切片功能给用上去。
QoS与切片的使用建议（TOC场景）
不管是使用QoS还是切片，事实上我们想做的都是提升用户的接入质量。
这两个东西使用还是有一些讲究的。
比如说，最大的问题是什么呢？
不管是开通了QoS还是开通了切片，成本是一个非常大的问题。我肯定是希望我网络接入质量不够的时候，才会去打开QoS或者是使用网络切片。
其他时候就用普通的服务就OK了。
所以说，我觉得我们如果以后在用的时候，一定要考虑怎么动态的来开和关QoS或切片的问题。
另外，除了成本之外，还有我刚才提到的GBR和MBR关系的问题。
这里有一个实际例子，是吃鸡游戏的一个主播使用VBR编码的时候，因为画面的变动非常大，编码码率变化得也就比较大。
使用2M的编码码率，输出码率有时候会冲到8M或者10M。
这个时候如果申请QoS，在GBR和MBR相等的情况下，我申请的就不是2M或者4M，而是10M的码率，成本非常惊人。
图12: 码率变化图
所以说，对成本的考量，会决定我们一定是在有需要的时候才会去打开QoS或者切片。
至于怎么判断要不要打开、什么时候去打开或关闭QoS或者切片，也是有讲究的。因为时间的关系，今天就不细讲了。
3.4 设备或者技术的升级换代
在扩大供给方面，还有一个成本比较低的做法，那就是对我们的设备或者是我们的通信标准进行升级。
●设备或者技术的升级换代（1）：从4G到5G
比如说，我们从4G到5G的升级。
很多人都在谈5G，虎牙现在也有超过20%的用户是在使用5G的手机和网络。那么实际情况是怎么样呢？
总体来讲，从卡顿率的角度来看，使用5G的主播的质量不见得比4G有多大的提升，为什么呢？
我们分析到很多用户发现，其实5G的网络覆盖比起4G来说还是有一些差距。这是特别大的一个原因。
如果覆盖搞不定，那户外开播肯定没办法去做得很顺畅，这是一个问题。
第二个问题也比较普遍，是什么呢？
我们很多主播就是带宽，哪怕买了无限流量的，播了几天就超过了限速阈值，后面运营商给你最小的带宽，大概是700K~800K左右，不管是4G还是5G，优势体现不出来。
5G好歹投入那么大，我们看到好的地方是什么呢？
RTT方面看到5G在RTT方面稍微有一些优势。
比如说我们在同城的话，我们的4G移动终端和同城服务器之间大概是40毫秒这样的RTT。换到5G可能是20毫秒，RTT稍微会有一些优势。
另外一个就是在高码率的时候，5G的稳定性确实漂亮一些。
我们可以看到当码率升到4M或者8M的时候，使用4G来支撑开播，可用带宽或者RTT会比较抖，使用5G会好不少。
当然这个我不排除现在5G网络负载还比较轻的原因。
总体而言，5G要在这个行业要比较好的应用，我觉得它的覆盖还得进一步的加强。
相信以后如果随着VR或者其他大码率的直播出现，可能4G真的扛不住了。这个时候也许用5G替代4G的动力才会更足。
●设备或者技术的升级换代（2）：WI-FI
还有一个WIFI的事情。
我这里列了三个例子，这个绿色的线是指我们用户手机或者是移动终端到他们家WIFI网关之间的RTT。你可以看到，其实之间的距离可能就几米，但它的RTT就是几十毫秒或者几百毫秒。
图13: WIFI链路信息-用户A
用户A质量非常差，用户B是非常漂亮的，基本上就是两三个毫秒的RTT。
用户C是时好时坏，而且这个用户很典型，因为它的终端到WIFI-AP之间的质量跟观众能够感受到的视频质量完全是正相关的。
图14: WIFI链路信息-用户B
图15: WIFI链路信息-用户C
你会发现在主播C这个例子里面，如果改善了开播设备到他家里AP那段的通信，对这个场景来说，整个端到端就是非常漂亮的。
●设备或者技术的升级换代（3）：WIFI的代差
所以，我经常在不同场合讲，最简单的去把网络质量搞好的一个做法是：提示我们的用户，升级他的手机或者升级AP。
我在我家架了两个设备，一个是WIFI-4的网关，另外一个是WIFI-5的网关。
然后，我用两台手机去测，手机当时是空载的，空载的时候RTT会偏高，我估计空载的时候手机会降频。
但不管怎么样，从总体来看，WIFI-4的网关比WIFI-5的网关延迟会有相当的差距。
图16: 手机A和B的数据
这个差距有两方面的原因。
第一个，是WIFI-4的网关已经是十年前买的，处理器的能力肯定比现在的网关处理能力差很多。
另外一个，是WIFI代差的区别，WIFI-4和WIFI-5的代差，这个图可以明显看到差别很明显。
图17: WIFI网关信息数据
如果我们做直播平台，让我去帮用户升级他的网关或者手机，可能做不到，但是去提示他这个总该可以吧。
这个对平台方来说，可能是成本最低的，可以迅速把质量拉升上去的一个做法吧。
4.
应对思路二：减少网络消耗（节流）
我们讲完开源，再讲一下节流的事情。
节流我们可能听得比较多的是：“拥塞控制”，以及网络不行时的降帧率、降码率的措施。但这是被动的做法，它损伤的是视频质量和开播质量。
有一些偏主动的，或者说能够尽可能的不去降太多质量的做法，现在业界也在做。
比如说，我们要去研究6G的东西，6G提出来的是什么呢？其中有一项是语义通信，或者叫语义的提取、编码和通讯。
我们是希望它能够打破香农公式的极限，但其实不是打破，毕竟香农公式给出的是数据传输信道的容量极限，数据再上一层才是语义。
不管我们的1G到5G，我们做的都是数据的通信。我们能不能有一天让网络传输的是我们的意思而不是数据本身。
就意味着什么呢？意味着网络两端通信双方可能要有一些共通的知识库，针对数据的理解，再把它提取到语义，传输的是语义。
这有两个好处。一个有可能是传输量变得特别小。
第二个是什么呢？有可能我对纠错的算法有不同的做法。这个是这一两年业界逐渐在考虑的东西。也有人想把它推到物联网那边去，大家可以关注一下。
还有一个是基于AI的编解码算法。例如大家应该听说过谷歌的Lyra，声称是3kbps可以达到比较流畅的语音交互，这样一来对网络的依赖就减轻了很多。
当然还有其他的一些做法，像虎牙用得比较多的是服务端的超分。
我可能上行的时候上去的码率比较低，但我做一个漂亮的超分之后，会让整个画质得到比较好的增强，下发给观众端更清晰的画面。
总的来说，如果管道不够好的时候，千方百计想怎么去提升它所传输的数据的表达效率，以此达到最终质量不会降得特别多的结果。
5.
“古老”的话题：带宽估计
不管是开源还是节流，其实特别依赖同一个东西。我必须得清楚地知道当前网络发生了什么，当前网络到底有多少带宽是可以用的。
如果带宽不够的时候，我可能要去申请用更多的带宽，这时候想方设法做开源；或者当谋求不到更多资源的时候，这个时候得考虑节流。
它的基础是必须要对现在网络状况有比较好的预测和估计，这就是带宽估计的逻辑。
带宽估计的概念，或者带宽预测的概念，也是比较古老的问题。
在实时音视频方面，有GCC等类似的算法，也有人在研究的基于AI的带宽估计算法，这方面的探索一直在做，而事实上做得比较好的也没有几家。
BBR对文件传输类比较好，但是应用于音视频通信就比较差强人意，实时或准实时音视频对带宽估计的要求比文件传输要高。这一块每家还得继续去再发力。这个话题可以作为一个专题来讲，今天不展开。
我大概讲一下我们的做法。
我们基于吞吐率、RTT以及丢包率，再加上我们对一些特定的模式的判断，还有引入应用层等方面的跨层信息，构建了针对视频传输的带宽估计的算法，测试结果还算是比较让人满意。
图18: 带宽估计
时间关系，我就不细说了。
带宽估计还有另外一个思路，我们为什么要估计？因为我们不知道网络上发生了什么。但是有人是最清楚网络上到底发生了什么的，运营商就有很多的信息。
他知道这个基站现在所有用户上行信道质量是什么样的，有多少PRB可分配，有多少用户是要优先处理的。
这些信息，运营商或者基站它是知道的。如果哪一天把信息开放出来了，对整个带宽估计会有很大的作用。
比如我现在有一个安卓手机，我想方设法的去采集一些RSRP或SINR的数据，但是对苹果手机完全没有任何这方面的信息，因为苹果不给。
如果运营商开放一个接口出来，把无线信道信息和PBR分配的信息给我，哪怕不直接告诉我有多少带宽，自己能大致能推导出来，这个上行可以达到多少带宽。
我觉得这是带宽估计最靠谱或者说是最简单的一种做法，我们现在用很多的方法去做估算、做滤波，做人工智能的训练，如果结合运营商的数据可能会更精准。
6.
无线网络的优化的其他方案
当然，无线网络优化还有一些其他的措施。
我们知道边缘计算会导致非常多的海量数据产生，如果不能把数据都传上网的时候，能不能做一些本地卸载的东西？
事实上是有很多的，比方说，4G已经定义了LTE-Direct，5G的时候叫D2D，主要看你有什么应用场景。
D2D意味着我两个用户的通信的数据通道不会再依赖于基站，而是直接点到点的两个设备之间的通讯，但是用的还是运营商的频谱。
还有另外一个事情，就是无线是有广播的特性，可以想想怎么用好广播的特性。
比如我以前想的例子，在大规模赛事直播的情况下，完全可以用多媒体多播广播系统（MBMS）来发送信号。
我只是在广播信道发送了一路视频，所有用户去监听该广播信道，他就可以看到同样的视频。
当然，前提是这个基站下是希望看同样视频的人足够多，广播的特性或者优势才能够体现出来。
还有一个，实在没办法了，我解决不了，那就绕过去。
我最近去看一些LoRa或者类似无线技术的东西，发现还挺好玩的。它的速率在国内被限制到不超过5kbps，但是你会发现基于LoRa的对讲机做得非常小，但是通话距离又蛮大。
在一些物联网的场景，当NB-IOT和CAT1不适合的时候，也许我们能够去考虑其他的方案。LoRa只是一个例子。
7.
总结和展望
刚才讲的无线接入网络，尤其是4G/5G的接入网络，是端到端网络里面总体来讲质量比较差的一段，差到什么程度？
我们有一个数据：在使用4G的虎牙主播里，上行质量不好的主播占比会超过10%。而其中因为信号不好导致了质量差的占比是多少呢？
只占了20%。
也就是说，质量差的4G主播里面，有80%左右的比例是网络拥塞或者限速或者其他非覆盖原因导致。
所以，这一块可优化空间还是蛮大的。
我们刚才谈到的主要从开源和节流两方面去谈优化思路。
“开源”大致对应着运营商经常讲的“网随业动”，我的网络要随着业务来变动，如果业务需求量大，网络供给变得更大一些，这是运营商的底层逻辑。
但是我们在2C场景下做，就得在业务层做这个事情。
如果是网络没法给我提供更多的带宽，这时候做的就是节流或者是“业随网动”，网络给了你多少带宽，你的业务就跟着网络带宽的供给来变化。这个逻辑大家都比较清楚。
开源节流的一个基础是精准的带宽估计。
这个话题挺有意思的，我原来一直觉得带宽估计这个事我做起来应该不难。但是后来发现理论上还行，真正在工程上去做一个对音视频非常准的带宽估计，还有很多工作去做。
我们再展望一下，不管是正在慢慢起来的5G或者是2030年的6G，我们这个优化的思路还会不会存在？
现在6G大家都在考虑，比如我们的可见光通信、我们的太赫兹、我们的陆海空全域覆盖。
这些都是不断把我们的管道做大的一些措施，因为我们大家都能看得到，随着物联网还有其他一些诸如XR业务的兴起，流量越来越大，对管道的需求也会越来越大。
当然，应用的需求也会跟着越来越大，所以流量治理和优化的需求一定还会存在，也仍然存在一些不同优先级的业务，怎么去跟其他业务去抢占的问题。
所以我认为，刚才讲的那些开源节流逻辑还是存在。
另外节流那一块，我个人对AI和语义通信这两个领域比较感兴趣一些。在座如果有人是做音视频和做传统网络相关的话，这些领域可以关注一下。
顺便说说MEC。
大家应该听到别人跟你，灌输MEC边缘计算的各种好处，车联网怎么受益于MEC的东西。大家有没有想过一个简单的问题，联通的车怎么跟移动的车通信？
在同一个运营商里面，UPF可以下沉到地市，也可以在UPF旁边建一个MEC，这对于运营商来说没问题。
但两个运营商之间的MEC怎么对通，需要经过全国那十几个互联节点吗？
进一步地，算力等资源如何调度和分配，以及是通过边缘容器还是边缘FAAS服务来承载，算力节点之间如何通信等等，其实都是会影响到整个产业真正落地的一些点。
存在着一个趋势，就是资源的融合，且它可能会再进一步的得到增强。这个资源包含云和网的资源。
这个趋势对网络治理的要求同样值得我们关注。
谢谢大家！
—— 全文完 ——
