基于電信網(wǎng)的云化虛擬現(xiàn)實 端到端業(yè)務(wù)質(zhì)量要求和監(jiān)測方法

基于電信網(wǎng)的云化虛擬現(xiàn)實端到端業(yè)務(wù)質(zhì)量要求和監(jiān)測方法本文件規(guī)定了體驗關(guān)鍵質(zhì)量指標(KeyQualityIndicator,以下簡稱KQI)、業(yè)務(wù)關(guān)鍵性能指標(KeyPerformanceIndicator,以下簡稱KPI)、網(wǎng)絡(luò)關(guān)鍵性能指標(KeyPerformanceIndicator)以及評估上述指標的監(jiān)測方法。本文件適用于面向電信網(wǎng)固定網(wǎng)絡(luò)接入云化虛擬現(xiàn)實場景下端到端業(yè)務(wù)質(zhì)量的評估。下列文件對于本文件的應(yīng)用是必不可少的。凡是注日期的引用文件，僅所注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。2020-1155T-YD基于電信網(wǎng)的云化虛擬現(xiàn)實總體技術(shù)要求2020-1154T-YD基于電信網(wǎng)的云化虛擬現(xiàn)實網(wǎng)絡(luò)技術(shù)要求ITU-TG.1035(05/2020)虛擬現(xiàn)實用戶質(zhì)量體驗影響因素(InfluenceFactorsonQualityofExperienceforVirtualRealITU-TG.1080(12/2008)IPTV業(yè)務(wù)質(zhì)量要求(QualityofExperienceReqITU-TP.1203(10/2017)經(jīng)可靠傳送的漸進式下載和自適應(yīng)音視頻流業(yè)務(wù)的基于參數(shù)比特流的質(zhì)量評估(ParanetricBitstream-BasedQualityAssessmentofProgressiveDounloadandAdaptiveAudiovisualStreamingServicesover3術(shù)語、定義和縮略語3.1術(shù)語和定義下列術(shù)語和定義適用于本文件。云化虛擬現(xiàn)實cloudvirtualre云化虛擬現(xiàn)實是將云計算、云渲染的理念及技術(shù)引入到VR業(yè)務(wù)場景中，借助高速穩(wěn)定的網(wǎng)絡(luò)，將云端的顯示輸出和聲音輸出等經(jīng)過壓縮編碼流化后傳輸?shù)接脩舻臒o繩終端設(shè)備，實現(xiàn)VR業(yè)務(wù)內(nèi)容上云、渲染上云面向用戶體驗、內(nèi)容質(zhì)量和網(wǎng)絡(luò)質(zhì)量，建立業(yè)務(wù)質(zhì)量指標評估體系，固化端到端問題3TCP傳輸控制協(xié)議TransmissionControlProtocolUDP用戶數(shù)據(jù)報協(xié)議UserDatagramProtocol4業(yè)務(wù)場景分類及其特征指標目前云化虛擬現(xiàn)實(CloudVirtualReality,以下簡稱CloudVR)產(chǎn)業(yè)在各行業(yè)中得到了廣泛應(yīng)用覆蓋的垂直行業(yè)包括教育、電競、醫(yī)療、旅游、房地產(chǎn)、智慧工廠等。在大眾市場中，主流的CloudVR業(yè)務(wù)體現(xiàn)在巨幕影院、360°視頻、游戲、音樂、健身、社交、購物等方面4.2影響云化虛擬現(xiàn)實強交互業(yè)務(wù)的因素暈動癥：運動響應(yīng)延時(MTP)是指從用戶頭部姿態(tài)或位置變化到終端顯示畫面出現(xiàn)相應(yīng)變化的時間差，業(yè)界主流觀點認為當(dāng)MTP延時小于20ms時就能大幅減少暈動癥的發(fā)生。傳統(tǒng)方案完全依賴云端渲染來完成對終端顯示畫面的刷新，無法滿足這一要求。端云異步渲染方案通過引入異步時間和空間扭曲技術(shù)，該技術(shù)能根據(jù)用戶頭部的姿態(tài)或位置的變化對前序畫面進行預(yù)測調(diào)整和插幀處理(頭動渲染),使得MTP處理流程在終端內(nèi)部就能完成，不再依賴于云渲染流化流程，最終達到了降低用戶眩暈感的目的。云渲染流化是指從終端上報指令，到云端計算渲染、編碼、推流，再到終端接收并解碼的過程，是CloudVR相對于本地VR在業(yè)務(wù)處理過程中引入的額外步驟。響應(yīng)滯后；在CloudVR游戲、教育等強交互應(yīng)用中，當(dāng)用戶走動、轉(zhuǎn)動頭盔、扣動扳機或揮動手柄時，都希望能從視覺和聽覺上獲得快速響應(yīng)，如果延遲偏大就會讓用戶產(chǎn)生遲滯感。參考多數(shù)在線射擊游戲的操作經(jīng)驗，對大部分人來說，當(dāng)操作響應(yīng)時延控制在100ms以內(nèi)時，用戶的感知一般就是即時的。從處理流程上來看，操作響應(yīng)在云渲染流化的基礎(chǔ)上，增加了動作捕捉和渲染顯示過程，未來可以從這幾個方向著手進行優(yōu)化04.3影響云化虛擬現(xiàn)實弱交互業(yè)務(wù)的因素初始緩沖時長：用戶從點擊播放按鈕(終端發(fā)出獲取0TT視頻源請求消息)開始，直至收到OTT云平臺返回的數(shù)據(jù)能夠滿足終端首次出現(xiàn)視頻影像的等待時間。測試工具將視頻頁面DNS請求報文的發(fā)送4時刻與終端第一次出現(xiàn)持續(xù)播放影像的時刻的時間差記錄為初始緩沖時長。由于互聯(lián)網(wǎng)視頻服務(wù)提供商普遍通過終端程序設(shè)計或腳本的方式在視頻播放前插播一段時長不等的廣告，故測試時應(yīng)采用屏蔽或跳過廣告的方式進行，確保測試結(jié)果能夠真實反映用戶體驗與網(wǎng)絡(luò)質(zhì)量之間的關(guān)系。無法屏蔽或跳過廣告的視頻不納入測量初始緩沖時長的測試場景范圍。卡頓/花屏；云渲染流量可通過TCP/UDP協(xié)議承載。當(dāng)使用TCP承載時，若傳輸過程中出現(xiàn)丟包或亂序問題，一方面，TCP的避免擁塞機制會調(diào)整發(fā)送窗口以降低發(fā)送速率。另一方面TCP協(xié)議棧在確保收到數(shù)據(jù)的完整性和一致性前不會將數(shù)據(jù)上送應(yīng)用層進行處理。而當(dāng)終端較長時間沒有新的視頻數(shù)據(jù)用于解碼呈現(xiàn)時(相鄰幀的解碼呈現(xiàn)時間間隔超過一定時間時，用戶就會觀察到明顯的畫面卡頓現(xiàn)象。而如果使用UDP協(xié)議承載，根據(jù)解碼器對幀數(shù)據(jù)丟失處理機制的不同，造成的結(jié)果可能是卡頓也可能是花屏。例如，當(dāng)解碼器采用凍結(jié)機制時，遇到幀數(shù)據(jù)丟失就會凍結(jié)畫面，直到下一個完整的I幀到達后再繼續(xù)播放，用戶側(cè)感知為畫面卡頓而當(dāng)解碼器采用忽略機制時，協(xié)議棧多數(shù)情況下會忽略數(shù)據(jù)丟失情況，直接上送應(yīng)用層進行解碼，用戶側(cè)會感知到花屏畫質(zhì)切換滯后：以TWS生FOV傳輸方案為例，經(jīng)過特殊編碼后的視頻源文件會被分割成多個tile分片進行存儲，每個tile分片對應(yīng)不同的高清視角區(qū)域。當(dāng)用戶頭部姿態(tài)出現(xiàn)變化時，云端會根據(jù)終端上報的信息，選擇與用戶視角區(qū)域相對應(yīng)的高質(zhì)量分片內(nèi)容進行響應(yīng)，同時響應(yīng)的還有一個較低質(zhì)量的全視角視頻內(nèi)容終端在收到云端推送的高質(zhì)量內(nèi)容之前，會先用低質(zhì)量全景內(nèi)容來進行填補，直到高質(zhì)量分片內(nèi)容到達后，再對低質(zhì)量部分進行替換和拼接。在這個過程中，如果高質(zhì)量內(nèi)容分片的更新時間過長超過了200ns,用戶就可能會看到明顯的低質(zhì)量畫面，影響觀看體驗。詳見附錄A。5云化虛擬現(xiàn)實端到端業(yè)務(wù)體驗指標5.1業(yè)務(wù)體驗指標架構(gòu)要求對業(yè)務(wù)體驗指標架構(gòu)進行三個維度的分解：體驗KQI指標如表1所示、業(yè)務(wù)KPI指標如表2所示、網(wǎng)絡(luò)KPI指標如表3所示?；谝陨先齻€維度，對CloudVR業(yè)務(wù)所涉及的指標進行定義并關(guān)聯(lián)分析。表1CloudVR體驗KQI指標集弱交互占插放時長的比例卡頓(TCP)花屏(LDP)弱/強交互(通用類)終端設(shè)備溫度超過限定值(預(yù)警值)電量模式的平均時長EPG(ElectronicProgranGuide)請求成功的EPG請求過程中，從發(fā)起HTTP_GET請求到收到索引文件請求過程中，從發(fā)起HTTP_GET分片開始下載時，終端發(fā)起TCPSyn請分片下載過程中，終端從發(fā)起HTTP_GET視頻CDN服務(wù)器自身問題主動返回ERROR或直播/點播業(yè)務(wù)請求過程中，從發(fā)起HTTP_G從終端發(fā)起DNS請求，到DNS解析完成的EPG(ElectronicProgranGuide)請求成功的EPG請求過程中，從發(fā)起HTTP_GET請求到收到渲染資源請求過程中，從發(fā)起HTTP_GET請終端與渲染節(jié)點建接過程中，終端發(fā)起TCP業(yè)務(wù)運行過程，出現(xiàn)中斷或異常退出的次數(shù)5.4網(wǎng)絡(luò)KPI指標要求分片下載過程中，終端從發(fā)起HTTP_G內(nèi)存利用率Wi-Fi下掛設(shè)備的報文在家庭網(wǎng)絡(luò)轉(zhuǎn)發(fā)的往返服務(wù)器從收到HTTP_GET請求到作出內(nèi)存利用率內(nèi)存使用情況占總內(nèi)存大小的比例內(nèi)存利用率Wi-Fi下掛設(shè)備的報文在家庭網(wǎng)絡(luò)轉(zhuǎn)發(fā)的往返9內(nèi)存利用率內(nèi)存使用情況占總內(nèi)存大小的比例6監(jiān)測方法要求6.1監(jiān)測工具要求6.1.1工具形態(tài)總體要求CloudVR質(zhì)量監(jiān)測覆蓋VR業(yè)務(wù)平臺，VR探針平臺，城域網(wǎng)，接入網(wǎng)，家庭網(wǎng)和VR終端等，通過CloudVR探針方案實現(xiàn)CloudVR業(yè)務(wù)的質(zhì)量監(jiān)測。CloudVR探針方案是指通過部署CloudVR平臺和探針，基于平臺探針，網(wǎng)元探針，網(wǎng)關(guān)探針以及終端頭盔探針采集用戶體驗指標，端管云三段指標，從而進行端到端的業(yè)務(wù)質(zhì)量監(jiān)測。要求各探針對終端本身的性能影響盡可能小。如探針的CPU負載不超過一定限值，內(nèi)存消耗不超過一定限值。要求各探針自身具有安全性和健壯性。能有效防止黑客利用軟件漏洞執(zhí)行病毒、蠕蟲和木馬等，獲取系統(tǒng)權(quán)限，竊取系統(tǒng)或用戶數(shù)據(jù)。6.1.2頭盔探針(軟探針)要求要求頭盔探針能夠在線采集全量CloudVR業(yè)務(wù)的KQI指標，并及時將指標上報給VR探針平臺。頭盔探針適用于不同類型終端設(shè)備，要求安裝探針的終端設(shè)備統(tǒng)一適配上報的管理平臺。6.1.3家庭網(wǎng)關(guān)探針(軟探針)要求要求家庭網(wǎng)關(guān)探針能夠在線采集Wi-FiKPI指標，按需啟動隨流KPI指標的采集。要求能對CloudVR業(yè)務(wù)進行識別，動態(tài)區(qū)分和判定強交互業(yè)務(wù)/弱交互業(yè)務(wù)。通過在CR上行鏈路上部署獨立DPI設(shè)備，采集CloudVR業(yè)務(wù)隨流的KPI指標，并將指標上報給CEM客戶體驗管理平臺。要求獨立的DPI探針能夠用于全網(wǎng)CloudVR流量的深度檢測，支持海量用戶同時在線6.1.5平臺探針(軟探針)要求平臺探針由渲染服務(wù)器探針和CDN探針組成，與終端頭盔探針一樣，要求平臺探針能夠在線采集全量CloudVR業(yè)務(wù)的KQI指標，并及時將指標上報給VR探針平臺。6.1.6網(wǎng)絡(luò)性能監(jiān)控平臺要求網(wǎng)絡(luò)性能監(jiān)控平臺主要對0LT,BRAS,CR各網(wǎng)絡(luò)節(jié)點進行性能監(jiān)控，要求能夠采集各網(wǎng)元端口的KPI指標和PON口線路KPI指標，并將指標上報給CEM客戶體驗管理平臺。6.2監(jiān)測數(shù)據(jù)處理要求6.2.1云化虛擬現(xiàn)實系統(tǒng)及測量指標采集標記點第一個圖2CloudVR系統(tǒng)及測量指標采集標記點CloudVR系統(tǒng)及測量指標如圖2所示，具體測量指標采集標記點定義如表4所示：表4測量指標采集標記點位姿發(fā)送時刻(PoseSendTime)位姿接收時刻(ServerRecvPoseTime)位姿提交時刻(PoseReadyToRenderJinc)服務(wù)器接收到位姿后立刻調(diào)用poselpda渲染完成時刻(AfterRenderTime)編碼完成時刻(AfterEncodeTime)送入發(fā)送隊列的時刻(ServerPushFrameTine)接收第一個包的時刻(RecvFirstPacketTine)解碼輸入時刻(FrameReconstructedTime)解碼完成時刻(DecodeOutputTime)6.2.2流信息傳輸承載結(jié)構(gòu)為了記錄各時刻，對每一個位姿pose設(shè)置唯一的ID:PoseID。服務(wù)器和客戶端都以PoseID為標端到端時延(TotalLatency)該幀解碼完成時刻(decodeOutputTime)-收到位姿的時刻(ServerRecvPoseTime)渲染時延(RenderDuration)時刻(PoseReadyToRenderTime)編碼時延(EncodeDuration)服務(wù)器編碼結(jié)束時刻(AfterEncodeTime)-取出服務(wù)器將慎送入發(fā)送隊列到該幀全部發(fā)送完成(ServerSendLastPacket解碼時延(DecodeDuration)decodeOutputTine-frameReconstru卡頓時長(Rebuffering)卡頓時長就是兩個相鄰的解碼完成時刻的差值(△T5)=DecodeOutputTine-m_lastDecodeO值f(nouPose,showPose)二EulerianAnglePoEulerianAnglePoseCurBulerianAnglePoseRendshowPose與nowPose對應(yīng)的歐拉角生。物件利用網(wǎng)絡(luò)已有成熟的定位系統(tǒng)，通過終端設(shè)備探針上報的錯誤碼判斷是否為通斷類問題平臺通斷和網(wǎng)絡(luò)通斷。第2類：非通斷類問題若排除通斷類問題，根據(jù)終端設(shè)備探針采集的體驗指標，如卡頓。黑邊等，判定質(zhì)差因素并對質(zhì)差因素進行三段定界。質(zhì)差因素的三段定界圖5三段定界流程第1類：時延分段定界時延三段定界分為終端處理時延，網(wǎng)絡(luò)RTT時延和云端處理時延，如圖5所示。對各采集點進行打點標記，信息如下：1)終端以固定周期上報視角信息，打上指令I(lǐng)D,并在本地保存信令發(fā)送時間T1:2)渲染服務(wù)器在接收信令時打上時間T2;3)渲染服務(wù)器根據(jù)視角信息進行渲染，并將指令和渲染幀進行關(guān)聯(lián)。渲染幀發(fā)送時將報文ID(至少包含指令I(lǐng)D、報文序列號和回填的發(fā)送時間T3),再發(fā)送給終端，終端打上接收時間T4和解碼時間T5:通過對已打點標記的各采集點依照如表6所示公式進行計算，CEM和VR探針平臺可以監(jiān)測各段時延是否在合理范圍內(nèi)進行時延的定界。表6分段時延計算丟包要求CloudVR弱交互業(yè)務(wù)中的視頻點播業(yè)務(wù)一般采用TCP傳輸，丟包影響是降低通量，即卡頓。在確定RTT和帶寬通量的情況下，根據(jù)公式計算性丟包率可得出視頻點播業(yè)務(wù)網(wǎng)絡(luò)丟包要求如表7所示：表7CloudVR弱交互業(yè)務(wù)中的視頻點播業(yè)務(wù)網(wǎng)絡(luò)丟包要求4K階段(實測)8K階段(實測)12K階段(預(yù)測)24K階段(預(yù)測)RTT(建議)為1,預(yù)測階段采用端云拼接。TCP流數(shù)按至少4條計算CloudVR強交互業(yè)務(wù)和弱交互業(yè)務(wù)中的視頻直播業(yè)務(wù)建議使用UDP傳輸，丟包將造成花屏、黑屏等問題。由于RET會引入時延，不建議部署。因此在無RET重傳的情況下，參考4K視頻已經(jīng)測試的數(shù)據(jù)，丟包在1E-5時，對體驗會有輕微影響，在1E-6時，影響已經(jīng)無法感知。所以此類業(yè)務(wù)丟包率要求建議如表8所示：表8CloudVR強交互業(yè)務(wù)和弱交互業(yè)務(wù)中的視頻直播業(yè)務(wù)網(wǎng)絡(luò)丟包要求2K階段(實測)4K階段(實測)8K階段(預(yù)測)16K階段(預(yù)測)強交互網(wǎng)絡(luò)RTT(必須)強交互丟包率(必須)4K階段(實測)8K階段(實測)16K階段(預(yù)測)24K階段(預(yù)測)直播網(wǎng)絡(luò)RTT(建議)直播丟包率(必須)注：強交互業(yè)務(wù)內(nèi)容為實時渲染生成，沒有全景畫面，絡(luò)端屏幕分辨率是指需要渲染的畫面的分辨率。2K終端屏幕分辨率對應(yīng)K視頻全景分辨率，4K終端屏幕分辨率對應(yīng)8K視頻全景分辨率，8K絡(luò)端屏幕分辨率對應(yīng)12K視頻全景分辨率丟包分段定界步驟1:云端服務(wù)器根據(jù)接收到的上行指令流中指令I(lǐng)D的連續(xù)性計算上行丟包率：步驟2:終端設(shè)備上部署的探針根據(jù)接收到的報文ID連續(xù)性計算下行丟包率：步驟3:VR探針平臺/CEM根據(jù)上行丟包率和下行丟包率判斷是否存在網(wǎng)絡(luò)問題。若排除網(wǎng)絡(luò)問題，則對“端-云”兩段進行下一步篩查和根因分析；若存在網(wǎng)絡(luò)問題，則需對網(wǎng)絡(luò)內(nèi)部再次定界，確定故障網(wǎng)絡(luò)分段后進行析因排障VR“端-云”兩側(cè)故障分析VR終端故障分析：通過部署在VR終端設(shè)備的探針，采集相關(guān)的業(yè)務(wù)體驗指標，如剩余電量，屏幕實時刷新率等，進一步分析質(zhì)差根因。VR云端故障分析：部署在WR云端的探針可以采集到內(nèi)存利用率，CPU占用率。GPU利用率等，進一步分析質(zhì)差根因。6.3.2支持網(wǎng)絡(luò)內(nèi)部定界要求基于ONT實現(xiàn)網(wǎng)絡(luò)的二分段具有端網(wǎng)協(xié)同接口的ONT不僅支持業(yè)務(wù)識別，還能基于不同業(yè)務(wù)類型對網(wǎng)絡(luò)內(nèi)部故障定界進行二分設(shè)時步驟2;網(wǎng)絡(luò)管理平臺根據(jù)策略對承載網(wǎng)內(nèi)部各節(jié)點部署探針，采集指標。步驟3;各節(jié)點網(wǎng)絡(luò)探針采集隨流KPI,定期上報給網(wǎng)絡(luò)管理平臺，平臺根據(jù)上報指標分析承載網(wǎng)內(nèi)部故障點。6.4保障體驗的帶寬需求建議CloudVR弱交互業(yè)務(wù)帶寬需求分析表90loudVR弱交互業(yè)務(wù)不同階段帶寬需求估算平均碼率往2=傳輸畫面像素點X每像素比特位X率FOV網(wǎng)絡(luò)帶寬=FOV傳輸系數(shù)生4×全視角傳輸注1;對于CloudVR弱交互業(yè)務(wù)，初始階段可采用全視角方案進行傳輸。隨著分辨率的提升。為節(jié)省帶寬，后續(xù)階段可以考慮利用FOV傳輸方案進行替代。注2:對于2D視頻，傳輸畫面像素點等于全視角分辨率；對于3D視頻，傳輸畫面像素點約為2D的兩信。紅黃藍三色，256級的RGB彩色原圖轉(zhuǎn)化為YUV420格式后，每像素比特位為12。4K階段的壓縮率基于H.264取業(yè)界典型值。H.265片源經(jīng)Tile轉(zhuǎn)碼后，總體壓縮率為1%左右。使用相同的編碼技術(shù)版本，3D效果的VR畫面壓縮效率可以比2D效果再提升25%左右。后續(xù)階段的壓縮率則根據(jù)業(yè)界經(jīng)驗測算得出，主要考慮編碼方式、幀率、分辨率三大因素：(1)編碼從H.264到H.265,H.265到H.266壓縮率預(yù)計分別提升30%左右；(2)幀率提高一倍，壓縮率預(yù)計提升50%左右；(3)分辨率提升一倍，壓縮率預(yù)計提升15%左右。注3;由于視頻流并不是完全平穩(wěn)的，有流量突發(fā)的情況，所以根據(jù)4K視頻的測試經(jīng)驗，當(dāng)網(wǎng)絡(luò)帶寬大于平均碼率2倍時，可保證視頻流暢播放，所以網(wǎng)絡(luò)帶寬需求按照2倍于平均碼率來計算。注4;FOV傳輸系數(shù)指所采用的FOV技術(shù)其FOV傳輸角度占全視角的比值。人眼視角極限大約為水平方向230度，垂直方向150度，這個視角范圍能達到身臨其境的效果。FOV傳輸系數(shù)=(230/360)*(150/180),計算得出FOW傳輸系數(shù)值約為0.53?；谌绫?所示的計算模型，對CloudVR弱交互業(yè)務(wù)不同發(fā)展階段的帶寬需求估算如表10所示；表10cloudMR弱交互業(yè)務(wù)不同階段帶寬需求估算12K階段弱交互業(yè)務(wù)碼率(1路)弱交互業(yè)務(wù)帶寬(1路)CloudVR強交互業(yè)務(wù)帶寬需求分析生表11CloudVR強交互業(yè)務(wù)帶寬計算模型平均碼率=終端屏幕像素點×(1+超視角渲染比例)2×每像素比注5:初期云渲染流化時延較大，可采用超視角渲染方案優(yōu)化黑邊問題，額外渲染部分按10%左右估算端云異步渲染在調(diào)整物體間的位置關(guān)系時，需調(diào)用景深或運動矢量等信息，建議每一幀畫面需額外傳輸15%的景深和運動矢量信息。H.265片源經(jīng)Tile轉(zhuǎn)碼后，總體壓縮率為1%左右。使用相同的編碼技術(shù)版本，3D效果的VR畫面壓縮效率可以比2D效果再提升25%左右，但強交互應(yīng)用采用H.264快速編碼，同等壓縮率下，畫質(zhì)效果要低于離線壓縮的視頻，因此3D畫面仍按1%估算。編碼從H.264到.265,H.265到L.266壓縮率預(yù)計分別提升30%左右：幀率提高一倍，壓縮率預(yù)計提升50%左右；分辨率提升一倍，壓縮率預(yù)計提升15%左右。基于如表11所示的計算模型，對CloudVR強交互業(yè)務(wù)不同階段的帶寬需求估算如表12所示：表12CloudVR強交互業(yè)務(wù)不同階段帶寬需求估算強交互業(yè)務(wù)帶寬(1路)注6:強交互業(yè)務(wù)內(nèi)容為實時渲染生成，沒有全最畫面，終端屏幕分辨率是指需要渲染的畫面的分辨率。強交互應(yīng)用渲染畫面分辨率取決于終端屏幕，4K終端屏幕分辨率為3840*2160。不同階段的帶寬保障建議表13不同階段帶寬保障建議準確的站點容量要求。1.升級增強家庭網(wǎng)+承載網(wǎng)網(wǎng)絡(luò)架構(gòu)1.進一步演進家庭網(wǎng)2.構(gòu)建確定性低時延承載網(wǎng)絡(luò)4K階段的帶寬保障建議單用戶平均上網(wǎng)速率=[城域核心設(shè)備出口流量一(IPTV+單用戶IPTV點播平均碼率=單用戶IPT單用戶CloudVR點播平均碼率-單用戶CloudVR點播總流量直播流量=2頻道碼率X頻道數(shù)，直播頻道包括IPTV站點上網(wǎng)流量=站點下掛寬帶用戶數(shù)×單用戶站點IPTV點播流量=站點IPTV點播并發(fā)用戶數(shù)*單用戶IPTV站點CloudVR點播流量=站點CloudVR點播并發(fā)用戶數(shù)×單用戶CloudVR站點經(jīng)過的流量大小=站點上網(wǎng)流量+站點IPTV點播流量+站點CloudVR點播流量+家庭組網(wǎng)采用獨立高性能AP承載VR業(yè)務(wù)，Wi-F802.1lac4*4MIMO或802.1lax技術(shù)，達到速率大于260接入網(wǎng)(PON升級)接入全面部署10GPON:8K階段，單路CloudYR業(yè)務(wù)帶寬要求為260MbpsIPTV和上網(wǎng)業(yè)務(wù)，用戶帶寬建議不小于400Mbps?。帶寬產(chǎn)業(yè)步入千兆時代，原有的GPON/EPON接入無法滿足用戶的業(yè)務(wù)需求，10GPON技術(shù)將逐漸成為PON網(wǎng)絡(luò)的主流技術(shù)，建議全10GEPON/GPON在分光比為1:64情況下無法達到400Mbps帶寬。需要控制用戶的實際安裝數(shù)量：只有在分光城域網(wǎng)(擴容升級)城域網(wǎng)演進到N*100Gbps/Tbps容量(升級單板/設(shè)備速率和集成度)1.0LT上行口建議至少升級到4*10GE2.城域核心設(shè)備建議升級為Tbps/槽位的集群平3.城域邊緣設(shè)備至少升級為4*100GE上聯(lián)城域核1.意圖感知：基于意圖感知識別不同Clo2.質(zhì)量感知：通過測量和評估CloudVR的業(yè)務(wù)質(zhì)量3.問題識別：基于質(zhì)量感知所采集的數(shù)據(jù)，采用大4.網(wǎng)絡(luò)優(yōu)化：對于網(wǎng)絡(luò)瓶頸點，實施自動化/人工的優(yōu)可以通過自動化的信道調(diào)優(yōu)等技術(shù)進行速率提升。對足問題，則需要通過人工擴容的方式解決問題。除了上述工程方法外，還可能通過一些技術(shù)手段提升產(chǎn)品能力。降低CloudVR的帶寬消耗和時廷要求。包括但不限于：低時延Wi-