第二章 . 系統模型
2.4. 非連續接收機制
在長程演進技術中，使用者裝置可以在RRC_CONNECTED的狀態啟動下行鏈路非 連續接收模式[11]，並且會在清醒和睡眠模式之間做切換(如圖 5)(高起的部份為清醒時 間)。使用者裝置清醒時會監聽實體下傳控制通道，判斷是否有資料需要接收；睡眠模 式時，使用者裝置會關閉射頻電路，停止接收封包以達到節省電力之效果。演進型基地 台可以針對每一個使用者裝置配置一組非連續接收模式的參數，以下為非連續接收模式 各參數的說明[12]：
清醒區間定時器(On-duration Timer， )說明使用者裝置在每一個非連續接收 週期開始時，需要保持連續清醒的子訊框個數，以讀取實體下傳控制通道的訊息。可設 定的長度為1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200個子訊框。
非活動定時器(Inactivity Timer， )說明使用者裝置需要繼續保持連續清醒的子 訊框個數。每當使用者裝置收到實體下傳控制通道通知有資料需要接收後，非活動定時 器將會被重置。可設定的長度為1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, …個子訊框。
短非連續接收週期(Short DRX Cycle， )為每一個短非連續接收週期的長度。
短非連續接收週期為選擇性使用。可設定的長度為 和 個子 訊框。
短非連續接收週期定時器(Short DRX Cycle Timer， )為使用者裝置連續進入 個短非連續接收週期後則進入長非連續接收週期。每當使用者裝置收到實體下傳控制 通道通知有資料需要接收後，短非連續接收週期定時器將會被重置。
長非連續接收週期(Long DRX Cycle， )為每一個長非連續接收週期的長度。
當 後才會進入長非連續接收週期。可設定的長度為 和 個子訊框。
15
非連續接收偏移值(DRX Offset， )用來獲得非連續接收週期的開始子訊 框位置。當( ) 時便是非連續接收週期的第一個子訊框，其中 為訊框編號； 為子訊框編號； 則等於 或 。
圖 5. 長程演進技術非連續接收模式運作架構
使用者裝置每次進入非連續接收週期便會連續地監聽 個子訊框的實體下傳控制 通道，一旦接收到傳輸資料的通知便會延長 個子訊框的清醒時間，繼續接收在佇列中 的封包。反之，若使用者裝置在清醒時間結束前( 和 )都未收到實體下傳控 制通道的通知便會進入睡眠模式，直到下一個非連續接收週期才會回到清醒模式繼續監 聽實體下傳控制通道。為了要簡化非連續接收模式的複雜度，我們只採用一種非連續接 收週期，長度設定為小於即時性訊務的延遲限制。這樣設置的方式將不會有封包在一個 非連續接收週期中到來，但卻在下一個非連續接收週期開始前就被丟棄。
16
第三章.
在非連續接收模式中做資源分配
3.1. 問題描述
當使用者裝置啟用了非連續接收模式後，其狀態便會在清醒模式和睡眠模式之間做 切換，一旦進入睡眠便會暫時關閉其射頻電路，暫停接收來自演進型基地台的訊息，必 頇要等到下一個非連續接收週期啟動清醒區間定時器，使用者裝置才會再次接收實體下 傳控制通道的訊息。若使用者裝置在清醒模式監聽到實體下傳控制通道通知有資料需要 接收，非活動定時器將會被重置以延長使用者裝置的清醒時間。非活動定時器的原本目 的是希望使用者裝置繼續保持清醒以消化在佇列中等待傳送的資料。倘若使用者裝置因 非活動定時器重置而延長清醒時間，但是佇列中並沒有資料在等待傳送；或是佇列中有 資料，但使用者裝置進入睡眠模式到下一個非連續接收週期前也不會違反其服務品質需 求。此時這段被延長的清醒時間不但對提升系統吞吐量沒有幫助，更傷害非連續接收模 式的省電效率。因此非活動定時器的啟動時機顯得格外重要，必頇確保其啟動的目的才 能發揮好的效果。
在長程演進技術中，傳統的封包排程器會在每個子訊框開始時執行資源分配演算法，
並且根據該資源分配的方針(分配公平性、保證延遲限制、保證封包遺失率…等等)在傳 送時間間隔內盡可能地滿足使用者裝置的需求。但很不幸地，非連續接收模式的特性使 得使用者裝置不再是永遠保持清醒的狀態。若分配資源只保證使用者裝置在傳送時間間 隔內滿足其需求，一旦它進入睡眠後無法參與資源分配時就有可能違反其需求。因此在 非連續接收模式中分配資源只有保證使用者裝置在當前的子訊框內滿足其需求是不夠 的，必頇將使用者裝置進入睡眠模式後的狀態一起納入考慮。下一節我們將針對非連續
17
接收模式提出兩種感知型的資源分配演算法。
3.2. 感知型非連續接收模式之資源分配
我們於先前一章中提到方法[1]針對即時性訊務會根據其延遲限制和資料遺失率計 算在當前的子訊框中滿足遺失率容忍度的最小所需頻寬(如圖 6)。方法[1]中計算滿足遺 失率容忍度的最小所需頻寬時採用的是緊急策略(urgent policy)模式，因此只有考慮在當 前子訊框結束時會遺失的資料量 , -。為了要因應使用者裝置在非連續接收模式中，有 可能在進入睡眠狀態後違反服務品質需求，我們在計算最小所需頻寬時將策略改為預留 服務品質策略模式，保證使用者裝置在未來 個子訊框中的服務品質，因此計算最小所 需頻寬時考慮資料遺失量將為∑ , -。首先定義 , -為使用者 在 子訊框結束時 考慮∑ , -的當前遺失率
, - , - , - , - (∑, - .∑ , - , -, -/ , -)， , - , - ( 3 )
接著根據遺失率容忍度，令 , - 即可算出預留未來 個子訊框中都能滿足遺失率容 忍度的最小所需頻寬。
圖 6. 方法[1]資源分配架構圖
18
在非連續接收模式中，若 >0或是 0使用者裝置便會保持清醒狀態監聽實體下 傳控制通道，一旦接收到通知有資料需要接收，非活動定時器將會被重置以延長使用者 的清醒時間繼續保持傳輸。若使用者裝置尚未到達最後一個清醒的子訊框時，我們不採 用服務品質預留策略，其原因有兩點：(1)使用者裝置還有剩餘的清醒時間去滿足對服務 品質的需求；(2)過早預留資源將減少其他的使用者裝置可以得到的資源。而當使用者裝 置到達最後一個清醒的子訊框時，我們才以預留服務品質的模式來判斷使用者裝置是否 會因為進入睡眠模式而違反服務品質需求。在接下來的小節中，我們將提出兩種感知型 非連續接收資源分配演算法。另外針對使用者 定義 為該使用者裝置距離到達 下一個非連續接收週期的子訊框個數。
3.2.1. 演算法一
假設有一個使用者裝置連結即時性訊務，而且非連續接收模式沒有啟用非活動定時 器，這樣此使用者裝置只會在每個非連續接收週期中的清醒區間監聽實體下傳控制通道，
其餘時間都將進入睡眠模式。基於此概念，最直覺的方式便是使用者裝置在清醒模式時 要盡可能地被服務，防止使用者裝置進入睡眠模式後違反其服務品質需求。因此演算法 一是透過預留資源的方式，讓使用者裝置在睡眠模式前能盡量獲得足夠多的資源，就能 降低在睡眠模式中違反服務品質的機會。當使用者 在非連續接收模式中到達最後 一個清醒的子訊框，封包排程器便計算 , -，接著令 , - 計算出 , -。這裡計 算出的 , -的意義將是使用者 在到達下一個非連續接收週期前皆不會違反其遺失率 容忍度的最小所需頻寬。若 , - 則表示使用者裝置 對頻寬有需求，如果沒有得到 任何頻寬而進入睡眠模式的話，使用者裝置將會在下一次回到清醒模式前違反其遺失率 容忍度。
19
Algorithm 1 DRX-aware Resource Allocation at the beginning of subframe Input: {* + * , -+ }
* , -+
Output: * , -+
Variables:
: The set of RTs which the minimum requested bandwidth is bigger than zero.
, -: The bandwidth allocated to user n at subframe.
20
if ( , - ) then
end if
end while
3.2.2. 演算法二
前一節演算法的主要構想是預留資源給即將進入睡眠模式的使用者裝置，雖然這樣 是較直覺地防止在睡眠模式中違反服務品質的方式，但是並沒有運用到非活動定時器的 特點，就是延長使用者裝置的清醒時間以繼續接收在佇列中等待的資料。若使用者裝置 是在進入睡眠模式後才會違反服務品質需求，只要能夠啟動其非活動定時器延長清醒時 間就能繼續參與資源分配。因此我們提出演算法二，運用非活動定時器防止那些會在睡 眠模式中違反服務品質需求的使用者裝置保持清醒狀態。首先，一樣在使用者 到 達最後一個清醒的子訊框時判斷是否會在睡眠模式違反遺失率容忍度。但與演算法一不 同的是這裡我們的判斷將分成三種結果
1) 令 , - 計算出 , -大於零：這意謂使用者 在此子訊框有最小頻寬需求，
若被分配到資源就會啟動非活動定時器，因此最小所需頻寬維持此計算結果。
2) 令 , - 計算出 , -等於零，但是令 , - 計算出 , -大於零：這表 示使用者 在此子訊框中雖然沒有最小頻寬需求，但若進入睡眠模式將會違反遺失率容 忍度。因此我們不需要過早預留資源，只要令 , - 使得使用者裝置至少有一個資源 區塊的需求。若使用者裝置有得到資源而啟動非活動定時器就能繼續保持清醒，防止進 入睡眠模式違反其遺失率容忍度。
3) 令 , - 計算出 , -和令 , - 計算出 , -皆等於零：這表示使用者 在到達下一個非連需傳輸週期前的子訊框中，沒有任何頻寬需求也不會違反其遺失率 容忍度。因此最小所需頻寬設成零，將資源保留給其他使用者裝置。
21
22
Algorithm 2 DRX-aware Resource Allocation at the beginning of subframe Input: {* + * , -+ }
* , -+
Output: * , -+
Variables:
: The set of RTs which the minimum requested bandwidth is bigger than zero.
, -: The bandwidth allocated to user n at subframe.
23
, - { , - , -}
, - , -
if ( , - ) then
end if
end while
24
第四章.
模擬
4.1. 模擬環境
本章節中，我們將使用LTE-Sim模擬器[13]執行演進型技術系統層級的模擬。LTE-Sim 是一個開放源碼基於C++的模擬器，其設計的理念是希望能完整實現演進型技術協定層，
本章節中，我們將使用LTE-Sim模擬器[13]執行演進型技術系統層級的模擬。LTE-Sim 是一個開放源碼基於C++的模擬器，其設計的理念是希望能完整實現演進型技術協定層，