999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

移動(dòng)網(wǎng)絡(luò)視頻傳輸速率自適應(yīng)控制技術(shù)的研究

2016-02-24 09:27:33黃仁樂王瑩煜

陳 飛,黃仁樂,李 藝,王瑩煜

(1.北京華電天益信息科技有限公司,北京 102200;2.國(guó)網(wǎng)北京市電力公司,北京 100031;3.北京科東電力控制系統(tǒng)有限責(zé)任公司,北京 100085)

移動(dòng)網(wǎng)絡(luò)視頻傳輸速率自適應(yīng)控制技術(shù)的研究

陳 飛1,黃仁樂2,李 藝1,王瑩煜3

(1.北京華電天益信息科技有限公司,北京 102200;2.國(guó)網(wǎng)北京市電力公司,北京 100031;3.北京科東電力控制系統(tǒng)有限責(zé)任公司,北京 100085)

目前移動(dòng)終端上的視頻傳輸與交互技術(shù)得到了廣泛應(yīng)用,但由于移動(dòng)網(wǎng)絡(luò)帶寬波動(dòng)等原因,網(wǎng)絡(luò)中的可用帶寬往往會(huì)小于視頻的傳輸速率,造成視頻在傳輸時(shí)出現(xiàn)丟包的情況,對(duì)視頻傳輸與交互的質(zhì)量產(chǎn)生了較大影響。因而如何根據(jù)網(wǎng)絡(luò)狀態(tài)的變化實(shí)時(shí)地調(diào)整視頻的傳輸速率,從而降低傳輸過程中的丟包率,保證視頻傳輸與交互的質(zhì)量,具有至關(guān)重要的意義。針對(duì)視頻傳輸對(duì)于移動(dòng)網(wǎng)絡(luò)環(huán)境的特殊要求,設(shè)計(jì)了一種適用于移動(dòng)網(wǎng)絡(luò)視頻傳輸?shù)淖赃m應(yīng)速率控制方法。該方法將TCP協(xié)議擁塞控制方法進(jìn)行了改進(jìn),在視頻傳輸?shù)倪^程中依據(jù)網(wǎng)絡(luò)狀態(tài)的變化情況動(dòng)態(tài)地調(diào)整視頻的傳輸速率。仿真實(shí)驗(yàn)結(jié)果表明,該方法能夠保證傳輸速率在一定范圍內(nèi)平穩(wěn)變化,提高了網(wǎng)絡(luò)可用帶寬的利用率,降低了傳輸過程中的丟包率,基本能夠滿足移動(dòng)網(wǎng)絡(luò)環(huán)境下對(duì)于視頻傳輸與交互質(zhì)量的要求。

移動(dòng)網(wǎng)絡(luò);視頻傳輸;速率控制;自適應(yīng);反饋控制

0 引 言

隨著移動(dòng)網(wǎng)絡(luò)及移動(dòng)終端設(shè)備的飛速發(fā)展與普及,移動(dòng)網(wǎng)絡(luò)視頻應(yīng)用越來越受到廣大用戶的歡迎。通過移動(dòng)網(wǎng)絡(luò)視頻應(yīng)用,用戶不僅可以隨時(shí)隨地點(diǎn)播與收看視頻節(jié)目,還可及時(shí)與家人、朋友及商業(yè)伙伴等進(jìn)行溝通與交互,這也使得近年來人們對(duì)于移動(dòng)網(wǎng)絡(luò)視頻應(yīng)用的需求越來越大,對(duì)于其服務(wù)質(zhì)量的要求也越來越高。然而當(dāng)大量的視頻數(shù)據(jù)在網(wǎng)絡(luò)中傳輸時(shí),會(huì)占據(jù)大量的網(wǎng)絡(luò)帶寬,而移動(dòng)網(wǎng)絡(luò)的可用帶寬本身較窄,且?guī)挷▌?dòng)較大,導(dǎo)致網(wǎng)絡(luò)中經(jīng)常出現(xiàn)擁塞,這對(duì)于移動(dòng)網(wǎng)絡(luò)視頻的正常傳輸與質(zhì)量保證產(chǎn)生了很大的影響,可能造成視頻畫面出現(xiàn)延遲或音視頻數(shù)據(jù)不同步等現(xiàn)象[1-4]。因而如何根據(jù)移動(dòng)網(wǎng)絡(luò)的狀態(tài)動(dòng)態(tài)地調(diào)整視頻傳輸?shù)乃俾剩WC所傳輸?shù)囊曨l數(shù)據(jù)的完整性和質(zhì)量,已成為近年來廣泛研究的一個(gè)課題。

目前在傳輸速率控制領(lǐng)域,應(yīng)用最廣泛的是TCP協(xié)議的擁塞控制機(jī)制。TCP協(xié)議的擁塞控制機(jī)制的核心思想就是“線性增加,乘積減少”,即當(dāng)網(wǎng)絡(luò)中尚未出現(xiàn)擁塞時(shí),發(fā)送速率呈線性增加,而當(dāng)網(wǎng)絡(luò)中出現(xiàn)擁塞時(shí),發(fā)送速率以一定倍數(shù)減小[5]。

對(duì)于TCP協(xié)議來說,由于其在每個(gè)環(huán)回時(shí)間內(nèi)就會(huì)對(duì)窗口進(jìn)行調(diào)整,所以這種速率控制策略可以快速地調(diào)整窗口以適應(yīng)網(wǎng)絡(luò)的變化。然而對(duì)于視頻傳輸應(yīng)用來說,由于其采用RTP協(xié)議進(jìn)行數(shù)據(jù)傳輸,而RTCP協(xié)議的發(fā)送者報(bào)告每5 s才會(huì)對(duì)網(wǎng)絡(luò)狀況進(jìn)行一次反饋,因而如果單純地將TCP協(xié)議的速率控制機(jī)制照搬到視頻傳輸應(yīng)用中,會(huì)使得視頻傳輸速率的抖動(dòng)過于劇烈,并且會(huì)加劇網(wǎng)絡(luò)的擁塞,降低網(wǎng)絡(luò)帶寬的有效利用率[6]。

