熊 雄，劉 新，葉德建

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

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

熊 雄，劉 新，葉德建

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

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

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

1 概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

考慮到在流媒體實時傳播中，數(shù)據(jù)包與各種控制協(xié)議的配合，QoSCapture只抓取特定的數(shù)據(jù)包進行分析。為了抓取本地向網(wǎng)絡(luò)發(fā)送的控制包，首先將網(wǎng)卡設(shè)置為混雜模式，然后根據(jù)IP地址在抓取到的數(shù)據(jù)包中篩選出和本機相關(guā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)和實時流傳輸協(xié)議(Real Time Streaming Protocol, RTSP)包，HTTP[10]用來傳輸認證信息和網(wǎng)頁請求，RTSP[11]包用來傳輸點播命令；UDP包中只對使用實時傳輸協(xié)議[12](Real-time Transport Protocol, RTP)的流媒體數(shù)據(jù)包進行分析。

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

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

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

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

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

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

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

(5)QoSCapture還需要定義時鐘來驅(qū)動QoSAnalyser定時生成和上報CSV文件。

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

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

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

(1)idleState

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

(2)multicastWaitDataState

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

(3)multicastPlayingState

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

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

(4)vodWaitDescribeState

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

(5)vodWaitSetupState

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

(6)vodWaitPlayState

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

(7)vodWaitDataState

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

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

(9)vodShiftingState

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

(10)smallWindowIdleState

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

(11)smallWindowPlayingState

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

如果說打字方面是“婦敲夫?qū)彙保敲闯鹄デ鷣?，則是“婦唱夫隨”了。張允和晚年與俞平伯等人一起成立了昆曲研習(xí)社，周有光常常陪同她去參加曲社活動。張允和70歲生日時,周有光送了她一套《湯顯祖全集》，張允和心里甜滋滋的：“他真是懂我的心思?！?/p>

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

3 狀態(tài)的切換

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

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

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

圖3 小窗口切換

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

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

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

4 實驗結(jié)果及分析

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

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

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

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

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

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

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

表1 主觀用戶體驗與丟包率范圍

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

圖7 RRT統(tǒng)計

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

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

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

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

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

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

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

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

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

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

5 結(jié)束語

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

[1] 羅斯青, 段保通. IPTV 端到端業(yè)務(wù)質(zhì)量監(jiān)測技術(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é)報, 2010, 32(6): 1463-1468.

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

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

[7] 魏 敏. IPT V 質(zhì)量監(jiān)測的研究與實現(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)計劃基金資助項目(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