基于電信IPTV的服務(wù)質(zhì)量監(jiān)測(cè)與實(shí)現(xiàn)

熊 雄，劉 新，葉德建

(復(fù)旦大學(xué)軟件學(xué)院寬帶網(wǎng)絡(luò)與互動(dòng)多媒體實(shí)驗(yàn)室，上海 20120 3)

基于電信IPTV的服務(wù)質(zhì)量監(jiān)測(cè)與實(shí)現(xiàn)

熊 雄，劉 新，葉德建

(復(fù)旦大學(xué)軟件學(xué)院寬帶網(wǎng)絡(luò)與互動(dòng)多媒體實(shí)驗(yàn)室，上海 20120 3)

信息化網(wǎng)絡(luò)的高速發(fā)展對(duì)于網(wǎng)絡(luò)的服務(wù)質(zhì)量提出更高的要求，但目前國內(nèi)缺少一套行之有效的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)來對(duì)IPTV網(wǎng)絡(luò)質(zhì)量進(jìn)行評(píng)估，網(wǎng)絡(luò)數(shù)據(jù)包的抓取與分析對(duì)于網(wǎng)絡(luò)服務(wù)質(zhì)量監(jiān)測(cè)必不可少，而現(xiàn)有的網(wǎng)絡(luò)服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)是以解碼器輸出的數(shù)據(jù)作為網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行分析，解碼器對(duì)于流媒體數(shù)據(jù)的糾錯(cuò)會(huì)使得評(píng)估不準(zhǔn)確。同時(shí)機(jī)頂盒作為IPTV的載體，內(nèi)存和CPU的性能遠(yuǎn)不及PC，導(dǎo)致現(xiàn)有的PC抓包軟件根本無法在機(jī)頂盒上運(yùn)行。針對(duì)這一現(xiàn)狀，基于用戶體驗(yàn)質(zhì)量的評(píng)估，考慮到IPTV上流媒體數(shù)據(jù)和各種控制協(xié)議的組合，采用狀態(tài)機(jī)處理數(shù)據(jù)組合中的各種邏輯，計(jì)算丟包率、MDI指標(biāo)、請(qǐng)求響應(yīng)時(shí)延等參數(shù)供服務(wù)質(zhì)量監(jiān)測(cè)使用，并與傳統(tǒng)網(wǎng)絡(luò)服務(wù)質(zhì)量監(jiān)測(cè)進(jìn)行實(shí)驗(yàn)對(duì)比，結(jié)果證明了監(jiān)測(cè)系統(tǒng)的準(zhǔn)確性。

電信網(wǎng)絡(luò)電視；服務(wù)質(zhì)量；機(jī)頂盒；網(wǎng)絡(luò)抓包；用戶體驗(yàn)質(zhì)量；狀態(tài)機(jī)

1 概述

隨著信息化網(wǎng)絡(luò)高速發(fā)展，網(wǎng)絡(luò)電視(Internet Pr otocol Television, I PTV)的應(yīng)用已經(jīng)成為國內(nèi)網(wǎng)絡(luò)發(fā)展的主流趨勢(shì)，而這也對(duì)網(wǎng)絡(luò)的服務(wù)質(zhì)量提出了更高的要求，如何提高IPTV服務(wù)質(zhì)量這一問題現(xiàn)已成為業(yè)界關(guān)注的焦點(diǎn)。由于IPTV是電視類的媒體業(yè)務(wù)，用戶希望得到如同有線電視的服務(wù)水平，包括頻道切換速度、節(jié)目的圖像質(zhì)量、播放的流暢性等。而傳統(tǒng)的寬帶業(yè)務(wù)質(zhì)量監(jiān)測(cè)側(cè)重于數(shù)據(jù)鏈路層和網(wǎng)絡(luò)層的監(jiān)測(cè)，無法直接反映用戶對(duì)IPTV業(yè)務(wù)的主觀感受，因此不能滿足IPTV質(zhì)量監(jiān)測(cè)的需求[1]。