針對(duì)移動(dòng)網(wǎng)絡(luò)視頻傳輸速率控制方面存在的問題,在對(duì)移動(dòng)網(wǎng)絡(luò)的特點(diǎn)進(jìn)行研究的基礎(chǔ)上,文中提出一種視頻傳輸速率自適應(yīng)控制的方法。該方法將TCP協(xié)議的擁塞控制機(jī)制進(jìn)行了改進(jìn),并將其應(yīng)用于移動(dòng)網(wǎng)絡(luò)視頻傳輸中,使其能夠根據(jù)移動(dòng)網(wǎng)絡(luò)狀態(tài)的改變而動(dòng)態(tài)地對(duì)視頻傳輸速率進(jìn)行調(diào)整。仿真結(jié)果表明,與簡(jiǎn)單地將TCP協(xié)議的擁塞控制機(jī)制應(yīng)用到移動(dòng)視頻傳輸中的方法相比,該方法能夠更為高效地利用網(wǎng)絡(luò)中的可用帶寬,實(shí)現(xiàn)了傳輸速率的平穩(wěn)變化,并降低了視頻傳輸過程中的丟包率,可以有效滿足用戶對(duì)于移動(dòng)網(wǎng)絡(luò)視頻傳輸質(zhì)量的要求。

1 移動(dòng)網(wǎng)絡(luò)在數(shù)據(jù)傳輸方面的缺陷及其對(duì)視頻傳輸造成的影響

1.1 移動(dòng)網(wǎng)絡(luò)在數(shù)據(jù)傳輸方面的缺陷

當(dāng)前的移動(dòng)網(wǎng)絡(luò)主要包括蜂窩網(wǎng)絡(luò)、無線局域網(wǎng)、藍(lán)牙、衛(wèi)星通訊等幾種形式。與傳統(tǒng)的有線網(wǎng)絡(luò)相比,移動(dòng)網(wǎng)絡(luò)在數(shù)據(jù)傳輸方面主要存在以下缺陷[7-8]。

(1)網(wǎng)絡(luò)帶寬較窄。在有線網(wǎng)絡(luò)環(huán)境中,與視頻傳輸有關(guān)的應(yīng)用的可用帶寬通常為70~700 Mbps。而在移動(dòng)網(wǎng)絡(luò)環(huán)境中,同類型應(yīng)用的可用帶寬通常僅為5~25 Mbps,因而移動(dòng)網(wǎng)絡(luò)的可用帶寬與有線網(wǎng)絡(luò)相比明顯較窄。此外,移動(dòng)網(wǎng)絡(luò)的上行帶寬與下行帶寬也不相同,傳輸過程中的速率也會(huì)隨時(shí)發(fā)生變化。

(2)數(shù)據(jù)傳輸延遲較高。由于在移動(dòng)網(wǎng)絡(luò)環(huán)境中物理層的傳輸信號(hào)不穩(wěn)定,這給數(shù)據(jù)鏈路層的數(shù)據(jù)控制帶來了更多的開銷,影響了實(shí)際的傳輸速率。因而與有線網(wǎng)絡(luò)相比,移動(dòng)網(wǎng)絡(luò)環(huán)境下數(shù)據(jù)包在傳輸過程中的延遲時(shí)間要更長(zhǎng),并且延遲時(shí)間經(jīng)常會(huì)發(fā)生波動(dòng)。

