基于CCA的云游戏平台系统设计
2023-03-08金安
金 安
(上海爱奇艺新媒体科技有限公司,上海 200050)
0 引言
云游戏是一种以云计算技术为基础,将游戏放在云端服务器运行的在线游戏,其本质是在线交互性流媒体。在云游戏模式下,游戏的存储、计算、渲染等均可在云端完成,用户可以通过任意终端体验到高品质游戏,而终端设备只需具备基本的流媒体播放和向远端发送指令的功能。
近两年,随着GPU、虚拟化、5G 和边缘计算等多种云游戏相关的核心技术得到突破,特别是元宇宙话题的兴起和破圈,国内外互联网企业纷纷布局云游戏。作为5G 高新视频新兴业务的排头兵,云游戏发展迎来新的机遇。然而,云游戏仍面对诸多困难和技术挑战,业界认为目前云游戏行业仍处于起步阶段,并未形成业界公认的最佳实践,云游戏技术还未形成广泛接受的标准体系架构[1]。为此,文献[2]从云游戏的概念、发展状况、关键技术、端到端解决方案等方面对文献[3]进行了详细解读。为降低企业客户实现云游戏产品的技术门槛,文献[4]在阐述云游戏技术基本原理的前提下,基于阿里云成熟的云计算基础设施体系,设计了一种云游戏PaaS(Platform as a Service)平台,为企业客户提供了快速搭建全场景云游戏产品的功能。文献[5]在自身开展云游戏业务的前提下,从内容生态、业务平台、承载网络与业务终端等方面结构性地提出了云游戏规模化商用的措施和方案,为其他云游戏企业提供了良好的借鉴思路。针对如何降低网络延时从而提高游戏服务质量的问题,文献[6]对5G 网络向边缘节点的分流方式和策略智能化进行了深入研究,并对边缘节点算力需求定制与异构化进行挖掘,从而制定了一套缓解云游戏网络延时的流程;文献[7-8]从不同角度提出各提出一种基于边缘计算的云游戏服务质量增强方法,前者在边缘节点上实现了一套压缩图形的云游戏系统,在降低边缘节点计算负载的同时有效减少了云到端网络的延时;后者为使用户减少网络带宽消耗,在运用边缘计算的基础上提出集群区域划分算法与服务器集群选择算法,从Peer-Sim 工具模拟边缘计算环境来看,该方案可减少延时18~20ms。
然而,以上文献大多从模拟环境、B 端等方面提出云游戏平台系统的设计或优化方案,并没有真正地与C 端业务紧密结合而持续优化,应用于云游戏商用场景中的效果可能会不太尽如人意。本文以某互联网企业为例,介绍云游戏平台系统框架与体验评估模型,针对业务内测中出现的延时原因进行了剖析,继而深入研究了帧率拥塞控制(Congestion Control Algorithm,CCA)算法和代码实现,最后列举了优化后的性能数据。
1 云游戏平台系统框架与体验评估模型
1.1 云游戏平台系统框架研究与设计
从云游戏业务商业化运营角度出发,通过分析云游戏活动的参与角色、构成要素、生命周期及其活动行为,可得出云游戏业务每个阶段涉及的功能点,从而提炼出云游戏各要素的功能架构[9]。本文中,云游戏平台系统框架由基础服务层、中台服务层、运营业务层和业务场景层构成[10-11]。该系统框架整体设计如图1所示。
Fig.1 Cloud gaming platform system architecture图1 云游戏平台系统框架
1.1.1 基础服务层
云计算平台主要用于提供基础计算、存储、网络资源。搭载云游戏的计算与存储载体主要由X86 和ARM(Advanced RISC Machine)两种服务器组成,两者都具有标准化程度高、硬件稳定和集群维护简单等优点。同时,通过虚拟化技术可对CPU、存储、GPU 等资源进行资源共享和最大化利用,并使资源的安全性得到强化。
1.1.2 中台服务层
中台服务层向上提供了应用流化能力支撑,向下封装了业务所需的系统环境,主要包括高性能渲染能力、低延迟流化服务、游戏容器管理、业务服务与推拉流能力等。该层是整个云游戏平台系统的核心所在,也是业务能否取得成功的技术关键。
1.1.3 运营服务层
运营服务层在基础与中台服务层之上,将业务场景抽象和流程化,通过编排系统软件与业务运营系统向用户与后台管理方提供云游戏业务的能力支撑,包括账号登录计费服务、订单管理和活动中心管理等。
1.1.4 业务场景层
业务场景层通过云端协同,对不同客户端展现云游戏、广告试玩与直播互动等场景服务,最大化程度地丰富企业的云游戏平台系统产品。
1.2 云游戏体验评估模型
云游戏内容质量和用户体验是业务商业化是否成功的关键所在,如何准确有效地评测用户在云游戏中的实际体验是业务商业化需要持续解决的问题。也就是说,建立科学合理的云游戏质量评估模型已经成为促进业务健康发展的迫切需求之一。
根据国际电信联盟文献标准[12-15],从游戏的广义程度来说,影响移动游戏体验质量QoE(Quality of Experience)的因素包含用户、系统和内容三大方面,进一步可以分解为用户影响因素4 小类、系统影响因素17 小类和内容5 小类,总计20 多项。由于云游戏技术尚处于发展阶段,当前并不具备将所有影响因素及KPI 指标纳入到体验评估范畴的条件,考虑到云游戏的流媒体特性并参考上文中提到的移动游戏影响因素,结合性能参数可获取、指标可测量的原则,本文主要选取分辨率、帧率、码率、延时、交互等指标作为云游戏体验评估模型输入参数,将游戏视听质量、交互感觉和产品体验等信息作为评估模型的输出结果。
本文在部分参考文献[12-15]中移动游戏测试模型的基础上对云游戏建模进行了可行性分析,采用模型分级映射的方式,尽量简化测试环节并避免结果失真,试图建立云游戏QoE 评估模型。具体的云游戏QoE 评估模型框架如图2所示。
Fig.2 Cloud gaming QoE evaluation model图2 云游戏QoE评估模型
其中,视听体验质量O.21 由画面与音频质量构成,主观上代表了用户体验云游戏时的视听等感官感受,具体客观指标则由分辨率、帧率、码率、编码参数等组成。考虑到最大化覆盖原则,评估模型将内容源与终端能力对应指标的最低值I.11、I.12和I.13作为实际输入参数。交互体验质量O.22 主要用于评价用户操作与网络传输延时中碰到的体验失真,具体游戏中的表现为延时抖动、丢包导致的卡顿花屏等,导致用户游戏体验不佳,输入参数为I.14 和I.15。云游戏产品体验质量O.23 与日常用到的软件涉及点大多一致,体现了用户使用云游戏产品全流程的体验保证,输入参数分别为I.16、I.17 和I.18。O.31 定义为云游戏综合体验质量,由输出信息O.21、O.22、O.23 构成,具体可用公式模型O.31=f(O.21,O.22,O.23)描述。其中,为充分体现综合体验质量的数据准确性,3 个子项的评估模型均基于用户游戏体验行为大于5min 的会话场景。由于篇幅原因,这里主要对评估模型进行了逻辑关系梳理,不再对云游戏QoE 评估算法进行阐述与详细的公式推算。
2 云游戏平台系统端到端延时优化
2.1 延时原因分析
根据客户端与服务器交互需求程度的不同,面向移动移动网的云游戏大体可以分为弱交互类、中交互类与强交互类三大类。业界的一些真机通用数据表明,对于强交互类游戏,例如FPS(First Person Shooting Game)、MOBA(Multiplayer Online Battle Arena)与RCG(Racing Game)等游戏,如果端到端延时超出100ms,用户游戏体验下降会比较明显;中等交互类游戏,例如RPG(Role-Playing Game)游戏,一般端到端延时在150ms 之内;而对于卡牌、SLG(Simulation Game)等弱交互类游戏而言,端到端延时即使在200ms,用户也感觉不到卡顿。
云游戏端到端延时是指云游戏运行过程中,用户对终端进行触控操作到游戏画面在终端上产生相应响应的时间差,通常由终端响应、主机端响应与网络推拉流等延时构成。如图3 所示,通过全国各地定点收集大量数据发现,该系统在内测期间的端到端延时平均达到220ms,用户反馈体验不佳,主要耗时发生在主机端响应与推拉流、播放性能阶段,相较于普通网络游戏延时分别增加85ms 与90ms左右,只能勉强符合弱交互类游戏体验。
为了对云游戏延时进行更好的代码优化,将业务响应阶段继续细分成以下12个详细步骤[16-18],见图4。
Fig.3 Sketch map of end-to-end latency stage图3 端到端延时阶段示意图
Fig.4 Detailed breakdown diagram of end-to-end latency steps图4 端到端延时步骤详细分解图
除步骤2-4 外,其余均为游戏云化带来的额外延时,因此这些步骤将作为云游戏延时优化的重点。进一步分析发现,原先的RTC 主机与播放器终端均未针对网络状况进行帧率发送动态调节,导致弱网情况下延时增加,故本文对基于WebRTC(Web Real-Time Communication)协议的帧率拥塞控制CCA 算法[19-22]进行了深入研究和代码实现,以减少推拉流过程中的网络延时。
2.2 帧率拥塞控制算法
该算法的中心思想为丢包率反映帧率拥塞状况。如果丢包率很小或者为0,说明帧率发送状况良好,在不超过阈值帧率的情况下,可以增大帧率发送;反之,说明帧率拥塞严重,此时应减少帧率发送。在其他情况下,帧率不变。
为准确计算网络延迟梯度,引入时延梯度变化di用于评估时延增长趋势,以判断帧率拥塞程度,从而避免发送端给网络传播延迟估计带来的误差,计算公式见式(1)。其中,ti-ti-1为帧率到达时间差,Ti-Ti-1为帧率发送时间差。
当发送链路存在拥塞,图5 中虚线标红到达的帧率经过路由器(Router)节点时排队等待,导致到达时间比原本要晚,延迟梯度d1=(t1-t0)-(T1-T0) >0。因此,延迟梯度可以作为帧率拥塞的指标。为了增加准确性,将一段时间内的帧率数据包组的延迟梯度累加、平滑、回归,最终得到延迟梯度的趋势用于判断是否拥塞。为了易于代码实现,CCA 算法可简化为指数平滑和最小二乘法线性回归算法。
采用指数平滑法(Exponential Smoothing)计算累计延迟梯度的原理为某时刻的指数平滑值为该时刻实际观察值与上一时刻指数平滑值的加权平均,具体如公式(2)所示。其中,St为t 时刻指数平滑趋势预测值,yt-1为t -1 时刻实际观察值,α为指数平滑系数。从公式得出,α按等比级数减少,在WebRTC 帧率拥塞控制场景中,由于时间序列对结果具有比较大的变动倾向,α建议取0.9。
Fig.5 Frame rate congestion图5 帧率拥塞
线性回归可进行时延梯度趋势预测,通过最小二乘法求得拟合直线斜率,最终可以根据斜率获得时延的增长趋势。假设拟合曲线 y=ax+b,对于一堆样本(x,y),可以推导出斜率a,具体如公式(3)所示。a 可用于表示图5 中Router队列的增长状况。
式中,输入样本点为(实际到达时间,累计延迟梯度平滑值),输出为延迟梯度变化趋势斜率a。
为改变时延梯度的敏感度,需要采用公式(4)、(5)获得动态调整帧率阈值H(ti)用于帧率过载判断。
式中,ΔTi表示距离上次阈值更新经历的时间,I(ti)表示帧率排队输入延迟,常数kd表示决定阈值增加的速度,建议数值为1.8×10-4;ku表示决定阈值减小的速度,建议数值为1×10-2[20]。
2.3 算法实现
从上文算法得知,需要获得时延梯度增长趋势并与动态帧率阈值比对来判断当前的网络状态是否饱和,然后采取下一步帧率的发送动作。其中,时延梯度趋势斜率a 由指数平滑法和最小二乘法线性回归预测求得,进而根据公式(2)求得帧率排队输入延迟I(ti),本文中代码不再描述。结合当前阈值 H(ti)、设定时间阈值(Time of Duration,参考文献[20]设置为10ms)和输入延迟I(ti),判断当前帧率发送是否拥塞。判断算法的伪代码为:
当帧率排队输入延迟I(ti)大于当前阈值 H(ti)时,计算当前延迟状态的持续时间TOD,如果持续时间TOD 大于设定时间阈值,并且延迟输入持续增加,系统需发出拥塞信号,同时重置持续时间TOD;如果延迟输入持续减少,说明帧率拥塞缓解,无需重置状态。当帧率排队输入延迟I(ti)小于阈值 H(ti)负值时,说明当前帧率发送处于空闲状态,系统发出空闲信号,发送端可以增加帧率发送。其他情况下,算法认为帧率发送适中,系统可以保持当前状态不变。
3 云游戏平台系统性能数据分析
某企业的云游戏业务在短暂内测后于2021 年12 月进行商业化运营,平台初期上线100 台高性能鲲鹏920 ARM服务器,虚拟化成3000 台云手机,同时上线200+款手游,最高支持1080P@60fps(Frames Per Second),游戏业务场景为广告试玩与云游戏中心等。
根据上文体验评估模型输出结果,云游戏平台系统核心的用户体验主要包含游戏延时、卡顿比与故障率等,通过监控2022 年1-3 月中旬数据获得图6~图8 结果。可以看出,端到端业务延时、卡顿比与故障率等数据指标曲线整体呈下降趋势。其中,春节期间由于访问用户量大导致数据有短暂波动,延时、卡顿比与故障率分别回升到143ms、8%与5.6%左右,后续数据分别稳定在100ms、4.13%与1%上下。图中3 月5-6 号,图6~图8 的曲线毛刺凸起是由于版本升级上线的系统bug导致。
通过实现监测帧率拥塞状况对发送码率进行动态调节后,在主机端响应与推拉流、播放性能阶段,延时从85ms 与90ms 左右下降到27ms 与32ms 左右,且图6 的总延时曲线也呈下降趋势,说明本文算法取得了良好效果,因此该企业的云游戏平台系统已符合市面上绝大多数游戏的上线要求。
4 结语
Fig.6 End-to-end service latency图6 端到端业务延时
Fig.7 Frame drop rate图 7 卡顿比
Fig.8 Fault rate图8 故障率
国内的5G 基础建设正在如火如荼的进行当中,云游戏作为5G 产业中重要的商业云应用场景,必将推动该产业的迅速发展。某企业的云游戏平台系统已经向用户提供服务,随着技术的预研深挖、端云协同,该平台将支撑更多业务场景,从而驱动成本降低,提升用户体验。当然,该平台还存在一定不足,如何将简化后的WebRTC 构建成为一个成熟稳定且扩容度高的框架,以及如何通过编码升级、带宽复用[23]等技术进一步降低用户成本都是后续需要解决的重点问题。