5G/NR  -  Power Saving  




Power Saving

In any wireless/celluar communication system, power saving would be one of the most important issue and this is especially more important for the mobile device which has limited amount of power source (pattery) comparing to other type of devices (like fixed wireless CPE or devices within a vehicle). This issue has become more important in 5G/NR since it has relatively widely experienced that a mobile device tend to drain power more quickly when it is in 5G than in other legacy technology(e.g, LTE).

I think the general philosophy of NR power saving is best summarized in RP-200494 as follows.

The substantial  power saving gains over the agreed baseline in UE power saving schemes with UE adaptation in frequency domain, time domain, antenna domain, DRX operations, and reducing PDCCH monitoring with different traffic types, such as FTP, IM, web browsing, video streaming, gaming and VoIP,  and network configurations.

If I turn this logic in my way, I would express it in a several bullets as below.

  • Park the connection to BWP with minimum allowable bandwidth when there is not such a huge traffic (Frequency Domain Adaptation)
  • Reduce the bandwidth allocation that is barely enough for the necessary traffic (Frequency Domain Adaptation)
  • Don't wake up unnecessarily in DRX cycle when there is no data being scheduled (DRX Operation Adaptation). Until Release 15, the wake up in DRX cycle is determined by a predefined cycle, but in release 16 there is a new mechanism to allow UE to sleep continously even when it is in Wakeup period. In release 16, UE would choose NOT to wake up unless it gets a specific signal called 'Wake Up Signal(WUS)' from network.
  • Don't active too many antenna when it is not really necessary (Antenna domain adaptation)

Unfornately, this kind of adaptation cannot be done by UE alone. As you know, in cellular communication Network is the one who determine the most of configuration listed above and NW does know in details about the exact time-to-time resource requirement. So for this adaptation to work effectively, NW would need some assisting information from UE. In other way, there should be some way in which UE can inform NW of it's necessary requirement. For this notification purpose, Release 16 introduced a lot of new parameters in UEAssistanceInformation as in RRC Parameter section.

Typical Power Saving Mechanism

Following table is the list of the NR protocol features that would have impact on power saving




Release 15

On Demand CRS (no CRS)

In NR, there is no CRS which is always on and cause consistant energy consumption for channel estimation on UE

Control Channel Design


In LTE, UE always need to decode the full channel band and at every subframe, but in NR the bandwidth and subframe for the control channel is configurable for the benefit of energy saving.


NOTE : In most of use cases, the largest contributors to engergy consumption is PDCCH decoding. So it is important to design power-efficient PDCCH design (Figure 8 of Ref [4])

Cross Slot Scheduling

Cross Slot Scheduling mean that PDCCH(DCI) and PDSCH/PUSCH is in different slot (i.e, k0 or k2 is greater than 0). In this case, UE can get into a micro sleep between PDCCH and PDSCH/PUSCH.


Same logic as LTE in terms of power saving (i.e, turning off physical layer processing periodically when there is no data traffic)

Rrc Inactive

Switching to a kind of dormant mode (RrcInactive) when there is no data traffic without completely release RRC.


NOTE : a comment worth paying attention to (Ref [4])

Overall, it is beneficial to UE power consumption especially if we consider heavy traffic load or long data packets.

For small data packets, the cost, including overhead, latency and power consumption, coming from random access procedure and RRC connection establishment is still too high relative to small data payload. Therefore, introduction of inactive state alone is not sufficient if small data transmission cannot be done under inactive state. This requires enhancements in further steps of 5G evolution.

BWP Adaptation/Switching

Allow to configure multiple BWP with different physical resources and switches to the specific BWP which consumes less energy. gNB can control energy consumption for each BWP by setting the different number of RBs and number of layers and other resources.

Release 16

WUS (Wake Up Signal)

This can be a kind of improvement on CDRX mechanism. This allows UE to continue to sleep even in CDRX wakeup periodic when there is no data.

2 Step RACH

I think the direct impact of 2 step rach would be latency reduction, but the reduction of signaling steps in this process may have indirect impact on power saving.

Secondary Cell Dormancy

