WUS (Wake Up Signal) is a type of power saving mechanism introduced in NR release 16. I tries to save power by letting UE to continue to sleep (i.e, No Wake up) even for DRX OnDuration period when there is no data for the UE and gNB notifies the UE of 'No Wake Up'. When there IS any data for the UE, gNB would notify the UE of 'Wave Up' so that UE wakes up and receive data during OnDuration time.
- Procedure
- UE Capability
- DCI 2_6
- RRC Parameters
- Does it realy save a lot of Energy ?
- Reference
- YouTube
Procedure
The detailed procedure for WUS mechanism is specified in 38.213 - 10.3 PDCCH monitoring indication and dormancy/non-dormancy behaviour for SCells. My simplied understanding of the process can be illustrated as below and I don't think I need to verbalize this illustration. I think (hope) the illustration itself is self explanatory.
Figure 1. The saving comes from an on-duration that never starts. The DCP does not shorten the on-duration and it does not change the cycle, and both intervals drawn under the timeline are measured back from the same point.
Top row : the Long DRX cycle as configured. Two on-durations arrive on a fixed period, and neither of them depends on whether data exists.Bottom row : the same cycle as executed. A DCI 2_6 occasion, drawn in red, sits before each on-duration.Wake Indication = 0 : the first on-duration is drawn as a dotted outline. The drx-onDurationTimer does not start, and the UE stays asleep.Wake Indication = 1 : the second on-duration is drawn solid. The drx-onDurationTimer starts, and the UE monitors PDCCH for the whole of it.ps-Offset-r16 : the start of the DCI 2_6 search time, measured back from the start of drx-onDurationTimer. The unit is 0.125 ms, so 1 is 0.125 ms and 120 is 15 ms.MinTimeGap-r16 : X slots immediately before that same on-duration start. The UE is not required to monitor for DCI 2_6 inside the gap, and X depends on the subcarrier spacing.
The illustration covers the two cases where a DCI 2_6 arrives. There is a third case, and it decides how the feature behaves in a real network.
A UE can reach the on-duration having detected nothing at all. The physical layer then reports no wake-up value to MAC, and ps-WakeUp-r16 decides instead. The UE wakes up when the field is present. The UE does not wake up when the field is absent. Sleep is therefore the default, so a UE that loses the DCP to a bad channel loses the on-duration with it.
Two situations look the same in a log and are not the same. The first is a UE that had monitoring occasions and detected nothing in them, and ps-WakeUp-r16 governs that one. The second is a UE with no monitoring occasions outside Active Time for that cycle, or a UE not required to monitor any of them. In the second case the physical layer reports 1, and the UE wakes up whatever ps-WakeUp-r16 says.
Two more fields answer a related question. Periodic reporting would normally stop together with the on-duration. The field ps-TransmitPeriodicL1-RSRP-r16 keeps the periodic L1-RSRP report running when drx-onDurationTimer does not start, and ps-TransmitOtherPeriodicCSI-r16 keeps the other periodic CSI reports running. Both are off when absent, so the network loses those reports on every skipped cycle unless it asks for them.
One limit applies to the whole mechanism. The UE does not monitor for DCI 2_6 during Active Time. The DCP therefore only ever answers one question, and that question is whether the next on-duration starts.
The saving is a skipped on-duration : the DCP does not shorten the on-duration and it does not change the DRX cycle. It only decides whether drx-onDurationTimer starts.Both intervals are anchored on the on-duration : ps-Offset-r16 sets where the search time begins, and MinTimeGap-r16 reserves X slots immediately before the same point.Nothing detected is not one case : with monitoring occasions available ps-WakeUp-r16 decides, and its absence means sleep. With no occasions available the physical layer reports 1.Periodic reporting stops with the on-duration : ps-TransmitPeriodicL1-RSRP-r16 and ps-TransmitOtherPeriodicCSI-r16 are what keep it running, and both are absent by default.
UE Capability
Since this is release 16 feature and there would already be a lot of release 15 device which does not support this feature, gNB should check whether the UE supports this feature or not. For this purpose, UE should inform gNB of its capability about WUS and followings are parameters in UE capability Information.
Following is based on
MAC-ParametersFRX-Diff-r16 ::= SEQUENCE { directMCG-SCellActivation-r16 ENUMERATED {supported} OPTIONAL, directMCG-SCellActivationResume-r16 ENUMERATED {supported} OPTIONAL, directSCG-SCellActivation-r16 ENUMERATED {supported} OPTIONAL, directSCG-SCellActivationResume-r16 ENUMERATED {supported} OPTIONAL, -- R1 19-1: DRX Adaptation drx-Adaptation-r16 SEQUENCE { non-SharedSpectrumChAccess-r16 MinTimeGap-r16 OPTIONAL, sharedSpectrumChAccess-r16 MinTimeGap-r16 OPTIONAL } OPTIONAL, ... } MinTimeGap-r16 ::= SEQUENCE { scs-15kHz-r16 ENUMERATED {sl1, sl3} OPTIONAL, scs-30kHz-r16 ENUMERATED {sl1, sl6} OPTIONAL, scs-60kHz-r16 ENUMERATED {sl1, sl12} OPTIONAL, scs-120kHz-r16 ENUMERATED {sl2, sl24} OPTIONAL }
The two columns of that table are the two choices the ENUMERATED offers. At 15 kHz sl1 and sl3 are Value 1 and Value 2 of the same row. The capability therefore reports a short gap or a long one, rather than a free number.
< 38.213 - Table 10.3-1 Minimum time gap value X >
38.213 Table 10.3-1. The gap is reported in slots, so the same table entry is a shorter wall-clock time at a higher subcarrier spacing.
Those four rows are the Release 16 form of the table. 38.213 v19.4.0 carries two more, because Release 17 extended the DCP to the FR2-2 subcarrier spacings. At 480 kHz the two values are 8 and 96 slots. At 960 kHz they are 16 and 192.
Following is the description about drx-Adaptation-r16 described in 38.306.
Indicates whether the UE supports DRX adaptation comprised of the following functional components:
- Configured ps-Offset for the detection of DCI format 2_6 with CRC scrambling by ps-RNTI and reported MinTimeGap before the start of drx-onDurationTimer of Long DRX
- Indication of UE whether or not to start drx-onDurationTimer for the next Long DRX cycle by detection of DCI format 2_6
- Configured UE wakeup or not when DCI format 2_6 is not detected at all monitoring occasions outside Active Time
- Configured periodic CSI report apart from L1-RSRP (ps-TransmitOtherPeriodicCSI) when impacted by DCI format 2_6 that drxonDurationTimer does not start for the next Long DRX cycle
- Configured periodic L1-RSRP report (ps-TransmitPeriodicL1-RSRP) when impacted by DCI format 2_6 that drx-onDurationTimer does not start for the next Long DRX cycle
- The capability signalling includes the minimum time gap between the end of the slot of last DCI format 2_6 monitoring occasion and the beginning of the slot where the UE would start the drx-onDurationTimer of Long DRX for each SCS. The value sl1 indicates 1 slot. The value sl2 indicates 2 slots, and so on. Support of this feature is reported for licensed and unlicensed bands, respectively. When this field is reported, either of sharedSpectrumChAccess-r16 or non-SharedSpectrumChAccess-r16 shall be reported, at least.
The capability follows the same split. MAC-ParametersFR2-2-r17 repeats the Release 16 structure with a Release 17 suffix, and its drx-Adaptation-r17 carries MinTimeGapFR2-2-r17 rather than MinTimeGap-r16. A UE that supports the DCP on FR2-2 therefore reports the capability twice, once per frequency range.
Following is based on
MAC-ParametersFR2-2-r17 ::= SEQUENCE { directMCG-SCellActivation-r17 ENUMERATED {supported} OPTIONAL, directMCG-SCellActivationResume-r17 ENUMERATED {supported} OPTIONAL, directSCG-SCellActivation-r17 ENUMERATED {supported} OPTIONAL, directSCG-SCellActivationResume-r17 ENUMERATED {supported} OPTIONAL, drx-Adaptation-r17 SEQUENCE { non-SharedSpectrumChAccess-r17 MinTimeGapFR2-2-r17 OPTIONAL, sharedSpectrumChAccess-r17 MinTimeGapFR2-2-r17 OPTIONAL } OPTIONAL, ... } MinTimeGapFR2-2-r17 ::= SEQUENCE { scs-120kHz-r17 ENUMERATED {sl2, sl24} OPTIONAL, scs-480kHz-r17 ENUMERATED {sl8, sl96} OPTIONAL, scs-960kHz-r17 ENUMERATED {sl16, sl192} OPTIONAL }
DCI 2_6
This DCI is used for notifying the power saving information outside DRX Active Time for one or more UEs. This is scrambled by PS-RNTI. The phrase for one or more UEs is the important part. One transmission serves a whole group, so the format is a concatenation of per-UE blocks rather than a message addressed to a single UE. That is why the UE needs two configured values before it can read anything. One gives the total size, and the other gives its own position inside it.
Structure of DCI format 2_6 is as follows :
block number 1, block number 2,, block number N
Structure of each block is as follows :
|
Field (Item) |
Bits |
Reference |
|
Wake-up indication |
1 |
As per 38.213 '- 10.3
|
|
SCell dormancy indication |
0,1,2,3,4,5 |
|
The overall structure of DCI 2_6 is shown in Figure 2 (Source : Figure 11 of Ref [4])
Figure 2. One DCI 2_6 carries a block for every UE in the group. A UE reads only its own block, and it finds that block from ps-PositionDCI-2-6-r16 rather than from anything inside the transmission.
Fields for UE-1 to Fields for UE-N : the payload is a concatenation of per-UE blocks, and the drawing shows the first and the last of them.wake-up indication : the hatched field at the start of each block. It is always one bit.SCell dormancy indication : the hatched field immediately after it. It is 0 bits when dormancyGroupOutsideActiveTime-r16 is not configured, and 1 to 5 bits when it is.Placement is by position, not by packing : each block starts where ps-PositionDCI-2-6-r16 says it starts, so a UE never has to count the blocks before its own.
A block carries no header and no UE identifier. Nothing inside DCI 2_6 marks where one block ends and the next one begins.
Two RRC fields supply the missing information, and both sit in DCP-Config-r16. The first is sizeDCI-2-6-r16. It gives the total payload size of the format, so the UE knows how many bits to expect after descrambling with the PS-RNTI. The second is ps-PositionDCI-2-6-r16, and it gives the starting position of this UE's own wake-up indication inside that payload. The network assigns a different position to every UE in the group.
The bits from that position are read in a fixed order. The wake-up indication is one bit. The SCell dormancy bitmap follows immediately after it, and its size is the number of SCell groups configured by dormancyGroupOutsideActiveTime-r16. The most significant bit of the bitmap is the first configured SCell group, and the order runs in ascending DormancyGroupID.
Where the UE looks is fixed as well. DCI 2_6 is monitored on the PCell or on the SpCell only, in a common search space, and the search space sets are given by dci-Format2-6. Within one long DRX cycle the UE does not expect to detect two DCI 2_6 carrying different wake-up values for itself.
One transmission, many UEs : DCI 2_6 is a concatenation of per-UE blocks under a shared PS-RNTI, so one PDCCH serves a whole group.Two values locate the block : sizeDCI-2-6-r16 gives the payload size, and ps-PositionDCI-2-6-r16 gives this UE's own starting bit.The dormancy bitmap is positional : it follows the wake-up bit immediately, and its most significant bit is the first configured SCell group in ascending DormancyGroupID order.Only the PCell or the SpCell carries it : the UE monitors a common search space given by dci-Format2-6, and it never monitors during Active Time.
RRC Parameters
Followings are RRC parameters directly or indirectly related to WUS. You see huge list of parameters here, but DCP-Config-r16 (marked red) is the most critical parameters.
Following is based on
DRX-Config ::= SEQUENCE { drx-onDurationTimer CHOICE { subMilliSeconds INTEGER (1..31), milliSeconds ENUMERATED { ms1, ms2, ms3, ms4, ms5, ms6, ms8, ms10, ms20, ms30, ms40, ms50, ms60, ms80, ms100, ms200, ms300, ms400, ms500, ms600, ms800, ms1000, ms1200, ms1600, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1 } }, drx-InactivityTimer 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}, drx-HARQ-RTT-TimerDL INTEGER (0..56), drx-HARQ-RTT-TimerUL INTEGER (0..56), drx-RetransmissionTimerDL ENUMERATED { sl0, sl1, sl2, sl4, sl6, sl8, sl16, sl24, sl33, sl40, sl64, sl80, sl96, sl112, sl128, sl160, sl320, spare15, spare14, spare13, spare12, spare11, spare10, spare9, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}, drx-RetransmissionTimerUL ENUMERATED { sl0, sl1, sl2, sl4, sl6, sl8, sl16, sl24, sl33, sl40, sl64, sl80, sl96, sl112, sl128, sl160, sl320, spare15, spare14, spare13, spare12, spare11, spare10, spare9, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1 }, drx-LongCycleStartOffset CHOICE { ms10 INTEGER(0..9), ms20 INTEGER(0..19), ms32 INTEGER(0..31), ms40 INTEGER(0..39), ms60 INTEGER(0..59), ms64 INTEGER(0..63), ms70 INTEGER(0..69), ms80 INTEGER(0..79), ms128 INTEGER(0..127), ms160 INTEGER(0..159), ms256 INTEGER(0..255), ms320 INTEGER(0..319), ms512 INTEGER(0..511), ms640 INTEGER(0..639), ms1024 INTEGER(0..1023), ms1280 INTEGER(0..1279), ms2048 INTEGER(0..2047), ms2560 INTEGER(0..2559), ms5120 INTEGER(0..5119), ms10240 INTEGER(0..10239) }, shortDRX SEQUENCE { drx-ShortCycle 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 }, drx-ShortCycleTimer INTEGER (1..16) } OPTIONAL, -- Need R drx-SlotOffset INTEGER (0..31) }
Following is based on
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 }
Following is based on
PhysicalCellGroupConfig ::= SEQUENCE { -- ... base fields omitted ..., -- ... earlier extension groups omitted [[ dcp-Config-r16 SetupRelease { DCP-Config-r16 } OPTIONAL, -- Need M -- ... remaining fields of this group omitted ]] } DCP-Config-r16 ::= SEQUENCE { -- DCP stands for DCI with CRC scrambled by PS-RNTI 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 }
Following is based on
ServingCellConfig ::= SEQUENCE { -- ... base fields omitted ..., [[ -- ... earlier fields of this group omitted dormantBWP-Config-r16 SetupRelease { DormantBWP-Config-r16 } OPTIONAL, -- Need M -- ... remaining fields omitted ]] } 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)
Does it realy save a lot of Energy ?
This is a big question. I think I saw some TR says it would save huge amount of energy (TR 38.840 - Table 7: Power saving scheme with UE adaptation to the DRX operation), but I personally think how much energy WUS can save would depend on use cases. To be honest, I am a little bit in doubt about such a huge energy savings in reality. Let's think of a few typical use cases: (NOTE : this is just my personal opinion based on my speculation, not based on any real test)
: I don't think there would be much energy saving effect of WUS since there would almost be no time for UE to fall into drx. UE would stay wake up all the time.
: Obviously this mode would comsume much less energy, but this is the state where WUS is not applicable.
: I think this would be the most typical case where WUS is applicable. But even in this case.. if the pause between the data traffic burst is large (like over 10 seconds), most of live network gNB would simply release RRC and put the call into idle mode to save more energy. One disadvantage of RRC Idle in this case is that it needs to do RRC setup process again when the next data burst comes which consume more energy. so depending on how to optimize gNB side operation (e.g, using more of WUS rather than releasing RRC even when the pause between data bursts are long), you may enjoy more energy saving.
Opinion from other experts
While I didn't have such a bright opinion about the practical impact of WUS in terms of power saving, there can be other experts who has different opinion from mine. First I would like to introduce one of those opinion from Sean Cho. If any of you have opinion or experience on this and want to share yours, please email me or chat with me in linkedIn.
Especially in NSA where both LTE and NR should be running simulteneously. Complete sleep on NR (no PDCCH monitoring) during drx-onDuration when there is no data, it is expected to have high gain in terms of energy saving.
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] Novel Wake-up Scheme for Energy-Efficient Low-Latency Mobile Devices in 5G Networks
[6] TS 38.213 - Physical layer procedures for control (clause 10.3)
[7] TS 38.331 - Radio Resource Control (RRC) protocol specification (DCP-Config-r16 and the field descriptions)
[8] TS 38.212 - Multiplexing and channel coding (DCI format 2_6)
YouTube
- 5G Mobile mmWave Technology Evolution (Mar 2020)