為了保證IPTV業(yè)務(wù)的高效運(yùn)營，端到端的服務(wù)質(zhì)量保障是電信運(yùn)營商的強(qiáng)烈需求，但無論是視頻質(zhì)量管理還是IP網(wǎng)絡(luò)資源管理，對(duì)電信運(yùn)營商而言都是全新的挑戰(zhàn)，IPTV服務(wù)質(zhì)量保障的最終目標(biāo)是提供理想的用戶體驗(yàn)[2]。在傳統(tǒng)的電信業(yè)務(wù)中服務(wù)質(zhì)量(Quality of Service, QoS)通常指網(wǎng)絡(luò)性能，尤其是網(wǎng)絡(luò)傳輸性能。但I(xiàn)PTV是一種上層應(yīng)用的業(yè)務(wù)，這使得傳統(tǒng)的QoS根本無法滿足對(duì)最終用戶感受的評(píng)估。目前業(yè)界往往采用體驗(yàn)質(zhì)量(Quality of Experience, QoE)一詞來描述面向最終用戶應(yīng)用的業(yè)務(wù)質(zhì)量。QoE在ITU-T P.10/G.100[3]中被定義為最終用戶對(duì)使用的應(yīng)用或業(yè)務(wù)的總體主觀可接受程度，可見QoE相比QoS更強(qiáng)調(diào)最終用戶的業(yè)務(wù)使用感受。

文獻(xiàn)[4]采用模糊理論的方法計(jì)算QoE到QoS的映射。文獻(xiàn)[5]綜述了用戶體驗(yàn)質(zhì)量的模型與評(píng)價(jià)方法等方面的工作，介紹了QoE領(lǐng)域的研究現(xiàn)狀和進(jìn)展。文獻(xiàn)[6]則概述了IPTV幾種常見的QoE業(yè)務(wù)質(zhì)量指標(biāo)。文獻(xiàn)[7]在理論層面上對(duì)于IPTV質(zhì)量監(jiān)測(cè)進(jìn)行了框架性的描述。目前對(duì)于IPTV的服務(wù)質(zhì)量進(jìn)行監(jiān)測(cè)還只是停留在理論階段，在此前提下，本文參考電信IPTV的規(guī)范，在對(duì)QoE的研究基礎(chǔ)上，通過對(duì)網(wǎng)絡(luò)原始數(shù)據(jù)包的抓取與分析達(dá)到對(duì)IPTV服務(wù)質(zhì)量的監(jiān)測(cè)。

2 IPTV服務(wù)質(zhì)量監(jiān)測(cè)的設(shè)計(jì)思路

2.1 設(shè)計(jì)目標(biāo)

主觀QoE主要是用戶對(duì)IPTV業(yè)務(wù)使用中的主觀感受，這些感受是對(duì)服務(wù)接入速度、內(nèi)容質(zhì)量、使用操作便利性等多方面的綜合，如視頻內(nèi)容的清晰度和流暢程度；直播頻道的切換速度；VOD節(jié)目進(jìn)行快進(jìn)、快退和暫停操作的響應(yīng)速度；業(yè)務(wù)請(qǐng)求的響應(yīng)速度、業(yè)務(wù)內(nèi)容的完整性等。

監(jiān)測(cè)系統(tǒng)的設(shè)計(jì)目標(biāo)是：通過對(duì)網(wǎng)絡(luò)包的實(shí)時(shí)監(jiān)控，獲取數(shù)據(jù)包丟包率、媒體傳輸指標(biāo)(Media Del ivery Index, MDI)、請(qǐng)求響應(yīng)時(shí)延(Request Response Time, RRT)等QoS參數(shù)，并將參數(shù)與IPTV中對(duì)于直播和點(diǎn)播中的各種操作進(jìn)行組合，以便對(duì)于IPTV服務(wù)質(zhì)量作出總體上的評(píng)估。同時(shí)模塊具有以下特性：

(1)準(zhǔn)確性：對(duì)于數(shù)據(jù)包的抓取和分析可以準(zhǔn)確地反映網(wǎng)絡(luò)質(zhì)量的變化情況。

(2)可控性：監(jiān)測(cè)系統(tǒng)在可接受的CPU和內(nèi)存消耗范圍內(nèi)運(yùn)行。

(3)實(shí)時(shí)性：監(jiān)測(cè)系統(tǒng)必須實(shí)時(shí)地反映網(wǎng)絡(luò)變化情況，這一點(diǎn)也在準(zhǔn)確性中體現(xiàn)。

2.2 系統(tǒng)設(shè)計(jì)

整個(gè)IPTV服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)分為3個(gè)部分：QoSCapture, QoSAnalyser和QoSLoader。整體布局如圖1所示。

圖1 IP TV監(jiān)測(cè)系統(tǒng)