When there is not so much traffic, an SCell can be put into a dormacy status where UE does not monitor PDCCH (CSI or RRM measurement is still being performed)

Dormant BWP

Within a SCell, the dormancy can be applied to BWP level as well.

UE assistance Info

(Release 16)

DRX parameters


maximum aggregated bandwidth


maximum number of secondary component carriers


maximum number of MIMO layers


minimum scheduling offset for cross-slot scheduling

this indicates the min gap in terms of symbols between PDCCH(DCI) and PDSCH/PUSCH. With this information, UE does need to buffer / process any symbols within the gap which may lead to more power saving.

Future Candidates

(Release 17 or further)

Low data traffic in RRC Inactive

In current release (Rel 15,16), no data transfer is allowed in RRC Inactive status. So if even a small amount of data need to be transferred, it should go through RACH/RRC Signaling to switch to RRCConnected status which consumes large amount of power. If low data traffic is allowed in RRC Inactive, UE/gNB can transfer the data without switching to RRC Connected status

PDCCH Monitoring Adaptation

In current release (Rel 15,16), UE need to monitor PDCCH at ever slot unless it is in DRX sleep. We can save power if we can configure UE to monitor in a certain interval (not every slot). We may need to define a new DCI to specify this periodic PDCCH monitoring.

PDCCH Skipping

In current release (Rel 15,16), UE need to monitor PDCCH at ever slot unless it is in DRX sleep. We can save power if we can configure UE to stop PDCCH monitoring for a certain number of consecutive slots.  We may need to define a new DCI to specify this periodic PDCCH monitoring.

Multiple Antenna Pannel

When multiple Antenna Panel is configured, it would save power if we can configure a certain panel (or panels) which is not used for a certain moment instead of turining on all the configured pannels.

RRC Parameters

