楊亞龍，嵩 天，朱洪辰

北京理工大學 計算機學院，北京 100081

1 引言

傳統(tǒng)電視服務已經(jīng)成為人民生活中不可缺少的一部分，如今，基于互聯(lián)網(wǎng)提供的視頻服務呈現(xiàn)出相同的重要性。視頻服務流量已經(jīng)成為網(wǎng)絡數(shù)據(jù)流量的主要組成部分，所占比例呈上升趨勢[1-2]。由于內(nèi)容新鮮且類別豐富，網(wǎng)絡視頻直播得到了廣泛的關注，參考傳統(tǒng)電視直播的流行性，未來網(wǎng)絡視頻直播很有可能會扮演更重要的角色，為世界范圍內(nèi)更廣泛的互聯(lián)網(wǎng)用戶提供服務。在此背景下，通過高效且經(jīng)濟的基礎架構進行網(wǎng)絡視頻直播內(nèi)容分發(fā)具有重要意義。

當前網(wǎng)絡視頻直播主要通過地面網(wǎng)絡進行內(nèi)容分發(fā)，從內(nèi)容服務器向某地傳輸數(shù)據(jù)時網(wǎng)絡跳數(shù)較多。此外，受限于物理設施，只有與地面網(wǎng)絡連通的地方才能獲得視頻直播內(nèi)容。參考衛(wèi)星提供的全球電視直播服務，網(wǎng)絡視頻直播內(nèi)容同樣可以通過衛(wèi)星廣播進行分發(fā)?；谛l(wèi)星廣播進行網(wǎng)絡視頻內(nèi)容分發(fā)主要有以下三方面優(yōu)勢：（1）衛(wèi)星具備廣播（組播）通信能力，內(nèi)容提供者到消費者間的網(wǎng)絡跳數(shù)將有效減少，數(shù)據(jù)通信開銷相應減?。唬?）衛(wèi)星可分擔地面網(wǎng)絡視頻內(nèi)容分發(fā)的壓力，地面網(wǎng)絡能夠為其他應用提供更好的服務；（3）衛(wèi)星能夠為部署地面終端的孤島或深山等地區(qū)提供服務，災難發(fā)生時能夠代替?zhèn)鹘y(tǒng)地面網(wǎng)絡發(fā)揮作用。

當前網(wǎng)絡視頻直播服務基于TCP/IP提供。為了獲得連續(xù)的視頻流，客戶端需要同內(nèi)容服務器建立端到端的IP鏈路，接入內(nèi)容服務器的IP鏈路數(shù)量與請求內(nèi)容的客戶端數(shù)量線性相關。視頻直播應用數(shù)據(jù)流以點對點的方式進行內(nèi)容分發(fā)。商業(yè)中廣泛使用的內(nèi)容分發(fā)網(wǎng)絡（content delivery network，CDN）服務只是采用了結(jié)合地理區(qū)域和網(wǎng)絡條件更好的IP鏈路，本質(zhì)上沒有改變點對點傳輸方式的基本模式。有觀點認為IP組播能夠為網(wǎng)絡視頻直播提供一定的幫助，然而在互聯(lián)網(wǎng)范圍下，由于地址過多，IP組播效果有限。衛(wèi)星通信如果以IP網(wǎng)絡開展直播內(nèi)容傳輸，仍然會遇到以上問題。

與IP相比，源于信息中心網(wǎng)絡（information centric networking，ICN）概念的命名數(shù)據(jù)網(wǎng)絡（named data networking，NDN）原生支持組播，能夠有效地利用衛(wèi)星廣播分發(fā)視頻直播內(nèi)容[3]?；趦?nèi)容名稱進行數(shù)據(jù)路由，可以有效減少內(nèi)容服務器的接入量及節(jié)點通信壓力。網(wǎng)內(nèi)緩存機制也有助于提升內(nèi)容分發(fā)效率?？紤]到應用前景及潛在優(yōu)勢，基于NDN或內(nèi)容中心網(wǎng)絡（content centric networking，CCN）的直播或?qū)崟r視頻應用研究得到了一定的關注。關于衛(wèi)星與ICN結(jié)合的研究也取得了一定的進展，相關研究將在第2章進行簡單介紹。

不同于傳統(tǒng)地面鏈路，衛(wèi)星與地面終端通信鏈路傳播延遲較高。由于NDN基本設計主要面向當前地面網(wǎng)絡，并沒有對傳播延遲較高的場景進行優(yōu)化。在基于NDN的衛(wèi)星廣播視頻直播應用中，較高的傳播延遲會造成冗余數(shù)據(jù)傳輸（redundant data transmission，RDT）問題。本文在NDN中未決信息表（pending interest table，PIT）的基礎上進行改進，延遲PIT表項移除以解決RDT問題。改進后的PIT機制命名為容遲未決信息表（delay pending interest table，DPIT）。此外，本文在DPIT基礎上進行進一步改進，以應對更加復雜的實際應用場景。

本文組織結(jié)構如下：第2章介紹了ICN（或NDN、CCN）結(jié)合衛(wèi)星或?qū)崟r內(nèi)容分發(fā)應用的研究情況；第3章介紹了基于NDN的衛(wèi)星廣播視頻直播系統(tǒng)概況和研究動機；第4章具體分析了RDT問題出現(xiàn)的原因及影響，提出用于解決該問題的DPIT機制，并對DPIT機制進行了改進；第5章描述了實驗設計，并對實驗結(jié)果進行分析；第6章總結(jié)全文。

2 相關研究

