LTE DRX原理介紹及優化思考

【摘要】 本文主要介紹DRX的概念，講解ACTIVE DRX和IDLE DRX這兩種DRX的工作原理，并結合實際案例剖析。在介紹ACTIVE DRX時，通過對相關定時器的分解介紹，以由簡單到復雜的例子組合闡述UE在啟用ACTIVE DRX時的工作狀態，最后通過一個ping時延分析案例進一步闡述其工作原理及對網絡性能的影響。在介紹IDLE DRX時，通過對相關公式的解讀，講解UE監聽尋呼幀和尋呼子幀的時機，并以不同IDLE DRX參數配置為例，對比不同配置下UE在IDLE DRX時的工作狀態。最后介紹了某項目的一個實際DRX參數配置以及某手機設備廠商公司建議的DRX 參數配置。

【關鍵詞】 DRX PF PO SR OnDurationTimer InactivityTimer DRX Cycle 休眠 激活

一、引言

LTE中的DRX（Discontinuous Reception）功能，即非連續接收，該功能可以讓UE在一定時刻保持醒著而在另外一定時刻處于休眠，從而節省UE電池消耗。

DRX分兩種，一種是IDLE DRX，顧名思義，也就是當UE處于IDLE狀態下的非連續性接收，由于處于IDLE狀態時，已經沒有RRC連接以及用戶的專有資源，因此這個主要是監聽呼叫信道與廣播信道，只要定義好固定的周期，就可以達到非連續接收的目的。

而另一種就是ACTIVE DRX，也就是UE處在RRCCONNECTED 狀態下的DRX， 其可以優化系統資源配置，更重要的是可以節約手機功率，而不需要通過讓手機進入到RRC_IDLE 模式來達到這個目的，例如一些非實時應用，像web瀏覽，即時通信等，總是存在一段時間，手機不需要不停的監聽下行數據以及相關處理，那么DRX就可以應用到這樣的情況。

二、ACTIVE DRX

2.1 Active DRX相關定時器

ACTIVE DRX是在RRC_CONNECTED狀態下的DRX，因此有的時候也寫成CDRX或者C-DRX。CDRX的工作主要跟幾個定時器有關：

On-Duration Timer

UE每次從DRX醒來后維持醒著的時間，UE在該段時間內會搜索PDCCH。On-Duration Timer是一個固定長度的周期性的定時器，它在每個DRX周期開始時刻啟動，在其超時后停止。

下圖是On-Duration Timer在只配置了Long DRX Cycle且UE沒有任何數據收發的情況下的工作示例：

Inactivity Timer

UE在醒著時每次成功解碼初始發送的PDCCH后保持active的時間。這里初始發送的意思就是，當UE收到的PDCCH指示的是一個UL/DL的初始傳輸，而不是重傳。

下圖是Inactivity Timer的一個工作示意圖，此例子中UE在DRX周期內實際醒著的時間因為Inactivity Timer 的啟動而變的比原來On-Duration Timer要長。

Inactivity Timer的設計思想是：當UE收到的PDCCH指示的是一個UL/DL的初始傳輸，意味這其后非常可能有更多的數據傳輸，因此讓UE在即使On-Duration Timer超時后仍能再保持醒著更長一些時長。Inactivity Timer一般會在OnDuration周期內被觸發，如果Inactive Timer設置得比OnDuration Timer小，它就有可能先于On-Duration Timer超時而失去其應有的意義，因此一般Inactivity Timer會設置得比On-Duration Timer長。

協議[1]規定當UE收到eNB發來的DRX Command MAC control element時，會停止Inactivity Timer，因此UE在DRX周期內實際醒著的時間也可能比On-Duration Timer短，如下圖所示：

HARQ RTT Timer/ DRX Retransmission Timer

HARQ RTT Timer：UE預期DL Retransmission到達的最少間隔時間，也就是說重傳最早會什么時候到，在此之前UE暫且不需要理會，也就是說這一段時間，該怎樣就怎樣，等到這個定時器超時了，那么它就要處于醒著的狀態。對于FDD來講，HARQ RTT Timer是8個子幀的數目。對于TDD來講，其大小為：從HARQ傳輸到對應的PHICH反饋時刻后推4個子幀之后的第一個下行子幀時刻。

DRX Retransmission Timer：UE預期接收DL Retransmission的時間，亦即需要這么多時間來接收下行重傳，此定時器一般和HARQ RTT Timer配合使用。協議TS36.321規定HARQ RTT Timer在每次收到下行傳輸或收到PDCCH指示的是下行傳輸（不一定是初始傳輸）時啟動，HARQ RTT Timer超時且下行數據解碼失敗（NACK）時啟動DRX Retransmission Timer；但在具體實現上，可能跟協議略有不同，HARQ RTT Timer可以僅在數據解碼失敗時啟動，HARQ RTT Timer超時后啟動Retransmission Timer，如圖所示：

