1.為什麽要使用DRX
在講解DRX的概念前，我們需要先了解下什麽是“空閑態”，什麽是“連接態”。
我們經常會聽到“空閑態”、“連接態”這樣的術語，這個概念是從RRC層角度來說的。簡單來說，當UE在某個小區完成了駐留之後，我們就可以稱該UE進入了“空閑態”或“IDLE態”。如果該UE後續又完成了隨機接入過程，那麽我們就可以稱該UE進入了“連接態”或“CONNECTED態”。
無論是空閑態，還是連接態，如果沒有我們本文提到的DRX機制，UE就會一直監聽下行PDCCH子幀，查看是否有來自服務小區的信息。這樣做看起來沒有問題，然而現實很多時候，UE並不是一直在和網絡進行有效信息的交互，不會總是執行上傳或者下載業務，通話時也不會一直有語音數據的傳輸。大多數的時間，UE和網絡是沒有數據交互的，如果這個時候UE還去持續的監聽PDCCH子幀，顯然是很費電的。因而，在保證數據能有效傳輸的前提下，有必要設計一種節省UE電量的機制，這個機制我們就叫做DRX。
2.什麽是DRX
DRX，英文全稱為Discontinuous Reception
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-inactivity定時器正在運行，那麽即便原本配置的On_Duration時間已經結束，UE仍然需要繼續監聽下行PDCCH子幀，直到DRX Inactivity定時器超時。增加了DRX-Inactivity機制之後，顯然會減少數據的處理時延，但這將會引入下文描述的另一個問題。
4.增加DRX command控制單元的意義
上文圖2描述了DRX-Inactivity定時器的作用是為了降低數據的處理時延，但如果DRX-Inactivity定時器的時長設置的過長，當網側的數據發送完之後定時器還沒有超時，則UE還不得不繼續監聽下行子幀，無法及時的進入睡眠狀態。為了盡量快速的讓UE進入睡眠狀態，系統引入了一個與DRX相關的MAC控制單元DRX command，有時候也被形象的叫做Go-To-Sleep CE。
當網側檢測到已經沒有下行數據可傳時，可以向該UE發送一個MAC PDU，這個PDU裏攜帶一個DRX command控制單元。當UE收到這個DRX控制單元之後，無論當前是處於On_Duration狀態，還是Inactivity定時器正在運行，都會立即進入睡眠狀態，如圖3所示。
（圖3）
每個MAC控制單元都對應著一個子頭，並且一般來說，控制單元都占用特定長度的字節數，比如短BSR控制單元占用了1個字節，加上1個字節的子頭，共占用2個字節；再比如長BSR控制單元占用了3個字節，加上1個字節的子頭，共占用4個字節。但DRX Command控制單元比較特殊，它所占用的字節數是0
（圖4）
5.長周期和短周期
前文圖1已經提到，一個DRX周期等於UE喚醒時間（ON-duration）和睡眠時間的總和。在LTE裏，系統可以根據不同的業務場景，給UE分別配置短周期（short DRX cycle）或者長周期（long DRX cycle）。比如在進行VOIP業務時，語音編解碼器通常20ms發送一個VOIP包，那麽就可以配置長度為20ms的DRX短周期，而在語音通話期間較長的靜默期，就可以配置DRX長周期。如果同時配置了短周期和長周期，且在drxShortCycleTimer個子幀內都沒有監測到下行PDCCH，那麽UE將進入一次長周期睡眠，如下圖5所示。
（圖5）
在圖5中，我們還可以發現有個drxStartOffset參數，這個參數的含義是DRX周期是從哪個子幀開始的，比如周期是10個子幀，那麽drxStartOffset的範圍就是0～9；而如果周期是20個子幀，那麽drxStartOffset的範圍就是0～19，有點類似測量GAP裏的gapOffset。
6.參數配置
前面已經介紹了與DRX相關的很多參數，包括on_duration時長、drx-Inactivity定時器、長短周期、drxShortCycleTimer、drxStartOffset等等，可能有些同學已經迫不及待的想知道怎麽獲取這些參數以及這些參數的範圍是怎麽樣的了，下面就說說這個。
同樣的，這些參數仍然由RRC配置，具體在消息 RRCConnectionSetup 或 RRCConnectionReconfiguration 或 RRCConnectionReestablishment 的
RadioResourceConfigDedicated 信元的 MAC-MainConfig 中，如圖6所示。
RadioResourceConfigDedicated 信元的 MAC-MainConfig 中，如圖6所示。
（圖6）
onDurationTimer：該參數表示在一個DRX周期裏，UE睡醒後的在線時長。以PDCCH子幀個數為基本單位，比如psf6表示UE在線監測的時長為6個PDCCH子幀。
drx-InactivityTimer：該參數表示當UE成功解碼到一個下行PDCCH之後，還需要繼續監測多少個PDCCH子幀。同樣以PDCCH子幀個數為基本單位，比如psf80表示UE還需要繼續監測80個下行PDCCH子幀才能進入睡眠態。
drx-RetransmissionTimer：這個參數用在下行重傳的場景，表示UE為了接收期望的下行重傳數據，需要連續監測的最大PDCCH子幀個數。同樣以PDCCH子幀個數為基本單位，比如psf8表示UE為了接收下行重傳數據，還需要繼續等待最多8個下行PDCCH子幀。因為下行重傳是自適應的，時間並不確定，如果UE發現eNB需要進行一次重傳，那麽就需要等待一段時間，這個時間就由這個參數來控制。在定時器運行的這段時間內，UE也是需要盲檢測PDCCH信道的。
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-inactivity定時器（3個子幀的長度）；到了時刻（0，5），滿足了進入短周期的時間條件（後文會介紹這個條件，這裏記為條件1），UE被喚醒進入on-duration（持續2個子幀）；在時刻（1，0）和（1，5）多次進入短周期；到了（2，0）時刻，(drxShortCycleTimer×shortDrxCycle)=15個子幀內沒有成功解碼到PDCCH子幀，且滿足長周期進入條件（這裏先記為條件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在收到期望的下行重傳數據之前，需要等待的最少子幀個數。HARQ RTT Timer 和 drx-RetransmissionTimer 的關系，後文介紹DRX具體流程的時候會提到。
對於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是否僅在DRX周期的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
（4）http://www.sharetechnote.com
（5）<<4g broadband="" dvanced="" for="" lte="" mobile="">>
（6）http://people.cs.nctu.edu.tw/~yctseng/papers.pub/mobile93-drx-ieee-jetcas.pdf
沒有留言:
張貼留言