4 Layer Deadline Scheduling Algorithm
4.2 Selection Phase
為了縮短下載的時間，我們針對每個要下載的,挑出一個最佳的節點,， 這個節點擁有最小的 RTT 值,∗ ，如下圖 8。
以節點 A 為例，一開始先透過起始點(Bootstrap)取得候選節點清單(Candidate Peer List)，並得知這些候選節點擁有所需要的階層檔案。為了從這些候選節點中 挑選出一個最佳的節點取得階層檔案，節點 A 便會送 Ping 封包給候選節點清單 上的每一個節點，並選擇具最小 RTT 值的節點 D 為最佳節點。並檢查與節點 D 間的可用頻寬是否符合,所需要的傳輸頻寬,，若符合則利用(3)計算出,
的最終播放時間,；若不符合，則從候選節點清單中挑選次佳的節點。
Figure 8 Selection Phase.
Pseudo code 如下圖 9，透過兩個 for 迴圈針對每一個,，從其候選節點清單
中比較 Ping 封包的 RTT 值，當此節點 k 的 RTT 值為最小又符合,所需要的頻 寬需求,時，將節點 k 設為最佳節點,，並計算相關的傳輸時間,以及最 終播放時間,以供排程階段使用。
圖 10 Selection Phase pseudo code 4.3 Scheduling Phase
在這個部分裡，為了達到在播放時無延遲的目的，就必須在每個區塊 i 的最 終播放時間內完成區塊 i 的傳輸；若希望區塊 i 能達到最高的畫質效果，則必 須取得最多個區塊 i 的,。因此綜合以上兩點，「在最終播放時間內，完成最 多個,的傳輸」是我們的最終目標。
for ( i=0 to i=N-1 ) for ( j=0 to j=M-1 ) for( k=1 to Ci,j ) {
if [(RTTk < RTTi,j* ) && (sizeof(ping)/ RTTk >= BWi,j) ] { RTTi,j* = RTTk ;
Bi,j = k ;
TRi,j = Si,j / BWi,j
TDi,j = Di - TRi,j }
}
Figure 9 The Pseudo Code of Selection Phase.
Components of Scheduling
首先我們要考慮的有三個部分，如圖 10 的 LDS 區域：
1. 最終播放時間(Deadline)
當取得,的時間已經超過它的最終播放時間,，此時,已經無用處。
為了避免收到,時超過,，造成不必要的傳輸，我們將「最終播放時間」
作為第一考量，進行傳輸順序的安排。
2. 相依性(Dependency)
由於每個階層之間無法獨立完成解碼，存在階層間的相依性問題，若是 基礎層不存在，其後續的增強層就沒有用處。因此給予基礎層最高的優先權 值，增強層則給予次高的優先權值。
3. 下載頻寬(Downlink bandwidth)
根據(2)以及(3)，在計算,的,時，是以,所需的基本頻寬,為 基礎，因此若是進行傳輸時的頻寬BW小於,，傳輸時間,勢必會增加，
因而影響到,。
Figure 10 A Conceptual Diagram of LDS Algorithm.
考慮上述因素，分三種狀況討論如表 7，當傳輸時的可用頻寬BW大於,時 表示有足夠的傳輸能力，因此不管其優先權值都可進行下載。但當BW小於,
時，如果其優先權值大於清單的前一個檔案時，表示目前這個檔案較重要，為滿 足相依性需求則必須先取得，因此將清單中的前一個項目刪除，重複檢查此步驟 直到BW大於,。但當優先權值小於清單的前一個檔案時，則表示目前的檔案 可有可無，為了節省傳輸頻寬而將其放棄下載。
Table 7 Three Cases of LDS.
Case BW I , Handle
1 ≥ , --- Download list[k]
2 < , > @LMN[?12] Drop list[k-1] , check again 3 < , < @LMN[?12] Drop list[k]
Scheduling Procedure
為了簡化過程，我們將一個完整的串流資料分段處理，每次處理個區塊
(Chunk)的資料。如下圖 11 對於這個區塊進行排程的步驟如下：
Figure 11 The Flow Chart of LDS.
1. 為了避免取得的階層超過其最終播放時間而失效，因此將所有需要的階 層,依照其最終播放時間,進行 最早期限優先(Earliest Deadline First，EDF)排程。
2. 若實際傳輸時間超過當初所預估之時間，則用來排程下載順序的最終播 放時間將失去準確性，因此為了保證先前所預估的傳輸時間無誤，將依 照順序檢測當時的下載頻寬BW是否符合該階層的所需頻寬,？ i. 若符合就進行傳輸，如表 7 的 Case 1。
ii. 若不符合但目前要傳輸的階層優先權值大於序列中前一個階層，便停
止前一個階層的傳輸，並重複此步驟，如表 7 的 Case 2。
iii. 若頻寬不符合且要傳輸的階層優先權值也比序列中前一個階層要來
的小，則表示這個階層非必要，因此可將其刪除，已完成後續的傳輸。，
如表 7 的 Case 3。
根據最早期限優先(EDF)的排程原則，我們可以在期限內完成所需階層的傳 輸，避免播放時的延遲。而靠著階層間的優先權值關係，我們則可以盡可能的取 得更多的階層來改善畫面品質。
4.4 Example Run
程序流程範例如下圖 12，步驟 1 先將每一回合(Round)的所有物件(Object) 根據各自的最終下載時間,排序成 list[0..MN-1]；步驟 2 判斷該回合的物件是 否都處理完畢，若尚未結束則接著檢查當時的可用頻寬是否符合,的最小需求 頻寬,，若符合則進行步驟 3.1 開始 list[k]的傳輸；若不符合則接著步驟 3.2 進行優先權值的比較，當目前的 list[k]權值較高則進行步驟 4.1 中斷 list[k-1]的傳 輸並重覆步驟 3 檢查可用頻寬；當目前的 list[k]權值較低則進行步驟 4.2 取消 list[k]
的傳輸，待該回合的所有物件皆處理完畢，接著步驟 5 開始下一回合的排程程 序。
Figure 12 The Example Run of LDS.
5 System Implementation
在這篇論文中，我們建構了一個系統平台來驗證前一章所提出的排程方法。
如下圖 13 所示，系統主要分為兩個部分：一是處理串流檔案的前置作業，負責 將串流檔案處理成所需要的階層格式，再將這些階層檔案放置到我們所建構的 Chord 網路環境中，讓一節點可利用此 P2P 環境取得所需的檔案，詳細如 5.1 節 所述；二則是讓依使用者可以看到串流影像的觀看程序，包含前一章所提及的 LDS 排程演算法，詳細如 5.2 節所述。
Figure 13 An Overview of System Implementation.
5.1 Pre-Processing
處理串流檔案的前置作業如下圖 14 所示，將一個串流檔案經由 JSVM 6.8.2 所提供的 SVC Encoder 壓縮成 SVC 檔案，再透過 Bitsream Extractor 萃取出各階 層的內容，再放置到 Chord-P2P 環境中。
Figure 14 An Overview of Pre-processing.
5.2 LDS Algorithm
在 LDS 排程演算法裡，我們使用 VB.NET 作為程式撰寫之基礎並執行於 Windows 平台上。其架構如下圖 15 所示，分成三個模組：搜尋模組(Searching Module)、選擇模組(Selection Module)、排程模組(Scheduling Module)。其中搜尋 模組主要功能為尋找某一特定階層檔案的網路位置，Hash File Name 程序將每個
,檔案的檔名進行雜湊(Hash)後取得 hash_id，Compare Hash ID 程序再透過 Chord-P2P 環境，利用雜湊後的 hash_id 進行字串比較，尋找在網路中擁有這個 檔案的候選節點群並回傳一候選節點清單(List of Candidate Peers)。
此清單被搜尋模組從中挑選出一個最適合的節點來取得須要的檔案，由下式 清單結構；而 Check Bandwidth、Check Priority 程序則根據表 7 的規則，檢查下 載清單結構裡每個,的頻寬以及優先權值，判斷是否該進行下載或是取消，以 達到最佳的下載順序；最後 Download File 程序先產生一執行緒(Thread)再利用
HTTP Protocol 進行,檔案的下載。在本地端會有一塊空間用來暫存待播放的影
像稱為緩衝區(Buffer)，每完成一個回合的排程後，為了節省網路資源，Check
Buffer 程序發現緩衝區的大小超過所設定的門檻值時，表示緩衝區內的資料太多
還不急著進行下一回合的排程及下載，等待一段時間後，再檢查一次，若緩衝區 的大小低於門檻值，則可進行下一回合的排程程序。
Figure 15 An Overview of LDS Procedure.
6 Experiments and Results
6.1 Test Environment
實驗的環境包含了三個角色 Client、WAN Emulator 以及 Peer A、B，如下圖 16。其中 Client 負責在 P2P 網路中搜尋一段串流視訊來觀看； WAN Emulator 則是用來模擬真實網路環境，藉此消除內部測試網路環境過於單純之問題，除了 限制各點之間的點對點頻寬之外，實際測試時並針對封包的延遲時間(RTT/2)、
遺失率(Loss Rate)、重複率(Duplication Rate)、錯誤率(Corruption Rate)進行參數 之設置；最後 Peer A、B 負責模擬 P2P 網路中大量的節點，並提供串流視訊檔案。
Figure 16 Test Environment.
6.2 Test Cases
將一個十二秒的串流視訊以每一秒的時間間隔分割成十二個不同區塊
(chunk)，再將每一個區塊分別用 JSVM 壓縮成三個不同品質的階層檔案(layer)：
Baseline @ Level 1.3、Scalable Baseline @ Level 2.1、Scalable High @ Level 2.2。
考慮將不同的區塊個數進行每一回合的 LDS 排程程序，若區塊個數過少則 會因下載程序會過於頻繁而造成同時有太多傳輸進行使得傳輸時間增加，反之，
若區塊個數過大表示同時有過多的階層檔案進行傳輸，也會使得傳輸時間增加，
從表 8 中可得知當區塊個數為三時所得到的效果為最好，也就是每回合排程三個
(2)不做任何處理的 Random Selection Algorithm、以及第二章的相關研究中所提及 的(3)Smooth Algorithm without delay 和(4)Smooth Algorithm with 1 sec[5]，以了解 畫面品質(Picture Quality)、演算法效能(Performance of Algorithm)、使用者等待時 間(User Waiting Time)與起始延遲時間(Startup Latency 數值)的影響。同樣於相關 研究中所提的 GaiaSharp[6]系統，由於其方法與內部元件結合較緊密，因此無法
好的，其畫面品質接近滿分 3；而 Random 是隨機挑選節點以取得檔案，因此挑 到 RTT 值大的節點機率較高，造成畫面品質不穩定；最後 Smooth_No_Delay 以 及 Smooth_Delay_1 固定從 RTT 值最小的節點取得基礎層，RTT 值次小的節點取 得增強層，因此當網路環境越來越差時取得增強層的時間便會增加，使得增強層 來不及在最終播放時間之內取得，造成其畫面品質無法提升，僅維持在基本品質 的部分。因此 LDS 能有效的改善畫面品質，並改善了 Smooth Algorithm 將近一 倍以上的畫面品質。
(A) RTT/2 (B) Loss Rate
(C) Duplication Rate (D) Corruption Rate
Figure 17 Picture Quality.
但觀察圖 17(B)(C)的畫面品質曲線部分，當封包遺失率與重複率逐漸增加時 LDS 所能提供的畫面品質並沒有因此而下降。所以我們對照使用者等待時間的 數據圖如下圖 18，同時參考使用者等待時間對畫面品質的影響時，發現這兩條 曲線的走向是一致的，也就是說當使用者等待時間增加時，由於緩衝的時間增加 使得有充裕的時間取得更多的階層，造成畫面品質隨著遺失率與重複率增加實並 無下降。
(A) Loss Rate (B) Duplication Rate Figure 18 Waiting Time and Picture Quality.
Performance of Algorithm
我們利用「失效下載率」來當作演算法效能的指標。失效下載率指的是下載 了多少失效的檔案，當取得某個增強層後因取得的時間已經超過其最終播放時間，
則這個增強層便無用處了。當失效下載率越高表示下載越多無用處的檔案，不僅 對畫面品質的改善沒有幫助之外，也多增加了不必要的網路流量。
如下圖 19 所示，當我們分別設置延遲時間(A)、遺失率(B)、重複率(C)、錯 誤率(D)等參數時，由於 LDS 演算法預先估算了每個階層的傳輸時間，當預測結 果顯示某個階層檔案來不及在其最終播放時間之前取得，便提早決定放棄這個可
如下圖 19 所示，當我們分別設置延遲時間(A)、遺失率(B)、重複率(C)、錯 誤率(D)等參數時，由於 LDS 演算法預先估算了每個階層的傳輸時間，當預測結 果顯示某個階層檔案來不及在其最終播放時間之前取得，便提早決定放棄這個可