DRX Cycle Length/ DRX Short Cycle Timer

DRX Cycle Length一旦配置/重配置就固定。在沒有任何數據發送/接收/重傳時，一個DRX周期長度包括OnDuration Timer時長和其后UE睡眠（inactive time）的所有時長。在DRX周期內，UE醒來的時長（active time）可能會因為有數據發送/接收/重傳而變得比On-Duration Timer長，也可能因為接收到DRX Command MAC control element而變短，但是DRX周期長度是不會因為active time大于或小于on duration而變化。

DRX cycle分為長周期和短周期兩種：即Long DRX Cycle和Short DRX Cycle。在同時配置了長短周期的情況下，UE使用的DRX周期會因為在DRX周期內是否有數據接收而轉換：如果在DRX Short Cycle Timer個短周期內，UE沒收到任何PDCCH，則 UE轉用Long DRX Cycle；如果UE收到PDCCH，則UE立刻使用Short DRX Cycle。

DRX Short Cycle Timer定義了連續若干個子幀內UE應使用Short DRX Cycle，單位是短周期。例如DRX Short Cycle Timer為2，則表示2*Short DRX Cycle個子幀。

下圖是一個相對復雜的示意圖：

1）解碼一個新傳PDCCH，啟動Inactivity Timer，UE醒著直到Inactivity Timer超時；

2）Inactivity Timer超時后，在短周期啟動條件滿足的子幀[注1]啟動短周期，同時啟動DRX Short Cycle Timer；

3）如果DRX Short Cycle Timer超時，如果沒收到PDCCH，啟動長周期；

[注1]：DRX運行的時機：

如果在使用短DRX周期，檢查當前子幀是否滿足下面的公式：

[（SFN * 10） + subframe number] modulo （shortDRXCycle） = （drxStartOffset） modulo （shortDRX-Cycle）

或者在使用長DRX周期，那么檢查如下的公式：

[（SFN * 10） + subframe number] modulo （longDRX-Cycle） = drxStartOffset

當上面的兩個條件滿足其中之一，那么就啟動定時器onDurationTimer，此時UE就要開始監聽PDCCH信道。

SR-pending （Timer）

指UE發送SR（Scheduling Request）請求UL-SCH資源后，UE應維持醒著并監聽PDCCH直到收到上行允許（UL grant）。根據eNB業務繁忙程度，UE得到調度的情況不同，因此SR-pending Timer 可能在eNB輕載的時候短至1ms，也可能在業務繁忙時高達好幾十毫秒。協議規定了SR-pending Timer最長不能超過dsrTransMax個TTI。UE可能在任何時刻發送數據，因此SR-pending Timer可能在DRX周期內任何時刻啟動。

CDRX小結

如果把UE醒著的狀態記為“1”，睡眠狀態記為“0”，那么UE的實際DRX狀態（醒著或者睡眠）可以看成是上述各個定時器作用下的一個“或”操作：

1）DRX的基礎是DRX周期內的On-Duration醒著時間和其后的休眠時間；其變化周期重復；

2）UE醒著的時間可能因為是否有數據接收（Inactivity Timer）/發送（Inactivity Timer SR Pending）/重傳（HARQ RTT TimerDRX Retransmission Timer）等而改變，UE實際狀態相當于在各個定時器作用下的“或”操作結果；

3）在啟用DRX短周期的情況下，UE使用的DRX周期會因在DRX周期內是否有數據接收而轉換。

協議歸納匯總的UE實際Active Time包括：

----onDurationTimer、drx-InactivityTimer、drxRetransmissionTimer 以及mac-ContentionResolutionTimer 運行的時間，或者

----有SR（調度請求）已近發送到PUCCH，并且處于SR pending（也就是這個調度請求還沒有滿足，如此之類的）或者，

----對一個掛起的HARQ重傳存在上行授權，并且在對應的HARQ 緩沖區里面有數據；或者

----在非競爭隨機接入后，成功收到隨機接入響應消息，此時應該有PDCCH發送給UE指示一個新的傳輸， 但是這個PDCCH還沒有收到，此時UE還是必須處于ACTIVE狀態。

2.2 Ping 時延案例分析

在某項目中，在DRX關閉的情況下，ping時延均值約為40ms，而打開DRX開關后，ping時延測試很差，從幾十毫秒到幾百毫秒不等。下面是對此現象的分析：

