金 安

（上海愛奇藝新媒體科技有限公司，上海 200050）

0 引言

云游戲是一種以云計(jì)算技術(shù)為基礎(chǔ)，將游戲放在云端服務(wù)器運(yùn)行的在線游戲，其本質(zhì)是在線交互性流媒體。在云游戲模式下，游戲的存儲(chǔ)、計(jì)算、渲染等均可在云端完成，用戶可以通過任意終端體驗(yàn)到高品質(zhì)游戲，而終端設(shè)備只需具備基本的流媒體播放和向遠(yuǎn)端發(fā)送指令的功能。

近兩年，隨著GPU、虛擬化、5G 和邊緣計(jì)算等多種云游戲相關(guān)的核心技術(shù)得到突破，特別是元宇宙話題的興起和破圈，國內(nèi)外互聯(lián)網(wǎng)企業(yè)紛紛布局云游戲。作為5G 高新視頻新興業(yè)務(wù)的排頭兵，云游戲發(fā)展迎來新的機(jī)遇。然而，云游戲仍面對(duì)諸多困難和技術(shù)挑戰(zhàn)，業(yè)界認(rèn)為目前云游戲行業(yè)仍處于起步階段，并未形成業(yè)界公認(rèn)的最佳實(shí)踐，云游戲技術(shù)還未形成廣泛接受的標(biāo)準(zhǔn)體系架構(gòu)［1］。為此，文獻(xiàn)［2］從云游戲的概念、發(fā)展?fàn)顩r、關(guān)鍵技術(shù)、端到端解決方案等方面對(duì)文獻(xiàn)［3］進(jìn)行了詳細(xì)解讀。為降低企業(yè)客戶實(shí)現(xiàn)云游戲產(chǎn)品的技術(shù)門檻，文獻(xiàn)［4］在闡述云游戲技術(shù)基本原理的前提下，基于阿里云成熟的云計(jì)算基礎(chǔ)設(shè)施體系，設(shè)計(jì)了一種云游戲PaaS（Platform as a Service）平臺(tái)，為企業(yè)客戶提供了快速搭建全場(chǎng)景云游戲產(chǎn)品的功能。文獻(xiàn)［5］在自身開展云游戲業(yè)務(wù)的前提下，從內(nèi)容生態(tài)、業(yè)務(wù)平臺(tái)、承載網(wǎng)絡(luò)與業(yè)務(wù)終端等方面結(jié)構(gòu)性地提出了云游戲規(guī)?；逃玫拇胧┖头桨?，為其他云游戲企業(yè)提供了良好的借鑒思路。針對(duì)如何降低網(wǎng)絡(luò)延時(shí)從而提高游戲服務(wù)質(zhì)量的問題，文獻(xiàn)［6］對(duì)5G 網(wǎng)絡(luò)向邊緣節(jié)點(diǎn)的分流方式和策略智能化進(jìn)行了深入研究，并對(duì)邊緣節(jié)點(diǎn)算力需求定制與異構(gòu)化進(jìn)行挖掘，從而制定了一套緩解云游戲網(wǎng)絡(luò)延時(shí)的流程；文獻(xiàn)［7-8］從不同角度提出各提出一種基于邊緣計(jì)算的云游戲服務(wù)質(zhì)量增強(qiáng)方法，前者在邊緣節(jié)點(diǎn)上實(shí)現(xiàn)了一套壓縮圖形的云游戲系統(tǒng)，在降低邊緣節(jié)點(diǎn)計(jì)算負(fù)載的同時(shí)有效減少了云到端網(wǎng)絡(luò)的延時(shí)；后者為使用戶減少網(wǎng)絡(luò)帶寬消耗，在運(yùn)用邊緣計(jì)算的基礎(chǔ)上提出集群區(qū)域劃分算法與服務(wù)器集群選擇算法，從Peer-Sim 工具模擬邊緣計(jì)算環(huán)境來看，該方案可減少延時(shí)18～20ms。

