5G/NR -  WUS

 

 

 

WUS (Wake Up Signal)

Three different things in 5G NR are called a wake-up signal, and they arrived in three different releases. I treated them as three features to learn separately for a long time. They are not three features. They are one idea applied in three places, and the shared part is small enough to hold in mind.

This page is about that shared part only. The detail of each mechanism lives on its own page. This one covers four questions that run across all of them. What does a wake-up signal actually gate ? Why does it always arrive early ? How is it addressed ? And what does the UE do when it hears nothing ?

Why is a periodic wake-up worth avoiding ?

DRX already puts the UE to sleep, so the first question is what is left to save. The answer is the wake-up that was scheduled and turned out to be unnecessary. That one case is the whole target of every mechanism on this page.

A UE in DRX wakes on a fixed period. In RRC_CONNECTED the period is the long DRX cycle, and the window is drx-onDurationTimer. In RRC_IDLE and RRC_INACTIVE the period is the paging cycle, and the window is the paging occasion. Neither window depends on whether anything is actually waiting for the UE.

That independence is the waste. In a lightly loaded cell most on-durations carry no grant, and most paging occasions carry no page for this UE. The UE still powers the main radio, retunes, synchronises and decodes a control channel. It does that on every cycle, and it learns nothing on most of them.

A wake-up signal makes the window conditional. The network sends a short indication before the window, and the UE opens the window only when the indication says so. The window itself is untouched. Its length, its period and its contents are the same as they were.

The cost side matters as much as the saving. A wake-up occasion is itself a reception, so it is not free. The saving is the cost of the skipped windows, minus the cost of every occasion the UE monitored. That subtraction includes the occasions that told it to wake, because those were paid for and saved nothing.

Two conditions follow from that arithmetic. The window has to be expensive relative to the indication, and most windows have to be ones the UE would have wasted. Where either condition fails, a wake-up signal costs more than it returns.

  • The target is the wasted wake-up : DRX already sleeps between windows. The only thing left to remove is the window that opens and finds nothing.
  • The window is gated, not changed : length, period and content stay as they were, and the indication only decides whether the window opens at all.
  • The occasion is a real cost : the saving is skipped windows minus every occasion monitored, including the ones that said wake.
  • Sparse traffic is the precondition : the mechanism pays when most windows would have been wasted. It costs more than it returns when they would not.

Which wake-up signals does 5G NR have ?

Three, and they do not compete with each other. Each one covers a state and a window that the others do not, so a UE can be configured with more than one. The table below sets them side by side, and the last column is where the detail lives.

Mechanism

UE state

Window it gates

How it is carried

Receiver

From

Detail

DCP

RRC_CONNECTED

drx-onDurationTimer of the long DRX cycle

DCI format 2_6, CRC scrambled by PS-RNTI

main radio

Rel-16

5G WUS DCP

PEI

RRC_IDLE, RRC_INACTIVE

the paging occasion

DCI format 2_7, CRC scrambled by PEI-RNTI

main radio

Rel-17

5G PEI

LP-WUS

RRC_IDLE, RRC_INACTIVE

the paging occasion, or the PEI occasion

its own waveform, outside PDCCH

separate low-power receiver

Rel-19

38.304 clause 7.5, 38.213 clause 10.4C

The first two rows are the same kind of thing in two states. Both are a PDCCH, so the main radio has to be awake to receive them. The saving comes from the shorter reception rather than from a cheaper one. Figure 1 in the next section is drawn from that shared shape.

The third row changes the family. LP-WUS is not a PDCCH at all. A separate low-power receiver monitors it while the main radio stays off. The cost of listening therefore drops by far more than a shorter PDCCH reception could achieve.

That difference also lets the three stack. A UE that detects an LP-WUS associated with it monitors the paging occasion. It may monitor PEI instead when PEI is configured. 38.304 leaves that choice to the UE implementation. One wake-up signal can therefore gate another.

One idea, three places to apply it UE state the wake-up signal the window it gates RRC_CONNECTED DCP DCI format 2_6, PS-RNTI main radio gates drx-onDurationTimer Release 16 RRC_IDLE / RRC_INACTIVE PEI DCI format 2_7, PEI-RNTI main radio gates the paging occasion Release 17 RRC_IDLE / RRC_INACTIVE LP-WUS its own waveform low-power receiver gates the paging occasion Release 19 or gates PEI A UE that detects an LP-WUS monitors the paging occasion, or monitors PEI when PEI is configured. The choice is left to the UE implementation.