QoSCapture在整個(gè)監(jiān)測(cè)系統(tǒng)中負(fù)責(zé)網(wǎng)絡(luò)抓包的任務(wù)，并將抓取到的數(shù)據(jù)包信息整理后傳遞給QoSAnalyser，再由QoSAnalyser以統(tǒng)一的格式寫入CSV文件并將文件上傳至日志服務(wù)器，QoSLoader則負(fù)責(zé)控制QoSAnalyser和QoS Capture的運(yùn)行并從更新服務(wù)器獲取機(jī)頂盒配置文件的更新信息。這3個(gè)模塊均在機(jī)頂盒上運(yùn)行。本文著重介紹QoS Capture模塊的設(shè)計(jì)。

考慮到在流媒體實(shí)時(shí)傳播中，數(shù)據(jù)包與各種控制協(xié)議的配合，QoSCapture只抓取特定的數(shù)據(jù)包進(jìn)行分析。為了抓取本地向網(wǎng)絡(luò)發(fā)送的控制包，首先將網(wǎng)卡設(shè)置為混雜模式，然后根據(jù)IP地址在抓取到的數(shù)據(jù)包中篩選出和本機(jī)相關(guān)的包進(jìn)行分析。抓取的數(shù)據(jù)包類型主要包括Internet組管理協(xié)議(Internet Group Management Protocol, IGMP)、傳輸控制協(xié)議(Transmission Control Protocol, TCP)、用戶數(shù)據(jù)包協(xié)議(User Datagram Protocol, UDP)包。其中，IGMP[8]包用來傳輸組播命令；TCP[9]包根據(jù)不同的控制協(xié)議又分為：超文本傳送協(xié)議(Hypertext T ransport Pro tocol, HTTP)和實(shí)時(shí)流傳輸協(xié)議(Real Time Streaming Protocol, RTSP)包，HTTP[10]用來傳輸認(rèn)證信息和網(wǎng)頁請(qǐng)求，RTSP[11]包用來傳輸點(diǎn)播命令；UDP包中只對(duì)使用實(shí)時(shí)傳輸協(xié)議[12](Real-time Transport Protocol, RTP)的流媒體數(shù)據(jù)包進(jìn)行分析。

在整個(gè)抓包過程中，為了得到更準(zhǔn)確的監(jiān)控信息，QoS Capture按照電信提供的IPTV3.0規(guī)范對(duì)抓取的包按照控制協(xié)議進(jìn)行歸類，分別統(tǒng)計(jì)組播和點(diǎn)播下流媒體數(shù)據(jù)包的傳輸情況，并且將對(duì)于使用HTTP協(xié)議傳輸?shù)臄?shù)據(jù)包需要統(tǒng)計(jì)失敗的次數(shù)以及失敗的原因。設(shè)計(jì)中QoSCapture使用狀態(tài)機(jī)來統(tǒng)計(jì)不同數(shù)據(jù)之間的組合。

2.2.1 質(zhì)量監(jiān)測(cè)描述

在質(zhì)量監(jiān)測(cè)系統(tǒng)中，QoSCapture需要對(duì)具體的數(shù)據(jù)信息做如下統(tǒng)計(jì)：

(1)在程序中，以5 s為一個(gè)統(tǒng)計(jì)周期，播放視頻時(shí)每一統(tǒng)計(jì)周期需要向QoSAnalyser發(fā)送該周期的數(shù)據(jù)統(tǒng)計(jì)信息。如果此時(shí)處于正常播放狀態(tài)，則發(fā)送該周期統(tǒng)計(jì)數(shù)據(jù)，包括周期開始和結(jié)束時(shí)間、收到的數(shù)據(jù)包數(shù)、丟包數(shù)、數(shù)據(jù)量、最大最小PCR值等；如果處于暫停、快進(jìn)、快退狀態(tài)，則發(fā)送一個(gè)填充包。如果一個(gè)統(tǒng)計(jì)周期內(nèi)既有正常播放也有暫停、快進(jìn)或快退操作，則舍棄該周期內(nèi)的統(tǒng)計(jì)數(shù)據(jù)，只發(fā)送一個(gè)填充包。視頻結(jié)束播放時(shí)通知QoSAnalyser。小窗口不統(tǒng)計(jì)。

(2)對(duì)每一股視頻流，記錄其類型(組播或點(diǎn)播)及請(qǐng)求響應(yīng)時(shí)間(RRT)。組播請(qǐng)求響應(yīng)時(shí)間從發(fā)送IGMP開始，到收到第一個(gè)視頻包結(jié)束。點(diǎn)播請(qǐng)求響應(yīng)時(shí)間從發(fā)RTSP請(qǐng)求開始，到收到第一個(gè)視頻包結(jié)束。根據(jù)電信規(guī)范時(shí)移電視RRT不統(tǒng)計(jì)，且存在請(qǐng)求響應(yīng)時(shí)間超過一定閾值從而認(rèn)為其請(qǐng)求失敗的情況，但為使QoSAnalyser能對(duì)屬于該視頻流的數(shù)據(jù)信息進(jìn)行處理，每一股視頻流都需要在其第一筆統(tǒng)計(jì)周期信息被發(fā)送給QoSAnalyser之前先發(fā)送一個(gè)記錄其RRT的結(jié)構(gòu)體，根據(jù)結(jié)構(gòu)體內(nèi)容可區(qū)分上述3種情況。