衛(wèi)星與ICN結(jié)合的大部分研究對ICN中原生支持組播的特性和網(wǎng)內(nèi)緩存機制的應用，以及二者結(jié)合的動力和可行性進行了討論[4-5]。同時，相關研究也分析了偏遠地區(qū)數(shù)據(jù)傳輸?shù)忍囟ǖ膽脠鼍癧6]，以及結(jié)合應用的安全需求和相應解決方法[7]。此外，還有一些研究分析了衛(wèi)星網(wǎng)絡結(jié)合ICN時存在的問題及解決方案，例如結(jié)合衛(wèi)星廣播能力的預緩存策略[8]，基于數(shù)據(jù)請求時間局部性特點的帶寬節(jié)省策略等[9]。需要注意的是，在絕大部分研究中，衛(wèi)星僅承擔數(shù)據(jù)轉(zhuǎn)發(fā)的工作，不具備緩存或路由等功能。

基于內(nèi)容尋址網(wǎng)絡體系結(jié)構進行實時數(shù)據(jù)流傳輸?shù)难芯拷陙淼玫搅艘欢P注[10]。例如，CCN實時數(shù)據(jù)流服務中可減少大量連續(xù)請求的單請求多數(shù)據(jù)包的通信模式[11]，支持實時電視流分發(fā)的CCN-TV系統(tǒng)[12]，基于NDN的減少無線局域網(wǎng)中視頻直播內(nèi)容請求的NLB體系結(jié)構[13]，基于ICN的實時多人視頻會議的體系結(jié)構[14]，CCN電視直播應用的模擬器[15]，以及基于NDN的實時視頻會議函數(shù)庫[16]。

基于已有相關研究內(nèi)容，本文認為視頻直播應用、衛(wèi)星以及NDN三者之間的結(jié)合是一種重要的候選技術路線，結(jié)合具體策略、優(yōu)勢、存在問題及解決方案等，將在后續(xù)章節(jié)進行闡述。

3 基于NDN的衛(wèi)星廣播視頻直播系統(tǒng)

3.1 系統(tǒng)概述及場景抽象

與傳統(tǒng)地面網(wǎng)絡視頻直播系統(tǒng)相比，基于NDN的衛(wèi)星廣播視頻直播系統(tǒng)主要存在兩方面的不同。首先，系統(tǒng)中所有數(shù)據(jù)傳輸基于NDN協(xié)議進行。其次，直播視頻內(nèi)容分發(fā)從地面骨干網(wǎng)絡遷移到衛(wèi)星通信網(wǎng)絡中。系統(tǒng)中主要包含5種基本組成元素，即用戶設備、用戶處地面終端、空間衛(wèi)星、服務器處地面終端以及內(nèi)容提供者服務器。其中，用戶設備主要提供操作接口并進行內(nèi)容展示，衛(wèi)星與地面終端通信，每個地面終端為特定區(qū)域內(nèi)網(wǎng)絡提供服務，用戶或服務器通過所在區(qū)域內(nèi)地面終端交互請求及內(nèi)容。

在傳統(tǒng)電視直播服務中，用戶可通過小型終端天線獲取視頻內(nèi)容，這種方式的可行性在于傳統(tǒng)電視節(jié)目內(nèi)容相對固定，交互性相對較弱。相比之下，網(wǎng)絡視頻直播節(jié)目由于內(nèi)容生產(chǎn)者很多，節(jié)目總體實時變化，結(jié)合NDN中數(shù)據(jù)傳輸由興趣請求驅(qū)動的特點，用戶處地面終端應具備一定的數(shù)據(jù)發(fā)送能力。在這種情況下，小型終端天線無法滿足應用需求。在某一區(qū)域內(nèi)部署一個具有較強數(shù)據(jù)收發(fā)、處理能力的地面終端可為區(qū)域內(nèi)的用戶提供服務。

在基于NDN的衛(wèi)星廣播視頻直播系統(tǒng)中，衛(wèi)星只承擔數(shù)據(jù)轉(zhuǎn)發(fā)的工作，不具備路由和緩存的功能。系統(tǒng)工作時，衛(wèi)星將用戶處地面終端轉(zhuǎn)發(fā)的來自于用戶設備的內(nèi)容請求（由NDN機制決定）轉(zhuǎn)發(fā)至服務器處地面終端，內(nèi)容服務器在接收到相連的地面終端轉(zhuǎn)發(fā)的請求后進行響應，將包含對應內(nèi)容的數(shù)據(jù)包經(jīng)由相應地面終端轉(zhuǎn)發(fā)至衛(wèi)星，再由衛(wèi)星廣播至覆蓋區(qū)域內(nèi)的用戶處地面終端，最后由轉(zhuǎn)發(fā)過請求的地面終端將數(shù)據(jù)包組播至等待內(nèi)容返回的用戶設備。系統(tǒng)概況如圖1所示，需要注意的是，某些情況下用戶處地面終端與服務器處地面終端間的數(shù)據(jù)轉(zhuǎn)發(fā)可能經(jīng)過由多顆衛(wèi)星組成的空間數(shù)據(jù)傳播鏈路。

Fig.1 System overview圖1 系統(tǒng)概況