然而，以上文獻(xiàn)大多從模擬環(huán)境、B 端等方面提出云游戲平臺(tái)系統(tǒng)的設(shè)計(jì)或優(yōu)化方案，并沒有真正地與C 端業(yè)務(wù)緊密結(jié)合而持續(xù)優(yōu)化，應(yīng)用于云游戲商用場(chǎng)景中的效果可能會(huì)不太盡如人意。本文以某互聯(lián)網(wǎng)企業(yè)為例，介紹云游戲平臺(tái)系統(tǒng)框架與體驗(yàn)評(píng)估模型，針對(duì)業(yè)務(wù)內(nèi)測(cè)中出現(xiàn)的延時(shí)原因進(jìn)行了剖析，繼而深入研究了幀率擁塞控制（Congestion Control Algorithm，CCA）算法和代碼實(shí)現(xiàn)，最后列舉了優(yōu)化后的性能數(shù)據(jù)。

1 云游戲平臺(tái)系統(tǒng)框架與體驗(yàn)評(píng)估模型

1.1 云游戲平臺(tái)系統(tǒng)框架研究與設(shè)計(jì)

從云游戲業(yè)務(wù)商業(yè)化運(yùn)營(yíng)角度出發(fā)，通過分析云游戲活動(dòng)的參與角色、構(gòu)成要素、生命周期及其活動(dòng)行為，可得出云游戲業(yè)務(wù)每個(gè)階段涉及的功能點(diǎn)，從而提煉出云游戲各要素的功能架構(gòu)［9］。本文中，云游戲平臺(tái)系統(tǒng)框架由基礎(chǔ)服務(wù)層、中臺(tái)服務(wù)層、運(yùn)營(yíng)業(yè)務(wù)層和業(yè)務(wù)場(chǎng)景層構(gòu)成［10-11］。該系統(tǒng)框架整體設(shè)計(jì)如圖1所示。

Fig.1 Cloud gaming platform system architecture圖1 云游戲平臺(tái)系統(tǒng)框架

1.1.1 基礎(chǔ)服務(wù)層

云計(jì)算平臺(tái)主要用于提供基礎(chǔ)計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)資源。搭載云游戲的計(jì)算與存儲(chǔ)載體主要由X86 和ARM（Advanced RISC Machine）兩種服務(wù)器組成，兩者都具有標(biāo)準(zhǔn)化程度高、硬件穩(wěn)定和集群維護(hù)簡(jiǎn)單等優(yōu)點(diǎn)。同時(shí)，通過虛擬化技術(shù)可對(duì)CPU、存儲(chǔ)、GPU 等資源進(jìn)行資源共享和最大化利用，并使資源的安全性得到強(qiáng)化。

1.1.2 中臺(tái)服務(wù)層

中臺(tái)服務(wù)層向上提供了應(yīng)用流化能力支撐，向下封裝了業(yè)務(wù)所需的系統(tǒng)環(huán)境，主要包括高性能渲染能力、低延遲流化服務(wù)、游戲容器管理、業(yè)務(wù)服務(wù)與推拉流能力等。該層是整個(gè)云游戲平臺(tái)系統(tǒng)的核心所在，也是業(yè)務(wù)能否取得成功的技術(shù)關(guān)鍵。

1.1.3 運(yùn)營(yíng)服務(wù)層

運(yùn)營(yíng)服務(wù)層在基礎(chǔ)與中臺(tái)服務(wù)層之上，將業(yè)務(wù)場(chǎng)景抽象和流程化，通過編排系統(tǒng)軟件與業(yè)務(wù)運(yùn)營(yíng)系統(tǒng)向用戶與后臺(tái)管理方提供云游戲業(yè)務(wù)的能力支撐，包括賬號(hào)登錄計(jì)費(fèi)服務(wù)、訂單管理和活動(dòng)中心管理等。

1.1.4 業(yè)務(wù)場(chǎng)景層

業(yè)務(wù)場(chǎng)景層通過云端協(xié)同，對(duì)不同客戶端展現(xiàn)云游戲、廣告試玩與直播互動(dòng)等場(chǎng)景服務(wù)，最大化程度地豐富企業(yè)的云游戲平臺(tái)系統(tǒng)產(chǎn)品。

1.2 云游戲體驗(yàn)評(píng)估模型