(3)在收到HTTP包時(shí)進(jìn)行分析記錄，以幫助QoS Analyser統(tǒng)計(jì)HTTP請(qǐng)求次數(shù)、HTTP請(qǐng)求失敗次數(shù)、認(rèn)證次數(shù)、認(rèn)證失敗次數(shù)。

(4)幫助QoSAnalyser統(tǒng)計(jì)其他信息，如視頻播放過程中(包括組播和單播)的數(shù)據(jù)出錯(cuò)，導(dǎo)致無法再播放的次數(shù)。

(5)QoSCapture還需要定義時(shí)鐘來驅(qū)動(dòng)QoSAnalyser定時(shí)生成和上報(bào)CSV文件。

(6)QoSCapture還需要記錄當(dāng)前機(jī)頂盒的工作狀態(tài)，據(jù)此處理抓獲的網(wǎng)口數(shù)據(jù)并與QoSAnalyser交互，并且根據(jù)網(wǎng)口數(shù)據(jù)的分析結(jié)果維護(hù)和更新機(jī)頂盒工作狀態(tài)。

2.2.2 狀態(tài)機(jī)的設(shè)計(jì)

根據(jù)流媒體傳輸過程中的實(shí)際情況，網(wǎng)口抓包模塊使用狀態(tài)機(jī)描述各種數(shù)據(jù)包之間的組合，狀態(tài)機(jī)的設(shè)計(jì)如下：

(1)idleState

空閑狀態(tài)，機(jī)頂盒不播放任何視頻，例如用戶正在瀏覽EPG頁面。

(2)multicastWaitDataState

組播發(fā)出第一個(gè)IGMP join包后轉(zhuǎn)到該狀態(tài)；在該狀態(tài)收到第一個(gè)數(shù)據(jù)包后可以計(jì)算該組播流的RRT，并轉(zhuǎn)到multicastPlayingState狀態(tài)。

(3)multicastPlayingState

組播播放中的狀態(tài)，在該狀態(tài)下每一統(tǒng)計(jì)周期末QoSCapture需要發(fā)送該周期的統(tǒng)計(jì)數(shù)據(jù)給QoSAnalyser；在該狀態(tài)收到IGMP leave包時(shí)組播結(jié)束，轉(zhuǎn)到idleState。

點(diǎn)播時(shí)機(jī)頂盒與平臺(tái)的交互較為復(fù)雜。為減少狀態(tài)機(jī)的狀態(tài)個(gè)數(shù)以對(duì)其進(jìn)行一定程度的簡化，對(duì)RTSP中請(qǐng)求的發(fā)出及其響應(yīng)均放在一個(gè)狀態(tài)中進(jìn)行處理，可以在狀態(tài)處理函數(shù)中使用靜態(tài)局部變量表示子狀態(tài)。以下幾個(gè)點(diǎn)播過程啟動(dòng)過程中的狀態(tài)均采用了該方法進(jìn)行子狀態(tài)的合并。

(4)vodWaitDescribeState

抓到第一個(gè)RTSP D ESCRIBE包時(shí)進(jìn)入該狀態(tài)，收到第二個(gè)DESCRIBE的成功響應(yīng)后進(jìn)入vodWaitSetupState。

(5)vodWaitSetupState

在該狀態(tài)中等待SETUP的發(fā)送，在收到SETUP的成功響應(yīng)后進(jìn)入vodWaitPlayState。

(6)vodWaitPlayState

若當(dāng)前是一股普通的點(diǎn)播流，則在該狀態(tài)中等待非快進(jìn)、快退的PLAY的發(fā)送，并在收到PLAY的成功響應(yīng)后進(jìn)入vodWaitDataState。根據(jù)目前的調(diào)研情況，除了華為高清以外的其他機(jī)頂盒其時(shí)移電視操作中會(huì)在該狀態(tài)直接抓到PAUSE或者快進(jìn)、快退的PLAY包，可據(jù)此區(qū)分出時(shí)移電視和普通的點(diǎn)播流，從而發(fā)送不同的RRT信息(時(shí)移電視RRT不統(tǒng)計(jì))。

