LTE資源調度（7）-DRX不連續接收（1）

1.為何要使用DRX

在講授DRX的概念前，我們需要先了解下甚么是“空閑態”，甚么是“連接態”。

我們常常會聽到“空閑態”、“連接態”這樣的術語，這個概念是從RRC層角度來講的。簡單來講，當UE在某個小區完成了駐留以后，我們就能夠稱該UE進入了“空閑態”或“IDLE態”。如果該UE后續又完成了隨機接入進程，那末我們就能夠稱該UE進入了“連接態”或“CONNECTED態”。

不管是空閑態，還是連接態，如果沒有我們本文提到的DRX機制，UE就會1直監聽下行PDCCH子幀，查看是不是有來自服務小區的信息。這樣做看起來沒有問題，但是現實很多時候，UE其實不是1直在和網絡進行有效信息的交互，不會總是履行上傳或下載業務，通話時也不會1直有語音數據的傳輸。大多數的時間，UE和網絡是沒有數據交互的，如果這個時候UE還去延續的監聽PDCCH子幀，明顯是很費電的。因此，在保證數據能有效傳輸的條件下，有必要設計1種節省UE電量的機制，這個機制我們就叫做DRX。

2.甚么是DRX

DRX，英文全稱為Discontinuous Reception，即不連續接收，這類方法可讓UE周期性的在某些時候進入眠眠狀態（sleep mode），不去監聽PDCCH子幀，而需要監聽的時候，則從睡眠狀態中喚醒（wake up），這樣就能夠使UE到達省電的目的。雖然這樣做對數據傳輸的時延有1定的影響，但如果這類時延其實不影響用戶體驗，那末斟酌到UE更加重要的功率消耗，履行DRX是很成心義的。

DRX機制在空閑態和連接態下的實現是不同的，相對而言，連接態下的DRX機制要復雜的多。本篇博文專門介紹連接態下的DRX機制（Connected DRX，CDRX），而空閑態下的DRX機制即尋呼機制，將在下1篇博文中介紹。下文描寫的DRX均特指UE處于連接態時使用的DRX。

1個典型的DRX周期如圖1所示。在這個圖中，標識“On Duration”的這段時間是UE監控下行PDCCH子幀的時間，在這段時間里，UE是處于喚醒狀態的。標識“Opportunity for DRX”的這段時間是DRX睡眠時間，即UE為了省電，進入了睡眠而不監控PDCCH子幀的時間。從這個圖中可以看到，用于DRX睡眠的時間越長，UE的功率消耗就越低，但相應的，業務傳輸的時延也會隨著增加。

（圖1）

3.為何要使用drx-InactivityTimer

我們來斟酌這樣的1個場景：0號子幀是喚醒時間On_Duration的最后1個子幀，此時網側恰好有1個較大字節的數據需要發給UE，這些數據沒法在0號子幀全部發送完。如果依照上文圖1的DRX周期，那末UE將在1號子幀進入DRX睡眠狀態，不會再去接收來自網側的任何下行PDSCH數據。網側也只能等到DRX周期結束，并在下1個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進入眠眠狀態，系統引入了1個與DRX相干的MAC控制單元DRX command，有時候也被形象的叫做Go-To-Sleep CE。

當網側檢測到已沒有下行數據可傳時，可以向該UE發送1個MAC PDU，這個PDU里攜帶1個DRX command控制單元。當UE收到這個DRX控制單元以后，不管當前是處于On_Duration狀態，還是Inactivity定時器正在運行，都會立即進入眠眠狀態，如圖3所示。

（圖3）

每一個MAC控制單元都對應著1個子頭，并且1般來講，控制單元都占用特定長度的字節數，比如短BSR控制單元占用了1個字節，加上1個字節的子頭，共占用2個字節；再比如長BSR控制單元占用了3個字節，加上1個字節的子頭，共占用4個字節。但DRX Command控制單元比較特殊，它所占用的字節數是0，即只需要發送1個字節的子頭便可，不需要為控制單元預留空間。這個子頭里的LCID需要設置為0x1E，如圖4所示。

（圖4）

5.長周期和短周期

前文圖1已提到，1個DRX周期等于UE喚醒時間（ON-duration）和睡眠時間的總和。在LTE里，系統可以根據不同的業務場景，給UE分別配置短周期（short DRX cycle）或長周期（long DRX cycle）。比如在進行VOIP業務時，語音編解碼器通常20ms發送1個VOIP包，那末就能夠配置長度為20ms的DRX短周期，而在語音通話期間較長的靜默期，就能夠配置DRX長周期。如果同時配置了短周期和長周期，且在drxShortCycleTimer個子幀內都沒有監測到下行PDCCH，那末UE將進入1次長周期睡眠，以下圖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所示。

（圖6）

onDurationTimer：該參數表示在1個DRX周期里，UE睡醒后的在線時長。以PDCCH子幀個數為基本單位，比如psf6表示UE在線監測的時長為6個PDCCH子幀。

drx-InactivityTimer：該參數表示當UE成功解碼到1個下行PDCCH以后，還需要繼續監測多少個PDCCH子幀。一樣以PDCCH子幀個數為基本單位，比如psf80表示UE還需要繼續監測80個下行PDCCH子幀才能進入眠眠態。

drx-RetransmissionTimer：這個參數用在下行重傳的場景，表示UE為了接收期望的下行重傳數據，需要連續監測的最大PDCCH子幀個數。一樣以PDCCH子幀個數為基本單位，比如psf8表示UE為了接收下行重傳數據，還需要繼續等待最多8個下行PDCCH子幀。由于下行重傳是自適應的，時間其實不肯定，如果UE發現eNB需要進行1次重傳，那末就需要等待1段時間，這個時間就由這個參數來控制。在定時器運行的這段時間內，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子幀為單位的，而與周期相干的都是以子幀為單位的。

1個典型的長短周期DRX流程如圖7所示。具體流程為：UE在時刻（0，0）成功解碼到1個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機制中，還需要用到1個名為“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處于激活時間）。除這些情況以外，當以下條件之1產生時，UE也需要延續的監測PDCCH信道：

DRX的處理流程需要斟酌的場景比較多，如果用文字描寫的話不太清晰，這里我用流程圖的情勢展現給大家，以下面的圖9所示（由于截圖的緣由，所以盡可能緊縮了空間排版）。

（圖9）

上面圖9中提到的半雙工FDD的概念，是2008年愛立信在深圳的1次3GPP會議中提出來的，初衷是允許UE在3.5GHz和小于860MHz的Band中，可以進入FDD半雙工的模式。但截至目前，還沒有聽說哪家手機芯片廠商支持LTE半雙工FDD的情況。

如果eNB配置了DRX功能，除影響UE側檢測下行PDCCH子幀，還會影響UE側SRS/CQI/PMI/RI的發送，具體為：

cqi-Mask參數是限制UE是不是僅在DRX周期的onDuration時間內發送CQI/PMI/RI的，由RRC消息配置，具體在 RRCConnectionReconfiguration 或 RRCConnectionReestablishment 或 RRCConnectionSetup 消息的 RadioResourceConfigDedicated -> PhysicalConfigDedicated -> CQI-ReportConfig 字段中。

除此以外，斟酌到UE側的處理時延，如果UE在激活時間的最后4個子幀內檢測到1個標識上行或下行新傳的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⑴2) Overall description

（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

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