云游戲內(nèi)容質(zhì)量和用戶體驗(yàn)是業(yè)務(wù)商業(yè)化是否成功的關(guān)鍵所在，如何準(zhǔn)確有效地評(píng)測(cè)用戶在云游戲中的實(shí)際體驗(yàn)是業(yè)務(wù)商業(yè)化需要持續(xù)解決的問題。也就是說，建立科學(xué)合理的云游戲質(zhì)量評(píng)估模型已經(jīng)成為促進(jìn)業(yè)務(wù)健康發(fā)展的迫切需求之一。

根據(jù)國際電信聯(lián)盟文獻(xiàn)標(biāo)準(zhǔn)［12-15］，從游戲的廣義程度來說，影響移動(dòng)游戲體驗(yàn)質(zhì)量QoE（Quality of Experience）的因素包含用戶、系統(tǒng)和內(nèi)容三大方面，進(jìn)一步可以分解為用戶影響因素4 小類、系統(tǒng)影響因素17 小類和內(nèi)容5 小類，總計(jì)20 多項(xiàng)。由于云游戲技術(shù)尚處于發(fā)展階段，當(dāng)前并不具備將所有影響因素及KPI 指標(biāo)納入到體驗(yàn)評(píng)估范疇的條件，考慮到云游戲的流媒體特性并參考上文中提到的移動(dòng)游戲影響因素，結(jié)合性能參數(shù)可獲取、指標(biāo)可測(cè)量的原則，本文主要選取分辨率、幀率、碼率、延時(shí)、交互等指標(biāo)作為云游戲體驗(yàn)評(píng)估模型輸入?yún)?shù)，將游戲視聽質(zhì)量、交互感覺和產(chǎn)品體驗(yàn)等信息作為評(píng)估模型的輸出結(jié)果。

本文在部分參考文獻(xiàn)［12-15］中移動(dòng)游戲測(cè)試模型的基礎(chǔ)上對(duì)云游戲建模進(jìn)行了可行性分析，采用模型分級(jí)映射的方式，盡量簡(jiǎn)化測(cè)試環(huán)節(jié)并避免結(jié)果失真，試圖建立云游戲QoE 評(píng)估模型。具體的云游戲QoE 評(píng)估模型框架如圖2所示。

Fig.2 Cloud gaming QoE evaluation model圖2 云游戲QoE評(píng)估模型

其中，視聽體驗(yàn)質(zhì)量O.21 由畫面與音頻質(zhì)量構(gòu)成，主觀上代表了用戶體驗(yàn)云游戲時(shí)的視聽等感官感受，具體客觀指標(biāo)則由分辨率、幀率、碼率、編碼參數(shù)等組成?？紤]到最大化覆蓋原則，評(píng)估模型將內(nèi)容源與終端能力對(duì)應(yīng)指標(biāo)的最低值I.11、I.12和I.13作為實(shí)際輸入?yún)?shù)。交互體驗(yàn)質(zhì)量O.22 主要用于評(píng)價(jià)用戶操作與網(wǎng)絡(luò)傳輸延時(shí)中碰到的體驗(yàn)失真，具體游戲中的表現(xiàn)為延時(shí)抖動(dòng)、丟包導(dǎo)致的卡頓花屏等，導(dǎo)致用戶游戲體驗(yàn)不佳，輸入?yún)?shù)為I.14 和I.15。云游戲產(chǎn)品體驗(yàn)質(zhì)量O.23 與日常用到的軟件涉及點(diǎn)大多一致，體現(xiàn)了用戶使用云游戲產(chǎn)品全流程的體驗(yàn)保證，輸入?yún)?shù)分別為I.16、I.17 和I.18。O.31 定義為云游戲綜合體驗(yàn)質(zhì)量，由輸出信息O.21、O.22、O.23 構(gòu)成，具體可用公式模型O.31=f（O.21，O.22，O.23）描述。其中，為充分體現(xiàn)綜合體驗(yàn)質(zhì)量的數(shù)據(jù)準(zhǔn)確性，3 個(gè)子項(xiàng)的評(píng)估模型均基于用戶游戲體驗(yàn)行為大于5min 的會(huì)話場(chǎng)景。由于篇幅原因，這里主要對(duì)評(píng)估模型進(jìn)行了邏輯關(guān)系梳理，不再對(duì)云游戲QoE 評(píng)估算法進(jìn)行闡述與詳細(xì)的公式推算。