(7)vodWaitDataState

若當(dāng)前是一股普通的點(diǎn)播流，則在該狀態(tài)中等待點(diǎn)播流的第一個(gè)數(shù)據(jù)包，計(jì)算出RRT后進(jìn)入vodPlayingState。華為高清機(jī)頂盒會(huì)在該狀態(tài)直接抓到PAUSE或快進(jìn)、快退的PLAY包，考慮到觀看普通點(diǎn)播流時(shí)不太可能在SETUP成功之后、RTP數(shù)據(jù)到達(dá)機(jī)頂盒之前馬上進(jìn)行暫?；蚩爝M(jìn)、快退操作，也可據(jù)此區(qū)分出時(shí)移電視和普通的點(diǎn)播流。

點(diǎn)播播放中的狀態(tài)，在該狀態(tài)下每一統(tǒng)計(jì)周期末QoS Capture需要發(fā)送該周期的統(tǒng)計(jì)信息給QoSAnalyser；在該狀態(tài)收到TEARDOWN包的成功響應(yīng)后點(diǎn)播結(jié)束，轉(zhuǎn)到idleState。

(9)vodShiftingState

普通點(diǎn)播流或是時(shí)移電視暫停、快進(jìn)、快退時(shí)，狀態(tài)機(jī)均處于該狀態(tài)，此時(shí)QoSCapture應(yīng)為每一個(gè)統(tǒng)計(jì)周期發(fā)送一個(gè)填充包給QoSAnalyser。

(10)smallWindowIdleState

在HTTP響應(yīng)包中發(fā)現(xiàn)小窗口后進(jìn)入此狀態(tài)，表示下一股視頻流為小窗口播放狀態(tài)，不統(tǒng)計(jì)相關(guān)信息；抓到視頻流開始信息(join或DESCRIBE)時(shí)轉(zhuǎn)到smallWindow PlayingState?？紤]到小窗口也可能播放失敗導(dǎo)致實(shí)際退出小窗口時(shí)網(wǎng)口沒有相關(guān)退出信息，小窗口視頻流啟動(dòng)時(shí)的信息也應(yīng)該加以記錄以供smallWindowPlayingState中收到新的視頻流啟動(dòng)包時(shí)加以比對(duì)。

(11)smallWindowPlayingState

按照電信提供的接口規(guī)范、小窗口播放狀態(tài)，不進(jìn)行視頻數(shù)據(jù)的統(tǒng)計(jì)和發(fā)送。抓到視頻流結(jié)束信息(leave或TEARDOWN)時(shí)回到idleState?？紤]到實(shí)際退出小窗口時(shí)可能沒有相關(guān)退出信息，在該狀態(tài)中收到不屬于當(dāng)前視頻流的視頻啟動(dòng)信息時(shí)需要根據(jù)該啟動(dòng)信息之前是否解析到新的小窗口標(biāo)志選擇留在當(dāng)前狀態(tài)或直接進(jìn)入相應(yīng)的視頻啟動(dòng)狀態(tài)。

如果說打字方面是“婦敲夫?qū)彙保敲闯鹄デ鷣?，則是“婦唱夫隨”了。張?jiān)屎屯砟昱c俞平伯等人一起成立了昆曲研習(xí)社，周有光常常陪同她去參加曲社活動(dòng)。張?jiān)屎?0歲生日時(shí),周有光送了她一套《湯顯祖全集》，張?jiān)屎托睦锾鹱套痰模骸八媸嵌业男乃?。?/p>

而在整個(gè)QoSCapture運(yùn)行過程中，程序始終處于這些狀態(tài)中的某一種。

3 狀態(tài)的切換

狀態(tài)之間的切換是整個(gè)模塊設(shè)計(jì)中的難點(diǎn)，主要切換分為組播、小窗口和點(diǎn)播的切換。組播的切換如圖2所示。

圖2 組播中狀態(tài)的切換

正常組播的播放流程切換只是在idleState、multicast WaitData和multicastPlaying之間進(jìn)行。小窗口的切換過程如圖3所示。

圖3 小窗口切換

按照電信規(guī)范，小窗口播放的數(shù)據(jù)不參與統(tǒng)計(jì)，所以在設(shè)計(jì)中小窗口切換必須體現(xiàn)。點(diǎn)播的切換過程比較復(fù)雜，如圖4所示。

圖4 點(diǎn)播中狀態(tài)的切換