在大部分情況下，網(wǎng)絡視頻直播內(nèi)容通過相對地球表面靜止的地球靜止軌道（geostationary earth orbit，GEO）衛(wèi)星即可完成大范圍分發(fā)，3顆GEO衛(wèi)星即可覆蓋地球表面絕大部分面積。然而，GEO衛(wèi)星無法覆蓋極地地區(qū)，且某些地區(qū)可能無法部署與GEO衛(wèi)星進行通信的大型地面終端。此時，用戶與內(nèi)容服務器間的數(shù)據(jù)傳播鏈路中可能包括處于移動狀態(tài)的低地球軌道（low earth orbit，LEO）衛(wèi)星和中地球軌道（medium earth orbit，MEO）衛(wèi)星。這些衛(wèi)星按照固定的軌跡移動，以集群形式協(xié)同工作。LEO或MEO衛(wèi)星天線系統(tǒng)工作模式包含衛(wèi)星固定足印和地球固定足印兩種[17]。在地球固定足印模式中，衛(wèi)星能夠自動調(diào)整天線以保證一段時間內(nèi)天線覆蓋區(qū)域不變，進而使得某一區(qū)域內(nèi)的地面終端在這段時間內(nèi)始終由一顆衛(wèi)星提供服務。在這種工作模式下，衛(wèi)星可視為相對某一區(qū)域靜止，用戶設備與服務器間的數(shù)據(jù)總是沿著相對地面某些區(qū)域靜止的衛(wèi)星組成的鏈路傳播，且數(shù)據(jù)傳播往返時間相對穩(wěn)定。這種情況下對于位于地表的用戶處終端和服務器處終端，并不需要關心由于衛(wèi)星移動帶來的問題。

基于以上分析，為了使下文描述更加清晰且合理，對于包含多顆衛(wèi)星的鏈路，本文將其抽象為只包含一顆相對地面靜止衛(wèi)星的傳播鏈路，抽象衛(wèi)星負責某一區(qū)域內(nèi)用戶處地面終端與服務器處地面終端間的通信。抽象場景如圖2所示，抽象前后用戶處地面終端與服務器處地面終端間數(shù)據(jù)傳播延遲保持不變。

Fig.2 Scenario abstraction with multiple satellites圖2 多星場景抽象

3.2 研究動機

NDN基于轉(zhuǎn)發(fā)信息庫（forwardinginformationbase，F(xiàn)IB）、未決信息表（PIT）和內(nèi)容存儲庫（content store，CS）對用于請求內(nèi)容的興趣（Interest）包和包含相應內(nèi)容的數(shù)據(jù)（Data）包進行處理，采用拉取（pull）數(shù)據(jù)方式完成通信[18-19]。其中，F(xiàn)IB存儲用于Interest包轉(zhuǎn)發(fā)的信息；PIT臨時保存正在獲得服務的Interest包信息，并根據(jù)這些信息在收到返回的Data包時進行分發(fā)；CS負責緩存轉(zhuǎn)發(fā)過的內(nèi)容，以服務未來請求相同內(nèi)容的Interest包。當收到一個Interest包時，節(jié)點將依次對PIT、CS和FIB進行查找。查找命中PIT的Interest包信息將存入對應的表項中。查找命中CS的Interest包將直接從CS緩存中得到服務。查找命中FIB的Interest包將依據(jù)表項信息轉(zhuǎn)發(fā)。當Data包返回時，將根據(jù)PIT表項中的信息進行分發(fā)以服務之前的Interest請求，并緩存至CS中。NDN中網(wǎng)絡包的處理轉(zhuǎn)發(fā)流程如圖3所示。

Fig.3 Working process in NDN圖3 NDN處理流程

在圖2所示的場景中，用戶處地面終端為多個用戶設備提供服務。為了獲得連續(xù)視頻直播數(shù)據(jù)流，用戶設備需要發(fā)送連續(xù)的Interest包。第一個Interest包將會被地面終端轉(zhuǎn)發(fā)給衛(wèi)星，并在PIT表中新建相應表項。后續(xù)到達的請求相同內(nèi)容的Interest包由于命中已有PIT表項，將被存入對應表項中，不會產(chǎn)生額外的衛(wèi)星通信。不同地面終端可能發(fā)出相同內(nèi)容請求的Interest包，這些Interest包經(jīng)由衛(wèi)星轉(zhuǎn)發(fā)后到達服務器處地面終端。同樣，由于PIT機制，只有一個Interest包會被發(fā)往服務器。當Data包返回時，服務器處地面終端將Data包轉(zhuǎn)發(fā)至衛(wèi)星進行廣播。衛(wèi)星覆蓋區(qū)域內(nèi)的所有地面終端都將收到衛(wèi)星廣播的Data包。針對某一區(qū)域內(nèi)的所有地面終端，一次Data包廣播可以滿足所有處于等候狀態(tài)的PIT表項。節(jié)點處CS通過緩存轉(zhuǎn)發(fā)的內(nèi)容，可以滿足延遲或重傳的請求，以此顯著減少網(wǎng)絡中傳輸?shù)臄?shù)據(jù)量。此外，基于CS機制還可以實現(xiàn)如即時重放以及緩存點播等功能。

基于NDN提供視頻直播衛(wèi)星廣播服務主要有以下3種優(yōu)勢：第一，用戶地面終端對請求相同內(nèi)容Interest包的聚合不會讓衛(wèi)星承受巨大傳輸壓力。第二，相同的情況發(fā)生在服務器地面終端處，服務器收到的實際請求數(shù)量將有效減少。第三，衛(wèi)星進行一次Data包廣播能夠服務區(qū)域內(nèi)的所有請求過該內(nèi)容的終端，一定程度上擴展了服務范圍，簡化了系統(tǒng)的處理過程，降低了實現(xiàn)難度。未發(fā)送內(nèi)容請求的地面終端通過無意監(jiān)聽方式獲得廣播的Data包，可進一步擴展實現(xiàn)其他功能。