2 云游戲平臺(tái)系統(tǒng)端到端延時(shí)優(yōu)化

2.1 延時(shí)原因分析

根據(jù)客戶端與服務(wù)器交互需求程度的不同，面向移動(dòng)移動(dòng)網(wǎng)的云游戲大體可以分為弱交互類、中交互類與強(qiáng)交互類三大類。業(yè)界的一些真機(jī)通用數(shù)據(jù)表明，對(duì)于強(qiáng)交互類游戲，例如FPS（First Person Shooting Game）、MOBA（Multiplayer Online Battle Arena）與RCG（Racing Game）等游戲，如果端到端延時(shí)超出100ms，用戶游戲體驗(yàn)下降會(huì)比較明顯；中等交互類游戲，例如RPG（Role-Playing Game）游戲，一般端到端延時(shí)在150ms 之內(nèi)；而對(duì)于卡牌、SLG（Simulation Game）等弱交互類游戲而言，端到端延時(shí)即使在200ms，用戶也感覺不到卡頓。

云游戲端到端延時(shí)是指云游戲運(yùn)行過程中，用戶對(duì)終端進(jìn)行觸控操作到游戲畫面在終端上產(chǎn)生相應(yīng)響應(yīng)的時(shí)間差，通常由終端響應(yīng)、主機(jī)端響應(yīng)與網(wǎng)絡(luò)推拉流等延時(shí)構(gòu)成。如圖3 所示，通過全國各地定點(diǎn)收集大量數(shù)據(jù)發(fā)現(xiàn)，該系統(tǒng)在內(nèi)測(cè)期間的端到端延時(shí)平均達(dá)到220ms，用戶反饋體驗(yàn)不佳，主要耗時(shí)發(fā)生在主機(jī)端響應(yīng)與推拉流、播放性能階段，相較于普通網(wǎng)絡(luò)游戲延時(shí)分別增加85ms 與90ms左右，只能勉強(qiáng)符合弱交互類游戲體驗(yàn)。

為了對(duì)云游戲延時(shí)進(jìn)行更好的代碼優(yōu)化，將業(yè)務(wù)響應(yīng)階段繼續(xù)細(xì)分成以下12個(gè)詳細(xì)步驟［16-18］，見圖4。

Fig.3 Sketch map of end-to-end latency stage圖3 端到端延時(shí)階段示意圖

Fig.4 Detailed breakdown diagram of end-to-end latency steps圖4 端到端延時(shí)步驟詳細(xì)分解圖

除步驟2-4 外，其余均為游戲云化帶來的額外延時(shí)，因此這些步驟將作為云游戲延時(shí)優(yōu)化的重點(diǎn)。進(jìn)一步分析發(fā)現(xiàn)，原先的RTC 主機(jī)與播放器終端均未針對(duì)網(wǎng)絡(luò)狀況進(jìn)行幀率發(fā)送動(dòng)態(tài)調(diào)節(jié)，導(dǎo)致弱網(wǎng)情況下延時(shí)增加，故本文對(duì)基于WebRTC（Web Real-Time Communication）協(xié)議的幀率擁塞控制CCA 算法［19-22］進(jìn)行了深入研究和代碼實(shí)現(xiàn)，以減少推拉流過程中的網(wǎng)絡(luò)延時(shí)。

2.2 幀率擁塞控制算法

該算法的中心思想為丟包率反映幀率擁塞狀況。如果丟包率很小或者為0，說明幀率發(fā)送狀況良好，在不超過閾值幀率的情況下，可以增大幀率發(fā)送；反之，說明幀率擁塞嚴(yán)重，此時(shí)應(yīng)減少幀率發(fā)送。在其他情況下，幀率不變。

為準(zhǔn)確計(jì)算網(wǎng)絡(luò)延遲梯度，引入時(shí)延梯度變化di用于評(píng)估時(shí)延增長(zhǎng)趨勢(shì)，以判斷幀率擁塞程度，從而避免發(fā)送端給網(wǎng)絡(luò)傳播延遲估計(jì)帶來的誤差，計(jì)算公式見式（1）。其中，ti-ti-1為幀率到達(dá)時(shí)間差，Ti-Ti-1為幀率發(fā)送時(shí)間差。