因?yàn)辄c(diǎn)播狀態(tài)中涉及到快進(jìn)、快退、暫停等諸多操作，所以圖4中省略了一些狀態(tài)內(nèi)部子狀態(tài)的轉(zhuǎn)換以及一些狀態(tài)收到TEARDOWN請(qǐng)求的成功響應(yīng)后轉(zhuǎn)入idleState的狀態(tài)轉(zhuǎn)換。

4 實(shí)驗(yàn)結(jié)果及分析

為了測(cè)試服務(wù)質(zhì)量檢測(cè)系統(tǒng)的性能以及分析結(jié)果的準(zhǔn)確性，將系統(tǒng)放在華為高清機(jī)頂盒EC5108上運(yùn)行，機(jī)頂盒配置為：CPU為BMIPS4380 V4.4 FPU V0.1，CPU主頻為404.48 MHz，內(nèi)存為125 MB，并在網(wǎng)絡(luò)環(huán)境中加入仿真模擬器，模擬網(wǎng)絡(luò)的丟包和延時(shí)。

在程序運(yùn)行過程中，對(duì)機(jī)頂盒進(jìn)行隨機(jī)操作，如點(diǎn)播、直播、快進(jìn)、快退等，并以5 s為周期對(duì)CPU和內(nèi)存的占用率進(jìn)行記錄，如圖5所示。

圖5 C PU和內(nèi)存占用率

在程序運(yùn)行過程中，程序?qū)PU的占用率基本穩(wěn)定在0.2%～3%之間，滿足電信規(guī)定的CPU占用率維持在10%以下的要求，而內(nèi)存占用率始終維持在0.2%，即消耗內(nèi)存0.25 MB，滿足電信規(guī)定的內(nèi)存占用率在5%以下的要求。在程序運(yùn)行中，使用損傷儀對(duì)網(wǎng)絡(luò)丟包進(jìn)行模擬，模擬結(jié)果如圖6所示。

圖6 丟包率統(tǒng)計(jì)

在測(cè)試中，使用損傷儀分別對(duì)網(wǎng)絡(luò)進(jìn)行0.2%的丟包、0.5%的丟包和1%的丟包模擬，程序以5 s為一個(gè)周期對(duì)收到的數(shù)據(jù)包總數(shù)和丟包個(gè)數(shù)進(jìn)行統(tǒng)計(jì)，并依此算出丟包率。對(duì)于監(jiān)測(cè)到的丟包率做出統(tǒng)計(jì)：在0.2%丟包的情況下，測(cè)試結(jié)果基本穩(wěn)定在0.2%左右；在0.5%的情況下，測(cè)試結(jié)果在0.46%～0.52%的范圍內(nèi)；在1%的情況下，測(cè)試結(jié)果在0.95%～1.05%的范圍內(nèi)。在使用損傷儀模擬的過程中，損傷儀給出的模擬丟包率是一個(gè)平均值，而包的丟失在整個(gè)程序運(yùn)行過程中是隨機(jī)出現(xiàn)的，這就使得模擬丟包率越大，而在實(shí)際抓包過程中丟包率的計(jì)算結(jié)果波動(dòng)也會(huì)越大。

通過主觀用戶體驗(yàn)評(píng)測(cè)，給出了視頻播放質(zhì)量大致對(duì)應(yīng)的丟包率范圍，如表1所示。

表1 主觀用戶體驗(yàn)與丟包率范圍

同時(shí)對(duì)程序運(yùn)行過程在正常情況下和增加時(shí)延的情況下的RRT進(jìn)行了統(tǒng)計(jì)，統(tǒng)計(jì)情況描述如圖7所示。

圖7 RRT統(tǒng)計(jì)

正常情況下組播RRT的測(cè)試結(jié)果大部分在0～300 ms范圍內(nèi)，點(diǎn)播RRT測(cè)試結(jié)果大部分是在200 ms～700 ms范圍內(nèi)，電信規(guī)范給出的正常RRT應(yīng)維持在1 s以內(nèi)，超過1 s將會(huì)造成用戶體驗(yàn)質(zhì)量的下降。在增加時(shí)延后的網(wǎng)絡(luò)，在RRT測(cè)試中也有所反映，如在增加網(wǎng)絡(luò)延時(shí)1 s和2 s的環(huán)境下，RRT的測(cè)試結(jié)果完全能夠反映出增加的時(shí)延。

在保證提取到的數(shù)據(jù)準(zhǔn)確的前提下，本文將基于用戶體驗(yàn)質(zhì)量設(shè)計(jì)的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)，對(duì)于新增加的監(jiān)測(cè)內(nèi)容與傳統(tǒng)的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)進(jìn)行對(duì)比，并描述新增監(jiān)測(cè)內(nèi)容對(duì)于用戶體驗(yàn)質(zhì)量評(píng)估的重要性。

