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
|
Category |
Mechanism |
Comments |
|
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.
|
|
|
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. |
|
|
DRX |
Same logic as LTE in terms of power saving (i.e, turning off physical layer processing periodically when there is no data traffic) |
|
|
Switching to a kind of dormant mode (RrcInactive) when there is no data traffic without completely release RRC.
|
||
|
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 |
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. |
|
|
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
} OPTIONAL,
reducedMaxMIMO-LayersFR2 SEQUENCE {
reducedMIMO-LayersFR2-DL MIMO-LayersDL,
reducedMIMO-LayersFR2-UL MIMO-LayersUL
} OPTIONAL
}
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)
} OPTIONAL,
reducedMaxMIMO-LayersFR2-r16 SEQUENCE {
reducedMIMO-LayersFR2-DL-r16 INTEGER (1..8),
reducedMIMO-LayersFR2-UL-r16 INTEGER (1..4)
} OPTIONAL
}
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)
YouTube
- 5G Mobile mmWave Technology Evolution (Mar 2020)