當(dāng)發(fā)送鏈路存在擁塞，圖5 中虛線標(biāo)紅到達(dá)的幀率經(jīng)過路由器（Router）節(jié)點(diǎn)時(shí)排隊(duì)等待，導(dǎo)致到達(dá)時(shí)間比原本要晚，延遲梯度d1=（t1-t0）-(T1-T0) >0。因此，延遲梯度可以作為幀率擁塞的指標(biāo)。為了增加準(zhǔn)確性，將一段時(shí)間內(nèi)的幀率數(shù)據(jù)包組的延遲梯度累加、平滑、回歸，最終得到延遲梯度的趨勢(shì)用于判斷是否擁塞。為了易于代碼實(shí)現(xiàn)，CCA 算法可簡(jiǎn)化為指數(shù)平滑和最小二乘法線性回歸算法。

采用指數(shù)平滑法（Exponential Smoothing）計(jì)算累計(jì)延遲梯度的原理為某時(shí)刻的指數(shù)平滑值為該時(shí)刻實(shí)際觀察值與上一時(shí)刻指數(shù)平滑值的加權(quán)平均，具體如公式（2）所示。其中，St為t 時(shí)刻指數(shù)平滑趨勢(shì)預(yù)測(cè)值，yt-1為t -1 時(shí)刻實(shí)際觀察值，α為指數(shù)平滑系數(shù)。從公式得出，α按等比級(jí)數(shù)減少，在WebRTC 幀率擁塞控制場(chǎng)景中，由于時(shí)間序列對(duì)結(jié)果具有比較大的變動(dòng)傾向，α建議取0.9。

Fig.5 Frame rate congestion圖5 幀率擁塞

線性回歸可進(jìn)行時(shí)延梯度趨勢(shì)預(yù)測(cè)，通過最小二乘法求得擬合直線斜率，最終可以根據(jù)斜率獲得時(shí)延的增長(zhǎng)趨勢(shì)。假設(shè)擬合曲線 y=ax+b，對(duì)于一堆樣本（x，y），可以推導(dǎo)出斜率a，具體如公式（3）所示。a 可用于表示圖5 中Router隊(duì)列的增長(zhǎng)狀況。

式中，輸入樣本點(diǎn)為（實(shí)際到達(dá)時(shí)間，累計(jì)延遲梯度平滑值），輸出為延遲梯度變化趨勢(shì)斜率a。

為改變時(shí)延梯度的敏感度，需要采用公式（4）、（5）獲得動(dòng)態(tài)調(diào)整幀率閾值H(ti)用于幀率過載判斷。

式中，ΔTi表示距離上次閾值更新經(jīng)歷的時(shí)間，I(ti)表示幀率排隊(duì)輸入延遲，常數(shù)kd表示決定閾值增加的速度，建議數(shù)值為1.8×10-4；ku表示決定閾值減小的速度，建議數(shù)值為1×10-2［20］。

2.3 算法實(shí)現(xiàn)

從上文算法得知，需要獲得時(shí)延梯度增長(zhǎng)趨勢(shì)并與動(dòng)態(tài)幀率閾值比對(duì)來判斷當(dāng)前的網(wǎng)絡(luò)狀態(tài)是否飽和，然后采取下一步幀率的發(fā)送動(dòng)作。其中，時(shí)延梯度趨勢(shì)斜率a 由指數(shù)平滑法和最小二乘法線性回歸預(yù)測(cè)求得，進(jìn)而根據(jù)公式（2）求得幀率排隊(duì)輸入延遲I(ti)，本文中代碼不再描述。結(jié)合當(dāng)前閾值 H(ti)、設(shè)定時(shí)間閾值（Time of Duration，參考文獻(xiàn)［20］設(shè)置為10ms）和輸入延遲I(ti)，判斷當(dāng)前幀率發(fā)送是否擁塞。判斷算法的偽代碼為：