此外，系統(tǒng)在部署與使用方面也存在一些便捷之處。應用系統(tǒng)可以單獨工作，提供完整的視頻直播服務，也可以與傳統(tǒng)的地面網(wǎng)絡視頻直播系統(tǒng)一同提供服務。當某一直播節(jié)目非常流行且需要在大范圍內(nèi)進行分發(fā)時，服務提供者可以選擇使用衛(wèi)星同地面網(wǎng)絡一起完成數(shù)據(jù)傳輸。通過衛(wèi)星直播視頻廣播系統(tǒng)，內(nèi)容提供者還可以推廣某些節(jié)目。部分用戶可通過付費方式獲得更多節(jié)目。對于無法接入到地面網(wǎng)絡的偏遠地區(qū)或相對極端環(huán)境下的用戶，該系統(tǒng)更具意義。

4 RDT問題與DPIT機制

4.1 RDT問題

3.2節(jié)基于具體場景說明了基于NDN通過衛(wèi)星廣播提供網(wǎng)絡視頻直播服務的優(yōu)勢，但該場景比較理想，沒有對衛(wèi)星鏈路的高傳播延遲以及視頻直播請求發(fā)出時間的不一致性進行討論。由于各用戶地面終端局域網(wǎng)環(huán)境和數(shù)據(jù)處理能力上存在差異，即使在直播應用中，各地面終端很難同時轉(zhuǎn)發(fā)請求相同內(nèi)容的Interest包?，F(xiàn)實中類似情況比較常見，比如同一局域網(wǎng)中不同設備同一時刻觀看的網(wǎng)絡視頻直播內(nèi)容存在時間差異。基于NDN的視頻直播衛(wèi)星廣播系統(tǒng)中，服務器處地面終端很可能在不同時刻收到請求相同內(nèi)容的Interest包，這將導致冗余數(shù)據(jù)傳輸問題出現(xiàn)。

以圖2中用戶處地面終端(T0,T1,T2),衛(wèi)星(SAT1)和服務器處地面終端(GW)所在場景（含連接的用戶設備和服務器）為例，場景中網(wǎng)絡包傳遞情況如圖4所示，X軸上橫坐標ti(i=0,1,2,…)代表時間點，兩個節(jié)點間的時間差代表衛(wèi)星到地面終端的傳播延遲，Y軸上縱坐標代表網(wǎng)絡中的主要節(jié)點。3個終端分別在t0和t1之間3個不同時刻發(fā)出請求相同內(nèi)容的Interest包，當來自T1的第一個興趣包在t2時刻到達GW時，將會產(chǎn)生一個相關的PIT表項，在收到返回的Data包之前將會出現(xiàn)一小段等待時間（圖中灰色區(qū)域所示）。在灰色時間內(nèi)到達的Interest包將會命中已經(jīng)存在的PIT表項。在灰色時間后，Data包到達GW，對應的PIT表項獲得服務并移除，Data包（D1）將被發(fā)往SAT1進行廣播。同時，GW處CS將緩存相應內(nèi)容。由于存在傳播延遲，所有終端將在大約t4時刻收到由衛(wèi)星廣播的D1，所有處于等待中的終端(T0,T1,T2)均可獲得服務。

Fig.4 Events in live video broadcasting over satellite with original NDN圖4 基于標準NDN視頻直播衛(wèi)星廣播系統(tǒng)包傳遞過程

在發(fā)出D1后，由終端T2發(fā)出的Interest包將到達GW，由于具有相同名字前綴的PIT表項已經(jīng)移除，將產(chǎn)生一個新的PIT表項存儲Interest包的信息，并對CS進行查找，查找命中之前緩存的內(nèi)容，包含相同內(nèi)容的Data包(D2)將再次被GW發(fā)出，衛(wèi)星在收到D2后將再次進行廣播，所有終端都將接收到D2。從T2的角度來看，發(fā)出的Interest包由約t4時刻接收到的D1服務。因此，D2將會被T2直接忽略，即使該Data包是由于GW為了滿足其發(fā)送的Interest包而發(fā)送的。更糟糕的是，所有終端都將收到第二個廣播Data包，該Data包對于所有不包含相應PIT表項的終端來說都是冗余的，這就是RDT問題。

假設用戶處地面終端與服務器處地面終端之間的傳播延遲為td，圖4中GW等待Data包的時間（灰色區(qū)域）為Δt。如果t0時刻發(fā)出了請求內(nèi)容的第一個Interest包，那么t時刻發(fā)出的請求相同內(nèi)容的Interest包若滿足如下條件將觸發(fā)一次RDT：

需要注意的是，Δt相對td比較小，且在基于NDN的視頻直播衛(wèi)星廣播系統(tǒng)中存在大量相同內(nèi)容請求的Interest包，RDT問題會經(jīng)常出現(xiàn)。服務器處地面終端衛(wèi)星將發(fā)送大量無意義的Data包，這些Data包經(jīng)由衛(wèi)星廣播后將被覆蓋區(qū)域內(nèi)的所有終端接收，在浪費系統(tǒng)內(nèi)的通信計算資源的同時，也增加了地面終端數(shù)據(jù)處理的壓力。

4.2 DPIT機制

根據(jù)4.1節(jié)的內(nèi)容，RDT問題是由衛(wèi)星鏈路較高的傳播延遲造成的。實際上，服務器處地面終端并不了解這種情況，因為傳播延遲并不是NDN體系結(jié)構直接支持的參數(shù)。在這種情況下，服務器處地面終端接收了會導致RDT問題的Interest包，即使這些Interest包可以從之前發(fā)出的Data包獲得服務。為了解決這個問題，本文提出了一種可以讓NDN適應較高傳播延遲的方法。該方法基于標準NDN中PIT機制進行改進，稱為容遲未決信息表（DPIT）。DPIT同標準CS和FIB一同部署在服務器處地面終端上。

