互動類型(NRT-interactive)之傳輸率模擬呈現

本論文在此節呈現上述場景一以及場景二之 NRT-interactive 類型傳輸量其透 過比例型公平演算法，在模擬結果展現本論文所提出之資源分配演算法於 NRT – Interactive 類型之系統傳輸率有令人滿意的表現。

圖 4- 11 模擬結果根據場景一，呈現前 100 個已成功傳送封包之封包總和(The sum of 100 transmitted packets)，意同整體系統之傳輸量。圖中 x 軸為模擬之時間 500 ms~1000 ms，y 軸為已成功傳送封包之封包總和，圖中比較之演算法有先進 先出(First In First Out Scheduling, FIFO Scheduling)演算法、原始比例型公平資源 分配演算法(Proportional Fairness Scheduling, PF Scheduling)[6]以及絕對保證 RT 類型服務 QoS 之絕對優先權演算法(Absolute QoS Scheduling)。從圖 4-11 可看出 本論文所提出之資源分配演算法之效能於整體系統傳輸量表現優異，可印證本論 文所提出之資源分配演算法可提升整體系統之傳輸量，絕對優先權演算法

Absolute QoS Scheduling 在此表現不佳之是植基於 RT-Conversational 類型封包之 傳輸量小，如使用 VoIP G.711 應用之封包為固定 162 bytes，而 NRT-Interactive 類性封包之特性為封包傳輸量大，如用戶若使用 FTP 下載或網頁瀏覽，封包最大

Absolute QoS Scheduling

Proposed Scheduling 500 16.24 Mbytes 10.62 Mbytes 0.162 Mbytes 13.61 Mbytes 600 17.38 Mbytes 10.88 Mbytes 0.162 Mbytes 16.59 Mbytes 700 21.70 Mbytes 14.91 Mbytes 0.162 Mbytes 17.32 Mbytes 800 22.30 Mbytes 15.53 Mbytes 0.162 Mbytes 18.76 Mbytes 900 24.79 Mbytes 17.33 Mbytes 0.162 Mbytes 21.19 Mbytes 1000 37.17 Mbytes 17.37 Mbytes 0.162 Mbytes 27.01 Mbytes

圖 4- 11、前 100 個已成功傳送封包之封包總和於場景一(Mbytes)

圖 4- 12 模擬結果根據場景二，呈現前 100 個已成功傳送封包之封包總和(The sum of 100 transmitted packets)，意同整體系統之傳輸量。圖中 x 軸四種比較之演 算法，y 軸為已成功傳送封包之封包總和，圖中比較之演算法有先進先出(First In First Out Scheduling, FIFO Scheduling)演算法、原始比例型公平資源分配演算法 (Proportional Fairness Scheduling, PF Scheduling)[6]以及絕對保證 RT 類型服務 QoS 之絕對優先權演算法(Absolute QoS Scheduling)。從圖 4-12 可看出本論文所 提出之資源分配演算法之效能於整體系統傳輸量表現優異，可印證本論文所提出 之資源分配演算法可提升整體系統之傳輸量，絕對優先權演算法 Absolute QoS Scheduling 在此表現不佳之是植基於 RT 類型封包之特性為傳輸量小，而

NRT-Interactive 類性封包之特性為封包傳輸量大，如用戶若使用 FTP 下載，封包 最大可達到 2 Mbytes；然而使用絕對優先權演算法在混合網路中之排程器只關注 於 RT 類型服務之 QoS 而不考慮用戶傳輸量，因此會在呈現整體系統傳輸量方面 表現不佳；使用 PF 演算法[6]在此表現良好之原因是因為 PF 演算法比較用戶傳 輸量，若是用戶之傳輸量高則就有機會列入排程，固使用 PF 演算法[6]會在總體 系統傳輸量呈現良好。

表 4- 13、前 100 個已成功傳送封包之封包總和於場景二(Mbytes) PF

Scheduling

FIFO Scheduling

Absolute QoS Scheduling

Proposed Scheduling Throughput

(Mbytes)

