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 ?

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.

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.

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

}

< 38.213 - Table 10.3-1 Minimum time gap value X >

Following is the description about drx-Adaptation-r16 described in 38.306.

drx-Adaptation-r16

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.

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.

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 :

The overall structure of DCI 2_6 is as shown below (Source : Figure 11 of Ref [4])

RRC Parameters

Followings are RRC parameters directly or indirectly related to WUS. You see huge list of parameters here, but DPC-Config-r16 (marked red) is the most critical parameters.

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)

}

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

}

PhysicalCellGroupConfig ::= SEQUENCE {

   ..

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

   ...

}

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

}

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)

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)

Case 1 - High Throughput Scenario

: 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.

Case 2 - Idle Mode

: Obviously this mode would comsume much less energy, but this is the state where WUS is not applicable.

Case 3 - Sporadic / Bursty data traffic in connected mode

: 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.

Sean : Based on previous experience when CDRX was first employed, I have more positive opinion on the effect of WUS. At the time of initial CDRX introduction, there were also conflicting opinions. But based on observation and experience of enabling CDRX, power saving effect was pretty good. So WUS augmenting the efficiency of CDRX operation is expected to improve the power saving effect as well.

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

YouTube

• 5G Mobile mmWave Technology Evolution (Mar 2020)