流媒體服務(wù)器IP的記錄：在整個(gè)服務(wù)質(zhì)量監(jiān)測(cè)過程中，不同的節(jié)目將因?yàn)榱髅襟w數(shù)據(jù)傳送的速度不同而使用不同的標(biāo)準(zhǔn)對(duì)用戶體驗(yàn)質(zhì)量進(jìn)行評(píng)估。例如比特率高的片源對(duì)于媒體丟包速率容忍度更高。但傳統(tǒng)的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)只能夠反映出片源碼率的不同，并不能對(duì)不同的流媒體服務(wù)器做不同的評(píng)估。表2給出了不同片源對(duì)于媒體丟包速率的可接受范圍，電信標(biāo)準(zhǔn)將碼率超過4 Mb/s的片源定義為高清片源。

表2 最大可接受媒體丟包速率 (個(gè)·s–1)

頻道切換的記錄：在頻道切換過程中，服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)會(huì)記錄下新頻道的請(qǐng)求響應(yīng)時(shí)延；而傳統(tǒng)的服務(wù)質(zhì)量監(jiān)測(cè)只能夠記錄下單位時(shí)間接收到的數(shù)據(jù)包量在這段時(shí)間內(nèi)一個(gè)減少到增多的過程。對(duì)于這一過程，接收到數(shù)據(jù)包的數(shù)量變化并不能正確反映出用戶體驗(yàn)質(zhì)量的變化。而在頻道切換過程中請(qǐng)求響應(yīng)時(shí)延卻能在一定程度上影響用戶的體驗(yàn)。在切換過程中，對(duì)于2種監(jiān)控系統(tǒng)獲取的丟包個(gè)數(shù)如圖8所示。

圖8 頻道切換丟包數(shù)的獲取

在頻道切換過程中，因?yàn)榱髅襟w服務(wù)器的變換將導(dǎo)致流媒體數(shù)據(jù)包的序號(hào)出現(xiàn)跳躍，使用傳統(tǒng)的質(zhì)量監(jiān)測(cè)系統(tǒng)將會(huì)反映為出現(xiàn)大量丟包從而影響對(duì)于用戶體驗(yàn)的評(píng)估。

電子節(jié)目菜單(Electronic Program Gui de, EPG)頁面小窗口播放的記錄：小窗口的播放并不屬于用戶的播放需求，所以小窗口的播放并不能真正反映用戶體驗(yàn)質(zhì)量，在電信規(guī)范中，這一段時(shí)間的播放也將不被納入統(tǒng)計(jì)。而傳統(tǒng)的視頻服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)會(huì)將小窗口的播放等同于正常播放進(jìn)行統(tǒng)計(jì)。

視頻點(diǎn)播中時(shí)移操作的記錄：在視頻點(diǎn)播中的時(shí)移操作如快進(jìn)、快退、暫停等，會(huì)使得視頻播放非常不流暢，但這是播放器對(duì)于時(shí)移操作的正常反應(yīng)，因此，時(shí)移操作過程中也不會(huì)對(duì)用戶體驗(yàn)質(zhì)量進(jìn)行評(píng)估。而傳統(tǒng)的視頻服務(wù)質(zhì)量卻并不能對(duì)此做出區(qū)分。

綜上所述，使用傳統(tǒng)的視頻服務(wù)質(zhì)量監(jiān)測(cè)方案并不能滿足對(duì)于用戶體驗(yàn)質(zhì)量進(jìn)行評(píng)估的需求。本文描述的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)對(duì)于不同的流媒體服務(wù)器發(fā)送的數(shù)據(jù)進(jìn)行區(qū)分，并記錄下整個(gè)播放過程中，用戶對(duì)于播放器的操作，使得參數(shù)對(duì)于用戶體驗(yàn)質(zhì)量的評(píng)估有更高的契合度。

5 結(jié)束語

本文在傳統(tǒng)服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)架構(gòu)上，增加了對(duì)于IPTV使用過程中的各種操作的監(jiān)控，使得通過網(wǎng)絡(luò)抓取到的數(shù)據(jù)更易于對(duì)用戶體驗(yàn)質(zhì)量進(jìn)行評(píng)估，目前該系統(tǒng)已成功應(yīng)用于和電信合作的各種型號(hào)的機(jī)頂盒。在下一步工作中，將參照主觀用戶體驗(yàn)質(zhì)量對(duì)提取的參數(shù)進(jìn)行擬合，以便對(duì)用戶體驗(yàn)質(zhì)量進(jìn)行數(shù)值化評(píng)級(jí)，并針對(duì)得到的用戶體驗(yàn)評(píng)級(jí)結(jié)果進(jìn)行相應(yīng)的策略提升研究，從而最終達(dá)到提高用戶體驗(yàn)質(zhì)量的目的。