根據(jù)式（1），服務器處地面終端在發(fā)出Data包后2td時間內(nèi)接收到請求相同內(nèi)容的Interest包時，RDT問題將出現(xiàn)。由于具有相同名字前綴的PIT表項已被移除，NDN無法知曉導致RDT問題的Interest包實際上已經(jīng)可以由前面發(fā)送的Data包服務。改進NDN體系結(jié)構通過感知通信延遲將能夠解決由于較高的鏈路傳播延遲帶來的RDT問題。PIT表項中記錄了等待服務的Interest包信息，如果延遲PIT表項的移除，則后續(xù)導致RDT問題的Interest包可以被延遲的PIT表項聚合，不會對CS進行查找，不會出現(xiàn)RDT問題。根據(jù)式（1），PIT表項的移除應延遲2td。

以圖4所在場景為例，在服務器處地面終端部署DPIT機制的情況下，圖中灰色區(qū)域擴展至Data包發(fā)出后2td的時間，來自T2的Interest包將不會造成RDT問題，因為該請求被處于延遲移除狀態(tài)的DPIT表項消耗。所有終端都能從廣播Data包中獲得服務，數(shù)據(jù)通信能夠正常完成。

標準PIT表項中主要包含Interest包中用于內(nèi)容分發(fā)的信息，例如名字前綴、到達的端口號（此端口為NDN結(jié)構中的FaceID，下文相同）以及用于標識不同Interest包的奇異值等。為了實現(xiàn)DPIT機制，標準NDN中PIT機制需要進行改進。改進主要包含兩方面：首先，表項中應當包含一個用于區(qū)分正常表項還是延遲表項的狀態(tài)標志。正常表項意味著一個或多個相關Interest包仍處于等待Data包返回狀態(tài)，延遲表項意味著具有相同名字前綴對應的Data包已經(jīng)發(fā)出，表項將在一段時間后移除。其次，表項中還應添加延遲時間的記錄。在延遲時間內(nèi)，任何新到達的具有相同名字前綴的興趣包都會被DPIT表項消耗。在延遲時間耗盡后，DPIT表項將會移除。為保證系統(tǒng)正常工作，延遲時間等于2td。

基于改進NDN的視頻直播衛(wèi)星廣播系統(tǒng)通信效率更高。然而，僅在標準PIT表項中添加一項延遲時間的記錄可能會帶來一些問題。第3章引入了抽象衛(wèi)星的概念，實際上，為了讓視頻直播服務可以覆蓋更多用戶，系統(tǒng)需要多顆抽象衛(wèi)星與服務器處地面終端相連，以完成大范圍內(nèi)容分發(fā)。這些衛(wèi)星到達地面終端的傳播延遲可能相同也可能不同。鏈路傳播延遲最小的衛(wèi)星轉(zhuǎn)發(fā)的Interest包將最先到達服務器處地面終端，DPIT中將添加一個新的表項，之后Data包返回時，處于等待服務狀態(tài)的Interest包都將獲得服務。根據(jù)前文所述，表項的移除將延遲2td，表項被標記為延遲狀態(tài)。由其他衛(wèi)星轉(zhuǎn)發(fā)的Interest包很可能會命中延遲表項，這些Interest包被該表項聚合，無法獲得服務，系統(tǒng)通信不能正常進行。

為了讓DPIT機制能夠適應復雜應用場景，提供大范圍視頻直播廣播服務，本文對DPIT機制進行了進一步改進。衛(wèi)星系統(tǒng)通信時可以通過多址技術對不同信號進行區(qū)分。對處于上層的NDN來說，經(jīng)由不同鏈路轉(zhuǎn)發(fā)的信號體現(xiàn)為到達端口號上的不同。在服務器處地面終端上，NDN可以通過到達端口號區(qū)分Interest包經(jīng)過的空間傳播鏈路，即識別轉(zhuǎn)發(fā)該Interest包的抽象衛(wèi)星。改進后的DPIT表結(jié)構如圖5所示，DPIT表項根據(jù)Interest包到達端口號進一步劃分為多個子項，每個子項中都包含對應的端口號、用于標記子項是否延遲的狀態(tài)標志以及相應的延遲時間記錄，子項延遲時間的記錄與端口號對應。處于正常狀態(tài)的子項表示到達該端口的Interest包等待Data包返回，處于延遲狀態(tài)的子項表示到達該端口的Interest包已經(jīng)得到服務，表項將在延遲時間耗盡后移除。擴展后的表項狀態(tài)包括正常狀態(tài)、延遲狀態(tài)和混合狀態(tài)3種。其中正常狀態(tài)表示表項中所有子項都處于正常狀態(tài)，延遲狀態(tài)表示表項中所有子項都處于延遲狀態(tài)，混合狀態(tài)表示表項中部分子項處于正常狀態(tài)。

Fig.5 Architecture of DPIT table圖5 DPIT表結(jié)構

Fig.6 Working process in revised NDN with DPIT圖6 具有DPIT的NDN處理流程