Figure 1. The three mechanisms answer the same question in different states, and the green path is the one worth noticing. LP-WUS can gate PEI rather than the paging occasion, so the family nests instead of overlapping.

  • Three mechanisms, no overlap : DCP covers RRC_CONNECTED, and PEI and LP-WUS cover RRC_IDLE and RRC_INACTIVE.
  • Two are PDCCH, one is not : DCP and PEI still need the main radio, and LP-WUS is received by a separate low-power receiver.
  • They nest : an LP-WUS can gate the paging occasion directly, or gate the PEI occasion that gates the paging occasion.

What do all three have in common ?

Five things, and the fifth is the one that shapes the rest of this page. Figure 2 shows the first three on a single cycle, because they are all positions in time.

Every 5G wake-up signal has the same four parts wake-up occasion gap the window drx-onDurationTimer, or the paging occasion configured offset, measured back from the start of the window the UE stops monitoring here and acts before the window starts indication says wake : the window opens, unchanged in length, period and content indication says sleep, or nothing was heard : the window is skipped

Figure 2. The wake-up occasion, the offset and the gap are all fixed relative to the start of the window rather than to each other. That is why a configuration change to the window moves everything else with it.

It gates a window, it does not replace one. Nothing that the window would have carried is carried in the wake-up signal instead. A page is still delivered in the paging occasion, and a grant is still delivered in the on-duration. The indication carries one fact about the next window, and nothing more.

It arrives early, by a configured offset. The offset is always measured back from the start of the window. For DCP it is ps-Offset-r16, in multiples of 0.125 ms. For PEI it is pei-FrameOffset together with firstPDCCH-MonitoringOccasionOfPEI-O, one at frame level and one at symbol level. For LP-WUS it is lpwus-LO-FrameOffsetList, at frame level.

It reserves a processing gap before the window. Detecting the indication is not the end of the work, because the UE has to act on the result before the window starts. DCP names that gap directly. A UE reports a MinTimeGap-r16 of X slots. It is then not required to monitor for DCI 2_6 during the X slots before the on-duration. LP-WUS states the same idea as a wake-up delay the UE reports. When the configured offset leaves less than that delay, the UE stops using LP-WUS and falls back to ordinary paging.

It is addressed to a group. One transmission serves many UEs in all three cases, and that is what makes the mechanism cheap on the network side. DCI 2_6 is a concatenation of per-UE blocks, and each UE finds its own from ps-PositionDCI-2-6-r16. DCI 2_7 carries one bit per subgroup per paging occasion, sized by po-NumPerPEI and subgroupsNumPerPO. LP-WUS has its own subgrouping in 38.304 clause 7.6.

It is never acknowledged. There is no HARQ on any of them, no retransmission and no feedback. The UE gets one attempt, and the network never learns whether it succeeded. Everything in the next section follows from that one property.

  • Only the decision travels : the wake-up signal carries whether the next window opens, and the window still carries the page or the grant.
  • Everything is anchored on the window : the offset and the gap are both measured back from the start of the window, not forward from the occasion.
  • The gap is a UE capability, not a constant : MinTimeGap-r16 and the LP-WUS wake-up delay are both reported by the UE. The network has to configure around them.
  • Group addressing is the economy : one transmission serves many UEs, and each UE reads a block or a bit that the configuration told it to read.
  • One attempt, no feedback : there is no HARQ anywhere in the family, so the behaviour on a miss has to be written into the specification.

What happens when the UE hears nothing ?

I expected all three to fail safe here, and none of them does. What the specification actually does is more careful than that. It splits hearing nothing into two situations, and it answers them in opposite directions.

The first situation is a UE that had its occasions and detected nothing in them. All three treat that as an instruction to stay asleep. For DCP the physical layer reports no wake-up value at all, and ps-WakeUp-r16 then decides, with sleep as the behaviour when the field is absent. For PEI and for LP-WUS the wording is the same in both cases : the UE is not required to monitor the associated paging occasion.