[1] 羅斯青, 段保通. IPTV 端到端業(yè)務(wù)質(zhì)量監(jiān)測(cè)技術(shù)研究[J].電信科學(xué), 2008, (3): 37-41.

[2] 洪 眉, 李林江, 王志中, 等. 面向用戶感知的IPTV服務(wù)質(zhì)量保障方案[J]. 通信技術(shù), 2012, 45(12): 104-107.

[3] ITU. ITU-T P.10/G.100-2006 Vocabulary for Performance and Quality of Service[S]. 2006.

[4] 倪 萍, 廖建新, 朱曉民, 等. 一種基于QoS的QoE到SLA映射方法[J]. 電子與信息學(xué)報(bào), 2010, 32(6): 1463-1468.

[5] 林 闖, 胡 杰, 孔祥震. 用戶體驗(yàn)質(zhì)量(QoE)的模型與評(píng)價(jià)方法[J]. 計(jì)算機(jī)學(xué)報(bào), 2012, 35(1): 1-15.

[6] 徐嘯濤, 俞金秀, 胡蕊莉. IPTV業(yè)務(wù)質(zhì)量指標(biāo)研究[J]. 計(jì)算機(jī)與網(wǎng)絡(luò), 2012, 38(19): 65-67.

[7] 魏 敏. IPT V 質(zhì)量監(jiān)測(cè)的研究與實(shí)現(xiàn)[J]. 福建電腦, 201 1, (7): 123-124.

[8] Fenner W. Internet Group Manageme nt P rotocol, V ersion 2[EB/OL]. (1997-11-15). http://w ww.embed.com.cn/protocol/ rfc/rfc2236.txt.

[9] Embed Corporation. Transmission Control Pr otocol[EB/OL]. (2009-10-10). h ttp://www.embed.com.cn/protocol/rfc/rfc793. txt.

[10] Embed Cor poration. HTTP Authentication: Basic and Digest Access Authenti cation[EB/OL]. (2004-06-22). http://www. embed.com.cn/protocol/rfc/rfc2617.txt.

[11] IETF. Real Time Streaming Protocol(RTSP)[EB/OL]. (1998-04-20). http://www.ietf.org/rfc/rfc2326.txt.

[12] IETF. R TP: A Transport Protocol for R eal-time A pplications[EB/OL]. (2003-07-08). http://www.ietf.org/rfc/rfc3550. txt.

編輯 顧逸斐

Monitoring and Implementation of QoS Based on IPTV of Telecom

XIONG Xiong, LIU Xin, YE De-jian

(Laboratory of Broadband Networks and Interactive Multimedia, School of Software, Fudan University, Shanghai 201203, China)

As the rapid development of information technology, the Quality of Service(QoS) of the network must be better. But it is lack of a well-established service quality monitoring system to assess the quality of the IPTV network. The data packet’s capture and analysis for the QoS of the netw ork monitoring is essen tial, and existing network monitoring system based on the decoder data flow which makes the assessment inaccurate. Set-top boxes, as the carrier of IPTV, whose memory an d CPU performance is far less than t he PC, the p acket capture software on the PC cannot run on the set-top box. Based on the quality of experience, this paper designs set capture program running on the se t-top box, uses th e state machine to describe th e logic between the data and the c ontrol information, and clas sifies data packets for IPTV on control information to calculate the packet loss rate, MDI, the request response time and other parameters for QoS of monitoring system. Compared with the traditional monitor system, the result proves the monitor system has accuracy.

Internet Protocol Television(IPTV) of Telecom; Quality of Service(QoS); set-top box; network packet capture; quality of user experience; state machine

10.3969/j.issn.1000-3428.2014.05.053

上?？萍及l(fā)展攻關(guān)計(jì)劃基金資助項(xiàng)目(12511503002)。

熊 雄(1987－)，男，碩士研究生，主研方向：網(wǎng)絡(luò)多媒體技術(shù)；劉 新，講師；葉德建，副教授。

2013-04-08

2013-05-27E-mail：10212010029@fudan.edu.cn

1000-3428(2014)05-0257-05

A

TP391