これは、スイッチ： https://blog.csdn.net/m_052148/article/details/52439789
1. なぜ使用DRX
我々は最初の「自由な状態」であると何が何であるかを理解する必要があり隣に、DRXの概念を説明する前に、「接続状態。」
私たちはしばしば、「アイドル状態」、「接続状態」などの用語、RRC層の観点から考え方を聞きます。簡単に言えば、とき住宅の完成後の細胞におけるUEは、私たちは、UEが「アイドル状態」または入ると言うことができる「IDLE状態。」UEは、フォローアップのランダムアクセス手順を完了している場合は、私たちは、UEは、「接続状態」または入ったと言うことができる「CONNECTED状態。」
それはアイドル状態または接続状態であるか否かを、我々はこの資料に記載のないDRX機構場合、UEは常にサービングセルからの情報があるかどうかを確認するために、ダウンリンクPDCCHサブフレームを監視します。そうすることで問題はいないようですが、現実に何回、UE効果的かつインタラクティブなかった情報ネットワークは、常にアップロードまたはダウンロードサービスを実行しないであろう、そこには、通話中に音声データを送信されなかったであろう。ほとんどの時間は、何のUEとネットワークのデータ交換がない、この時間UEはまた、明らかに、PDCCHサブフレームを監視するために多くの電力を続ければ。そのため、効果的なデータ伝送前提を確保するために、我々がDRXと呼ばれるこのメカニズムをUEの電力を節約するためのメカニズムを設計する必要があります。
2. DRXは何ですか
DRX、英語の完全な不連続受信、すなわち間欠受信は、このアプローチは、PDCCHサブフレームを監視するのではなく、スリープ（スリープモード）に移行し、スリープから耳を傾ける必要がある時点で、定期的にUEを可能にウェイクアップ状態を（ウェイクアップ）、UEは、バッテリ電力を節約することができそうという。これは、レイテンシのデータ伝送に何らかの影響を持っていますが、この遅延は、ユーザーエクスペリエンスに影響を与えていない場合は、より重要なUEの電力消費量を考慮しながら、DRXは理にかなって行います。
比較的接続状態DRX機構に、話すことははるかに複雑であり、DRX機構は、アイドル状態で実装され、接続状態が異なっています。このポストは、接続状態（DRX、CDRX接続された）特定のDRX機構で、アイドル状態、すなわちページング機構においてDRX機構は、ブログについて説明します。DRXは、後述DRXにおけるUEの状態が接続されている場合に特に使用されます。
図に示すように、典型的なDRXサイクル。この図では、識別は、「オンデュレーション」今回は、UEモニタはPDCCHの下りリンクサブフレーム、この時点で、UEが起きている時間です。ロゴ「DRXの機会」この時間は、UEは、電力を節約すること、DRXのスリープ時間である時間のPDCCHサブフレームを監視することなくスリープ状態になります。この図、長くDRXスリープ、UEの低消費電力から見ることができますが、対応するサービスの伝送遅延の増加が続きます。
（図1）
3.なぜ使用DRX-InactivityTimer
レッツは、このシナリオを考える：0ナンバーサブフレームは、ネットワーク側は、単にUEを送信するデータのより大きなバイトを持っている場合には、最後のサブフレームOn_Durationウェイクアップ時間を、である、これらのデータは、にすることはできません0すべてを送信するサブフレーム番号完成しました。DRXサイクルの場合、図1上記によれば、UEはであろうフレームDRXスリープ状態聖歌に入り、その後、ネットワーク側PDSCHから任意のダウンリンクデータを受信しません。ネットワーク側では唯一のDRXサイクルの終了まで待つことができ、そして次のOn_Durationモーメントが到着し、データを送信し続けるUEに完成説教ではありません。メカニズムは間違っていないが、このプロセスは、どうやらビジネス全体の処理遅延が増加します。図に示すように、このような状況を回避するために、DRX機構DRX-休止タイマーに加えました。
（図2）
DRX-inactivityTimerがOn_Duration時間の元の設定が終了した場合でも、実行されている場合、UEは、まだDRX InactivityTimerタイムアウトするまでPDCCHのダウンリンクサブフレームを監視し続ける必要があります。増加DRX-InactivityTimerメカニズムの後にもう一つの問題は、明らかに処理遅延データを削減しますが、以下に記載紹介します。
DRXコマンド制御部4意義を増やします
図2は、DRX-InactivityTimer効果がデータの処理遅延を低減することであると上述したが、場合DRX-InactivityTimerならセットが長すぎる、データタイマを送信するネットワーク側がタイムアウトしていない場合、UEにもされていませんタイムリーなスリープ状態に入ることができない、ダウンリンクサブフレームを監視し続けないでください。迅速なUEがスリープ状態になるようにしようするために、システムは、時々、ゴー・ツー・スリープCEイメージと呼ばれるDRX、関連付けられたDRXコマンドMAC制御部を紹介します。
アップリンクとダウンリンクデータを送信することはできないことと、ネットワーク側検出し、MAC PDUは、PDUがDRXコマンド制御部を運びUEに送信することができます。図に示すように、UEは、DRX制御部を受け取り、停止できるだけ早くDRXにOnDurationTimer DRX-InactivityTimer、場合。
（図3）
各MAC制御要素のサブヘッダに対応し、一般的に、制御ユニットは、ショートBSR制御要素は1バイトと1つのバイトのサブヘッダを占有するように、長さがバイトの一定の数を占め、 2バイトの総数、長いBSR制御要素の別の例は、3バイトと1バイトのサブヘッダ、4バイトの合計を占めます。しかし、DRXコマンド制御部特別な、バイトの数は、それによって占めゼロである、すなわち、1つのバイトのみサブヘッダを送信するには、コントロールユニットのための予備スペースには必要ありません。図に示すように、この部分集合は、LCID 0x1Eを事前に必要とされます。
（図4）
長いサイクルと短いサイクル
前文图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