1）UE發送ping包，啟動Inactivity Timer；

2）如果ping響應包在時刻1到達，則UE仍處于激活態，UE 可以成功接收，ping時延<40ms；

3）如果ping響應包在時刻2/3到達，由于此時UE處于休眠態，eNB會調度到下一個DRX周期的UE On-Duration時刻發送，時延>=80ms；

4）同理，如果ping響應包在時刻5/6/7到達，則ping時延>160ms；

三、IDLE DRX

3.1 IDLE DRX原理

Idle DRX是指當UE處于IDLE狀態下的非連續性接收，跟尋呼有關。協議[2]定義了UE可以在空閑狀態下使用DRX監聽尋呼從而達到省電的目的。UE使用P-RNTI周期監聽PDCCH來了解PDSCH上是否有尋呼。如果有， 則解碼PDSCH上承載的PCH的尋呼消息，從解碼后的尋呼消息中查看是否有針對該UE的尋呼記錄。在Idle DRX下，UE只需要監聽屬于它的PO/PF。關于PF和PO，定義詳見協議[2。

UE需要監聽的PF由下式決定：

SFN mod T= （T div N）*（UE_ID mod N）

式中T為尋呼周期，T = min（Tc， Tue），Tc為RRC協議[3]規定的值，在SIB2中廣播，取值可為32、64、128、256，單位為無線幀；Tue為UE指定值，該值由UE在attach過程中的附著請求消息中攜帶，屬于NAS消息，傳輸給核心網MME，基站透傳，并不知道其內容，因此MME再發送給eNB來通知UE的特定DRX大小[4][5]。基站根據T = min（Tc， Tue）來確定T的大小。同樣，UE通過SIB2得到RRC配置的default pagingcycle后（即Tc），與自己請求的UE specific DRX 取小作為尋呼監聽的周期。

N=min（T， nB）。N可以理解為每個尋呼周期T內的尋呼幀PF個數。一個尋呼周期內的尋呼幀和尋呼子幀數量由nB決定，nB在SIB2中廣播，取值可為4T、2T、T、T/2、T/4、T/8、T/16、T/32，單位是無線幀。

UE_ID=（IMSI的后十位）mod1024。

UE需要監聽的PO位置由i_s決定：

i_s=floor（UE_ID/N） MOD Ns

式中Ns=max（1，nB/T）。Ns可以理解為每個尋呼幀PF內尋呼子幀PO個數。由nB的取值可知Ns的取值只能是1、2或者4。

i_s和具體UE監聽的子幀PO位置映射關系如下：

3.2 IDLE DRX參數舉例

由上述分析可以看出，UE需要監聽的時刻主要由T和nB這兩個參數決定，舉例如下：

假設尋呼周期T=128rf，如果nB取值設置為T/2則：

每個尋呼周期T內的尋呼幀個數N=min（T， nB）=T/2=64rf，表示一個長為128個無線幀的尋呼周期內，均勻分布64個尋呼幀。

每個尋呼幀內的尋呼子幀個數Ns=max（1， nB/T）=1，表示每個尋呼幀內存在一個尋呼子幀。尋呼子幀的序號由i_s通過i_s與PO之間固定的映射關系得到。

同理，當nB取值為T時，則每個尋呼周期內有T個尋呼幀，每個尋呼幀內有1個尋呼子幀；當nB取值為2T時，則每個尋呼周期內有T個尋呼幀，每個尋呼幀內有2個尋呼子幀；當nB取值為4T時，則每個尋呼周期內有T個尋呼幀，每個尋呼幀內有4個尋呼子幀。

四、結束語

筆者寫本文是因為在某項目上客戶正要測試DRX相關參數，因此有必要對DRX的工作原理及可能影響進行深入了解。本文主要介紹DRX的概念以及ACTIVE DRX和IDLE DRX的工作原理，結合Ping時延講解了CDRX的工作時機，最后講解了Idle DRX的相關尋呼時機。

參 考 文 獻

[1] 3GPP，36.321 Medium Access Control （MAC） protocol specification（Release 8）

[2] 3GPP，36.304 User Equipment （UE） procedures in idle mode （Release 8）

[3] 3GPP，TS 36.331 Radio Resource Control （RRC）； Protocol specification （Release 8）

[4] 3GPP，TS23.401 General Packet Radio Service （GPRS） enhancements for Evolved Universal Terrestrial Radio Access Network （E-UTRAN） access （Release 8）

[5] 3GPP，TS36.413 S1 Application Protocol （S1AP） （Release 8）