1. Introduction
Similar to LTE, Discontinuous Reception (DRX) in 5G is of two types, Idle mode DRX and Connected mode DRX. In Idle mode DRX, the UE periodically wakes up to monitor for paging messages and goes back to sleep mode if paging message is not intended for it. NR Connected mode DRX is thoroughly discussed in this post. LTE C-DRX concepts are thoroughly discussed in LTE: Connected Mode DRX.
Without C-DRX in 5G NR or LTE, the UE must be awake all the time in order to decode downlink data, as the data in the downlink may arrive at any time. This means that UE must be monitoring PDCCH in every subframe in order to check if there is PDCCH available. This consumes a lot of the user equipment’s power.
C-DRX in 5G/LTE is introduced to improve UE battery power consumption by allowing the UE to periodically enter ‘sleep’ state (Off duration) during which PDCCH need not be monitored. In order to monitor PDCCH for possible downlink/uplink data, the UE is allowed to wake up periodically and stay ‘awake’ (On duration) for a certain amount of time before going to ‘sleep’ again. Additionally, the UE may be required to wake up occasionally to monitor PDCCH, this is for example to receive a possible re-transmission.
The gNodeB configures UE with a set of C-DRX parameters. These DRX parameters are selected based on the application type such that power and resource savings are maximized. When C-DRX is enabled, the UE battery power consumption is reduced but this will increase latency. This is because, there might be an extended delay in receiving data as, the UE may be in DRX Sleep state at the time of data arrival at the gNodeB, and the gNodeB would have to wait until the UE becomes active. The latency increases with DRX cycle length, i.e., the longer the DRX cycle length, the higher the latency is. So, the DRX parameters must be carefully selected such that the packet delay is minimized, and power saving is maximized.
DRX is also beneficial from the network point of view. Without DRX, the UE would be transmitting periodic CSI or SRS very frequently (based on the configuration). With DRX, during OFF periods, the UE is not allowed to transmit Periodic CSI or SRS, so the gNodeB can assign those resources to the other UEs to maximize resource utilization.
Uplink is usually unaffected by DRX as discontinuous reception is applicable only for the downlink. Whenever data is available in the uplink buffer, the UE can send Scheduling Request (SR) irrespective of active or sleep state i.e., the UE can interrupt the ‘sleep’ state when there is a need to transmit uplink data.
2 C-DRX in detail
During DRX mode, the UE powers down most of its circuitry when there are no packets to be received or transmitted. During this time the UE listens to the downlink PDCCH occasionally which is called active state or DRX ON period, whereas the time during which UE doesn’t listen PDCCH is called DRX Sleep state or DRX OFF period.
Each DRX cycle consists of DRX ON period and OFF period. There are two types of DRX cycles defined; Long DRX Cycle and Short DRX Cycle each of which are explained below in detail.
Case1: Only Long DRX Cycle is configured
Each Long DRX Cycle consists of an ON period and an OFF period. The ON period also referred to as “On Duration” defined in terms of milliseconds is the period in which the UE would stay awake and decode PDCCH. The ON and OFF durations together form a Long DRX duration and repeat once every Long DRX Cycle period which is configured by RRC.
The network can control the start location of the Long DRX Cycle using the RRC parameter drx-LongCycleStartOffset. This offset value is defined in milliseconds i.e., the offset is defined such that the Long DRX Cycle could start at a subframe boundary.
Additionally, the network can configure start of the ‘On Duration’ at slot level granularity within a subframe. The parameter drx-SlotOffset defines the start of ‘On Duration’ relative to the start of subframe boundary.
Once a Long DRX Cycle starts, the UE stays active for a duration of ‘drx-onDurationTimer’ and if there is no PDCCH received during this time, the UE would go to DRX sleep state, until the start of next ‘On Duration’. This simple scenario is illustrated below.
Let’s say that there was some PDCCH activity during ‘On duration’ period, it is highly likely that the device might be scheduled again. If the UE goes to DRX sleep state, it cannot receive the scheduling grants/assignments. So, 3GPP has defined a parameter to keep the UE in active state after being scheduled. This timer is called DRX Inactivity Timer and is configured by RRC as drx-InactivityTimer. The UE starts/restarts this timer every time PDCCH indicates a new UL or DL transmission, and UE stays in active state and keep monitoring for PDCCH until the expiry of drx-InactivityTimer. This scenario is illustrated below.
Case2: Both Long DRX Cycle and Short DRX Cycle are configured
As discussed, Long DRX Cycle is characterized by active state and sleep states, and if there is certain data activity, the device extends the active state by a length of inactivity duration. Long DRX Cycle is not suitable for certain services which require periods of data transmission followed by periods of no activity. In such cases, the gNodeB has the flexibility to configure Long DRX Cycle together with additional DRX cycle which is shorter compared to long cycle. This second cycle is referred to as ‘Short DRX Cycle’.
When the gNodeB has configured Short DRX Cycle, that means both long and short cycles are configured. Configuring Short DRX Cycle is optional and if not configured, the UE follows Long DRX Cycle as usual. Whenever the gNodeB configures Short DRX Cycle, it should ensure that Long DRX Cycle duration is an integer multiple of Short DRX Cycle duration. This means, short cycle duration in general is shorter than long cycle duration.
In case if there is no data activity during ‘On Duration’ of a long cycle, the device simply follows Long DRX Cycle as if Short DRX Cycle is not configured. If there is any data activity, the UE would switch to Short DRX Cycle and follows short cycle for certain amount of time. If there is no data activity during this time, the UE would then switch to Long DRX Cycle and so on. Short DRX Cycles after recent data activity can be useful as the probability of being scheduled again during a certain amount of time after recent activity can be higher.
The Short DRX configuration consists of two parameters:
- drx-ShortCycle: defines the Short DRX Cycle duration.
- drx-ShortCycleTimer: configured as integer which defines number of short cycles the UE should follow after the start of short cycle.
If there is no data activity during the period defined by drx-ShortCycleTimer x drx-ShortCycle, the UE enters long cycle i.e., the UE enters Long DRX Cycle upon the drx-ShortCycleTimer number of short cycles.
Within a Short DRX Cycle, the start of ‘On Duration’ is determined using long cycle parameter drx-StartOffset and drx-SlotOffet which is similar mechanism as long cycle. Basic operation when both Short and Long Cycles are configured is shown below.
3 C-DRX Configuration
The MAC entity is configured by the RRC layer with DRX configuration. Entire DRX configuration is sent in drx-Config IE structure within MAC-CellGroupConfig structure. In 3GPP Release15, this DRX configuration is applicable for all the NR serving cells. In Release 16, an IE structure drx-ConfigSecondaryGroup-r16 is introduced to configure DRX related parameters for the second DRX group (of serving cells).
When there are more than one serving cell, the network may configure DRX in two DRX groups with separate DRX parameters. When RRC does not configure a secondary DRX group, there is only one DRX group and all Serving Cells belong to that one DRX group which is referred to as ‘default DRX group’. When two DRX groups are configured, each Serving Cell is uniquely assigned to either of the two groups.
The IE structure of MAC-CellGroupConfig is given below, observe that default DRX group configuration is provided using drx-Config and secondary DRX group configuration is provided via drx-ConfigSecondaryGroup-r16.
MAC-CellGroupConfig | |
drx-Config | SetupRelease { DRX-Config } |
. . . | |
csi-Mask | BOOLEAN |
. . . | |
drx-ConfigSecondaryGroup-r16 | SetupRelease { DRX-ConfigSecondaryGroup } |
. . . | |
The DRX parameters that are separately configured for each DRX group are: drx-onDurationTimer, drx-InactivityTimer. This means that the network has the flexibility to control active time per serving cell. The DRX parameters that are common to the DRX groups (or serving cells) are: drx-SlotOffset, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle (optional), drx-ShortCycleTimer (optional), drx-HARQ-RTT-TimerDL, and drx-HARQ-RTT-TimerUL.
DRX-Config for default DRX group
The gNodeB configures the following RRC parameters for DRX. Each DRX parameter and it’s purpose is explained below. Note that some of the newly introduced (in Rel-16) DRX parameters are discussed in later sections when it is relevant.
drx-Config | ||
drx-onDurationTimer | subMilliSeconds | INTEGER (0..31) |
milliSeconds | ENUMERATED {1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 400, 500, 600, 800, 1000, 1200, 1600} | |
drx-InactivityTimer | ms | ENUMERATED {0, 1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 500, 750, 1280, 1920, 2560} |
drx-HARQ-RTT-TimerDL | symbols | INTEGER (0..56) |
drx-HARQ-RTT-TimerUL | symbols | INTEGER (0..56) |
drx-RetransmissionTimerDL | slots | ENUMERATED {0, 1, 2, 4, 6, 8, 16, 24, 33, 40, 64, 80, 96, 112, 128, 160, 320} |
drx-RetransmissionTimerUL | slots | ENUMERATED {0, 1, 2, 4, 6, 8, 16, 24, 33, 40, 64, 80, 96, 112, 128, 160, 320} |
drx-LongCycleStartOffset | Cycle length in ms (offset: 0 to cycle length) | ENUMERATED {10 (0..9), 20 (0..19), 32 (0..31), 40 (0..39), 60 (0..59), 64 (0..63), 70 (0..69), 80 (0..79), 128 (0..127), 160 (0..159), 256 (0..255), 320 (0..319), 512 (0..511), 640 (0..639), 1024 (0..1023), 1280 (0..1279), 2048 (0..2047), 2560 (0..2559), 5120 (0..5119), 10240 (0..10239)} |
shortDRX | ||
drx-ShortCycle | ms | ENUMERATED {2, 3, 4, 5, 6, 7, 8, 10, 14, 16, 20, 30, 32, 35, 40, 64, 80, 128, 160, 256, 320, 512, 640} |
drx-ShortCycleTimer | num shortCycles | INTEGER (1..16) |
drx-SlotOffset | 1/32 ms units | INTEGER (0..31) |
- drx-onDurationTimer specifies the amount of time at the beginning of each DRX Cycle (DRX ON) todecode PDCCH during every DRX cycle before entering the power saving mode (DRX OFF).
- drx-InactivityTimer specifies the time period for which the UE should be active after successfully decoding a PDCCH indicating a new transmission (UL or DL). This timer is (re-) started upon receiving PDCCH for a new transmission (UL or DL). Upon the expiry of this timer the UE should go to DRX mode(more details in Section 4). The value of this timer is configured in milliseconds (subframe level).
- drx-LongCycleStartOffset configure two parameters drx-LongCycle in ms and drx-StartOffset in multiples of 1 ms. drx-LongCycle defines Long DRX Cycle length and drx-StartOffset is used to determine the starting subframe number within a DRX cycle.
- drx-RetransmissionTimerUL and drx-HARQ-RTT-TimerUL are used in uplink data retransmission handling. Similarly, drx-RetransmissionTimerDL and drx-HARQ-RTT-TimerDL are used in downlink data re-transmission handling. This will be discussed in Section 4.
- drx-ShortCycle is the first type of DRX cycle (if configured) that needs to be followed after certain data activity. This IE indicates the length of the short cycle in ms which include ON time followed by an OFF (sleep) time.
- drx-ShortCycleTimer expressed as multiples of drx-ShortCycle. The timer value can vary from 1 to 16 (short DRX cycles). This timer indicates the number of Short DRX cycles to follow once entering Short DRX cycle and before entering the long DRX cycle.
- drx-SlotOffset defines the start of ‘On Duration’ w.r.t the start of subframe.
Note1: Same onDurationTimer value is applied for both long and short DRX cycles.
Note2: If shortDRX-Cycle is configured, the value of longDRX-Cycle shall be a multiple of the shortDRX-Cycle value.
DRX-Config for Secondary DRX Group
As discussed already, drx-ConfigSecondaryGroup-r16 is introduced in 3GPP In Release 16 to configure DRX related parameters for the second DRX group. The network configures only drx-InactivityTimer and drx-onDurationTimer as part of this configuration. In other words, the network has the flexibility to control ‘On Duration’ and ‘Inactivity time’ per serving cell.
It is important to note that if networks configure drx-config for secondary group, drx-InactivityTimer and drx-onDurationTimer values for the second DRX group are smaller than the respective values configured for the default DRX group in IE DRX-Config.
The IE structure of drx-ConfigSecondaryGroup-r16 is given below.
DRX-ConfigSecondaryGroup | ||
drx-onDurationTimer | subMilliSeconds | INTEGER (0..31) |
milliSeconds | ENUMERATED {1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 400, 500, 600, 800, 1000, 1200, 1600} | |
drx-InactivityTimer | ms | ENUMERATED {0, 1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 500, 750, 1280, 1920, 2560} |
Enabling Secondary Group DRX-Config for a serving cell
If drx-ConfigSecondaryGroup-r16 is configured, the gNodeB may indicate which serving cells belong to the secondary group within SCellConfig IE structure. The field secondaryDRX-GroupConfig-r16 is used to indicate whether the corresponding SCell belongs to the secondary DRX group or not. If this field is not included, that means, the SCell belongs to default DRX group.
SCellConfig | |
sCellIndex | SCellIndex |
sCellConfigCommon | ServingCellConfigCommon |
sCellConfigDedicated | ServingCellConfig |
. . . | |
drx-ConfigSecondaryGroup-r16 | ENUMERATED {true} |
All serving cells in the secondary DRX group shall belong to one Frequency Range (FR) and all serving cells in the default DRX group shall belong to another Frequency Range.
4 DRX Operation
The triggering condition (timing) for DRX cycle is as follows:
If Short DRX Cycle is configured, the ‘On Duration’ period starts at a subframe satisfying the below condition…Within the calculated (as below) subframe, the actual ‘On Duration’ starts after a certain slot offset which is determined by drx-SlotOffset.
[(SFN×10) + subframe number] mod (drx-ShortCycle) = (drx-StartOffset) mod (drx-ShortCycle)
Upon the expiry of drx-ShortCycleTimer or if Short DRX Cycle is not configured, the UE uses Long DRX Cycle with the below triggering condition for the start of ‘On Duration’ period. Again, the actual ‘On Duration’ starts after a certain slot offset which is determined by drx-SlotOffset.
[(SFN × 10) + subframe number] mod (drx-LongCycle) = (drx-StartOffset)
As discussed already, during ‘On Duration’ period, the UE monitors PDCCH and if no data activity detected during this period, the UE would switch to sleep mode. Depending upon the kind of data activity one or a combination of below procedures could be triggered.
Reception of PDCCH indicating new transmission (UL or DL)
Whenever UE receives a PDCCH indicating a new transmission (DL or UL) on a Serving Cell of a specific DRX group, it should start or restart drx-InactivityTimer of the corresponding DRX group (default or secondary) in the first symbol after the end of the PDCCH reception.
If there is no new data transmission detected while drx-InactivityTimer was running, this timer gets expired. Upon the expiry of this timer, the UE enters into Short DRX Cycle (if configured) and continues for drx-ShortCycleTimer number of Short DRX Cycles. If Short DRX Cycle is not configured, the UE enters Long DRX Cycle as illustrated below. This procedure ensures that the DRX Cycle pattern is re-started after inactivity timer is expired.
Re-transmission Handling for PDSCH
Similar to LTE, HARQ re-transmissions are asynchronous in 5G NR downlink. When a DL transport block is erroneously received (CRC error), the UE sends a NACK to gNodeB and the gNodeB would then re-transmitthe same packet again. The UE would miss the re-transmission from the gNodeB if it is not in active state at the time of the re-transmission. Being awake all the time until receiving the re-transmitted packet is also not power efficient.
Technically, the network could re-transmit the packet at any time, but it is often as soon as possible. Depending upon network implementation and the HARQ round trip time, the network timing to re-transmit the DL packet may vary. So, the most important thing for the UE to be awake after this time duration. In order for UE to be awake during the time of re-transmission and not before, two timers are defined in 3GPP. The first timer drx-HARQ-RTT-TimerDL (in number of symbols) defines after how long the UE can expect a re-transmission. This way, the UE won’t be in active state beforehand.
Now the UE needs to know the time duration for which it must be awake to receive the re-transmission. Another timer drx-RetransmissionTimerDL (in number of slots) is defined for this purpose. This timer specifies maximum number of slots for which the UE should be monitoring PDCCH when a re-transmission from the gNodeB is expected by the UE.
When a new DL transmission is received by the UE, it should start the drx-HARQ-RTT-TimerDL in the immediate first symbol after transmitting NACK in the UL. Once drx-HARQ-RTT-TimerDL timer is expired, the UE starts drx-RetransmissionTimerDL timer in the next symbol and becomes active for this duration of this timer. As soon as UE detects a DL transmission for the corresponding HARQ process, it should stop the timer drx-RetransmissionTimerDL. This procedure is illustrated below.
Re-transmission Handling for PUSCH
Unlike LTE, HARQ re-transmissions are asynchronous in 5G NR uplink direction. When an UL transport block is erroneously received (CRC error) by the gNodeB, the UE may be asked to re-transmit the same packet. The UE would miss the re-transmission request (grant) from the gNodeB if it is not in active state at the time of re-transmission request. Being awake all the time until receiving the re-transmission request is also not power efficient.
In order for UE to be awake during the time of re-transmission request and not before, two timers are defined in 3GPP. The first timer drx-HARQ-RTT-TimerUL (in number of symbols) defines after how long the UE can expect a grant for uplink re-transmission.
Now the UE needs to know the time duration for which it has to be awake to receive the grant for uplink re-transmission. drx-RetransmissionTimerUL (in number of slots) is defined for this purpose. This timer specifies maximum number of slots for which the UE should be monitoring PDCCH when a grant for uplink re-transmission is expected by the UE.
The UE should start the timer drx-HARQ-RTT-TimerUL in the immediate first symbol after transmitting PUSCH. If PUSCH repetition is configured, then it is after first PUSCH transmission within a bundle. Once drx-HARQ-RTT-TimerUL timer is expired, the UE starts drx-RetransmissionTimerUL timer in the next symbol and becomes active for this duration of this timer. As soon as UE detects an UL transmission for the corresponding HARQ process, drx-RetransmissionTimerUL is stopped. This procedure is illustrated below.
Reception of DRX related MAC Control Element (MAC CE)
When the gNodeB knows that there is no additional data awaiting in the downlink, it can use a MAC CE to force the UE to terminate the ongoing active state and enter inactive state immediately. There is no point in being active when there is not going to be any data, this helps reduce UE’s power consumption. There are two MAC CEs defined in 3GPP MAC specification.
Note: When a DRX related MAC CE is received by the UE, the corresponding procedure (described below) is applied to both default group and secondary group.
1. DRX Command MAC CE
‘DRX Command MAC CE’ forces the UE to terminate the current active time and enter regular DRX cycle routine.
After receiving this MAC CE:
- The UE comes out of ‘active’ state and becomes inactive.
- The UE enters Short DRX Cycle mode if Short DRX Cycle is configured, else, the UE enters Long DRX Cycle mode.
The ‘DRX Command MAC CE’ is identified by a MAC sub-header with LCID: 60. It has a fixed size of zero bits (no payload).
The picture below illustrates the procedure for the case when Short DRX Cycle is configured.
The picture below illustrates the procedure for the case when only Long DRX Cycle is configured.
2. 2. Long DRX Command MAC CE
‘Long DRX Command MAC CE’ is used to force the UE to terminate the current active time and enter Long DRX cycle. In this case, the UE should enter Long DRX Cycle even if the Short DRX Cycle is configured. This is mainly useful if the gNodeB already knows that there is not going to be any data that requires Short DRX Cycle to be used.
After receiving this MAC CE.
- The UE comes out of ‘active’ state and becomes inactive.
- The UE enters Long DRX Cycle mode.
The ‘Long DRX Command MAC CE’ is identified by a MAC sub-header with LCID: 59. It has a fixed size of zero bits (no payload).
The picture below illustrates the procedure for the case when Short DRX Cycle is configured but, the procedure is same even if only Long DRX Cycle is configured; the UE always enters Long DRX Cycle mode.
DRX in conjunction with Semi-Persistent Scheduling
Downlink:
For downlink SPS, PDCCH carrying DCI 1_0 and 1_1 is addressed to Configured Scheduling-RNTI (CS-RNTI). The resource assignment received using CS-RNTI is referred to as Configured Downlink assignment. The Configured DL assignment in NR is given by the gNodeB to the UE, which stores this assignment and uses it according to the pre-configured timing given by the gNodeB.
As configured DL assignment periodically recurs, the UE uses this resource information to decode PDSCH. When the UE receives a MAC PDU using the configured DL assignment, the re-transmission handling is similar to that of regular DL data detection (PDSCH reception with explicit PDCCH DL assignment) as explained below.
If a MAC PDU is received in a configured DL assignment, the UE should start the drx-HARQ-RTT-TimerDL in the immediate first symbol after transmitting NACK in the UL. Once drx-HARQ-RTT-TimerDL timer is expired, the UE starts drx-RetransmissionTimerDL timer in the next symbol and becomes active for this duration of this timer.
Uplink:
For uplink SPS, PDCCH carrying DCI 0_0 and 0_1 is addressed to Configured Scheduling-RNTI (CS-RNTI). The grant received using CS-RNTI is referred to as Configured Grant. The grant can also be configured by RRC. The Configured Grant is given by the gNodeB to the UE, which stores the received grant and uses it according to the pre-configured timing given by the gNodeB.
As configured UL grant periodically recurs, the UE uses this resource information to transmit PUSCH. When the UE transmits MAC PDU using the configured UL grant, the re-transmission handling is similar to that of regular UL data transmission (PUSCH transmission with explicit PDCCH UL grant) as explained below.
If a MAC PDU is transmitted on PUSCH using a configured UL grant, the UE should start the timer drx-HARQ-RTT-TimerUL in the immediate first symbol after transmitting PUSCH. If PUSCH repetition is configured, then it is after first PUSCH transmission within a bundle. Once drx-HARQ-RTT-TimerUL timer is expired, the UE starts drx-RetransmissionTimerUL timer in the next symbol and becomes active for this duration of this timer in order to receive re-transmission request (grant).
5 Various Cases of ‘Active Time’
Active time is the duration that the UE monitors PDCCH. Below is the summary and explanation of all the ‘active time’ cases mentioned in MAC specification:
- drx-onDurationTimer configured for the DRX group is running
- drx-InactivityTimer configured for the DRX group is running
- drx-RetransmissionTimerDL or drx-RetransmissionTimerUL is running on any serving cell in the DRX group (as discussed in section 4)
- ra-ContentionResolutionTimer or msgB-ResponseWindow is running
The UE shall start ra-ContentionResolutionTimer in the first symbol after the end of the Msg3 transmission. Since the UE is waiting for the contention resolution which is via PDCCH reception on C-RNTI (in connected mode), the UE needs to be monitoring PDCCH. So the time duration in which mac-ContentionResolutionTimer is running is also considered as Active Time.
Similarly in a 2-step RA procedure, MsgB reception and contention resolution are important, so the UE needs to be in Active state to receive PDCCH while msgB-ResponseWindow is running.
- a Scheduling Request is sent on PUCCH and is pending
In order to receive the UL grant from the gNodeB, the UE has to be in active state after transmitting SR over the air on PUCCH.
- a PDCCH indicating a new transmission addressed to the C-RNTI has not been received after successful reception of a RAR in non-contention based RA procedure
In a non-contention based RA procedure, after receiving RAR, the UE should be in active state until PDCCH addressed to C-RNTI for a new transmission is received.
6 C-DRX Capabilities in UE Capability Information
The UE informs its C-DRX capabilities in UE Capability Information message to the gNodeB within the IE structure MAC-ParametersXDD-Diff. Summary of UE’s C-DRX capabilities are given below.
- longDRX-Cycle indicates whether UE supports long DRX cycle or not.
- shortDRX-Cycle indicates whether UE supports short DRX cycle or not.
- secondaryDRX-Group-r16 indicates whether UE supports secondary DRX group.
UE-NR-Capability -> mac-Parameters -> MAC-ParametersXDD-Diff | |
longDRX-Cycle | ENUMERATED {supported} |
shortDRX-Cycle | ENUMERATED {supported} |
. . . | |
secondaryDRX-Group-r16 | ENUMERATED {supported} |
. . . | |
7 Miscellaneous
Regardless of whether the MAC entity is monitoring PDCCH or not on the serving cells in a DRX group, the MAC entity transmits HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS on the Serving Cells in the DRX group when such is expected.
If the UE is not in Active time during an OFDM symbol, it shall not transmit periodic SRS and semi-persistent SRS, not report CSI on PUCCH and semi-persistent CSI configured on PUSCH.
Regardless of whether the UE is monitoring PDCCH or not, it should transmit HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS when such is expected.
The UE may be configured with a CSI Mask to limit the transmission of CSI reports to the On-duration period of the DRX cycle. The field csi-Mask under MAC-CellGroupConfig is defined for this purpose.
MAC-CellGroupConfig | |
drx-Config | SetupRelease { DRX-Config } |
. . . | |
csi-Mask | BOOLEAN |
. . . | |
drx-ConfigSecondaryGroup-r16 | SetupRelease { DRX-ConfigSecondaryGroup } |
. . . | |
8 UE Power Savings Techniques in 3GPP Release-16
C-DRX techniques discussed so far allows UE to save power. However, 3GPP Release-16 introduced a couple of enhancements to existing DRX techniques and these features have proven to have shown substantial power saving gain. These features will be discussed in a separate post. <Link to follow>
Reference: 3GPP TS 38.321, 38.331, 38.306, and 38.300