服務器處地面終端上部署的具有DPIT機制的改進NDN工作流程如圖6所示。當一個Interest包到達服務器處地面終端時，將依次對DPIT、CS和FIB進行查找。對查找命中DPIT表項Interest包的處理取決于Interest包到達端口是否存在于該表項中以及該表項的狀態(tài)。對于到達端口包含在該表項中的Inter-est包，不對CS進行查找；對于到達端口不在該表項中的Interest包的處理由表項的狀態(tài)決定。若表項處于正?；蚧旌蠣顟B(tài)，說明已有相關請求發(fā)出，相同請求無須再次發(fā)送，此時將新到達端口添加到表項中，標記為正常狀態(tài)，等待Data包返回；若表項處于延遲狀態(tài)，說明CS中含有相應內(nèi)容的緩存，此時將新端口添加到表項中，標記為正常狀態(tài)，表項改為混合狀態(tài)，對CS進行進一步查找以獲得請求內(nèi)容。在CS查找命中后，包含相應內(nèi)容的Data包從表項中所有處于正常狀態(tài)子項中的端口發(fā)出，并將這些子項標記為延遲狀態(tài)，并添加相應延遲時間記錄，同時將表項改回延遲狀態(tài)。服務器處地面終端對于返回Data包的處理與標準NDN基本相似，唯一不同之處在于DPIT表項及其中所有子項都會被標記為延遲狀態(tài)，Data包會從表項中所有端口發(fā)出，子項中將添加相應延遲時間記錄。對于處于延遲狀態(tài)下的子項，當延遲時間耗盡時將移除。在延遲表項中最后一個子項移除后，該表項移除。

5 實驗分析與性能評估

本章主要進行實驗分析和性能評估，旨在分析衛(wèi)星廣播網(wǎng)絡視頻直播系統(tǒng)中，應用改進NDN是否能有效減少系統(tǒng)中由于空間鏈路較高的傳播延遲造成的冗余數(shù)據(jù)傳輸現(xiàn)象。

5.1 實驗設計

本文以ndnSIM模擬器[20-21]為基礎，模擬應用標準NDN和改進NDN時網(wǎng)絡包的傳遞處理過程。實驗中采用類似圖2的拓撲結(jié)構，利用抽象衛(wèi)星代替實際鏈路中多顆衛(wèi)星。ndnSIM可通過讀取文件來獲取拓撲信息和鏈路信息。實驗中包含前文所述的5種網(wǎng)絡節(jié)點，衛(wèi)星僅對收到的Interest包進行轉(zhuǎn)發(fā)，對Data包進行廣播。實驗中DPIT部署于服務器處地面終端。

實驗中td設置為50 ms到250 ms之間。用戶設備在60 s內(nèi)以每秒5包的頻率發(fā)送Interest包。為了模擬局域網(wǎng)差異，每個用戶設備隨機延遲一段時間發(fā)送Interest包。通過對ndnSIM模擬器進行修改，在網(wǎng)絡節(jié)點上收集并統(tǒng)計所有終端接收到的Data包總量與發(fā)送Interest包總量。實驗中將二者比值作為性能指標，比值越大說明冗余越嚴重。

考慮到實際情況中不同的視頻直播節(jié)目流行程度各有差異，實驗中通過設定用戶設備發(fā)送請求的概率模擬節(jié)目流行程度，節(jié)目越流行，用戶設備發(fā)送請求概率越高。一旦確定發(fā)送請求，用戶設備將在整個實驗周期內(nèi)發(fā)送Interest包；反之，用戶設備將不發(fā)送Interest包。為了進行全面比較，本文一共進行6組對比實驗。

5.2 實驗結(jié)果與分析

第1組實驗主要分析視頻流行程度對系統(tǒng)效率的影響，并對不同流行程度下改進NDN與標準NDN性能進行對比。實驗中包含一顆鏈路往返延遲為250 ms的抽象衛(wèi)星以及50個用戶處地面終端。實驗結(jié)果如圖7所示，改進NDN可以有效減少系統(tǒng)中的冗余數(shù)據(jù)傳輸。隨著視頻流行程度的提升，應用標準NDN時系統(tǒng)中冗余比基本不變，而應用改進NDN時系統(tǒng)中冗余比會不斷下降，對于系統(tǒng)效率提升更大。當視頻流行程度為1，即每個用戶地面終端都轉(zhuǎn)發(fā)請求時，應用改進NDN時系統(tǒng)基本可以做到無冗余數(shù)據(jù)傳輸。

Fig.7 Redundancy in scenario including one satellite with different radio of sending request圖7 單顆衛(wèi)星場景不同流行程度冗余對比

為了更加接近真實使用場景，后續(xù)5組實驗中每個用戶設備隨機以20%至80%間的概率發(fā)送數(shù)據(jù)請求。其中，第2、3、4組實驗中用戶處地面終端與內(nèi)容服務器處地面終端間傳播延遲相同，均為250 ms；第5、6組實驗中不同區(qū)域的用戶處地面終端與內(nèi)容服務器處地面終端間傳播延遲不同，傳播延遲設置在50 ms到250 ms之間，服從均勻分布（例如，3顆衛(wèi)星延遲為50、150、250 ms，5顆衛(wèi)星延遲為50、100、150、200、250 ms）。

第2組實驗中只包含一顆衛(wèi)星，用戶處地面終端數(shù)量不固定，具體設定在10至100之間。實驗結(jié)果如圖8所示，改進NDN可以有效減少系統(tǒng)中的冗余數(shù)據(jù)傳輸。地面終端數(shù)量越多，造成RDT問題的Interest包數(shù)量越多，衛(wèi)星在廣播時分發(fā)的冗余Data包也越多，應用標準NDN冗余更嚴重，改進NDN對系統(tǒng)性能提升越大。改進NDN中可通過DPIT對造成RDT問題的Interest包進行聚合，因此改進NDN中冗余比基本不變。

Fig.8 Redundancy in scenario including one satellite圖8 單顆衛(wèi)星場景冗余對比