(3)傳輸過程中的丟包率較高。在有線網(wǎng)絡(luò)環(huán)境中,出現(xiàn)數(shù)據(jù)包丟失的主要原因是由于網(wǎng)絡(luò)中出現(xiàn)擁堵,因?yàn)樵趥鬏斶^程中發(fā)生誤碼而導(dǎo)致數(shù)據(jù)包丟失的可能性較小。然而在移動(dòng)網(wǎng)絡(luò)環(huán)境中,因?yàn)閭鬏旀溌氛`碼導(dǎo)致數(shù)據(jù)包丟失的概率與有線網(wǎng)絡(luò)相比要大得多,加之移動(dòng)網(wǎng)絡(luò)環(huán)境的可用帶寬較窄,導(dǎo)致移動(dòng)網(wǎng)絡(luò)環(huán)境下傳輸過程中的丟包率大大增加。

(4)網(wǎng)絡(luò)穩(wěn)定性較差。由于接入移動(dòng)網(wǎng)絡(luò)的終端設(shè)備通常都處在位置不斷變化的狀態(tài)之下,尤其在移動(dòng)終端快速移動(dòng)的時(shí)候,移動(dòng)終端可能會(huì)在多個(gè)蜂窩區(qū)內(nèi)進(jìn)行切換,這可能會(huì)導(dǎo)致數(shù)據(jù)傳輸鏈接在發(fā)生蜂窩區(qū)切換時(shí)出現(xiàn)鏈接斷開和重連的情況。因而移動(dòng)終端在快速移動(dòng)中,通信鏈路可能經(jīng)常會(huì)出現(xiàn)中斷。

(5)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)較為復(fù)雜。盡管移動(dòng)網(wǎng)絡(luò)中接入的終端通常處于無線網(wǎng)絡(luò)環(huán)境下,然而其業(yè)務(wù)服務(wù)器通常處于有線網(wǎng)絡(luò)環(huán)境中,因而一般的移動(dòng)網(wǎng)絡(luò)業(yè)務(wù)的數(shù)據(jù)傳輸需要穿越無線網(wǎng)絡(luò)和有線網(wǎng)絡(luò),從而導(dǎo)致其網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)與有線網(wǎng)絡(luò)業(yè)務(wù)相比更為復(fù)雜。

1.2 移動(dòng)網(wǎng)絡(luò)環(huán)境對(duì)視頻傳輸造成的影響

鑒于移動(dòng)網(wǎng)絡(luò)自身存在的缺陷,移動(dòng)網(wǎng)絡(luò)中的設(shè)備在進(jìn)行視頻傳輸時(shí)會(huì)受到以下幾個(gè)方面的影響。

(1)視頻傳輸將受到網(wǎng)絡(luò)帶寬波動(dòng)的影響。從理論上講,當(dāng)前的移動(dòng)網(wǎng)絡(luò)對(duì)于視頻媒體的傳輸是可以滿足要求的,然而在實(shí)際應(yīng)用中,由于移動(dòng)網(wǎng)絡(luò)在傳輸過程中的可用帶寬會(huì)發(fā)生較大波動(dòng),因而會(huì)給視頻的傳輸帶來很大的問題。

(2)傳統(tǒng)的針對(duì)有線網(wǎng)絡(luò)的數(shù)據(jù)傳輸擁塞控制機(jī)制將不能很好地應(yīng)用到移動(dòng)網(wǎng)絡(luò)視頻傳輸過程中。在目前的傳輸擁塞控制機(jī)制中,應(yīng)用最廣泛的就是TCP協(xié)議所采用的擁塞控制機(jī)制。該機(jī)制在網(wǎng)絡(luò)空閑時(shí)呈線性增加其發(fā)送速率,而在網(wǎng)絡(luò)中出現(xiàn)擁塞時(shí),則呈乘性減小其發(fā)送速率。這種擁塞控制機(jī)制在有線網(wǎng)絡(luò)中應(yīng)用時(shí)效果較高,然而在移動(dòng)網(wǎng)絡(luò)環(huán)境中,由于網(wǎng)絡(luò)的可用帶寬的變化往往非常劇烈,這勢(shì)必將引起視頻傳輸速率的劇烈變化,影響視頻播放的最終效果。因而在移動(dòng)網(wǎng)絡(luò)環(huán)境中,需要對(duì)現(xiàn)有的擁塞控制機(jī)制進(jìn)行改進(jìn)。

(3)移動(dòng)網(wǎng)絡(luò)視頻傳輸中的其他問題。在移動(dòng)網(wǎng)絡(luò)進(jìn)行視頻傳輸時(shí)還會(huì)受到其他因素的影響,如移動(dòng)終端的電源和能量等問題。

2 傳輸速率自適應(yīng)控制技術(shù)及其控制算法

2.1 傳輸速率自適應(yīng)控制的總體解決方案

文中提出的傳輸速率自適應(yīng)控制技術(shù)采用如下的解決思路:首先對(duì)視頻傳輸過程中由接收端返回給發(fā)送端的RTCP數(shù)據(jù)包進(jìn)行分析,從中提取與網(wǎng)絡(luò)狀態(tài)有關(guān)的參數(shù)并進(jìn)行分析,由此構(gòu)建當(dāng)前的網(wǎng)絡(luò)狀態(tài),并對(duì)后續(xù)時(shí)間段內(nèi)網(wǎng)絡(luò)狀態(tài)的變化進(jìn)行估計(jì)。隨后對(duì)于TCP協(xié)議所采用的擁塞控制機(jī)制進(jìn)行改進(jìn),將原有的定常數(shù)提高與降低發(fā)送速率的方法替換為變常數(shù)提高與降低發(fā)送速率,并且發(fā)送速率提高或降低的幅度隨著時(shí)間的推移逐漸變小,從而在發(fā)送速率可以對(duì)網(wǎng)絡(luò)狀態(tài)的變化及時(shí)做出響應(yīng)的同時(shí),避免速率的波動(dòng)過于劇烈。

2.2 RTCP協(xié)議

2.2.1 RTCP協(xié)議概述

實(shí)時(shí)傳輸控制協(xié)議(Real-time Transport Control Protocol,RTCP)是與實(shí)時(shí)傳輸協(xié)議(Real-time Transport Protocol,RTP)一道被定義在1996年提出的RFC 1889中的,與RTP協(xié)議一起工作的控制協(xié)議[9-10]。RTCP單獨(dú)運(yùn)行于UDP協(xié)議之上,由UDP協(xié)議對(duì)其提供數(shù)據(jù)與控制包的復(fù)用。在RTP會(huì)話過程中,每個(gè)RTP會(huì)話參與者周期性地向所有其他參與者發(fā)送RTCP控制信息包,如圖1所示。對(duì)于RTP會(huì)話或者廣播來說,RTCP協(xié)議通常會(huì)使用單個(gè)多目標(biāo)廣播地址,屬于這個(gè)會(huì)話的所有RTP和RTCP信息包都會(huì)使用這個(gè)多目標(biāo)廣播地址,由于在會(huì)話過程中RTP協(xié)議和RTCP協(xié)議使用不同的UDP端口號(hào),因而通過使用不同的端口號(hào)即可把RTP數(shù)據(jù)包和RTCP數(shù)據(jù)包區(qū)分開來[11]。

圖1 RTCP協(xié)議工作原理示意圖

2.2.2 RTCP協(xié)議的功能

在視頻傳輸及交互過程中,RTCP協(xié)議主要具有以下功能[12]。

(1)為參與會(huì)話的應(yīng)用提供會(huì)話質(zhì)量保證或?qū)?huì)話質(zhì)量信息進(jìn)行廣播。

RTCP協(xié)議的主要功能是為參與會(huì)話的應(yīng)用提供會(huì)話質(zhì)量的保證,以及廣播會(huì)話質(zhì)量信息。在RTCP數(shù)據(jù)包不對(duì)需要傳輸?shù)囊纛l或視頻數(shù)據(jù)進(jìn)行封裝,而是封裝發(fā)送端與接收端會(huì)話質(zhì)量的統(tǒng)計(jì)信息。這些信息包括發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)目、傳輸過程中的延時(shí)以及傳輸延時(shí)的抖動(dòng)情況等。這些信息反映了網(wǎng)絡(luò)的當(dāng)前狀態(tài),可以為發(fā)送端、接收端程序或者網(wǎng)絡(luò)管理程序調(diào)整傳輸或管理策略提供參考。

(2)識(shí)別與定位會(huì)話中的用戶。

RTCP協(xié)議為參與到會(huì)話中的每個(gè)用戶提供了一個(gè)規(guī)范名稱(Canonical Name,CNAME)的全局唯一的標(biāo)識(shí)符。通過這一標(biāo)識(shí)符,即可對(duì)一個(gè)RTP會(huì)話過程中的參與者進(jìn)行定位。與此同時(shí),會(huì)話中的接收者也可以利用CNAME在相關(guān)RTP連接的幾個(gè)數(shù)據(jù)流之間建立聯(lián)系,例如實(shí)現(xiàn)音視頻同步等。

(3)對(duì)RTCP數(shù)據(jù)包的發(fā)送速率進(jìn)行控制。

由于在會(huì)話過程中,每個(gè)參與者都會(huì)定期地發(fā)送RTCP數(shù)據(jù)包,當(dāng)會(huì)話的參與者數(shù)量較大時(shí),網(wǎng)絡(luò)中傳輸?shù)腞TCP數(shù)據(jù)包將占用過多的網(wǎng)絡(luò)資源。為了防止網(wǎng)絡(luò)擁塞的發(fā)生,必須對(duì)RTCP數(shù)據(jù)包的發(fā)送速率進(jìn)行控制,使其所占的帶寬不超過可用帶寬的5%。由于會(huì)話中任意兩個(gè)參與者之間都會(huì)互相發(fā)送RTCP數(shù)據(jù)包,因此比較容易計(jì)算出參與者的數(shù)量,進(jìn)而對(duì)RTCP數(shù)據(jù)包的發(fā)送速率進(jìn)行調(diào)整。

2.2.3 RTCP數(shù)據(jù)包格式

RTCP數(shù)據(jù)包主要有以下5種類型[13]。

(1)發(fā)送者報(bào)告(Sender Report,SR)。由RTP會(huì)話的發(fā)送端發(fā)送,其中主要包含發(fā)送端的信息、媒體間的同步信息、累計(jì)發(fā)送的數(shù)據(jù)包的數(shù)量以及累計(jì)發(fā)送的字節(jié)數(shù)等。

(2)接收者報(bào)告(Receiver Report,RR)。由RTP會(huì)話中的接收端發(fā)送,其主要內(nèi)容是對(duì)數(shù)據(jù)傳輸過程中接收質(zhì)量的反饋。針對(duì)為其發(fā)送數(shù)據(jù)的每個(gè)發(fā)送端,接收者報(bào)告都為其提供丟失報(bào)文的數(shù)量、已接收?qǐng)?bào)文的最大序列號(hào)、平均時(shí)延抖動(dòng)、接收最后一個(gè)發(fā)送者報(bào)告的時(shí)間、接收最后一個(gè)發(fā)送者報(bào)告的延時(shí)等信息。

(3)信源描述符(Source Description Items,SDES):包含對(duì)發(fā)送端進(jìn)行描述的信息,包括CNAME等。

(4)BYE:參與者結(jié)束會(huì)話。當(dāng)會(huì)話過程中有參與者離開時(shí),會(huì)發(fā)送一個(gè)BYE類型的RTCP數(shù)據(jù)包。

(5)APP:該類型的RTCP數(shù)據(jù)包通常包含具有特定功能的應(yīng)用函數(shù)。

RTCP數(shù)據(jù)包主要由數(shù)據(jù)包頭部分和結(jié)構(gòu)化的報(bào)告內(nèi)容組成,數(shù)據(jù)包的內(nèi)容根據(jù)類型的不同而有所差異。文中以發(fā)送者報(bào)告為例進(jìn)行說明,其數(shù)據(jù)包結(jié)構(gòu)如圖2所示。

圖2 發(fā)送者報(bào)告數(shù)據(jù)包格式示意圖

通常一個(gè)發(fā)送者報(bào)告報(bào)文由三部分構(gòu)成。

(1)RTCP數(shù)據(jù)包頭部分。

V:版本號(hào),長(zhǎng)度為2 bit,當(dāng)前版本為2。

P:填充標(biāo)志,長(zhǎng)度為1 bit,如果該標(biāo)志的值為1,則在數(shù)據(jù)包的尾部填充一個(gè)八位組。

RC:接收?qǐng)?bào)告計(jì)數(shù),長(zhǎng)度為5 bit,指接收?qǐng)?bào)告的塊的個(gè)數(shù)。

PT:報(bào)文類型,長(zhǎng)度為8 bit,SR類型為200。

Length:報(bào)文長(zhǎng)度,長(zhǎng)度為16 bit,以32位為單位。

SSRC of sender:長(zhǎng)度為32 bit,表示發(fā)送該發(fā)送者報(bào)告的信源的同步標(biāo)識(shí)符。

(2)發(fā)送者信息部分。

NTP timestamp:長(zhǎng)度為64 bit,指該發(fā)送者報(bào)告發(fā)送時(shí)的全局網(wǎng)絡(luò)時(shí)間。

RTP timestamp:長(zhǎng)度為32 bit,其所指示的時(shí)間與NTP timestamp一致,但所使用的時(shí)間單位與RTP數(shù)據(jù)包中的相同。

Sender’s packet count:長(zhǎng)度為32 bit,表示發(fā)送者從開始發(fā)送RTP數(shù)據(jù)包到該發(fā)送者報(bào)告產(chǎn)生所經(jīng)過的時(shí)間間隔內(nèi)總共發(fā)送的RTP數(shù)據(jù)包的數(shù)量。

Sender’s octet count:長(zhǎng)度為32 bit,表示發(fā)送者從開始發(fā)送RTP數(shù)據(jù)包到該發(fā)送者報(bào)告產(chǎn)生所經(jīng)過的時(shí)間間隔內(nèi)總共發(fā)送的字節(jié)數(shù)。

(3)接收?qǐng)?bào)告塊部分。

SSRC_n:長(zhǎng)度為32 bit,表示在該時(shí)間間隔內(nèi)曾向該參與者發(fā)送過RTP數(shù)據(jù)包的發(fā)送者的序號(hào)。

Fraction lost:長(zhǎng)度為8 bit,表示在該時(shí)間間隔內(nèi)從SSRC_n接收到的RTP數(shù)據(jù)包的丟包率。

Cumulative number of packets lost:長(zhǎng)度為24 bit,表示從開始接收RTP數(shù)據(jù)包到現(xiàn)在為止累計(jì)丟失的數(shù)據(jù)包數(shù)量。

Extended highest sequence number received:長(zhǎng)度為32 bit,表示從SSRC_n接收到的RTP數(shù)據(jù)包的最大序列號(hào)。

Interarrival jitter:長(zhǎng)度為32 bit,表示從SSRC_n接收RTP數(shù)據(jù)包的時(shí)延的抖動(dòng)情況。

Last SR(LSR):長(zhǎng)度為32 bit,表示從SSRC_n接收到的最近一個(gè)發(fā)送者報(bào)告中所記錄的該發(fā)送者報(bào)告發(fā)送的時(shí)間。

Delay since last SR(DLSR):長(zhǎng)度為32 bit,表示從SSRC_n接收到的最后一個(gè)發(fā)送者報(bào)告到發(fā)送該報(bào)告之間的時(shí)間差。

2.3 視頻傳輸過程中網(wǎng)絡(luò)狀態(tài)的測(cè)量與預(yù)測(cè)

2.3.1 網(wǎng)絡(luò)丟包率的計(jì)算與預(yù)測(cè)

網(wǎng)絡(luò)丟包率是指?jìng)鬏斶^程中丟失的數(shù)據(jù)包的數(shù)目與所傳輸?shù)臄?shù)據(jù)包的總數(shù)的比值。一般來說,在網(wǎng)絡(luò)中的鏈路與物理設(shè)備均工作正常的情況下,網(wǎng)絡(luò)中出現(xiàn)擁塞是造成傳輸過程中數(shù)據(jù)包丟失的最主要原因。當(dāng)網(wǎng)絡(luò)中數(shù)據(jù)包丟失的狀況持續(xù)出現(xiàn)時(shí),說明網(wǎng)絡(luò)持續(xù)處于擁塞狀態(tài),因而網(wǎng)絡(luò)丟包率可以反映網(wǎng)絡(luò)在一段時(shí)間內(nèi)的擁塞情況。依據(jù)2.1.3節(jié)所描述的發(fā)送者報(bào)告,通過提取其中的累計(jì)丟失報(bào)文數(shù)(Cumulative number of packets lost)以及接收到的報(bào)文的最高序號(hào),即可計(jì)算出某一時(shí)間間隔內(nèi)視頻傳輸過程中的丟包率,從而對(duì)網(wǎng)絡(luò)中的擁塞狀況進(jìn)行長(zhǎng)時(shí)間測(cè)量[14-15]。令第i個(gè)時(shí)間間隔內(nèi)的丟包率為L(zhǎng)i,則Li的計(jì)算方法如式(1)所示。

(1)

其中,cum_losti表示從視頻傳輸過程開始到第i個(gè)傳輸時(shí)間間隔內(nèi)累計(jì)丟失的RTP數(shù)據(jù)包總數(shù);hi_num_recvi表示從視頻傳輸過程開始到第i個(gè)傳輸時(shí)間間隔內(nèi)所接收到的RTP數(shù)據(jù)包的最大序列號(hào)。

由于在發(fā)送者報(bào)告中只是給出了某一個(gè)時(shí)間間隔內(nèi)丟失包的數(shù)目,在視頻傳輸過程中,如果簡(jiǎn)單地根據(jù)式(1)中計(jì)算出的丟包率對(duì)傳輸速率進(jìn)行控制,會(huì)導(dǎo)致傳輸速率的波動(dòng)。為了減小波動(dòng),采用一次指數(shù)平滑法對(duì)預(yù)測(cè)的丟包率進(jìn)行平滑,其計(jì)算方法如式(2)所示。

(2)

2.3.2 網(wǎng)絡(luò)平均時(shí)延抖動(dòng)的計(jì)算

時(shí)延抖動(dòng)指的是網(wǎng)絡(luò)傳輸時(shí)延的變化情況。與網(wǎng)絡(luò)丟包率主要對(duì)網(wǎng)絡(luò)中長(zhǎng)期的擁塞狀況進(jìn)行描述不同,平均延時(shí)抖動(dòng)(Interarrivaljitter)主要是對(duì)網(wǎng)絡(luò)中短期的擁塞狀況進(jìn)行描述。此外,時(shí)延抖動(dòng)的變化可能預(yù)示著網(wǎng)絡(luò)擁塞即將出現(xiàn)。依據(jù)發(fā)送者報(bào)告,第i個(gè)時(shí)間間隔內(nèi)的平均時(shí)延抖動(dòng)Ji可以直接從發(fā)送者報(bào)告中獲取,即Ji=jitter。

2.3.3 網(wǎng)絡(luò)狀態(tài)預(yù)測(cè)量的定義與計(jì)算

(3)

在實(shí)際應(yīng)用中,通過對(duì)權(quán)重系數(shù)α和β的不斷調(diào)整,可以最大程度地?cái)M合移動(dòng)網(wǎng)絡(luò)中網(wǎng)絡(luò)狀態(tài)的變化情況,從而更精確地對(duì)發(fā)送速率進(jìn)行控制,避免視頻傳輸過程中RTP數(shù)據(jù)包的丟失,并減小抖動(dòng)的程度。

2.4 速率控制算法的工作流程

文中所提出的視頻傳輸速率自適應(yīng)控制算法利用RTCP作為傳輸反饋控制協(xié)議,引入網(wǎng)絡(luò)狀態(tài)預(yù)測(cè)量P作為判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)的依據(jù),并采用變常數(shù)提高與降低的方法來對(duì)視頻傳輸過程中的發(fā)送速率進(jìn)行調(diào)整。令vi+1為第i+1個(gè)時(shí)間間隔內(nèi)的發(fā)送速率,其具體的計(jì)算方法如式(4)所示。

(4)

把式(2)代入到式(4)得到式(5)。

vi+1=

(5)

通過式(5)可以看出,當(dāng)Pi+1≤θ時(shí),說明此時(shí)網(wǎng)絡(luò)狀態(tài)較好,網(wǎng)絡(luò)中無擁塞現(xiàn)象或擁塞程度較低,此時(shí)可提升發(fā)送速率;而當(dāng)Pi+1>θ時(shí),說明此時(shí)網(wǎng)絡(luò)中擁塞較為嚴(yán)重,網(wǎng)絡(luò)狀態(tài)較差,此時(shí)應(yīng)降低發(fā)送速率。并且由該公式的函數(shù)性質(zhì)可知,vi+1分別為L(zhǎng)i和Ji的減函數(shù),也就是說隨著Li和Ji的增加,發(fā)送速率提升和降低的服務(wù)都趨于收斂,因而采用該公式對(duì)發(fā)送速率進(jìn)行控制,可以降低發(fā)送速率的變化程度,使發(fā)送速率趨于平穩(wěn)。另外,在網(wǎng)絡(luò)傳輸過程中,發(fā)送速度要受到網(wǎng)絡(luò)帶寬的限制,因而根據(jù)網(wǎng)絡(luò)狀態(tài)預(yù)測(cè)量計(jì)算出的發(fā)送速率需要與預(yù)先設(shè)定的最大和最小發(fā)送速率進(jìn)行比較,確保發(fā)送速率在可以接受的范圍內(nèi)。

文中提出的視頻傳輸速率自適應(yīng)控制算法的工作流程描述如下。

(1)將發(fā)送速率的初始值設(shè)置為v0,開始進(jìn)行視頻傳輸。

(3)從發(fā)送者報(bào)告中提取第i個(gè)時(shí)間間隔內(nèi)的平均時(shí)延抖動(dòng)值Ji。

(4)根據(jù)式(3)計(jì)算第i+1個(gè)時(shí)間間隔內(nèi)的網(wǎng)絡(luò)狀態(tài)預(yù)測(cè)量Pi+1。

文中提出的視頻傳輸速率自適應(yīng)控制算法的工作流程如圖3所示。

圖3 視頻傳輸速率自適應(yīng)控制算法工作流程示意圖

3 實(shí)驗(yàn)與分析

為了對(duì)文中提出的視頻傳輸速率自適應(yīng)控制算法的有效性和實(shí)用性進(jìn)行驗(yàn)證,保證實(shí)驗(yàn)評(píng)價(jià)的客觀性,利用OMNeT++仿真軟件構(gòu)建了一個(gè)典型的啞鈴狀單瓶頸鏈路網(wǎng)絡(luò),并對(duì)上述算法進(jìn)行仿真實(shí)驗(yàn)。OMNeT++(ObjectiveModularNetworkTestbedinC++)是一個(gè)專門為大型網(wǎng)絡(luò)提供的開源的、基于組件的、模塊化的、開放的、面向?qū)ο蟮碾x散事件網(wǎng)絡(luò)仿真工具。OMNeT++具備非常強(qiáng)大和完善的圖形界面,并能夠?qū)D形界面中的參數(shù)進(jìn)行配置,同時(shí)具備編程、調(diào)試和跟蹤支持的功能,能夠有效而便捷地對(duì)通信網(wǎng)絡(luò)及其他復(fù)雜IT系統(tǒng)進(jìn)行仿真。與此同時(shí),OMNeT++提供對(duì)用戶組件庫的支持,可以實(shí)現(xiàn)模塊化的靈活重用,允許對(duì)仿真內(nèi)核提供擴(kuò)展,并且提供了圖形化的網(wǎng)絡(luò)編輯和網(wǎng)絡(luò)數(shù)據(jù)流查看工具。與其他開源的網(wǎng)絡(luò)仿真軟件(如NS2等)相比,OMNeT++具有高度的模塊化特性,并可運(yùn)行于多個(gè)操作系統(tǒng)平臺(tái),具備更好的靈活性[16-17]。文中構(gòu)造的啞鈴狀單瓶頸鏈路網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)如圖4所示。

在圖4中,S1,S2和S3為視頻傳輸過程中的發(fā)送端,R1,R2和R3是接收端,N1和N2是網(wǎng)絡(luò)中的兩個(gè)中間節(jié)點(diǎn),網(wǎng)絡(luò)中鏈路的帶寬均為4Mbps,傳輸延遲均為20ms。發(fā)送端每5s向所有接收端發(fā)送一次發(fā)送者報(bào)告,設(shè)置網(wǎng)絡(luò)狀態(tài)預(yù)測(cè)量的檢測(cè)閾值θ為0.43,權(quán)重系數(shù)α和β分別為0.36和0.41。初始發(fā)送速率設(shè)定為200kbps,最大和最小發(fā)送速率分別設(shè)定為500kbps和50kpbs。實(shí)驗(yàn)持續(xù)時(shí)間為600s,由S1,S2和S3分別向R1,R2和R3傳輸視頻數(shù)據(jù)。

圖4 啞鈴狀單瓶頸鏈路網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)示意圖

實(shí)驗(yàn)結(jié)果顯示,簡(jiǎn)單地采用TCP協(xié)議擁塞控制的傳輸速率控制機(jī)制的發(fā)送速率在整個(gè)實(shí)驗(yàn)過程中的波動(dòng)非常劇烈,而文中所提出的傳輸速率控制算法的速率波動(dòng)則明顯較為平緩。在經(jīng)過一段時(shí)間的調(diào)整之后,視頻的發(fā)送速率逐步穩(wěn)定在280~295kbps,有效提高了網(wǎng)絡(luò)中有效帶寬的利用率。實(shí)驗(yàn)中兩種方法的速率變化情況見圖5,以S1發(fā)往R1的視頻數(shù)據(jù)為例。

圖5 視頻發(fā)送速率波動(dòng)情況對(duì)比示意圖

此外,實(shí)驗(yàn)也對(duì)視頻傳輸過程中的丟包率進(jìn)行了統(tǒng)計(jì),統(tǒng)計(jì)結(jié)果如表1所示。

表1 兩種方法在視頻傳輸過程中丟包率的比較

結(jié)果顯示,文中提出的傳輸速率控制算法在整個(gè)實(shí)驗(yàn)過程中的丟包率被控制在1.5%以下,與簡(jiǎn)單地采用TCP協(xié)議擁塞控制的傳輸速率控制機(jī)制相比有了明顯提高。由此可見,文中提出的傳輸速率控制算法在保證傳輸速率平穩(wěn)變化的同時(shí),降低了視頻傳輸?shù)膩G包率,保證了接收端視頻播放的質(zhì)量,滿足了移動(dòng)網(wǎng)絡(luò)應(yīng)用對(duì)于視頻傳輸質(zhì)量的要求。

4 結(jié)束語

移動(dòng)視頻傳輸技術(shù)及交互應(yīng)用的出現(xiàn)和普及,為人與人之間溝通與交流提供了極大的便利。然而視頻數(shù)據(jù)在移動(dòng)網(wǎng)絡(luò)中的傳輸往往會(huì)受到移動(dòng)網(wǎng)絡(luò)帶寬波動(dòng)等不利因素的影響,導(dǎo)致視頻數(shù)據(jù)無法正常傳輸,影響視頻傳輸與交互的質(zhì)量,因而根據(jù)網(wǎng)絡(luò)狀態(tài)實(shí)時(shí)對(duì)視頻傳輸速率進(jìn)行調(diào)整至關(guān)重要。現(xiàn)有的傳輸速率控制機(jī)制雖然對(duì)于有線網(wǎng)絡(luò)及基于TCP協(xié)議的數(shù)據(jù)傳輸調(diào)控效果較好,但其調(diào)控幅度對(duì)于視頻傳輸來說過于劇烈,反而會(huì)影響視頻交互的效果。

針對(duì)目前視頻傳輸在移動(dòng)網(wǎng)絡(luò)中存在的問題,文中提出了一種視頻傳輸速率自適應(yīng)控制方法。該方法對(duì)于TCP協(xié)議的擁塞控制方法進(jìn)行了改進(jìn),通過對(duì)視頻傳輸中產(chǎn)生的RTCP數(shù)據(jù)包的內(nèi)容進(jìn)行分析,提取與當(dāng)前網(wǎng)絡(luò)狀態(tài)有關(guān)的信息,并以此來對(duì)網(wǎng)絡(luò)狀態(tài)的變化情況進(jìn)行分析與預(yù)測(cè),進(jìn)而依據(jù)網(wǎng)絡(luò)狀態(tài)的變化動(dòng)態(tài)地對(duì)視頻傳輸過程中的速率進(jìn)行調(diào)整。該方法在提高了網(wǎng)絡(luò)帶寬利用率的同時(shí),降低了視頻傳輸過程中的丟包率,提高了視頻傳輸與交互的質(zhì)量。在今后的工作中,可將該方法應(yīng)用于移動(dòng)視頻交互應(yīng)用中,從實(shí)踐角度對(duì)該方法的正確性進(jìn)行驗(yàn)證。

[1] 鄭啟鴻.移動(dòng)網(wǎng)絡(luò)通信質(zhì)量測(cè)評(píng)方案的分析與研究[J].信息技術(shù)與信息化,2015(2):47-48.

[2]SamanchuenT,KiattisinS.Implementationandqualityevaluationofvideotelephonyusingsessioninitiationprotocol[C]//Procof2014Asia-Pacificsignalandinformationprocessingassociationannualsummitandconference.ChiangMai,Thailand:Asia-PacificSignalandInformationProcessingAssociation,2014.

[3]QiX,YangQ,NguyenDT,etal.LBVC:towardslow-bandwidthvideochatonsmartphones[C]//Proceedingsofthe6thACMmultimediasystemsconference.Portland,USA:ACM,2015.

[4]AktasI,SchmidtF,Weing?rtnerE,etal.AnadaptivecodecswitchingschemeforSIP-basedVoIP[M]//InternetofThings,SmartSpaces,andNextGenerationNetworking.Berlin:Springer,2012:347-358.

[5]KuangT,TangP.Anewfeedbackstreamingmediacongestioncontrolalgorithm[J].JournalofChemical&PharmaceuticalResearch,2014,6(6):2286-2289.

[6] 梁 皓,駱新全.一種基于RTCP的自適應(yīng)流媒體擁塞控制算法[J].中國(guó)傳媒大學(xué)學(xué)報(bào):自然科學(xué)版,2014,21(5):28-31.

[7] 張成偉,程文青,黑曉軍.基于Android平臺(tái)的3G移動(dòng)網(wǎng)絡(luò)測(cè)量研究及性能分析[J].計(jì)算機(jī)科學(xué),2015,42(2):24-28.

[8] 李曉城,錢松榮.3G網(wǎng)絡(luò)中流媒體點(diǎn)對(duì)點(diǎn)自適應(yīng)傳輸策略[J].計(jì)算機(jī)工程,2011,37(20):66-68.

[9] 許 寧.基于RTP協(xié)議的移動(dòng)視頻監(jiān)控系統(tǒng)的設(shè)計(jì)[J].通信技術(shù),2014,47(4):455-458.

[10]GhoshR,GoswamiP.Implementationonadaptivetransmissionofrealtimemultimediadata[J].InternationalJournalofResearchinEngineering&Technology,2014,2(4):175-184.

[11]VolkertT,Mitschele-ThielA,BeckeM,etal.Homerconferencing-amultimediatestbedforvariousexperimentsandmeasurements[C]//Procof7thinternationalconferenceoncomputingandconvergencetechnology.Seoul,Korea:IEEE,2012:224-229.

[12]SchulzrinneH,CasnerS,FrederickR,etal.RFC3550RTP:atransportprotocolforreal-timeapplications[S].Fremont,USA:InternetEngineeringTaskForce,2003.

[13]XuY,HuH.DevelopmentofanetworkadaptiveH.264/AVCmedicalvideotransmissionsystem[J].InternationalJournalofFutureComputerandCommunication,2013,2(4):292-295.

[14]JiangW,MengL,YingS,etal.Acontrolmechanismofstreammediabasedon3Gnetwork[J].JournalofSoftwareEngineeringandApplications,2013,5(12):8-13.

[15] 劉國(guó)柱,王洪林.RTCP反饋和緩沖區(qū)的傳輸控制算法研究[J].計(jì)算機(jī)工程與設(shè)計(jì),2010,31(12):2704-2706.

[16] 楊 寧,李滿坡,宋元成,等.基于OMNeT的電力調(diào)度數(shù)據(jù)網(wǎng)仿真[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2014,23(6):28-34.

[17]DhobaleJV,KalyankarNV,KhamitkarSD.ComputernetworkperformanceevaluationbasedondifferentdatapacketsizeusingOMNeT++simulationenvironment[J].GlobalJournalofComputerScienceandTechnology,2014,5(5):2041-2045.

Research on Self-adaptive Control Technology of Video Transmission Speed in Mobile Networks

CHEN Fei1,HUANG Ren-le2,LI Yi1,WANG Ying-yu3

(1.Beijing Huadian Tianyi Information Technology Corporation Limited,Beijing 102200,China;2.State Grid Beijing Electric Power Company,Beijing 100031,China;3.Beijing Kedong Electric Power Control System Co.,Ltd.,Beijing 100085,China)

Nowadays video transmission and interaction on mobile terminals is widely used.However,because the bandwidth of mobile network often fluctuates,it may lead the available bandwidth lower than the transmission speed and packets loss transmitted in network,which in turn affects the quality of video transmission and interaction.Thus how to change the transmission speed timely according to the change of network status,decreasing packet loss ratio in transmission,guaranteeing the quality of transmission and interaction,is very crucial.Aiming at the specific request of video transmission in mobile network environment,a self-adaptive speed control method applicable for mobile network video transmission is put forward.It improves the congestion control method used for TCP,and adjusts transmission speed dynamically according to the variation of network situation during the process of video transmission.The result of simulation shows that this method can guarantee the transmission speed change placidly within limits,which improves utilization ratio of network available bandwidth,and reduces packet loss ratio during transmission.Thus it can basically meet the requirement of video transmission and interaction quality in mobile networks.

mobile network;video transmission;speed control;self-adaption;feedback control

2015-11-27

2016-03-16

時(shí)間:2016-08-01

國(guó)家電網(wǎng)公司總部科技項(xiàng)目(0711-13OTL21501237-033)

陳 飛(1986-),男,博士,研究方向?yàn)殡娏χ悄芑夹g(shù)、電力信息安全;黃仁樂,碩士,教授級(jí)高工,研究方向?yàn)橹悄茈娋W(wǎng)、電力智能化技術(shù)。

http://www.cnki.net/kcms/detail/61.1450.TP.20160801.0904.034.html

TP311.1

A

1673-629X(2016)10-0177-07

10.3969/j.issn.1673-629X.2016.10.039

主站蜘蛛池模板: 69av免费视频| 国产最新无码专区在线| 亚洲欧美另类色图| 欧美亚洲中文精品三区| 亚洲成人黄色在线观看| 国产SUV精品一区二区| 亚洲天堂.com| 国产微拍精品| 国产精品自在自线免费观看| 久久精品国产91久久综合麻豆自制| 久久99国产综合精品1| 人人爽人人爽人人片| 99视频在线观看免费| 97久久人人超碰国产精品| 午夜国产在线观看| 看看一级毛片| 亚洲欧洲日产国产无码AV| 怡春院欧美一区二区三区免费| 国产亚洲现在一区二区中文| 欧美视频在线第一页| 好紧好深好大乳无码中文字幕| 成人免费视频一区| 又爽又黄又无遮挡网站| a毛片在线免费观看| 日本久久网站| 日韩视频福利| 91九色最新地址| 国产综合精品日本亚洲777| 99精品视频播放| 国产福利在线观看精品| 1级黄色毛片| 国产精品久线在线观看| 色天堂无毒不卡| 免费看的一级毛片| 亚洲综合九九| 亚洲精品无码av中文字幕| 99尹人香蕉国产免费天天拍| 最新亚洲人成网站在线观看| 中文字幕亚洲乱码熟女1区2区| 久久天天躁夜夜躁狠狠| 成人午夜视频网站| 国产福利免费视频| 午夜精品久久久久久久无码软件| 亚洲人成网址| 美女被狂躁www在线观看| 亚洲丝袜中文字幕| 久久99精品久久久久久不卡| 国产凹凸一区在线观看视频| 国产丝袜91| 国产精品大白天新婚身材| 亚洲精品777| 日韩欧美国产成人| 超级碰免费视频91| 婷婷在线网站| 久996视频精品免费观看| 国产精选小视频在线观看| 91久久国产热精品免费| 久久综合伊人 六十路| 草草影院国产第一页| 日韩欧美成人高清在线观看| 国产黄色爱视频| 国产精品亚洲va在线观看| 精品人妻无码区在线视频| 另类综合视频| 在线免费看黄的网站| 婷婷六月天激情| 久久国产精品嫖妓| 亚洲成人在线免费| 国产精品美女在线| 精品视频一区在线观看| AV熟女乱| 国产精品久久久久久久久久98| 在线观看国产精品日本不卡网| 少妇极品熟妇人妻专区视频| 啊嗯不日本网站| 久久人搡人人玩人妻精品| 好吊日免费视频| 国产一区成人| 亚洲色欲色欲www在线观看| 亚洲精品第一在线观看视频| 欧美成人午夜影院| 欧美国产日本高清不卡|