The second situation is a UE that could not monitor at all. All three treat that as an instruction to wake up. For DCP there are two ways to reach that state. A UE may have no monitoring occasions outside Active Time before the next cycle, or it may not be required to monitor any of them. In both cases a value of 1 is reported to higher layers. For PEI, a UE unable to monitor its PEI occasion during cell reselection monitors the paging occasion anyway. For LP-WUS, a UE whose exit condition is met returns to ordinary paging or to PEI.

Mechanism

Monitored, and detected nothing

Could not monitor at all

DCP

The physical layer reports no value, and ps-WakeUp-r16 decides. The field is absent by default, so the UE sleeps.

A value of 1 is reported to higher layers, and the UE opens the on-duration.

PEI

The UE is not required to monitor the associated paging occasion.

The UE monitors the associated paging occasion (38.304 clause 7.1).

LP-WUS

The UE is not required to monitor the associated paging occasion.

The UE follows the ordinary paging procedure, or PEI (38.304 clause 7.1 or 7.2).

The distinction is between an absent indication and an absent opportunity. An absent indication is information, because the network had the chance to say wake and did not use it. An absent opportunity carries no information at all. The UE cannot read anything into it, so the only safe reading is to open the window.

One consequence is worth carrying into a debug session. A UE that missed its wake-up signal because the channel was poor behaves exactly like a UE that was correctly told to sleep. Neither opens the window, and nothing at that moment separates them. A missed page of this kind therefore appears later as a reachability complaint, rather than at the time as an error.

  • Nothing heard is two different cases : the specification separates a UE that monitored and detected nothing from a UE that had no chance to monitor.
  • An absent indication means sleep : all three treat a silent occasion as a decision the network made. DCP is the only one that lets the network override it.
  • An absent opportunity means wake : all three send the UE back to the full window when it could not monitor. Silence it never heard is not a decision.
  • A miss and a correct sleep look identical : neither opens the window, so a reliability problem surfaces as a reachability problem much later.

Why is the wake-up channel the least reliable part ?

Every saving on this page rests on one detection, and that detection is never retried. This is where the design effort in all three mechanisms actually goes.

Detection is cascaded with what follows it. The UE has to detect the wake-up signal, and then decode the window it opened. The combined reliability is the product of the two. Therefore the wake-up signal needs a tighter target than the channel it gates. Otherwise adding the mechanism makes the end to end performance worse.

The two failure directions do not cost the same. A false wake-up costs energy, and the UE opens a window it did not need. A missed wake-up costs latency in RRC_CONNECTED, and it costs reachability in RRC_IDLE. Losing a page is a much worse outcome than opening one unnecessary on-duration, so the design is biased towards the false wake-up.

LP-WUS makes that reasoning explicit, because its receiver is deliberately worse than the main radio. 38.304 therefore gates LP-WUS monitoring on measured thresholds rather than leaving it always on. The entry condition tests both radios, with Srxlev on the main radio and Qrxlevmeas_lr on the low-power receiver. The exit condition tests the low-power receiver alone. A UE in a weakening cell stops using LP-WUS and returns to ordinary paging.

That threshold pair is the honest statement of the whole family. A wake-up signal is a cheaper receiver carrying a smaller amount of information, so it works where there is link margin to spend. The specification has to say what happens where there is not. In all three cases the answer is to stop saving energy and open the window.

  • Reliability multiplies : the UE must detect the indication and then decode the window, so the indication needs a tighter target than the channel it gates.
  • The two errors are not symmetric : a false wake costs energy, and a missed wake costs latency or reachability. The design accepts the first to avoid the second.
  • LP-WUS is coverage gated : entry tests the main radio and the low-power receiver together, and exit tests the low-power receiver alone.
  • Energy saving is the first thing dropped : when margin runs out, all three mechanisms give up the saving and open the window.

Reference :

[1] 3GPP TS 38.213 - Physical layer procedures for control. Clause 10.3 for DCP, clause 10.4A for PEI and clause 10.4C for LP-WUS.

[2] 3GPP TS 38.212 - Multiplexing and channel coding. DCI format 2_6 and DCI format 2_7.

[3] 3GPP TS 38.331 - Radio Resource Control (RRC) protocol specification. DCP-Config-r16 and the field descriptions for ps-Offset, ps-WakeUp and MinTimeGap.

[4] 3GPP TS 38.304 - User Equipment (UE) procedures in Idle mode and RRC Inactive state. Clause 7.2 for PEI reception, clause 7.5 for LP-WUS monitoring and clause 7.6 for LP-WUS subgrouping.