78.45 Mbytes 41.65 Mbytes 0.36 Mbytes 78.12 Mbytes

圖 4- 12、前 100 個已成功傳送封包之封包總和於場景二(Mbytes)

圖 4- 13 模擬結果根據場景二，呈現 NRT-Interactive 類型之封包傳送率於前 100 個已成功傳送封包(The NRT-Interactive packets transmission rate)，意同觀察整 體系統之傳輸量。圖中 x 軸為四種比較之演算法，y 軸為 NRT-Interactive 類型之 封包傳送率於前 100 個已成功傳送封包，圖中比較之演算法有先進先出(First In First Out Scheduling, FIFO Scheduling)演算法、原始比例型公平資源分配演算法 (Proportional Fairness Scheduling, PF Scheduling)[6]以及絕對保證 RT 類型服務 QoS 之絕對優先權演算法(Absolute QoS Scheduling)。從圖 4-13 可看出本論文所 提出之資源分配演算法之效能於整體系統傳輸量表現優異，可印證本論文所提出 之資源分配演算法可提升整體系統之傳輸量，NRT-Interactive 類性之封包特性為

封包傳輸量大，如用戶若使用 FTP 下載，封包最大可達到 2 Mbytes， PF 演算法 [6]在此表現良好之原因是因為 PF 演算法比較用戶傳輸量，若是用戶之傳輸量高 則就有機會列入排程，因此若 eNodeB 內使用 PF 演算法[6]，排程器將會挑選 NRT 類型封包進行傳送，因此在 NRT-Interactive 傳輸率呈現良好。

圖 4- 13、NRT-Interactive 類型之封包傳送率於前 100 個已成功傳送封包(%)

從圖 4-11~圖 4-13 可看出，本研究提出之資源分配演算法可維持 NRT 類別服 務之系統資源使用率，於封包傳送率與傳送封包總和呈現之效能幾乎貼近 PF 演 算法，即表示本系統之 NRT 服務用戶對系統服務感覺良好，可保證 NRT 服務之 系統資源使用率。

圖 4- 14 模擬結果根據場景二，呈現比較 NRT 類型封包傳送率於與 RT 類 型封包傳輸率。圖中 x 軸為 RT 類型封包傳輸率，y 軸為 NRT 類型封包傳輸率，

圖中比較之演算法有先進先出(First In First Out Scheduling, FIFO Scheduling)演 算法、原始比例型公平資源分配演算法(Proportional Fairness Scheduling, PF Scheduling)[6]以及絕對保證 RT 類型服務 QoS 之絕對優先權演算法(Absolute QoS Scheduling)。

從圖 4-14 可看出本論文所提出之資源分配演算法之效能於整體系統效能表 現優異，可印證本論文所提出之資源分配演算法兼顧 RT 類型服務與 NRT 類型 服務。圖中顯示 PF 演算法[6]與絕對優先權演算法呈現相對極端是基於排程器 關注之焦點不同，PF 演算法[6]在 NRT 類型之封包傳輸率表現良好之原因是由 於此演算法比較用戶傳輸量，若是用戶之傳輸量高則就有機會列入排程，而 NRT 類型之封包特性為封包傳輸量大，因此若 eNodeB 內使用 PF 演算法，排 程器將會挑選 NRT 類型封包進行傳送，因此在 NRT 類型封包傳輸率呈現良好。

然而使用絕對優先權演算法在 RT 類型之封包傳輸率表現良好之原因是由於此 演算法中排程器只關注於 RT 類型服務之 QoS 而不考慮用戶傳輸量，因此在混 合網路中只要有 RT 類型用戶出現，NRT 類型用戶就必須等候直至 RT 類型用 戶釋出多餘資源，雖然絕對優先權演算法可保障 RT 類型服務之 QoS，然而卻 會在系統總傳輸量表現差強人意，其因 RT 類型封包特性為封包傳輸量小，造 成整體系統傳輸量不佳。

圖 4- 14、比較 NRT 類型封包傳送率於與 RT 類型封包傳輸率