第3組實驗與第2組實驗相似，區(qū)別在于實驗場景中包含5顆衛(wèi)星，每顆衛(wèi)星服務終端數(shù)量不固定，具體設定在5至50之間。實驗結(jié)果如圖9所示。與第2組實驗相同，改進NDN具有更好的性能，且性能提升隨著終端數(shù)量增多而增加。結(jié)合第2組實驗結(jié)果，當?shù)孛娼K端總量相同時，單顆衛(wèi)星服務地面終端數(shù)量越少，導致RDT問題的Interest包以及觸發(fā)的冗余廣播Data包更少，采用標準NDN時冗余數(shù)據(jù)傳輸越少，改進NDN對于系統(tǒng)性能提升越小。

Fig.9 Redundancy in scenario including multiple satellites with same propagation delay(the number of satellites is stable)圖9 多顆同延遲衛(wèi)星場景冗余對比（衛(wèi)星數(shù)量固定）

第4組實驗中每顆衛(wèi)星為20個地面終端提供服務，衛(wèi)星數(shù)量不固定，設定在2至20之間。實驗結(jié)果如圖10所示，改進NDN性能更好，與第2、3組實驗不同，性能提升比較穩(wěn)定，基本不隨衛(wèi)星數(shù)量增加而變化。單顆衛(wèi)星服務終端數(shù)量固定，導致RDT問題的Interest包以及觸發(fā)的冗余廣播Data包數(shù)量基本不變。對第2、3、4組實驗數(shù)據(jù)綜合對比后可知，地面終端總數(shù)一定時，衛(wèi)星數(shù)量越少，單顆衛(wèi)星服務終端越多，造成RDT問題的Interest包數(shù)量越多，出現(xiàn)RDT問題時產(chǎn)生的冗余Data包越多，采用標準NDN時冗余越多，應用改進NDN性能提升越大。在用戶處地面終端到服務器處地面終端傳播延遲與視頻流行程度相同的情況下，冗余程度主要與單顆衛(wèi)星服務終端數(shù)量相關，衛(wèi)星數(shù)量的提升并不會造成更嚴重的冗余數(shù)據(jù)傳輸。

Fig.10 Redundancy in scenario including multiple satellites with same propagation delay(the number of satellites is unstable)圖10 多顆同延遲衛(wèi)星場景冗余對比（衛(wèi)星數(shù)量不固定）

第5組實驗中包含5顆衛(wèi)星，每顆衛(wèi)星服務終端數(shù)量不固定，具體設定在5至50之間。實驗結(jié)果如圖11所示，改進NDN性能更好，且性能提升隨著衛(wèi)星數(shù)量增多而增加。與除傳播延遲外其他參數(shù)相同的第3組實驗對比，傳播延遲不同的場景下冗余數(shù)據(jù)傳輸問題更嚴重。應用標準NDN時，傳播延遲最小的衛(wèi)星轉(zhuǎn)發(fā)的Interest包將先獲得服務，相關PIT表項移除，服務器處地面終端CS中緩存請求的內(nèi)容。后續(xù)經(jīng)由傳播延遲更高鏈路到達的絕大部分Interest包幾乎都會導致一次冗余數(shù)據(jù)傳輸。

Fig.11 Redundancy in scenario including multiple satellites with different propagation delay(the number of satellites is stable)圖11 多顆不同延遲衛(wèi)星場景冗余對比（衛(wèi)星數(shù)量固定）

第6組實驗中衛(wèi)星數(shù)量不固定，實驗結(jié)果如圖12所示，與第4組實驗相似，改進NDN性能更好，但性能提升不隨衛(wèi)星數(shù)量增加而波動。在第5、6組實驗中，單顆衛(wèi)星服務終端越多，采用標準NDN時冗余越多，應用改進NDN性能提升越大。與第3、4組實驗對比發(fā)現(xiàn)，衛(wèi)星及單顆衛(wèi)星服務終端數(shù)量以及視頻流行程度相同時，延遲不同情況下采用標準NDN時存在冗余越多，改進NDN對于系統(tǒng)性能提升越大。

Fig.12 Redundancy in scenario including multiple satellites with different propagation delay(the number of satellites is unstable)圖12 多顆不同延遲衛(wèi)星場景冗余對比（衛(wèi)星數(shù)量不固定）

根據(jù)以上6組對比實驗可以得出如下結(jié)論：應用改進NDN時，視頻越流行，冗余數(shù)據(jù)傳輸越少，衛(wèi)星數(shù)量、單顆衛(wèi)星服務終端數(shù)量以及傳播延遲差異影響較?。粦脴藴蔔DN時，單顆衛(wèi)星服務終端數(shù)量越多，冗余數(shù)據(jù)傳輸越高，傳播延遲不同時冗余數(shù)據(jù)傳輸更嚴重，衛(wèi)星數(shù)量以及視頻流行程度影響較小。

6 結(jié)論

本文闡述了基于NDN的衛(wèi)星廣播視頻直播的背景、方案和應用價值，分析并說明了由于較高的空間鏈路傳播延遲帶來的冗余數(shù)據(jù)傳輸（RDT）問題，并提出了可以提升效率的容遲未決信息表（DPIT）機制。實驗結(jié)果表明，與標準NDN相比，帶有DPIT的改進NDN可以有效減少RDT問題帶來的影響，提升應用效率。本文研究方法不僅限于衛(wèi)星廣播網(wǎng)絡視頻直播應用中，也可以應用于其他基于衛(wèi)星開展的大規(guī)模內(nèi)容分發(fā)應用或鏈路傳播延遲較高的相關場景。

