研究作法之動機

LTE-A 下行鏈路資源分配演算法實現於基地台 eNodeB 中之排程器(scheduler)，

但[12]出版書中指出，現行 LTE-A 系統規格尚未針對下行鏈路之資源分配演算法 有明確之定義，因此目前 eNodeB 中資源分配演算法可讓營運商自行決定。下行 鏈路資源分配示意圖如圖 3-1 所示，混合網路中之各類型服務之封包陸續抵達 eNodeB，其次 eNodeB 中分級器(classifier)會根據各類型服務之特性，將封包依序 分類且存放於 eNodeB 中之佇列(queue)中，其次排程器根據內部選定之資源分配 演算法，依據演算法則將各用戶封包先後排序傳送。

本論文探討之重點在於混合網路中各類型服務封包都有各自相對應之特性，

在現行之資源分配演算法中，若排程器過分關注 RT 類型服務之 QoS，進而在排 程中給予 RT 用戶享有絕對優先權，特別是 RT 服務中之 Conversational 類型用戶 享有優先權為最高，雖然此種絕對優先排程機制(Absolute QoS Scheduling)在 RT 類型服務之 QoS 呈現良好，如有較低的 RT 類型封包遺失率(RT service drop rate)、

RT 類型封包延遲時間(RT service packet delay)以及較高的 RT 類型封包傳輸率(RT service transmission rate)等；然而卻會在整體系統之傳輸量表現不佳，其因 RT Conversational 類型之封包傳輸量遠低於 NRT 類型服務封包，造就整體系統傳輸 量低。反之若資源分配演算法只注重整體系統傳輸量，則 NRT 類型服務在此法 則中獲得傳送優先權會高於 RT 類型服務，其因 NRT 類型封包特性─NRT 封包 傳輸量會高於 RT 類型用戶，雖然使用此資源分配演算法在整體系統傳輸量呈現 優異，如有較高的系統傳輸率，然而卻會在 RT 類型之 QoS 表現不盡理想。

在混合網路中為得到最佳的系統效益，排程器之資源分配演算法應綜合考量

Packets from Different Evolved Node B

(eNodeB)

‧ ‧ ‧

圖 3- 1、下行鏈路排程演算法於混合網路示意圖

3.1.1 研究動機之起源

根據 3GPP Standard 23.107[21]中指出─RT 服務與 NRT 服務需維持 ITU-T 建 議之 G.114 規範 [8]。RT-Conversational 類型服務對時間延遲要求嚴格，須符合 單位時間內，傳輸資料量固定，即為固定傳輸資料量之要求，因此排程器需滿足 固定位元速率(constant bit rate, CBR)之要求，在 ITU-T G.711 應用[19][20]要求之 固定頻寬為 64 kbps Pules Code Modulation (PCM)。RT-Streaming 類型服務之頻寬 要求為變動位元速率(variable bit rate, VBR)，即串流之傳輸率會跟隨時間變動，

根據 3GPP TS 23.107[21]、3GPP TS 22.105[22]以及 ITU H.264 技術[24]之標準，

若串流類型使用即時視訊(real time video streaming)、Movie clips 等應用服務，其 服務變動位元速率為 64kbps~384kbps[7][27]。

在本論文中假定當 RT 類型用戶之封包延遲尚未到達預設門檻值，即該用戶 為非緊急狀態 (Non-urgent)，RT 類型用戶之延遲時間容忍度高，可以暫留在佇列 裡等候傳送，尚且不會衍生該封包在佇列等候過久而被丟棄之問題，此時排程器 可將系統內有限之資源分配給可提升系統傳輸量之 NRT-Interactive 用戶與

RT-Streaming 類型用戶，將非緊急狀態之 RT-Streaming 類型列入提升系統傳輸量 之原因是植基於 RT-Streaming 類型服務之傳輸量有時可比擬 NRT-Interactive 類型 服務，參考文獻[7][27]中假定 RT-Streaming 類型之用戶傳輸率為 64~384kbps，而 ITU-T H.264 規格書[24]指出 H.264 後續發展技術傳輸率甚至可達到更高，串流類 型封包之時間延遲限制比較於語音封包也較為彈性；至於 NRT-Interactive 類型之 用戶在文獻[11]中使用網頁瀏覽服務(Web browsing)，傳輸率為 144 kbps~2048 kbps，亦或是文獻[26]使用 FTP(File Transfer Protocol)下載，傳輸率為

512kbps~2048kbps。本論文在保證 RT 類型用戶之 QoS 此條件下，為服務對時間 延遲要求彈性之 NRT 類型用戶並考量提升系統總傳輸量，將 NRT-Interactive 類 型用戶與 RT-Streaming 類型用戶在系統內尚未有緊急狀態之 RT 用戶時，將 NRT-Interactive 類型用戶與 RT 串流類型用戶比較優先排程參數其根據比例型公 平演算法。

然而隨著 RT 類型封包已在佇列中等候傳送經過一段時間，封包延遲時間逐 漸增加，進而導致封包之緊急程度漸進上升，可容忍延遲時間逐漸減少，即該封 包處於緊急狀態(urgent)時，此時系統應將盡力而為服務 RT 緊急狀態之用戶，以 避免 RT 用戶之系統滿意度降低、RT 封包遺失率升高、RT 封包傳輸率下降等負 面影響。