UEAssistanceInformation-v1540-IEs ::= SEQUENCE {

   overheatingAssistance                        OverheatingAssistance OPTIONAL,

   nonCriticalExtension                         UEAssistanceInformation-v1610-IEs OPTIONAL



OverheatingAssistance ::= SEQUENCE {

   reducedMaxCCs                               ReducedMaxCCs-r16 OPTIONAL,

   reducedMaxBW-FR1                            ReducedMaxBW-FRx-r16 OPTIONAL,

   reducedMaxBW-FR2                            ReducedMaxBW-FRx-r16 OPTIONAL,

   reducedMaxMIMO-LayersFR1 SEQUENCE {

      reducedMIMO-LayersFR1-DL                 MIMO-LayersDL,

      reducedMIMO-LayersFR1-UL                 MIMO-LayersUL


   reducedMaxMIMO-LayersFR2 SEQUENCE {

      reducedMIMO-LayersFR2-DL                MIMO-LayersDL,

      reducedMIMO-LayersFR2-UL                MIMO-LayersUL




ReducedAggregatedBandwidth ::= ENUMERATED {mhz0, mhz10, mhz20, mhz30, mhz40, mhz50, mhz60,

                                           mhz80, mhz100, mhz200, mhz300, mhz400}


UEAssistanceInformation-v1610-IEs ::= SEQUENCE {

   idc-Assistance-r16                      IDC-Assistance-r16 OPTIONAL,

   drx-Preference-r16                      DRX-Preference-r16 OPTIONAL,

   maxBW-Preference-r16                    MaxBW-Preference-r16 OPTIONAL,

   maxCC-Preference-r16                    MaxCC-Preference-r16 OPTIONAL,

   maxMIMO-LayerPreference-r16             MaxMIMO-LayerPreference-r16 OPTIONAL,

   minSchedulingOffsetPreference-r16       MinSchedulingOffsetPreference-r16 OPTIONAL,

   releasePreference-r16                   ReleasePreference-r16 OPTIONAL,

   sl-UE-AssistanceInformationNR-r16       SL-UE-AssistanceInformationNR-r16 OPTIONAL,

   referenceTimeInfoPreference-r16         BOOLEAN OPTIONAL,

   nonCriticalExtension SEQUENCE {} OPTIONAL



IDC-Assistance-r16 ::= SEQUENCE {

   affectedCarrierFreqList-r16             AffectedCarrierFreqList-r16 OPTIONAL,

   affectedCarrierFreqCombList-r16         AffectedCarrierFreqCombList-r16 OPTIONAL,




AffectedCarrierFreqList-r16 ::= SEQUENCE (SIZE (1.. maxFreqIDC-r16)) OF AffectedCarrierFreq-r16

   AffectedCarrierFreq-r16 ::= SEQUENCE {

      carrierFreq-r16 ARFCN-ValueNR,

      interferenceDirection-r16 ENUMERATED {nr, other, both, spare}



AffectedCarrierFreqCombList-r16 ::= SEQUENCE (SIZE (1..maxCombIDC-r16))

                                         OF AffectedCarrierFreqComb-r16


AffectedCarrierFreqComb-r16 ::= SEQUENCE {

   affectedCarrierFreqComb-r16 SEQUENCE (SIZE (2..maxNrofServingCells)) OF ARFCN-ValueNR OPTIONAL,

   victimSystemType-r16        VictimSystemType-r16



VictimSystemType-r16 ::= SEQUENCE {

   gps-r16                    ENUMERATED {true} OPTIONAL,

   glonass-r16                ENUMERATED {true} OPTIONAL,

   bds-r16                    ENUMERATED {true} OPTIONAL,

   galileo-r16                ENUMERATED {true} OPTIONAL,

   navIC-r16                  ENUMERATED {true} OPTIONAL,

   wlan-r16                   ENUMERATED {true} OPTIONAL,

   bluetooth-r16              ENUMERATED {true} OPTIONAL,




DRX-Preference-r16 ::= SEQUENCE {

   preferredDRX-InactivityTimer-r16 ENUMERATED {

      ms0, ms1, ms2, ms3, ms4, ms5, ms6, ms8, ms10, ms20, ms30, ms40, ms50, ms60, ms80,

      ms100, ms200, ms300, ms500, ms750, ms1280, ms1920, ms2560, spare9, spare8,

      spare7, spare6, spare5, spare4, spare3, spare2, spare1} OPTIONAL,

   preferredDRX-LongCycle-r16 ENUMERATED {

      ms10, ms20, ms32, ms40, ms60, ms64, ms70, ms80, ms128, ms160, ms256, ms320, ms512,

      ms640, ms1024, ms1280, ms2048, ms2560, ms5120, ms10240, spare12, spare11, spare10,

      spare9, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1 } OPTIONAL,

   preferredDRX-ShortCycle-r16 ENUMERATED {

      ms2, ms3, ms4, ms5, ms6, ms7, ms8, ms10, ms14, ms16, ms20, ms30, ms32,

      ms35, ms40, ms64, ms80, ms128, ms160, ms256, ms320, ms512, ms640, spare9,

      spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1 } OPTIONAL,

   preferredDRX-ShortCycleTimer-r16 INTEGER (1..16) OPTIONAL



MaxBW-Preference-r16 ::= SEQUENCE {

   reducedMaxBW-FR1-r16        ReducedMaxBW-FRx-r16 OPTIONAL,

   reducedMaxBW-FR2-r16        ReducedMaxBW-FRx-r16 OPTIONAL



MaxCC-Preference-r16 ::= SEQUENCE {

   reducedMaxCCs-r16           ReducedMaxCCs-r16 OPTIONAL



MaxMIMO-LayerPreference-r16 ::= SEQUENCE {

   reducedMaxMIMO-LayersFR1-r16 SEQUENCE {

      reducedMIMO-LayersFR1-DL-r16         INTEGER (1..8),

      reducedMIMO-LayersFR1-UL-r16         INTEGER (1..4)


   reducedMaxMIMO-LayersFR2-r16 SEQUENCE {

      reducedMIMO-LayersFR2-DL-r16         INTEGER (1..8),

      reducedMIMO-LayersFR2-UL-r16         INTEGER (1..4)




MinSchedulingOffsetPreference-r16 ::= SEQUENCE {

   preferredK0-r16 SEQUENCE {

         preferredK0-SCS-15kHz-r16        ENUMERATED {sl1, sl2, sl4, sl6} OPTIONAL,

         preferredK0-SCS-30kHz-r16        ENUMERATED {sl1, sl2, sl4, sl6} OPTIONAL,

         preferredK0-SCS-60kHz-r16        ENUMERATED {sl2, sl4, sl8, sl12} OPTIONAL,

         preferredK0-SCS-120kHz-r16       ENUMERATED {sl2, sl4, sl8, sl12} OPTIONAL

      } OPTIONAL,

   preferredK2-r16 SEQUENCE {

         preferredK2-SCS-15kHz-r16        ENUMERATED {sl1, sl2, sl4, sl6} OPTIONAL,

         preferredK2-SCS-30kHz-r16        ENUMERATED {sl1, sl2, sl4, sl6} OPTIONAL,

         preferredK2-SCS-60kHz-r16        ENUMERATED {sl2, sl4, sl8, sl12} OPTIONAL,

         preferredK2-SCS-120kHz-r16       ENUMERATED {sl2, sl4, sl8, sl12} OPTIONAL

      } OPTIONAL



ReleasePreference-r16 ::= SEQUENCE {

   preferredRRC-State-r16                ENUMERATED {idle, inactive, connected, outOfConnected}



ReducedMaxBW-FRx-r16 ::= SEQUENCE {

   reducedBW-DL-r16                      ReducedAggregatedBandwidth,

   reducedBW-UL-r16                      ReducedAggregatedBandwidth



ReducedMaxCCs-r16 ::= SEQUENCE {

   reducedCCsDL-r16                     INTEGER (0..31),

   reducedCCsUL-r16                     INTEGER (0..31)



PhysicalCellGroupConfig ::= SEQUENCE {


   dcp-Config-r16                        SetupRelease { DCP-Config-r16 } OPTIONAL, -- Need M




DCP-Config-r16 ::= SEQUENCE {

   ps-RNTI-r16                                          RNTI-Value,

   ps-Offset-r16                                        INTEGER (1..120),

   sizeDCI-2-6-r16                                     INTEGER (1..maxDCI-2-6-Size-r16),

   ps-PositionDCI-2-6-r16                           INTEGER (0..maxDCI-2-6-Size-1-r16),

   ps-WakeUp-r16                                     ENUMERATED {true} OPTIONAL, -- Need S

   ps-TransmitPeriodicL1-RSRP-r16               ENUMERATED {true} OPTIONAL, -- Need S

   ps-TransmitOtherPeriodicCSI-r16              ENUMERATED {true} OPTIONAL -- Need S



ServingCellConfig ::= SEQUENCE {

   dormantBWP-Config-r16              SetupRelease { DormantBWP-Config-r16 }



DormantBWP-Config-r16::= SEQUENCE {

   dormantBWP-Id-r16              BWP-Id OPTIONAL, -- Need M

   withinActiveTimeConfig-r16     SetupRelease { WithinActiveTimeConfig-r16 } OPTIONAL,-- Need M

   outsideActiveTimeConfig-r16    SetupRelease { OutsideActiveTimeConfig-r16 } OPTIONAL-- Need M



WithinActiveTimeConfig-r16 ::= SEQUENCE {

   firstWithinActiveTimeBWP-Id-r16                 BWP-Id OPTIONAL, -- Need M

   dormancyGroupWithinActiveTime-r16               DormancyGroupID-r16 OPTIONAL -- Need R



OutsideActiveTimeConfig-r16 ::= SEQUENCE {

   firstOutsideActiveTimeBWP-Id-r16                BWP-Id OPTIONAL, -- Need M

   dormancyGroupOutsideActiveTime-r16              DormancyGroupID-r16 OPTIONAL -- Need R



DormancyGroupID-r16 ::= INTEGER (0..4)

Reference :

[1] The 5G Evolution:3GPP Releases 16-17 (5G Americas)

[2] RP-200494 - UE Power Saving in NR (Work Item Description)

[3] TR 38.840 - Study on User Equipment (UE) power saving in NR

[4] Power Saving Techniques for 5G and Beyond

[5] 5G NR Power Saving Enhancements in Release 17 - Mediatek (Witepaper)