當(dāng)幀率排隊(duì)輸入延遲I(ti)大于當(dāng)前閾值 H(ti)時(shí)，計(jì)算當(dāng)前延遲狀態(tài)的持續(xù)時(shí)間TOD，如果持續(xù)時(shí)間TOD 大于設(shè)定時(shí)間閾值，并且延遲輸入持續(xù)增加，系統(tǒng)需發(fā)出擁塞信號(hào)，同時(shí)重置持續(xù)時(shí)間TOD；如果延遲輸入持續(xù)減少，說明幀率擁塞緩解，無需重置狀態(tài)。當(dāng)幀率排隊(duì)輸入延遲I(ti)小于閾值 H(ti)負(fù)值時(shí)，說明當(dāng)前幀率發(fā)送處于空閑狀態(tài)，系統(tǒng)發(fā)出空閑信號(hào)，發(fā)送端可以增加幀率發(fā)送。其他情況下，算法認(rèn)為幀率發(fā)送適中，系統(tǒng)可以保持當(dāng)前狀態(tài)不變。

3 云游戲平臺(tái)系統(tǒng)性能數(shù)據(jù)分析

某企業(yè)的云游戲業(yè)務(wù)在短暫內(nèi)測(cè)后于2021 年12 月進(jìn)行商業(yè)化運(yùn)營(yíng)，平臺(tái)初期上線100 臺(tái)高性能鯤鵬920 ARM服務(wù)器，虛擬化成3000 臺(tái)云手機(jī)，同時(shí)上線200+款手游，最高支持1080P@60fps（Frames Per Second），游戲業(yè)務(wù)場(chǎng)景為廣告試玩與云游戲中心等。

根據(jù)上文體驗(yàn)評(píng)估模型輸出結(jié)果，云游戲平臺(tái)系統(tǒng)核心的用戶體驗(yàn)主要包含游戲延時(shí)、卡頓比與故障率等，通過監(jiān)控2022 年1-3 月中旬?dāng)?shù)據(jù)獲得圖6～圖8 結(jié)果。可以看出，端到端業(yè)務(wù)延時(shí)、卡頓比與故障率等數(shù)據(jù)指標(biāo)曲線整體呈下降趨勢(shì)。其中，春節(jié)期間由于訪問用戶量大導(dǎo)致數(shù)據(jù)有短暫波動(dòng)，延時(shí)、卡頓比與故障率分別回升到143ms、8%與5.6%左右，后續(xù)數(shù)據(jù)分別穩(wěn)定在100ms、4.13%與1%上下。圖中3 月5-6 號(hào)，圖6～圖8 的曲線毛刺凸起是由于版本升級(jí)上線的系統(tǒng)bug導(dǎo)致。

通過實(shí)現(xiàn)監(jiān)測(cè)幀率擁塞狀況對(duì)發(fā)送碼率進(jìn)行動(dòng)態(tài)調(diào)節(jié)后，在主機(jī)端響應(yīng)與推拉流、播放性能階段，延時(shí)從85ms 與90ms 左右下降到27ms 與32ms 左右，且圖6 的總延時(shí)曲線也呈下降趨勢(shì)，說明本文算法取得了良好效果，因此該企業(yè)的云游戲平臺(tái)系統(tǒng)已符合市面上絕大多數(shù)游戲的上線要求。

4 結(jié)語

Fig.6 End-to-end service latency圖6 端到端業(yè)務(wù)延時(shí)

Fig.7 Frame drop rate圖 7 卡頓比

Fig.8 Fault rate圖8 故障率

國內(nèi)的5G 基礎(chǔ)建設(shè)正在如火如荼的進(jìn)行當(dāng)中，云游戲作為5G 產(chǎn)業(yè)中重要的商業(yè)云應(yīng)用場(chǎng)景，必將推動(dòng)該產(chǎn)業(yè)的迅速發(fā)展。某企業(yè)的云游戲平臺(tái)系統(tǒng)已經(jīng)向用戶提供服務(wù)，隨著技術(shù)的預(yù)研深挖、端云協(xié)同，該平臺(tái)將支撐更多業(yè)務(wù)場(chǎng)景，從而驅(qū)動(dòng)成本降低，提升用戶體驗(yàn)。當(dāng)然，該平臺(tái)還存在一定不足，如何將簡(jiǎn)化后的WebRTC 構(gòu)建成為一個(gè)成熟穩(wěn)定且擴(kuò)容度高的框架，以及如何通過編碼升級(jí)、帶寬復(fù)用［23］等技術(shù)進(jìn)一步降低用戶成本都是后續(xù)需要解決的重點(diǎn)問題。