1.爲什麼要使用DRX
在講解DRX的概念前，我們需要先了解下什麼是“空閒態”，什麼是“連接態”。
我們經常會聽到“空閒態”、“連接態”這樣的術語，這個概念是從RRC層角度來說的。簡單來說，當UE在某個小區完成了駐留之後，我們就可以稱該UE進入了“空閒態”或“IDLE態”。如果該UE後續又完成了隨機接入過程，那麼我們就可以稱該UE進入了“連接態”或“CONNECTED態”。
無論是空閒態，還是連接態，如果沒有我們本文提到的DRX機制，UE就會一直監聽下行PDCCH子幀，查看是否有來自服務小區的信息。這樣做看起來沒有問題，然而現實很多時候，UE並不是一直在和網絡進行有效信息的交互，不會總是執行上傳或者下載業務，通話時也不會一直有語音數據的傳輸。大多數的時間，UE和網絡是沒有數據交互的，如果這個時候UE還去持續的監聽PDCCH子幀，顯然是很費電的。因而，在保證數據能有效傳輸的前提下，有必要設計一種節省UE電量的機制，這個機制我們就叫做DRX。
2.什麼是DRX
DRX，英文全稱爲Discontinuous Reception，即不連續接收，這種方法可以讓UE週期性的在某些時候進入睡眠狀態（sleep mode），不去監聽PDCCH子幀，而需要監聽的時候，則從睡眠狀態中喚醒（wake up），這樣就可以使UE達到省電的目的。雖然這樣做對數據傳輸的時延有一定的影響，但如果這種時延並不影響用戶體驗，那麼考慮到UE更爲重要的功率消耗，執行DRX是很有意義的。
DRX機制在空閒態和連接態下的實現是不同的，相對而言，連接態下的DRX機制要複雜的多。本篇博文專門介紹連接態下的DRX機制（Connected DRX，CDRX），而空閒態下的DRX機制即尋呼機制，將在下一篇博文中介紹。下文描述的DRX均特指UE處於連接態時使用的DRX。
一個典型的DRX週期如圖1所示。在這個圖中，標識“On Duration”的這段時間是UE監控下行PDCCH子幀的時間，在這段時間裏，UE是處於喚醒狀態的。標識“Opportunity for DRX”的這段時間是DRX睡眠時間，即UE爲了省電，進入了睡眠而不監控PDCCH子幀的時間。從這個圖中可以看到，用於DRX睡眠的時間越長，UE的功率消耗就越低，但相應的，業務傳輸的時延也會跟着增加。
（圖1）
3.爲什麼要使用drx-InactivityTimer
我們來考慮這樣的一個場景：0號子幀是喚醒時間On_Duration的最後一個子幀，此時網側剛好有一個較大字節的數據需要發給UE，這些數據無法在0號子幀全部發送完。如果按照上文圖1的DRX週期，那麼UE將在1號子幀進入DRX睡眠狀態，不會再去接收來自網側的任何下行PDSCH數據。網側也只能等到DRX週期結束，並在下一個On_Duration時刻到來時，繼續向UE發送沒有傳完的數據。這種處理機制雖然沒有錯，但顯然增加了整個業務的處理時延。爲了避免這種情況的出現，DRX機制中增加了drx-Inactivity定時器，如圖2所示。
（圖2）
如果drx-inactivityTimer正在運行，那麼即便原本配置的On_Duration時間已經結束，UE仍然需要繼續監聽下行PDCCH子幀，直到DRX InactivityTimer超時。增加了DRX-InactivityTimer機制之後，顯然會減少數據的處理時延，但這將會引入下文描述的另一個問題。
4.增加DRX command控制單元的意義
上文圖2描述了DRX-InactivityTimer的作用是爲了降低數據的處理時延，但如果DRX-InactivityTimer的時長設置的過長，當網側的數據發送完之後定時器還沒有超時，則UE還不得不繼續監聽下行子幀，無法及時的進入睡眠狀態。爲了儘量快速的讓UE進入睡眠狀態，系統引入了一個與DRX相關的MAC控制單元DRX command，有時候也被形象的叫做Go-To-Sleep CE。
當網側檢測到已經沒有上下行數據可傳時，可以向該UE發送一個MAC PDU，這個PDU裏攜帶一個DRX command控制單元。當UE收到這個DRX控制單元之後，將停止OnDurationTimer和drx-InactivityTimer，儘快的進入DRX，如圖3所示。
（圖3）
每個MAC控制單元都對應着一個子頭，並且一般來說，控制單元都佔用特定長度的字節數，比如短BSR控制單元佔用了1個字節，加上1個字節的子頭，共佔用2個字節；再比如長BSR控制單元佔用了3個字節，加上1個字節的子頭，共佔用4個字節。但DRX Command控制單元比較特殊，它所佔用的字節數是0，即只需要發送1個字節的子頭即可，不需要爲控制單元預留空間。這個子頭裏的LCID需要設置爲0x1E，如圖4所示。
（圖4）
5.長週期和短週期
前文圖1已經提到，一個DRX週期等於UE喚醒時間（ON-duration）和睡眠時間的總和。在LTE裏，系統可以根據不同的業務場景，給UE分別配置短週期（short DRX cycle）或者長週期（long DRX cycle）。比如在進行VOIP業務時，語音編解碼器通常20ms發送一個VOIP包，那麼就可以配置長度爲20ms的DRX短週期，而在語音通話期間較長的靜默期，就可以配置DRX長週期。如果同時配置了短週期和長週期，且drxShortCycleTimer定時器超時，那麼UE將進入一次長DRX週期，如下圖5所示。圖中，drx-InactivityTimer定時器超時後開啓drxShortCycleTimer定時器。
（圖5）
在圖5中，我們還可以發現有個drxStartOffset參數，這個參數的含義是DRX週期是從哪個子幀開始的，比如週期是10個子幀，那麼drxStartOffset的範圍就是0～9；而如果週期是20個子幀，那麼drxStartOffset的範圍就是0～19，有點類似測量GAP裏的gapOffset。
6.參數配置
前面已經介紹了與DRX相關的很多參數，包括on_duration時長、drx-InactivityTimer、長短週期、drxShortCycleTimer、drxStartOffset等等，可能有些同學已經迫不及待的想知道怎麼獲取這些參數以及這些參數的範圍是怎麼樣的了，下面就說說這個。
同樣的，這些參數仍然由RRC配置，具體在消息 RRCConnectionSetup 或 RRCConnectionReconfiguration 或 RRCConnectionReestablishment 的
RadioResourceConfigDedicated 信元的 MAC-MainConfig 中，如圖6所示。
（圖6）
onDurationTimer：該參數表示在一個DRX週期裏，UE睡醒後的在線時長。以PDCCH子幀個數爲基本單位，比如psf6表示UE在線監測的時長爲6個PDCCH子幀。當UE滿足DRX週期條件時，就會進入onDurationTimer，比如下文圖7中的時間（0，5）,（0，6）等短週期PDCCH子幀，以及（2，0），（2，1）等長週期PDCCH子幀。
drx-InactivityTimer：該參數表示當UE成功解碼到一個下行PDCCH之後，還需要繼續監測多少個PDCCH子幀。同樣以PDCCH子幀個數爲基本單位，比如psf80表示UE還需要繼續監測80個下行PDCCH子幀才能進入睡眠態。當PDCCH子幀中顯示有新的上行或下行傳輸時啓動該定時器，當收到Go-To-Sleep CE時停止該定時器。
drx-RetransmissionTimer：這個參數用在下行重傳的場景。由於下行HARQ採用的是異步重傳，因此UE並不確定eNB什麼時候會下發重傳數據，但UE也不可能無限制的等待下去，畢竟UE還需要省電，還需要進入睡眠狀態，所以這個重傳定時器是表示UE爲了接收期望的下行重傳數據，需要連續監測的最大PDCCH子幀個數。同樣以PDCCH子幀個數爲基本單位，比如psf8表示UE爲了接收下行重傳數據，還需要繼續等待最多8個下行PDCCH子幀。當HARQ RTT定時器超時且下行HARQ緩存裏還有數據沒有被解碼成功時啓動該重傳定時器，當收到PDCCH子幀顯示該進程有數據傳輸或當前屬於DL-SPS子幀時，停止該定時器。HARQ RTT定時器一旦超時就意味着UE可以開始接收eNB側的重傳數據了，若RTT定時器還沒有超時，eNB也不會下發重傳數據。
longDRX-CycleStartOffset：這個參數可以同時表示 longDRX-Cycle 和 drxStartOffset 這兩層含義，以子幀爲單位。比如長週期選擇sf1280，偏移選擇0。但需要注意的是，如果網側同時也配置了短週期（ShortDrx-Cycle）參數，那麼長週期必須配置成短週期的整數倍。比如短週期配置的是sf64（64個子幀），那麼長週期就不能配置sf80，因爲80不能整除64。
shortDRX-Cycle：這個參數表示DRX採用的短週期時長，以子幀爲單位，sf5表示短週期時長（含on-duration時間）爲5個子幀。
drxShortCycleTimer：這個參數表示在短週期內持續多少個子幀沒有收到PDCCH就進入長週期。如果值爲2，則表示持續（2×shortDRX-Cycle）個子幀沒有成功解碼到PDCCH就進入長週期。
也就是說：與定時器相關的參數都是以PDCCH子幀爲單位的，而與週期相關的都是以子幀爲單位的。
一個典型的長短週期DRX流程如圖7所示。具體流程爲：UE在時刻（0，0）成功解碼到一個PDCCH子幀，因此開啓了drx-inactivityTimer（3個子幀的長度）；當drx-inactivityTimer超時後開啓drxShortCycleTimer（注意，圖中應該是在4號子幀開啓，而不是5號子幀開啓drxShortCycleTimer）；到了時刻（0，5），滿足了進入短週期的時間條件（後文會介紹這個條件，這裏記爲條件1），UE被喚醒進入on-duration（持續2個子幀）；在時刻（1，0）和（1，5）多次進入短週期；到了（1，9）時刻，(drxShortCycleTimer×shortDrxCycle)=15個子幀內沒有成功解碼到PDCCH子幀，準備進入長DRX週期，在（2，0）滿足長週期進入條件（這裏先記爲條件2，後文再介紹這個條件），UE進入長DRX週期，時刻（2，9）結束長週期；UE在（3，0）收到PDCCH子幀，因此重新啓動了drx-inactivity定時器。
（圖7）
再具體說說進入長短DRX週期的判斷條件。對於進入短週期的條件1，幀號SFN和子幀號subframeNumber需要滿足：
[(SFN *10) + subframeNumber] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle) （條件1）
對照圖7的例子，shortDrx-Cycle=5，drxStartOffset=0，因此時刻（0，5）、（1，0）、（1，5）都是滿足條件1的。對於進入長週期的條件2，幀號SFN和子幀號subframeNumber需要滿足：
[(SFN * 10) + subframeNumber] modulo (longDRX-Cycle) = drxStartOffset （條件2）
對照圖7的例子，longDrx-Cycle=10，drxStartOffset=0，因此時刻（1，0）、（2，0）、（3，0）都是滿足條件2的。我們可以看到，時刻（1，0）同時滿足了短週期和長週期的條件，但爲什麼此時需要執行短週期DRX呢？下文會對這個地方做出解釋。
7.HARQ RTT Timer
在DRX機制中，還需要用到一個名爲“HARQ RTT Timer”的定時器，這個定時器或者說這個參數，也是與下行重傳相關的。它的含義是，UE在收到期望的下行重傳數據之前，需要等待的最少子幀個數。當收到PDCCH子幀顯示有下行傳輸或處於DL-SPS子幀時開啓該RTT定時器，同時也將drx-RetransmissionTimer停掉，而當HARQ RTT Timer超時時會開啓drx-RetransmissionTimer。
對於FDD-LTE來說，HARQ RTT Timer的值固定等於8個子幀。對於TDD-LTE來說，HARQ RTT Timer的值等於（k+4）個子幀，k表示下行PDSCH傳輸與其應答ACK的時延，具體值如下圖8所示。比如當前是上下行子幀配置1，PDSCH是在9號子幀下發的，那麼eNB將在3號子幀接收應答，所以k=4。
（圖8）
8.DRX處理流程
前文已經提到，當UE處於on-duration時期，或者drx-InactivityTimer正在運行，或者drx-RetransmissionTimer正在運行，那麼UE都需要持續的監測下行PDCCH信道（即UE處於激活時間）。除了這些情況之外，當以下條件之一發生時，UE也需要持續的監測PDCCH信道：
（1）衝突解決定時器mac-ContentionResolutionTimer正在運行。
（2）有準備在PUCCH上發送的SR。
（3）上行HARQ重傳的授權已經存在，且對應的HARQ緩存裏有數據。
（4）非競爭隨機接入過程成功收到RAR響應之後，還沒有收到以CRNTI加擾的、指示有新數據的PDCCH。關於非競爭接入過程請參考《LTE-TDD隨機接入過程（1）-目的和分類》。
DRX的處理流程需要考慮的場景比較多，如果用文字描述的話不太清晰，這裏我用流程圖的形式展示給大家，如下面的圖9所示（因爲截圖的原因，所以儘量壓縮了空間排版）。
（圖9）
上面圖9中提到的半雙工FDD的概念，是2008年愛立信在深圳的一次3GPP會議中提出來的，初衷是允許UE在3.5GHz和小於860MHz的Band中，可以進入FDD半雙工的模式。但截至目前，還沒有聽說哪家手機芯片廠商支持LTE半雙工FDD的情況。
如果eNB配置了DRX功能，除了影響UE側檢測下行PDCCH子幀，還會影響UE側SRS/CQI/PMI/RI的發送，具體爲：
（1）UE在非激活時間內，不發送SRS。
（2）如果上層配置了cqi-Mask，那麼onDuration定時器不在執行時，UE不應該在PUCCH中發送CQI/PMI/RI；如果沒有配置cqi-Mask，那麼當UE在非激活時間內，不應在PUCCH中發送CQI/PMI/RI。從這點可以看出，如果當前是LTE-TDD制式，RRC在配置參數的時候，應該確保onDuration或激活時間內，至少有1個上行子幀用於發送SRS/CQI/PMI/RI參數。
cqi-Mask參數是限制UE是否僅在onDuration時間內發送CQI/PMI/RI的，由RRC消息配置，具體在 RRCConnectionReconfiguration 或 RRCConnectionReestablishment 或 RRCConnectionSetup 消息的 RadioResourceConfigDedicated -> PhysicalConfigDedicated -> CQI-ReportConfig 字段中。
除此之外，考慮到UE側的處理時延，如果UE在激活時間的最後4個子幀內檢測到一個標識上行或下行新傳的PDCCH子幀，那麼在接下來的4個子幀內，UE是可以不用在PUCCH中發送CQI/PMI/RI或傳輸SRS的；而如果UE是因爲收到了Go-To-Sleep控制單元而退出激活時間，那麼UE也是可以選擇在接下來的4個子幀裏繼續在PUCCH中發送CQI/PMI/RI或傳輸SRS的。
需要留意的是，無論UE是否在監聽PDCCH子幀，都不影響UE發送或接收HARQ反饋。
參考文獻：
（1）3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification
（2）3GPP TS 36.300 V9.10.0 (2012-12) Overall description
（3）3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)
（4）http://www.sharetechnote.com
（5）<<4G LTE/LTE-Advanced for Mobile Broadband>>
（6）http://people.cs.nctu.edu.tw/~yctseng/papers.pub/mobile93-drx-ieee-jetcas.pdf
————————————————
版權聲明：本文爲CSDN博主「阿米爾C」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/m_052148/article/details/52439789