1 U-vMOS的標準及對網(wǎng)絡(luò)要求
1.1 U-vMOS評價體系介紹
視頻已成為網(wǎng)絡(luò)上的最主要流量,視頻業(yè)務(wù)體驗已成為衡量網(wǎng)絡(luò)服務(wù)質(zhì)量的關(guān)鍵指標。伴隨著視頻分辨率的不斷提升(從360p/720p逐漸過度至4K/8K),視頻業(yè)務(wù)對網(wǎng)絡(luò)的要求也越來越高。如何評價當前網(wǎng)絡(luò)下視頻業(yè)務(wù)的體驗,對用戶和運營商來說意義越來越重大。
IP承載網(wǎng)是一個“盡力而為”的網(wǎng)絡(luò),網(wǎng)絡(luò)視頻業(yè)務(wù)占用帶寬資源較多、實時性要求較高,并且對分組丟失、時延、抖動等網(wǎng)絡(luò)特性非常敏感,尤其是時變的網(wǎng)絡(luò)特性嚴重影響網(wǎng)絡(luò)視頻業(yè)務(wù)的質(zhì)量。通過對網(wǎng)絡(luò)視頻質(zhì)量的監(jiān)控和反饋,可以調(diào)節(jié)編解碼器或信道的參數(shù),改善傳輸視頻的服務(wù)質(zhì)量。因此,需要實時準確地對網(wǎng)絡(luò)視頻服務(wù)質(zhì)量進行監(jiān)控,獲得反映用戶感受的視頻體驗質(zhì)量。
早在2009年ITU-T就啟動了針對視頻業(yè)務(wù)的vMOS標準研究項目,并于2012年參考語音MOS指標體系發(fā)布了第一個基于視頻體驗的VMoS指標,用于監(jiān)控視頻經(jīng)過網(wǎng)絡(luò)傳輸后的質(zhì)量損失,關(guān)注點在于視頻QoE的檢測和問題定位。這套指標完全參考了語音MOS的定義,先定義影響因素Compression、packet-loss、rebuffering,自下而上地計算vMOS。出發(fā)點是為了發(fā)現(xiàn)問題,用于視頻質(zhì)量監(jiān)控,只站在技術(shù)視角看問題,沒有考慮消費者對視頻體驗優(yōu)劣的評價是跨越視頻業(yè)務(wù)的全流程,也沒有站在最終消費者體驗的角度去橫向比較不同的分辨率帶給用戶的不同體驗。因此也無法完整的指導(dǎo)運營商網(wǎng)絡(luò)的設(shè)計和優(yōu)化。
華為認為在原有vMOS的基礎(chǔ)上,需要根據(jù)以用戶體驗為中心的評價體系標準,用統(tǒng)一的衡量標準,來評價不同網(wǎng)絡(luò),不同屏幕,不同場景應(yīng)用下的視頻體驗的好壞;谝陨铣霭l(fā)點,華為視頻研究團隊結(jié)合人體工程學(xué)實驗,樣本調(diào)研和深入技術(shù)研究,提煉出適配全場景的視頻體驗TOP3影響因子,即視頻質(zhì)量(sQaultiy),互動體驗(sInteraction)和觀看體驗(sView)。華為基于三大核心思想,設(shè)計了視頻體驗衡量體系評價標準U-vMOS,使TOP3視頻體驗影響因子得以量化,使得視頻體驗標準體系實現(xiàn)可采集、可評估、可演進。據(jù)此,我們擬合出如下公式(其中,影響視頻質(zhì)量、操作體驗和播放體驗三個模塊的主要因素如圖2~4所示)。
圖1 U-vMOS建模方法
圖2 sQuality的影響因子
圖3 sInteraction的影響因子
圖4 sView 的影響因子
1.2 基于U-vMOS評價體系對網(wǎng)絡(luò)的要求
基于U-vMOS標準,對其中的各項KQI進一步分解,可以得出某一目標U-vMOS得分的條件下,網(wǎng)絡(luò)需要提供的KPI:
基于U-vMOS 5分標準,分解出的網(wǎng)絡(luò)要求已經(jīng)大大超出當前網(wǎng)絡(luò)的能力,我們認為,5分的標準需要依賴云/管/端革新的技術(shù)&方案才能達成。
中短期內(nèi),U-vMOS達到4分已經(jīng)代表了較好的體驗,我們將U-vMOS4分設(shè)置為網(wǎng)絡(luò)優(yōu)化達成的目標。
2 面向U-vMOS的移動承載網(wǎng)絡(luò)優(yōu)化方案介紹
從上一章節(jié)的介紹中我們知道,影響視頻業(yè)務(wù)體驗的網(wǎng)絡(luò)要素,主要是三個:帶寬(更確切的說是通量)、時延、以及丟包率。其中,丟包率往往由端到端的線路質(zhì)量決定,難以通過個別網(wǎng)絡(luò)節(jié)點的調(diào)整達到立竿見影的優(yōu)化效果;通量和時延則不然。如何在當前移動承載網(wǎng)絡(luò)的基礎(chǔ)上,通過成本可控的優(yōu)化方案,保障移動承載網(wǎng)的高通量和低時延,繼而提升每用戶的移動視頻體驗高質(zhì)量(U-vMOS>=4),我們認為可以參考如下的策略和應(yīng)對方案。
2.1 TCP加速技術(shù)
2.1.1 傳統(tǒng)TCP的不足
互聯(lián)網(wǎng)帶寬的高速發(fā)展增催生了各類高吞吐率應(yīng)用,典型如4K視頻播放,普通4K視頻片源的平均碼率基本都在25Mbps以上,峰值碼率甚至?xí)_到50Mbps以上。雖然物理帶寬能夠通過擴容來滿足4K視頻應(yīng)用的吞吐率需求,但是由于承載視頻傳輸?shù)腡CP協(xié)議的設(shè)計局限和不足,實際傳輸吞吐率可能遠遠達不到物理帶寬,TCP可能會成為高吞吐率應(yīng)用的瓶頸。
TCP通過調(diào)節(jié)擁塞窗口CWND來控制數(shù)據(jù)發(fā)送的吞吐率,由于TCP并不了解應(yīng)用需求和網(wǎng)絡(luò)狀態(tài),為了避免盲目增長窗口造成網(wǎng)絡(luò)擁塞,傳統(tǒng)TCP協(xié)議采用比較保守的擁塞控制策略,例如Reno在擁塞避免階段采用的AIMD策略,窗口增長采用緩和的線性方式,窗口降低采用激進的指數(shù)方式,具體如圖5所示:
圖5 Reno窗口調(diào)整原理
a) 丟包時進入快速重傳和快速恢復(fù)狀態(tài),CWND減半;
b) 收到重傳報文的ACK后進入擁塞避免狀態(tài),每個RTT周期CWND增加一個MSS;
以100Mbps帶寬、60ms時延的網(wǎng)絡(luò)為例,應(yīng)用傳統(tǒng)TCP技術(shù),在吞吐率逼近100Mbps的情況下,單純發(fā)生一次丟包,吞吐率需要經(jīng)過約16.2秒才能重新恢復(fù)到丟包前的水平;如果丟包率為1/10000,那么實際吞吐率將只有23Mbps左右,遠遠小于物理帶寬。而在真實的網(wǎng)絡(luò)環(huán)境中,隨著終端設(shè)備接入的多樣化尤其是手機等無線設(shè)備的加入,網(wǎng)絡(luò)中可能會存在更高的隨機丟包率和時延抖動,類似Reno的傳統(tǒng)TCP算法已經(jīng)無法滿足應(yīng)用高吞吐率的需求,提出一種高效的TCP加速技術(shù)勢在必行。
2.1.2 TCP加速技術(shù)演進
TCP加速技術(shù)的核心是設(shè)計高效的擁塞控制算法,在不喪失TCP公平性和友好性的前提下盡量提升TCP流的吞吐率。擁塞控制的基本思路是發(fā)送端根據(jù)從網(wǎng)絡(luò)獲得的擁塞反饋信息調(diào)整TCP的發(fā)送速率,基于根據(jù)何種擁塞反饋信息可以將TCP加速技術(shù)分為三類:基于顯式信息反饋的TCP加速技術(shù)、基于隱式信息反饋的TCP加速技術(shù)和基于智能數(shù)據(jù)分析的TCP加速技術(shù),本節(jié)將逐一分析三類技術(shù)的基本原理和優(yōu)缺點。
基于顯式信息反饋的TCP加速技術(shù)
部分TCP加速技術(shù)提出了利用路由器配合進行顯式擁塞反饋,由路由器主動向發(fā)送端通告網(wǎng)絡(luò)的擁塞狀況,發(fā)送端據(jù)此調(diào)整發(fā)送速率。比較典型的主要有:XCP和VCP等。由于該類技術(shù)對網(wǎng)絡(luò)設(shè)備支持的依賴程度非常高,因此協(xié)議可擴展性很差,這也是該類技術(shù)至今依然停留在理論,尚未在網(wǎng)絡(luò)中獲得大規(guī)模部署的原因。
基于隱式信息反饋的TCP加速技術(shù)
如果路由器不提供顯式的擁塞指示,那么TCP只能利用傳輸過程中獲取的反饋作為隱式擁塞指示,典型反饋信息主要分為丟包事件和往返時延,該類TCP加速技術(shù)通常根據(jù)其中一或兩個維度來判定當前網(wǎng)絡(luò)的擁塞程度,并在發(fā)送端做出相應(yīng)的擁塞控制策略。
丟包事件是最能直觀反映網(wǎng)絡(luò)擁塞的行為,目前大多數(shù)TCP加速技術(shù)都選擇將丟包事件作為擁塞反饋,然而,該類技術(shù)都面臨一個共通的問題:對丟包事件判定不精確,無法區(qū)分擁塞丟包和隨機丟包。只要發(fā)生丟包事件就根據(jù)預(yù)設(shè)參數(shù)降低窗口,這種做法會導(dǎo)致在隨機丟包較多的網(wǎng)絡(luò)中吞吐率很低。
與丟包時間相比,往返時延能夠更加及時地反應(yīng)網(wǎng)絡(luò)擁塞,將往返時延作為擁塞反饋的TCP加速技術(shù)也有一些。該類技術(shù)的思路是:根據(jù)往返時延與網(wǎng)絡(luò)輕載時時延的變化程度來調(diào)整窗口。該類技術(shù)所面臨的問題是:時延測量的不公平性,例如網(wǎng)絡(luò)擁塞時加入的TCP流測得的網(wǎng)絡(luò)輕載時延偏高,這會導(dǎo)致該TCP流的擁塞窗口設(shè)置過大、占用過大的帶寬。
由上分析可知,基于隱式信息反饋的TCP加速技術(shù)依賴于丟包事件和往返時延等信息對網(wǎng)絡(luò)擁塞判定的精確度,無論是擁塞丟包和隨機丟包的判斷錯誤,還是輕載網(wǎng)絡(luò)時延的判定錯誤,都會給TCP的擁塞控制產(chǎn)生負面影響,因此依靠簡單的隱式擁塞信息反饋來調(diào)整TCP擁塞控制難以滿足應(yīng)用的高吞吐率需求。
基于智能數(shù)據(jù)分析的TCP加速技術(shù)
針對上述兩類TCP加速技術(shù)的缺點,華為公司研究設(shè)計了新一代的基于智能數(shù)據(jù)分析的TCP加速技術(shù)——RACE(Rapid, Adjustable, Clever, Efficient),針對每一條TCP流收集與該流相關(guān)的來自于應(yīng)用和網(wǎng)絡(luò)等多個維度的信息,通過設(shè)計智能數(shù)據(jù)分析引擎,將來自應(yīng)用的真實需求信息和來自網(wǎng)絡(luò)的真實狀態(tài)信息分析處理成智能標識擁塞控制信息,指導(dǎo)算法更加精確地判斷網(wǎng)絡(luò)擁塞程度。華為公司提出的RACE首次將智能數(shù)據(jù)分析技術(shù)引入TCP加速技術(shù),克服了傳統(tǒng)TCP加速技術(shù)對網(wǎng)絡(luò)狀況判斷不準確的缺陷,真正能夠做到:窗口快速增長(Rapid)、目標速率可調(diào)(Adjustable)、丟包智能甄別(Clever)和自適應(yīng)調(diào)整窗口達到高通量(Efficient)。
2.1.3 典型部署方案介紹
本節(jié)我們介紹一下,采用華為新一代TCP加速技術(shù)RACE的高通量路由器(High Throughput Router),在實際部署中的常見應(yīng)用場景。如下圖所示,通常我們會采用HTR旁路部署的方案,該方案對現(xiàn)網(wǎng)原有業(yè)務(wù)影響小,方案可靠性高,加速性能上無性能損失。如果客戶加速的流策略比較穩(wěn)定,沒有頻繁調(diào)整的需求,可作為現(xiàn)網(wǎng)部署的首選方案。
圖6 典型HTR部署方案
HTR旁路部署方案:
1. 將加速設(shè)備新增鏈路旁路署在EPC與公網(wǎng)鏈路之間;
2. 調(diào)整上下游設(shè)備的路由策略,針對要加速的視頻流量做ACL策略,讓相應(yīng)的需要加速的流量上下行都經(jīng)過加速設(shè)備;
3. 在HTR設(shè)備上啟用TCP加速功能,代理相應(yīng)的視頻流量,起到端到端加速的效果。
路由及引流策略:
1. 如果要針對某個網(wǎng)外IP內(nèi)容加速,在PE和EPC/PGW上可以匹配相應(yīng)IP段引流到HTR設(shè)備;
2. 如果要針對整個移動數(shù)據(jù)業(yè)務(wù)加速,在PE和EPC/PGW上以PGW的公網(wǎng)IP引流到HTR設(shè)備;
3. 如果要針對整個特定的用戶業(yè)務(wù)加速,要求用戶按固定的地址段映射公網(wǎng)IP,在PE和EPC/PGW上以該公網(wǎng)IP+端口范圍作策略引流到HTR設(shè)備。
2.2 CDN下沉方案
2.2.1 背景
隨著LTE在全球大規(guī)模部署,移動互聯(lián)網(wǎng)高速發(fā)展,移動互聯(lián)網(wǎng)流量將以每年57%的速度增長,預(yù)測2019年移動視頻流量占所有移動數(shù)據(jù)流量的超過70%。這種增長主要將由用戶更加偏好視頻流服務(wù),包括新聞、廣告與社交媒體等在線視頻內(nèi)容日益普及所驅(qū)動,流量的快速增長也對移動承載網(wǎng)提出更高的帶寬要求。
各運營商之間的競爭慢慢聚焦到用戶體驗的競爭,提供最佳體驗的運營商才能持續(xù)獲得商業(yè)成功,F(xiàn)階段,移動視頻寬帶業(yè)務(wù)在高速發(fā)展,更高分辨率的視頻(1080P和4K)逐漸普及,人們觀看視頻也在追求極致體驗,對網(wǎng)絡(luò)E2E時延提出了新的挑戰(zhàn)。正是基于此,華為的CDN下沉方案將CDN內(nèi)容下沉到網(wǎng)絡(luò)各個不同位置,聚焦減少用戶訪問內(nèi)容源的端到端時延,節(jié)省承載帶寬,保障用戶體驗。
2.2.2 CDN下沉的多種方案
a) CDN下沉到基站
內(nèi)容下沉到eNodeB,“零”距離接近用戶,這種方案可最大程度節(jié)省RTT和承載帶寬,但是每個基站部署CDN-Edge,面臨部署成本高,維護難度大的問題;另一方面,基站覆蓋的用戶少、訪問分散,根據(jù)Cache熱點緩存的特性,CDN下沉到基站的命中率會稍低。
圖7 CDN下沉到基站
b) CDN下沉到EPC SGi口
內(nèi)容下沉到EPC SGi出口,部署成本可控,用戶訪問量大,熱點效應(yīng)明顯。然而,這個方案無法節(jié)省MBH的承載帶寬,并且省干傳輸帶來RTT時延較大(3~5ms),給體驗帶來了一定的影響。
圖8 CDN下沉到EPC SGi口
c) CDN下沉到MBH
內(nèi)容下沉到MBH網(wǎng)絡(luò),兼顧RTT時延(節(jié)省省干單向時延3-5ms、EPC單向時延4ms)、部署成本可承受(如地市PTN L2入L3節(jié)點2~7對)、節(jié)省MBH網(wǎng)絡(luò)帶寬(引流的匯聚節(jié)點到EPC之間的鏈路)、用戶訪問內(nèi)容熱點效應(yīng)明顯等特點,是綜合CDN下沉成本與節(jié)省時延效益的折衷考慮結(jié)果。
圖9 CDN下沉到MBH匯聚節(jié)點
3 面向U-vMOS的移動視頻運維方案介紹
3.1 現(xiàn)狀概述
圖10 移動用戶的卡頓投訴維護難
最后,讓我們談?wù)勔苿映休d網(wǎng)絡(luò)運維過程中遇到的問題。隨著LTE網(wǎng)絡(luò)的快速發(fā)展,手機視頻流量在移動網(wǎng)絡(luò)中的份額逐年上升。視頻業(yè)務(wù)體驗對用戶來說至關(guān)重要,然而傳統(tǒng)的網(wǎng)絡(luò)維護手段只關(guān)注網(wǎng)絡(luò)KPI,無法感知用戶的業(yè)務(wù)體驗,往往會出現(xiàn)網(wǎng)絡(luò)KPI很好,但用戶反映體驗很差的情況;同時當用戶投訴時,故障現(xiàn)象可能早已消失,造成問題定位困難。實際上更為常見的是,最終用戶為了避免麻煩、不進行任何投訴,選擇直接關(guān)閉應(yīng)用窗口。這在無形中造成了用戶忠誠度的下降、繼而帶來用戶流失的風險。
本章節(jié)描述針對OTT移動視頻業(yè)務(wù),如何實時監(jiān)控用戶體驗,并在用戶觀看移動視頻發(fā)生卡頓時,能夠?qū)σ苿映休d網(wǎng)進行實時定界定位的運維方案。
3.2 方案描述
圖11 移動視頻實時運維方案
在承載網(wǎng)出口或Gi接口,通過分光或直通的方式部署SIG,SIG通過分析用戶報文直接監(jiān)控用戶體驗。當SIG監(jiān)測到用戶觀看視頻發(fā)生卡頓時,通告給uTraffic,uTraffic還原用戶視頻業(yè)務(wù)報文在承載網(wǎng)的傳輸路徑,并在傳輸路徑上部署管道IPFPM進行故障的定界定位。
用戶視頻卡頓監(jiān)控
SIG通過觀察和分析用戶視頻報文,判斷視頻質(zhì)量是否發(fā)生了劣化。原理如下:
SIG實時計算獲取視頻流已經(jīng)下載的字節(jié)數(shù)、視頻播放的時間、播放器的播放碼率,如果播放碼率與視頻已播放時間大于已經(jīng)下載的字節(jié)數(shù),則表明卡頓發(fā)生了。
網(wǎng)絡(luò)故障定位
uTraffic接收到SIG傳來的用戶卡頓信息后, 向承載網(wǎng)設(shè)備查詢用戶視頻報文傳輸?shù)穆窂健?在用戶視頻報文的傳輸路徑確定后,在各設(shè)備上部署IPFPM檢測設(shè)備的丟包率,最終精確定位故障的設(shè)備。
IPFPM是華為公司提出的隨流的性能監(jiān)控系統(tǒng)。它通過給報文的IP頭染色來提示沿路IPFPM測量點進行性能統(tǒng)計,不插入任何額外報文,并且具有高的精度, 能夠有效監(jiān)控用戶業(yè)務(wù)流的性能狀況。