[1]Sandvine.Global Internet phenomena report:Africa,Middle East&North America[EB/OL].(2015-12-07)[2016-10-25].http://www.internetphenomena.com/2015/12/global-internetphenomena-report-africa-middle-east-north-america/.

[2]Cisco.Cisco VNI forecast and approachology,2015—2020[EB/OL].(2016-06-01)[2016-10-25].http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visal-networkingindex-vni/complete-white-paper-c11-481360.html.

[3]Zhang Lixia,Afanasyev A,Burke J,et al.Named data networking[J].Computer Communication Review,2014,44(3):66-73.

[4]Siris V,Ververidis C N,Polyzos G C,et al.Information-centric networking(ICN)architectures for integration of satellites into the future Internet[C]//Proceedings of the 1st AESS European Conference on Satellite Telecommunications,Rome,Oct 2-5,2012.Piscataway:IEEE,2012:1-6.

[5]Siris V A,Ververidis C N,Polyzos G C.Techno-economic gains analysis of services over an information-centric integrated satellite-terrestrial network[C]//Proceedings of the Future Network and Mobile Summit,Lisbon,Jul 3-5,2013.Piscataway:IEEE,2013:1-10.

[6]Liolis K P,Drougas A,Andrikopoulos I A,et al.Satelliteterrestrial integration scenarios for future information-centric networks[C]//Proceedings of the 30th International Communications Satellite Systems Conference,Ottawa,Sep 24-27,2012.Menlo Park:AAAI,2012:253-258.

[7]Fotiou N,Thomas Y,Siris V A,et al.Security requirements and solutions for integrated satellite-terrestrial informationcentric networks[C]//Proceedings of the 7th Advanced Satellite Multimedia Systems Conference and the 13th Signal Processing for Space Communications Workshop,Livorno,Sep 8-10,2014.Piscataway:IEEE,2014:106-113.

[8]Galluccio L,Morabito G,Palazzo S.Caching in informationcentric satellite networks[C]//Proceedings of the 2012 International Conference on Communications,Ottawa,Jun 10-15,2012.Piscataway:IEEE,2012:3306-3310.

[9]Detti A,Caponi A,Blefari-Melazzi N.Exploitation of information centric networking principles in satellite networks[C]//Proceedings of the 1st AESS European Conference on Satellite Telecommunications,Rome,Oct 2-5,2012.Piscataway:IEEE,2012:1-6.

[10]Xu Hongfeng,Chen Zhen,Chen Rui,et al.Live streaming with content centric networking[C]//Proceedings of the 3rd International Conference on Networking and Distributed Computed,Hangzhou,Oct 21-24,2012.Washington:IEEE Computer Society,2012:1-5.

[11]Li Haibo,Li Yang,Lin Tao,et al.MERTS:a more efficient real-time traffic support scheme for content centric networking[C]//Proceedings of the 6th International Conference on Computer Sciences and Convergence Information Technology,Seogwipo,Nov 29-Dec 1,2011.Piscataway:IEEE,2011:528-533.

[12]Ciancaglini V,Piro G,Loti R,et al.CCN-TV:a data-centric approach to real-time video services[C]//Proceedings of the 27th International Conference on Advanced Information Networking and Applications Workshops,Barcelona,Mar 25-28,2013.Washington:IEEE Computer Society,2013:982-989.

[13]Li Menghan,Pei Dan,Zhang Xiaoping,et al.NDN live video broadcasting over wireless LAN[C]//Proceedings of the 24th International Conference on Computer Communication and Networks,Las Vegas,Aug 3-6,2015.Piscataway:IEEE,2015:1-7.

[14]Jangam A,Ravindran R,Chakraborti A,et al.Realtime multiparty video conferencing service over information centric network[C]//Proceedings of the 2015 International Conference on Multimedia&Expo Workshops,Torino,Jun 29-Jul 3,2015.Washington:IEEE Computer Society,2015:1-6.

[15]Eftekhari S,Ghahfarokhi B S,Moghim N.Otanes:a live TV simulator for content-centric networking[C]//Proceedings of the 7th Conference on Information and Knowledge Technology,Urmia,May 26-28,2015.Piscataway:IEEE,2015:1-6;

[16]Gusev P,Burke J.NDN-RTC:real-time videoconferencing over named data networking[C]//Proceedings of the 2nd International Conference on Information-Centric Networking,San Francisco,Sep 30-Oct 2,2015.New York:ACM,2015:117-126.

[17]Lu Yong,Zhao Youjian,Sun Fuchun,et al.Routing techniques on satellite networks[J].Journal of Software,2014,25(5):1085-1100.

[18]Yi Cheng,Afanasyev A,Wang Lan,et al.Adaptive forwarding in named data networking[J].ACM SIGCOMM Computer Communication Review,2012,42(3):62-67.

[19]Yuan Haowei,Song Tian,Crowley P.Scalable NDN forwarding:concepts,issues and principles[C]//Proceedings of the 21st International Conference on Computer Communications and Networks,Munich,Jul 30-Aug 2,2012.Piscataway:IEEE,2012:1-9.

[20]Afanasyev A,Moiseenko I,Zhang Lixia.ndnSIM:NDN simulator for NS-3,NDN-0005[R].2012.

[21]Mastorakis S,Afanasyev A,Moiseenko I,et al.ndnSIM 2.0:a new version of the NDN simulator for NS-3,NDN-0028[R].2015.

附中文參考文獻：

[17]盧勇,趙有健,孫富春,等.衛(wèi)星網(wǎng)絡路由技術[J].軟件學報,2014,25(5):1085-1100.