Let's start by separating the three discussions that share the 6G WUS agenda item. The first is the design of the downlink wake-up signal itself. The second is what the device actually does with it in each RRC state. The third is a completely separate uplink signal, which lets a device wake a sleeping network. I'll explain those three discussions in the next section. First, we need to understand the starting condition that connects them and differs from 5G. In 5G, LP-WUS was built around a separate low-power receiver. Its noise figure was several dB worse than the main radio, so it could only reach part of the cell. It also needed its own always-on synchronization signal (LP-SS). In the end, LP-WUS coexisted with DCP and PEI instead of replacing them. In 6G the agreed EE processing state is different. It has the same noise figure as the main radio. It uses only 5 MHz of bandwidth, with 1 or 2 Rx chains. With these assumptions, we can realistically target PDCCH coverage across the whole cell for the wake-up signal. That single change drives three arguments. Companies argue for one unified wake-up signal for every RRC state. They also argue for offloading RRM measurement into the same low-power state. Finally, they argue for dropping OOK and LP-SS entirely. So the remaining disagreement concerns how much functionality we should expect from WUS. Companies need to balance that functionality against implementation cost and network overhead, rather than debate whether WUS is worthwhile.
- Executive Summary
- Agreed Items
- Acronym
- What does WUS stand for, and how does UL WUS differ from DL WUS?
- What are the three separate problems inside the 6G WUS agenda?
- How does 6G WUS differ from 5G WUS?
- What is EE processing, and why does it change the whole WUS discussion?
- Should 6G have one unified wake-up signal across all RRC states, or several specialised ones?
- What coverage target should DL WUS aim for?
- Should idle and connected mode have different coverage targets?
- How big is the coverage gap in practice?
- Which techniques should be used to close the coverage gap?
- Should basic and extended coverage both be in scope?
- What SNR target follows from matching PDCCH coverage?
- How should the #126-bis coverage results be compared?
- Should the DL WUS sequence be defined in the time domain or the frequency domain?
- Which sequence family should 6G DL WUS use?
- How many information bits should DL WUS carry, and how should they be mapped?
- How should the UE synchronize before detecting DL WUS?
- How should MDR, FAR and FDR be defined and targeted?
- How much network resource should DL WUS consume?
- What does DL WUS do in RRC IDLE/INACTIVE, and how much does it save?
- Should RRM measurement be moved into EE processing?
- How should DL WUS trigger PDCCH monitoring in RRC CONNECTED?
- Should RLM/BFD and CSI measurement also move to EE processing?
- What extra functions should DL WUS carry in connected mode?
- How deep does the UE sleep between WUS occasions, and what decides that?
- Would a longer WUS cycle with the sleep duration in the payload save more?
- How should DL WUS coexist with cell DTX/DRX, PDCCH skipping and SSSG switching?
- Is WUS the same idea as a Wi-Fi or Bluetooth wake-up radio?
- If a base station serves many UEs, can it ever sleep long enough for UL WUS to help?
- What is UL WUS for, and is it even needed?
- Which UL WUS deployment scenarios are feasible?
- How does the UE get the UL WUS configuration before it has SIB1?
- Should UL WUS be a PRACH preamble or a new signal?
- How much network energy does UL WUS actually save?
- Should the base station have a low-power receive mode, and how is it modelled?
Executive Summary
|
Area |
Main Topics Covered |
Summary |
Design Implication for 6G WUS |
|---|---|---|---|
|
Overall design philosophy |
|
In 5G, we ended up with three overlapping wake-up mechanisms, each with its own configuration and limitations. Almost every company argues that 6G should avoid repeating this. They propose a single sequence-based DL WUS for idle, inactive and connected states. But as we add use cases, the signal needs a larger payload and faces a harder coverage target. |
Aim for one signal structure with a single waveform and sequence family. Handle the differences between states through configuration. Add functionality only where it does not damage the basic wake-up reliability or the coverage target. |
|
Coverage target and enhancement |
|
RAN1 agreed to target the same coverage as the 6G PDCCH in the same band. Later, RAN1 fixed the link-level reference PDCCH configuration: AL8, 4 Rx and a 40-bit payload. The RAN1 #125 reference update uses 4 Tx at 3.5 GHz and 7 GHz. When you compare a plain single-symbol WUS with this reference, you find a gap of about 4.5 dB to 7 dB in mid-band. In addition, the gap between around 7 GHz and 3.5 GHz reaches 19 to 22 dB in MPL terms. |
We cannot meet the coverage target with one fixed WUS format. We need a baseline resource unit plus a scalable extension. The extension can be in the time, the frequency or the spatial domain. Among these options, 2-Rx reception and wider bandwidth cost less UE energy than long repetition, making them preferable. |
|
Waveform and sequence design |
|
Here we reach the strongest disagreement in the agenda. Device vendors favour a time-domain definition. This lets the UE correlate without an FFT while keeping PAPR low. Infrastructure vendors favour a frequency-domain definition instead. Their preferred definition needs no DFT pre-processing, simplifies multiplexing and allows free sequence lengths. However, link-level results from both camps are close to identical for a small number of sequences. |
With similar raw link performance, we need to compare implementation cost, multiplexing and multi-symbol sequence behaviour. A workable compromise is a definition that leaves the receiver free to process in either domain. The RAN1 #126 conclusion narrows the sequence-family comparison to Zadoff-Chu and Gold, with down-selection due by RAN1 #127. Receiver processing domain remains a separate implementation question. |
|
Payload and information provisioning |
|
Companies agree on more than 5 bits, but they disagree on how much more. Proposals cluster around 10 plus or minus 2 bits. The evidence also suggests that the idle-mode false wake-up benefit saturates beyond roughly 6 bits, or 64 subgroups. However, one company argues that true per-UE indication would need 10^3 to 10^4 sequences per occasion. Whichever payload we choose, every extra bit costs coverage and adds detection complexity and blind hypotheses. |
Fix the wake-up indication as the mandatory content. Then size the payload from the subgrouping benefit, and not from the wish list of extra features. Codepoint mapping suits the low arrival rate of idle mode. For connected mode, study bitmap or segmented mapping because the network may wake several UEs at once. |
|
Synchronization and impairments |
|
RAN1 agreed to study at least the 6GR sync signals for UE synchronization before WUS reception. RAN1 treats additional sync methods as conditional options, only if those signals prove insufficient. RAN1 #126 fixed the same-carrier evaluation baseline at maximum errors of 1 us and 2 ppm, with uniformly distributed actual errors. The 2 us and 5 ppm case remains an additional robustness condition. |
Do not introduce a new LP-SS equivalent. Use the agreed synchronization assumptions consistently. State whether the UE processes the preceding SSB. Coverage, sequence choice and detector complexity all depend on that assumption. In addition, handle integer CFO explicitly rather than assuming it away. |
|
Reliability metrics |
|
RAN1 clarified the definitions in RAN1#125. FAR covers detection of a targeting sequence when nothing was transmitted. FDR covers detection of a targeting sequence when a different sequence was transmitted. RAN1 #126-bis recorded two evaluation pairs: MDR 1% with max(FAR, FDR) 1%, and MDR 0.5% with max(FAR, FDR) 5%. These are evaluation operating points, not a completed normative design. |
Keep noise-driven and sequence-driven errors as separate metrics. A design optimised for noise-only FAR can have a much worse real false wake-up rate. Relaxing FAR is a legitimate design tool because a false wake-up only costs energy, while a missed detection costs a paging cycle. |
|
Operation in RRC IDLE/INACTIVE |
|
You'll find large reported energy saving gains, but check what else the UE must do. Against I-DRX with PEI, the gain is roughly 22% to 37% when the UE reaches deep sleep. With ultra-deep sleep, it rises to about 73%. But the gain collapses if the main radio still performs RRM measurement every cycle. |
Design the idle-mode procedure and the measurement offloading together. If the main radio still wakes for measurement, removing paging PDCCH monitoring delivers only a small fraction of the available gain. |
|
Measurement by EE processing |
|
Companies widely view serving cell measurement as adding almost no cost beyond synchronization. Companies report RSRP accuracy of about 2 to 3 dB with one or two SSB samples using 2 Rx. For neighbour cell measurement, they disagree. Cell detection, interference handling and configuration storage are harder to reduce for low-power operation than correlation. |
Treat serving cell measurement as a baseline capability. Keep neighbour cell measurement conditional, with a limited cell list and limited timing uncertainty, starting with synchronous deployments. Cell search may need to stay in the main radio or in an enhanced EE state. |
|
Operation in RRC CONNECTED |
|
RAN1 agreed a common procedure. The UE monitors WUS periodically. After detection and a time offset, the UE starts PDCCH monitoring for a time duration. The remaining questions are the duration and the offset, whether WUS continues during the duration, and how monitoring stops. Reports show gains of 21% to 53% for FTP3 and up to 70% for IM traffic. When you compare these gains, check how deeply the main radio sleeps during WUS monitoring. This has the largest single effect. Also, the meeting record and contributions disagree on how the gains map to periodicity. |
Do not treat "with C-DRX" and "without C-DRX" as two features. They are two configurations of the same timer-based framework. Compare them at equal triggering periodicity; matching the configuration labels alone does not give a useful comparison. |
|
UL WUS scenarios and feasibility |
|
To assess feasibility, first check what the cell transmits before the UL WUS. Where always-on sync signals with PBCH exist, RAN1 has already observed that the UE can synchronize and determine transmit power. If the cell transmits nothing, most companies argue that the UE cannot even discover it. Moreover, GNSS assistance does not resolve transmit power or regulatory concerns. |
Anchor UL WUS to scenarios where at least a sync signal exists. Keep blind transmission only as a limited special case, if at all. Focus on the minimum information the UE needs before SIB1. |
|
UL WUS design and network power model |
|
Most companies want to reuse PRACH rather than invent a second uplink access signal. The study considers additional requirements only where they differ, such as receiver architecture and tolerance to uplink synchronization error. The base station side is harder. The RAN1 #125 evaluation agreement provides two BS power-model options. Option 2 applies to reference Set 4 with more than 64 TRxRUs and accounts for partial activation. |
Keep UL WUS inside the PRACH family, unless a specific requirement forces otherwise. Also account for the coverage cost of a reduced-antenna receiver. It saves network energy but reduces uplink coverage, so the UE needs more transmit power or repetitions. |
Agreed Items
These entries separate confirmed decisions from agreements to continue a study. Earlier origins are retained when a #126-bis summary reproduces the baseline. They describe the study record available here, rather than a completed 6G specification. Simulation assumptions and unresolved alternatives stay visible because they determine what each decision can support. Company proposals remain in the topical discussion.
RAN1 #125 - earlier baseline retained
The available #126-bis summaries retain these earlier decisions. Their meeting labels preserve when the baseline originated, so the later summary does not make them new #126-bis agreements. The transmit reference and partial-activation power model control comparisons across several new papers. Their coverage consequences therefore remain relevant when reading the latest results.
- For the 3.5 GHz and 7 GHz WUS link-level reference, use 4 Tx antennas in place of 2 Tx. Source: R1-2608634, previous-agreement appendix.
- Study one waveform and sequence family across RRC states. This is a unified-design study objective. Source: R1-2608634.
- The BS evaluation power model includes partial-TRxRU Option 2 for reference Set 4 above 64 TRxRUs, with 30% ramp-down and 70% ramp-up. Reduced active TRxRUs reduce coverage. Source: R1-2608792.
RAN1 #126 - earlier baseline retained
These decisions provide the comparison baseline used by the new papers. The agreed study scopes still contain unresolved targets and alternatives, which should remain visible when interpreting later simulation results. In particular, a basic SNR reference does not set extended coverage, and listing a deployment case does not establish its normative support.
- Study both basic and extended DL WUS coverage. Use reference PDCCH 1% BLER at -8.1 dB as the starting point. Source: R1-2608634.
- For same-carrier DL WUS evaluation in FR1 and around 7 GHz, use maximum timing/frequency errors of 1 µs and 2 ppm with uniform actual errors. Additionally study solutions for 2 µs and 5 ppm. Source: R1-2608634.
- Down-select between Zadoff-Chu and Gold families no later than RAN1 #127. This schedules a decision; it does not select either family. Source: R1-2608634.
- Study TDM, FDM and mixed WUS occasion arrangements without requiring a UE to monitor more than one occasion at a time. Source: R1-2608771, earlier-agreement section.
- Study the listed UL WUS use cases and five configuration-acquisition mechanisms, including combinations and implicit information. SIB26 is the payload reference. The non-co-located DS#2a case retains timing, power, beam and interference questions. Source: R1-2608792, previous-agreement appendix.
RAN2 #135 - liaison received at RAN1 #126-bis
This rule originates in RAN2 and reaches RAN1 through the WUS/C-DRX liaison. It governs their combined configuration while leaving measurement requirements to RAN4 and detailed behavior for further discussion. The distinction matters when interpreting simulations that use a WUS periodicity shorter than the configured C-DRX cycle or assume a separate measurement schedule.
- With WUS and C-DRX configured together, the UE has one DL-monitoring cycle/timer set. A negative WUS indication does not start C-DRX active time. Measurement periodicity may differ, subject to RAN4. Source: R1-2606981 / R2-2606053.
RAN1 #126-bis
The following outcomes are explicitly recorded as achieved agreements in the available summaries. DL design entries use summary #4 because the later design summaries were inaccessible. Open proposals in other-function summary #2 are excluded. The entries preserve each decision's scope: evaluation points, study objectives and conditional observations have different implications from a selected signal design.
- DL design: compare cell pools of 32, 64, 128 or 256 transmittable candidates per sequence resource, pending down-selection. Reuse the cell pool across resources; the maximum targeting a UE is eight. Source: R1-2608634.
- DL design: assume maximum information payloads of 6, 8 and 12 bits for link-level simulations, with other values allowed. Support one WUS sequence in one OFDM-symbol duration; connected-mode overhead reduction remains open. Source: R1-2608634.
- DL evaluation: use MDR 1% with max(FDR, FAR) 1%, and MDR 0.5% with max(FDR, FAR) 5%. These are paired evaluation points. Source: R1-2608634.
- Paging at least in RRC idle: monitor paging PDCCH after a wake-up indication, with WUS periodicity equal to paging periodicity. Direct paging PDSCH reception remains open. Source: R1-2608771.
- Agreed study scope: evaluate the use case, necessity and benefit of WUS monitoring during active time, including WUS/PDCCH start and stop behavior. Source: R1-2608771.
- RRM evaluation: align known-cell serving and intra-frequency measurement assumptions using NR PSS/SSS, TDL-C 300 ns, one Tx/layer, one or two Rx and uniformly distributed frequency error bounded by 2 ppm. Cell identification/search is excluded. Source: R1-2608771.
- Connected measurement evaluation: study the SNR/SINR difference between EE and regular processing with the agreed assumptions. This does not establish RLM feasibility. Source: R1-2608771.
- Adopt the 17 collected idle-mode energy observations in R1-2608770 in principle with their assumptions and figures, allowing later refinement. These are conditional observations. Source: R1-2608771.
- UL evaluation: use common reporting templates for on-demand SS/PBCH, SIB1, combined requests and connected-mode uplink-data cases. Include BS configuration, request rate, signal resources, energy gain/loss and applicable latency/QoS metrics. Source: R1-2608792.
Acronym
This note uses a large number of acronyms, and several of them are new in 6G. The table below covers the wake-up vocabulary, together with the terms that the note leans on most often. Where a term carries a specific meaning in this agenda item, that meaning is given as well.
|
Acronym |
Meaning |
|---|---|
|
|
Beam Failure Detection |
|
|
DCI with CRC scrambled by PS-RNTI, the Rel-16 power saving signal |
|
|
Deployment Scenario. DS#1 and DS#2 are the UL WUS scenario families |
|
|
Discontinuous Transmission |
|
|
Energy Efficient. EE processing is the low-power state in which the UE detects the WUS |
|
|
False Alarm Rate. Detection when no WUS sequence was transmitted |
|
|
Frequency Division Multiplexing |
|
|
False Detection Rate. Detection of a targeting sequence when a different sequence was transmitted |
|
|
Global Navigation Satellite System |
|
|
Instant Message traffic model |
|
|
Internet of Things |
|
|
Idle mode DRX |
|
|
Low-Power Synchronization Signal, the Rel-19 sync signal for the low-power receiver |
|
|
Low-Power Wake-Up Signal, the Rel-18/19 feature |
|
|
Missed Detection Rate |
|
|
New Radio, the 5G radio access |
|
|
On-Off Keying |
|
|
Peak to Average Power Ratio |
|
|
Paging Early Indication, the Rel-17 feature, carried in DCI format 2_7 |
|
|
Paging Frame |
|
|
Paging Occasion |
|
|
Power Saving Radio Network Temporary Identifier |
|
|
Radio Link Monitoring |
|
|
Search Space Set Group |
|
|
Transmission and Reception Point |
|
|
Transceiver Unit at the base station |
|
|
Voice over IP |
|
|
Wake-Up Signal. DL WUS wakes the device, and UL WUS wakes the network |
|
|
Zadoff-Chu sequence |
What does WUS stand for, and how does UL WUS differ from DL WUS?
WUS stands for Wake-Up Signal. In this agenda item, you need to distinguish two signals with that name. They travel in opposite directions, and they wake opposite ends of the link. For DL WUS, the downlink wake-up signal, the base station sends it and the UE detects it. Its job is to tell a sleeping device that something is coming. For UL WUS, the uplink wake-up signal, the UE sends it and the base station detects it. Its job is to tell a quiet network that a device needs something. I'll follow that order here: first the downlink signal, then the uplink signal.
Now consider who saves energy, because the direction also changes the beneficiary. DL WUS saves UE energy, because the device can stay in a sleep state until the signal arrives. UL WUS saves network energy, because the base station can stop transmitting common signals until a device asks for them. In the uplink case, the UE pays through transmit power, latency and complexity. That is why the two signals attract different objections. For DL WUS, companies debate how much information the signal can carry before detection becomes too expensive. For UL WUS, they debate whether we need the feature at all.
Let's divide the uplink use cases into three groups. The first is a request for an on-demand signal or channel, such as SSB, PBCH, SIB1 or other system information. The second is a request to wake a base station that is in a low-power mode. The third is an indication about uplink data, for example data arrival during a cell DTX non-active period. The first group drives the current study; the other two remain proposed extensions.
Figure 1. One name, two signals. DL WUS wakes a sleeping device. UL WUS wakes a sleeping network, with the UE paying the cost.
WUS is Wake-Up Signal : The acronym is identical in both directions. Check the DL or UL prefix to identify which signal we mean.The beneficiary is reversed : DL WUS saves UE energy. UL WUS saves network energy. In the uplink case the UE pays in transmit power, latency and complexity.The design problems barely overlap : For DL WUS, companies debate payload, coverage, sequence family and detection metrics. For UL WUS, they debate synchronization, transmit power and whether a PRACH preamble already does the job.What the uplink request is used for : The three groups are on-demand signal or channel requests, base station wake-up from low-power mode, and uplink data indications. Only the first group is driving the current study.
What are the three separate problems inside the 6G WUS agenda?
Let's separate agenda item 10.6 into its three design problems. First, we need to define the downlink wake-up signal itself. We need to decide the OFDM sequence structure, its coverage and its payload. We also need to set the required detection reliability. Second, we need to define what the UE does with the signal. Here we consider how the signal replaces or reshapes paging monitoring in RRC IDLE, and how it triggers PDCCH monitoring in RRC CONNECTED. We also consider how much of the measurement workload can move into the new low-power EE processing state. Third, we have the uplink wake-up signal, which lets a device wake a sleeping network. The network then no longer needs to transmit synchronization signals and system information all the time. Keep these three problems separate when you read the contributions. A proposal can look reasonable in one discussion yet cost too much in another. For example, a larger payload is attractive to the operation discussion, because it reduces false wake-ups. But in the signal design discussion, every extra bit costs coverage. Similarly, a base station that sleeps deeply is attractive in the uplink discussion. But it lengthens the access latency that the downlink discussion is trying to protect.
Figure 2. The structure of agenda item 10.6, and the direction each part points in.
10.6.1.1 decides what the signal is : Here we examine the sequence family and whether to define the sequence in the time or frequency domain. It also covers the coverage target and how to reach it. Finally, it covers the payload size, the mapping of bits onto sequences, and the missed detection, false alarm and false detection targets.10.6.1.2 decides what the device does with it : Here we examine whether WUS replaces PEI as the single paging trigger in idle mode. We also examine how the UE starts and stops PDCCH monitoring in connected mode. We then consider how much RRM, and possibly RLM, can move out of the main radio into EE processing.10.6.2 points the other way : Here the UE transmits and the base station listens. The purpose is to let the network stop transmitting synchronization signals, PBCH and system information continuously. At the same time, initial access must not become unacceptably slow. This single item covers both the uplink signal and its procedure, so it has no equivalent of 10.6.1.1.There is no separate uplink signal design item, by choice : The majority position is to reuse the 6G PRACH preamble. The initial access work in AI 10.5.1.2 already covers that preamble. Designing a second uplink access signal would duplicate the work. One company went furthest and proposed postponing 10.6.2 altogether until PRACH is settled. The company argued that we still could not clearly distinguish an UL WUS from a PRACH preamble.What design discussion there is keeps getting deferred : The moderator tabled essentially the same proposal at all three meetings. The moderator asked only whether we need performance requirements beyond 6GR PRACH. Examples included the base station receiver architecture and robustness to uplink synchronization error. At RAN1#124 the proposal was marked as discussable only after the scenarios were resolved. At RAN1#124-bis it was closed, and the moderator agreed that use cases come first. At RAN1#125 it was tagged low priority, with a note that it might not be reached at that meeting either.The first two are tightly coupled : The payload we can support in the signal design sets the wake-up granularity. We then need to design the operation around that granularity. In the same way, the agreed PDCCH coverage target is what makes the 5G entry and exit conditions unnecessary in 6G.The third couples to other agenda items instead : The initial access study covers on-demand synchronization signals and on-demand SIB1. A separate item covers PRACH. For this reason, several companies asked for the scope of 10.6.2 to be clarified. Otherwise the conclusions may be duplicated or inconsistent.They are not moving at the same pace : Across the two downlink items, RAN1 reached agreements at every meeting. For uplink, RAN1 spent three meetings recording feasibility observations for each deployment scenario and repeatedly deferred signal design.
How does 6G WUS differ from 5G WUS?
To understand the motivation for 6G WUS, let's first look at the difficulties in 5G. NR ended up with three separate wake-up mechanisms. First, Rel-16 DCP is a DCI, so the UE must run PDCCH blind decoding to read it. That is exactly the operation the UE is trying to avoid. Second, Rel-17 PEI is also DCI-based and gives a coarse subgroup indication before a paging occasion. Third, Rel-18/19 LP-WUS uses sequences and is much cheaper to detect. However, it was built around a separate low-power receiver. That receiver was assumed to have a noise figure several dB worse than the main radio. As a result, its coverage target ended up at Msg3 PUSCH level. It also needed entry and exit conditions to handle the cell-edge case. It also needed its own always-on synchronization signal, LP-SS, which costs network energy on top of SSB. The result was three overlapping features, and none of them could be used everywhere in the cell. In 6G the agreed power model removes the underlying cause. The EE processing state is a low-power mode of the same receiver, with the same noise figure. With this assumption, we can target whole-cell coverage for the wake-up signal. That is why almost every contribution starts from the same premise. We should specify one 6G wake-up signal and use it in every RRC state.
Figure 3. The design space that 6G DL WUS is trying to occupy.
You can compare the two generations in the table below. Each 6G entry reflects either an agreement or the majority direction; none represents a settled specification.
|
Aspect |
5G: Rel-16 DCP (DCI with CRC scrambled by PS-RNTI), Rel-17 PEI (Paging Early Indication, DCI format 2_7), Rel-18/19 LP-WUS (Low-Power Wake-Up Signal) |
6G DL WUS |
|---|---|---|
|
|
Three features cover different states: DCP for connected mode, PEI for idle mode, and LP-WUS for idle and inactive modes. |
One design for every RRC state is the majority position. Some companies still argue for separate designs. |
|
|
DCP and PEI use DCI on PDCCH. LP-WUS is OOK, with an OFDM sequence overlaid on the ON chips, using Manchester coding. |
An OFDM-based sequence without OOK, so the sequence can use the whole symbol in 6G. |
|
|
DCP and PEI use the main radio. LP-WUS needs a separate low-power wake-up receiver. |
EE processing is a low-power mode of the same receiver. It runs inside a sleep state without triggering a transition out of that state. |
|
|
The low-power receiver may be at least 2 dB worse than the main radio, per the Rel-19 agreement. |
Equal to the 6GR UE noise figure. This removes the noise figure penalty. |
|
|
LP-WUS occupies about 11 PRB. |
5 MHz bandwidth, 1 or 2 Rx chains, and reception time up to one slot. |
|
|
LP-WUS targets Msg3, so it reaches only part of the cell. DCP and PEI reach the whole cell, but each costs a PDCCH blind decode. |
The same coverage as 6G PDCCH in the same band, and no blind decode. |
|
|
LP-WUS needs its own always-on synchronization signal, LP-SS, on top of SSB. |
No dedicated sync signal is proposed. The same correlator can process PSS/SSS. Whether WUS supports self-synchronization remains open. |
|
|
The model assigns the wake-up receiver an on-power from 0.01 to 30 relative units and a 10 ms ramp-up. |
10, 12 or 15 relative power, added on top of micro, light or other sleep, with a 2 ms ramp. |
|
|
Rel-19 LP-WUS carries about 5 bits. |
The expectation is more than 5 bits. Choosing how many more means balancing payload against coverage. |
|
|
RRM measurement stays in the main radio, so the main radio still wakes on the measurement schedule. |
Study of moving serving cell and neighbour cell RRM measurement into EE processing, and possibly RLM and BFD as well. |
|
|
DCP, PEI and LP-WUS coexist, and answer the same question three times. |
The aim is one Day-1 mechanism that replaces all three, rather than a later addition. |
Now that we've compared the two generations, let's look at why these changes matter. The first four remove constraints that shaped the 5G design; they do not add new capabilities. The last three are conditions that the result still has to meet.
Remove the OOK constraint : Rel-19 LP-WUS overlaid OFDM sequences on OOK ON-chips, with Manchester coding. This limited the payload to about 5 bits, and it wasted transmit energy on the OFF chips. 6G studies only OFDM-based sequences. The sequence can therefore use the full symbol and carry more information at the same coverage.Remove the noise figure penalty : The 6G EE processing state is defined with the same noise figure as the 6GR UE, 5 MHz bandwidth and 1 or 2 Rx chains. This removes the several-dB penalty that limited LP-WUS to part of the cell. We can therefore realistically target PDCCH-level coverage.Remove the dedicated synchronization signal : With an OFDM receiver, the same correlator that detects the wake-up sequence can process PSS/SSS. Most companies therefore propose dropping LP-SS and reusing the 6GR sync signals to save always-on network resources.Remove duplicated wake-up features : DCP, PEI and LP-WUS all tell the UE whether it needs to monitor control channels in the next window. Carrying three answers to one question into 6G would repeat the fragmentation that operators complained about in NR.Make wake-up a Day-1 feature : Several companies warn that adding wake-up later would again leave it constrained by decisions for other channels. If we design it from the start, we can coordinate the paging structure, sync signal periodicity and wake-up signal.Target the real energy bottleneck : When you examine idle-mode measurements, the dominant costs are sleep-to-active transitions and the synchronization and measurement that precede them. The paging occasion itself costs less. We need to address those costs too if the wake-up signal is to deliver the reported large gains.Keep the network side in view : A wake-up signal is an additional always-configured downlink transmission. Several companies say we need to meet two conditions to justify it. First, the resource overhead must stay at a fraction of a percent. Second, unused WUS resources must be reclaimable for scheduling.
What is EE processing, and why does it change the whole WUS discussion?
Let's look closely at EE processing, the 6G replacement for the low-power wake-up receiver concept. Its definition influences this agenda more than any other input. The UE enters EE processing during a sleep state and processes OFDM-based sequences for wake-up indication. Where applicable, it also processes them for synchronization and measurement. For FR1, including around 7 GHz, we assume 5 MHz bandwidth and 1 or 2 Rx chains. The original EE model considered up to 5 ppm residual CFO and 2 us timing offset. The RAN1 #126 same-carrier WUS evaluation baseline uses maximum errors of 2 ppm and 1 us. The noise figure equals that of the 6GR UE, and the reception time is up to one slot. The relative power values are 10, 12 and 15 units. Which value applies depends on whether the underlying sleep state is micro, light or deeper sleep. Entering or leaving EE processing from deep or ultra-deep sleep costs about 15 units of transition energy. The ramp time is about 2 ms. We can draw two conclusions from these assumptions. First, the noise figure is not degraded, so PDCCH-level coverage becomes a reasonable target. Second, EE processing consumes energy even though its power is low. We need to justify every activity, including measurement, against the wake-up rate.
Figure 4. EE processing power model. Monitoring occasions per cycle matter as much as power per occasion.
The noise figure assumption is the enabler : With no NF penalty, we can focus the coverage discussion on processing gain and resources. The receiver hardware no longer imposes that limitation. That is why the coverage target moved from Msg3 in 5G to PDCCH in 6G.The 5 MHz constraint shapes the sync design : In EE processing the UE can only open 5 MHz. Any signal the UE must receive in that state, including the sync signal for measurement, has to fit within that bandwidth. Two companies raise this as a direct requirement on the 6GR sync signal design.The baseline separates ordinary and larger errors : RAN1 #126 uses maximum errors of 1 microsecond and 2 ppm for same-carrier WUS evaluation. The study additionally addresses 2 microseconds and 5 ppm. Receiver search and processing time must be reported for each case.Transition cost limits how often you can wake : For ultra-deep sleep, the transition energy is tens of thousands of relative units. Therefore the number of monitoring occasions per cycle matters as much as the power per occasion. One company shows that adding monitoring occasions can turn a 47% power saving into a negative gain.EE processing is a state, not a receiver : EE processing is a mode of the main receiver, and not separate hardware. In 5G, entry and exit conditions existed to protect the low-power receiver at the cell edge. The widespread view for 6G is that we no longer need such features.Measurement is the second-order use : The same correlation machinery can measure PSS/SSS. That's why we need to discuss measurement offloading and signal design together.
The 5 MHz figure is a power-model reference, so wider WUS configurations need an explicit power assumption. A 10 MHz simulation cannot silently reuse the 5 MHz receiver energy. The same applies when a second Rx chain shortens the required monitoring duration.
Clock quality also affects the comparison. Keeping a faster clock active can reduce synchronization uncertainty while increasing sleep power. Allowing greater drift can save sleep energy but requires more correlation hypotheses or additional synchronization work.
Should 6G have one unified wake-up signal across all RRC states, or several specialised ones?
Most companies favour one unified DL WUS. It would replace DCP, PEI and LP-WUS, and it would work in idle, inactive and connected states. The feature lead for the sequence design agenda took this further at RAN1#125. The feature lead proposed studying one time or frequency domain waveform and one sequence family across all RRC states. The aim was to keep implementation complexity down. But when you read "unified", check which of two meanings the contribution intends. The first is unification of the physical signal. That is what the sequence design agenda cares about. The second is unification of the procedure, which is harder because idle and connected modes have different traffic statistics. In idle mode the paging arrival rate is around 1% or less per UE. In connected mode the arrival probability can exceed 10% per monitoring occasion. So the practical direction is to share the signal structure and configure it for each state, rather than force one procedure.
Unify the signal, configure the procedure : A common waveform, sequence family and synchronization source across states keeps UE and base station implementation simple. At the same time, the periodicity, the payload size and the mapping scheme can still differ per state.Do not carry PEI and DCP forward : If DL WUS reaches PDCCH coverage, the reason for keeping a DCI-based fallback disappears. Several companies explicitly propose not to specify a 5G PEI equivalent in addition to 6G WUS.Recognise the traffic asymmetry : Codepoint mapping is efficient in idle mode, where the network will likely page only one subgroup per occasion. In connected mode, the network may need to wake several UEs at once, making a bitmap more efficient. This is a mapping choice, not a different signal.Avoid excessive configurability : Several companies warn against repeating the 5G pattern of many options for one function. They argue that this fragments the device market and complicates network operation.Keep RRC state differences visible in coverage : Two companies observe a 4 to 6 dB antenna gain difference between idle-mode common PDCCH and connected-mode unicast PDCCH. Therefore the same signal design may still need different resource sizing per state.Beware of feature creep : The feature lead stressed the implementation risk at RAN1#125. The most successful WUS is the one that actually gets implemented. If we ask for too much, we may lose the feature altogether.
Should the same design serve eMBB and 1-Rx IoT devices?
Here, the feature lead withdrew a proposal because too many companies thought it was premature. To understand the difficulty, look at receive diversity: it dominates the link budget. Multiple sources report a 3.5 to 4.5 dB gain from a second receive antenna. One company translates this gain into resource requirements. A 6-bit subgroup indication needs about 12 OFDM symbols with 1 Rx to beat the reference PDCCH in the critical TDL-A channel. With 2 Rx, it needs only about 3 symbols. So if we size the design for 1-Rx devices, the network needs four times the resources required for 2-Rx devices. Some companies insist that IoT requirements must not be dropped. Another proposes waiting until the fundamental 6G IoT characteristics are agreed. In the meantime, that company would avoid separate IoT and non-IoT designs.
Scale rather than fork : The preferred direction is one signal with a scalable resource unit. The network would configure a 1-Rx device with more repetitions or a longer sequence while keeping the same waveform.Quantify the 1-Rx penalty explicitly : Since the second antenna is worth roughly 3.5-4.5 dB, the number of symbols needed for a given payload changes by a factor of about four. We should include this explicitly when we discuss payload size.Consider transmit diversity as compensation : Two companies propose transmit diversity, such as precoder cycling or large-delay CDD. It recovers part of the missing receive diversity for 1-Rx devices, and it needs no extra time resources. But another company asks us to consider two limitations. Large-delay CDD reduces the number of usable cyclic shifts, and frequency-domain precoder cycling destroys the sequence correlation. Therefore only small-delay CDD is suitable.Extended coverage is a separate question : Several companies argue that the WUS must follow the network. If the network supports deep-indoor extended coverage at 153 to 154 dB MCL, for example, WUS must also reach those devices. Otherwise the devices that need power saving most cannot use it.Do not let energy saving become energy spending : One company notes a side effect of heavy repetition. Repetition closes the link budget for the weakest device but damages the strongest device's energy efficiency. Therefore the repetition depth should be configurable per device, rather than fixed by the worst case.
The #126-bis contributions still disagree on a common IoT and eMBB procedure. One approach changes repetition and wake-up offset with UE capability. Another keeps a common offset to avoid maintaining several network schedules. Neither approach establishes mandatory device support or an agreed NTN format.
What coverage target should DL WUS aim for?
RAN1 agreed early, at RAN1#124, that DL WUS targets the same coverage as the 6G PDCCH in the same band. The study should consider missed detection rate and false alarm rate. It should also consider RRC state differences, use cases and the reference PDCCH configuration. RAN1 then agreed the reference configuration at RAN1#124-bis for link-level assessment of EE processing. It is aggregation level 8, with 4 Rx antennas for PDCCH. It uses the CORESET of TR 38.830 and a 40-bit payload excluding CRC. RAN1 #125 changed the reference to 4 Tx antennas at 3.5 GHz and 7 GHz; the original 2 Tx reference remains for the other case. At RAN1#125 the feature lead proposed a change for bands below 1 GHz, namely AL16 and 2 Rx. The feature lead argued that 4 Rx is not realistic for sub-GHz devices. Pay attention to this reference, because it determines the target SNR. One company computes about -8 dB for AL8 with 4 Rx, and another proposes -6.4 dB for the NR common PDCCH equivalent. We then size the sequence length, bandwidth and number of symbols to meet that target.
Use PDCCH, not Msg3, as the anchor : The 5G LP-WUS target of Msg3 PUSCH was a consequence of receiver limitations. With EE processing, we can reach a control-channel coverage target and make wake-up usable across the whole cell.The reference configuration is a measuring stick, not a design : Several companies stress that fixing AL8, 4 Rx and 40 bits is only for link-level comparison. Don't interpret it as a decision on the eventual 6G PDCCH design, which remains open.Do not front-run other agenda items : Two companies note that the 6G PDCCH and SSB designs are still immature. We will therefore need to revisit WUS coverage conclusions around 7 GHz after the initial access agenda settles.Keep the metric consistent : We compare coverage through required SNR at a given MDR and FAR. If companies use different FAR definitions, we cannot meaningfully compare their results. This is part of why the FAR and FDR definitions were tightened at RAN1#125.Consider what happens at 7 GHz : One company reports an MPL-based gap for ZC-based WUS between around 7 GHz and 5G mid-band. The reported gap reaches 19 to 22 dB. In addition, another company reports a larger WUS-to-PDCCH performance gap at 7 GHz than at 3.5 GHz or 700 MHz.Remember the second detection stage : Two companies argue that the WUS missed detection rate must be lower than the BLER of the channel it triggers. The reason is that the two failures multiply. Therefore the WUS target becomes tighter than the PDCCH target, rather than equal to it.
Should idle and connected mode have different coverage targets?
Let's compare the beamforming in the two cases. In idle mode, the network transmits common PDCCH on wide beams to cover the whole cell. Unicast PDCCH in connected mode benefits from UE-specific beamforming instead. One company measures this difference as roughly 4 dB of transmit antenna gain, and another reports a similar 4 to 6 dB effect. Both propose aligning UE-specific WUS with PDCCH in the UE-specific search space. They would align group WUS with PDCCH in the common search space. A third company makes the same split. It targets the paging PDCCH for idle mode, and a unicast PDCCH with 48 RBs, 50-bit DCI and 4 Rx for connected mode. However, the feature lead offers a counter-argument. If DL WUS and its associated PDCCH use the same precoder, we no longer need to distinguish the two search space types.
Same design, different resource sizing : Two companies argue that even if the performance target differs, the signal design should stay common and only the configured resources should change.Beamforming is the real variable : The difference between the two cases is mostly antenna gain, not waveform. If the network can beamform WUS like the PDCCH it triggers, the gap closes without a design change.Connected mode can afford a different reliability point : One company proposes 0.1% MDR with a relaxed 10% FAR for idle mode. The company points out that a missed page costs a whole paging cycle. For connected mode, the same company proposes 1% MDR with 1 to 10% FAR. Another company makes a similar state-dependent proposal.Watch out for functional coupling : One company asks us to consider WUS triggers beyond plain monitoring, such as an uplink transmission or a parameter change. These uses change the target. In that case, the acceptable false alarm rate drops by orders of magnitude, towards PDCCH CRC levels.A single conservative target simplifies evaluation : Several companies accept using the more demanding of the two states for link-level simulation. At the same time, they keep the system-level overhead analysis separate. This is the compromise reflected in the agreed reference configuration.
How big is the coverage gap in practice?
Let's use the reported results to estimate how much coverage gain we need. Against the agreed reference PDCCH, a plain single-symbol sequence carrying a handful of bits does not reach the target. One company measures about a 7 dB gap without repetition, and about 5 dB with one repetition. Another reports about 4.5 dB, and a third reports 7 to 8.5 dB in mid-band. A fourth company instead reports the WUS duration needed to reach 1% MDR at 1% FAR. That duration is roughly 5, 14 and 40 OFDM symbols at -3, -6 and -9 dB SNR respectively. If the MDR target tightens to 0.5%, it grows to 6, 18 and 54 symbols. A fifth company reports results per band. At 700 MHz, only a 2-Rx configuration with at least 24 PRBs reaches comparable coverage for a 5-bit payload in a single symbol. At 3.5 GHz and 7 GHz, none of the single-symbol configurations it evaluated reached the target. These results suggest we can reach the target, but we need techniques that provide several dB of gain. Choosing a sequence alone will not close the gap.
The gap is a few dB, not tens of dB, in mid-band : Roughly 4.5 to 8 dB is the range companies report against the reference PDCCH. We can recover that gap through repetition, bandwidth or a second receive antenna.The 7 GHz case is a different order of problem : One company reports a band-to-band gap of 19 to 22 dB. This is a deployment issue, and it is shared with every other 6G channel at that frequency. So we cannot solve it through WUS design alone.Payload costs coverage measurably : One company reports about 1.5 dB extra required SNR going from 1 bit to 6 bits, and another reports similar behaviour. You can use this result to connect payload size directly to the coverage cost.Channel model choice matters : TDL-C with 300 ns is the agreed baseline. But one company argues that TDL-A with 30 ns delay spread is critical because low delay spread limits frequency diversity. Results differ by several dB between the two models.Impairments eat the margin : One company reports that a 2 us timing error is tolerable. However, it also reports that a 1 ppm frequency error already degrades performance severely at higher carrier frequencies. Another company measures about a 2.5 dB coverage difference at 7 GHz between 1 ppm and 2 ppm residual frequency error.
Which techniques should be used to close the coverage gap?
The feature lead's RAN1#125 proposal captures the consensus list. It asks RAN1 to study targets and solutions for scalable DL WUS coverage, based on a baseline resource unit. The proposal lists time domain expansion through repetition or sequence extension, plus frequency domain expansion or hopping. It also lists spatial diversity in transmit and receive, and power boosting if feasible. We should also consider UE energy consumption and complexity. Let's compare these techniques by UE energy cost, because their costs differ. Two companies observe that increasing bandwidth is more energy-efficient than increasing duration. They explain that UE power scales sub-linearly with bandwidth but linearly with time. Another company quantifies the two effects. Doubling the bandwidth is worth about 4 dB, while doubling the duration is worth about 2 dB. So we should consider wider bandwidth first, then repetition when we cannot use more bandwidth.
Figure 5. Coverage enhancement options. Bandwidth and a second receive antenna give the most gain per unit of UE energy. Repetition gives the most absolute gain but costs time and latency.
Prefer bandwidth over duration : Doubled bandwidth is worth about 4 dB, while doubled duration is worth about 2 dB. Bandwidth also carries a smaller UE energy penalty. So bandwidth expansion gives us a more energy-efficient option. Several companies propose supporting 10 MHz or even 20 MHz configurations, rather than the fixed 11 PRBs of Rel-19.Sequence extension beats plain repetition : Two companies compare two ways of using two symbols. Mapping one longer sequence across them gives about 1.1 dB more than repeating a shorter sequence twice. This is because the correlation gain remains coherent across the whole sequence.Frequency hopping is cheap diversity : One company reports 0.7 to 1.2 dB for hopping at 11 PRBs. Under the same overhead, it reports 1.3 to 3.2 dB for a 22-PRB allocation. In addition, another company proposes three hopping variants, namely intra-slot, inter-slot and inter-occasion.Receive diversity is the largest single step : A second Rx chain is worth 3.5 to 4.5 dB. It also shortens the required WUS duration by roughly a factor of three to four. So the UE can consume less total energy even though its instantaneous power increases.Transmit diversity needs care with sequences : Precoder cycling in the frequency domain breaks the correlation property that the detector relies on. This leaves two viable variants: time-domain precoder cycling across repetitions and small-delay CDD. One company reports about 1.4 to 1.6 dB for small-delay CDD. For time-domain precoder cycling with four repetitions, it reports about 2.7 dB.Channel coding is probably not the answer : Several companies report that Reed-Muller style coding does not outperform repetition at the short block lengths used here. Companies also broadly agree that we should not carry Manchester coding over from Rel-19.Watch the latency cost : One company points out that every repetition adds wake-up latency and resource overhead. We therefore need to choose the coverage technique and target latency together.
Should basic and extended coverage both be in scope?
We need to study both basic and extended coverage. RAN1 #126 agreed this study scope while also fixing the basic reference SNR and impairment assumptions. Extended-coverage targets remain open. As we work on sequence and repetition design, we can no longer assume a single coverage target.
With one coverage target, we could use one sequence length and repetition scheme for every case. With two targets, we need a scalable design. A receiver that meets basic coverage in one detection attempt must also reach the extended target. It does this by accumulating more energy over more occasions.
For basic coverage, we want the DL WUS wake-up decision wherever an ordinary UE can already receive paging. For extended coverage, we target deep-indoor and low-power devices. These devices benefit most from energy saving but face the weakest link budgets. We need to distinguish these requirements because device class matters as much as geometry for extended coverage.
The scope is now fixed, the target is not : Agreeing to study both does not set either value. We can no longer design for one target and leave the other until later.Extension is paid for in occupancy : To reach the extended target, we need repetitions, which consume network resources and add latency. This works against the resource and latency reductions we want from WUS.The gap analysis now has two answers : We must size the techniques discussed above against both targets. A technique sufficient for basic coverage may not scale to the extended one.
What SNR target follows from matching PDCCH coverage?
RAN1 #126 agreed -8.1 dB SNR at 1% BLER of the reference PDCCH as the starting point for DL WUS design. That gives the basic comparison a common operating point. Extended-coverage targets still need further discussion. The reference includes a specific PDCCH configuration, so changing its antenna count or payload would also change the basis for the comparison.
We cannot simulate a coverage target stated only as a comparison; we need an SNR target. That operating SNR determines our choices for sequence length, bandwidth, repetition count and detector. Every design question below depends on fixing this number.
If we widen the allocation from 5 MHz to 10 MHz, we gain roughly 4 dB. That closes a large part of the coverage gap. The gain comes from collecting more energy in the same time, without changing the sequence.
The target is a design input, not an outcome : If we fix SNR early, we can compare sequence and repetition proposals against one target. Otherwise, each proposal uses its own assumption.Basic and extended coverage need two numbers : The agreement above puts both in scope, so a single SNR target does not close the question. For extended coverage, the receiver must work below this SNR, so we need additional margin.
How should the #126-bis coverage results be compared?
Coverage results need the complete receiver and resource configuration beside them. At -8.1 dB, the required duration changes with bandwidth, Rx count, detector and residual CFO. A single reported symbol count cannot serve every configuration. Results also need the transmit-power convention and channel model, because equal time-frequency occupancy does not guarantee equal energy or diversity.
For example, 10 MHz instead of 5 MHz gives about 3.3 to 3.8 dB in one evaluation. A second Rx antenna gives about 3.5 to 5 dB. These are conditional results, so adding the gains arithmetically would overstate the combined improvement.
Extended coverage remains a separate design question. Proposals include about -15 dB for a 153 dB MaxCL case, or about -14 dB for a 7 GHz group-common WUS. A UE-specific beamforming assumption gives a different target. None of those proposed values becomes a universal requirement.
Channel and detector choices can reverse the preferred extension method. A longer sequence may collect more coherent energy, but larger normalized CFO can remove that gain. Comparisons therefore need equal transmitted energy, equal payload and the same detection threshold.
Should the DL WUS sequence be defined in the time domain or the frequency domain?
Now let's look at the sharpest disagreement in the agenda: where to define the sequence. The feature lead described it as a topic with very little room for compromise. A time-domain definition means that the sequence exists before transform precoding. In effect, this is a DFT-s-OFDM style generation. With a frequency-domain definition, the transmitter maps the sequence directly onto subcarriers. This is consistent with the CP-OFDM baseline used for everything else in the 6G downlink. RAN1#124-bis agreed to study both options against a list of aspects. The list covers link-level performance, base station implementation complexity and UE detection complexity. It also covers frequency-domain and time-domain receiver processing. PAPR and its relevance, and multiplexing and coexistence, are also on the list. The camps are stable across meetings, with roughly a dozen companies on each side. Most chipset and device vendors favour the time-domain definition. Most infrastructure vendors, together with several device vendors, favour the frequency-domain definition. But both sides report almost identical link-level performance. We therefore need to compare implementation and multiplexing to choose between them.
Figure 6. Why the time-domain versus frequency-domain argument is about implementation, not about link performance.
The UE-side argument for time domain : If the sequence is defined in the time domain, the receiver can correlate directly on samples. It can then leave the FFT off, even though that block contributes the most to the EE processing budget.The network-side argument for frequency domain : Generating the sequence in the frequency domain needs no DFT pre-processing block. It also reuses the same chain as every other downlink signal. Furthermore, it allows arbitrary sequence lengths, rather than lengths restricted to products of small primes.Multi-symbol behaviour favours time domain : Two companies examine what happens when the transmitter maps one sequence across several symbols. In that case, a frequency-domain definition breaks the correlation property because each segment goes through its own IFFT. This produces phase discontinuities and secondary correlation peaks.Multiplexing favours frequency domain : One company notes that generating everything in the same domain simplifies frequency-multiplexing. This applies to multiplexing several WUS signals together or a WUS with other transmissions. The same company also notes that sub-symbol sequence segmentation is incompatible with frequency-domain receiver processing.ZC is domain-agnostic : Both sides acknowledge that the DFT of a prime-length ZC sequence is another ZC sequence. So for ZC specifically, we change only the description when we change the definition domain; the properties remain the same.Base station complexity is contested, not measured : One company raises the hardware, timing and memory impacts of DFT pre-processing. But two others argue that pre-computing and storing frequency responses makes the impact marginal. A fourth company simply states that BS complexity is the same either way.The compromise on the table : The feature lead's RAN1#125 proposal is that the DL WUS design shall allow either receiver processing domain. That is, detection may use frequency-domain or time-domain processing. The feature lead therefore focuses on what the receiver design must allow, leaving the definition-domain disagreement open.
Does the definition domain force the receiver processing domain?
You don't necessarily need to use the same domain for sequence definition and detection. One company explains the distinction using 5G PSS. In 5G, PSS is generated in the frequency domain. Even so, it is routinely detected by time-domain correlation. So we can make these two choices separately. Another company reports that BLER performance for a WUS is similar in both detection domains. The company also compares DFT-s-OFDM and CP-OFDM with time-domain detection. Under that condition, it reports no UE complexity difference. However, a third company disagrees on this specific point. It reports severe degradation if a frequency-domain-generated WUS is detected directly in the time domain. To understand the disagreement, check how many sequences the UE must test and what residual CFO each company assumes.
Separate the two decisions explicitly : We specify the definition domain, while the UE implementation determines the processing domain. If we combine these decisions, we overlook the room for compromise.The degradation claim depends on assumptions : Some reports show severe loss for time-domain detection of frequency-defined sequences. However, they generally assume larger residual CFO and frequency-selective channels. Under those assumptions, we can no longer treat the two domains as equivalent.Sliding-window detection closes part of the gap : One company finds that a sliding correlator improves time-domain accuracy at the cost of extra complexity. Therefore time-domain processing of frequency-defined sequences is more viable than a single-shot correlator suggests.Keep both options open in the specification : A design that allows either receiver implementation serves both sides. Low-tier devices can avoid the FFT. Other devices can use frequency-domain processing where it is cheaper. This is what the final feature lead proposal aims at.
How much does PAPR really matter for DL WUS?
PAPR matters less here than you might first expect. The argument for lower PAPR has weakened over the three meetings, although the theoretical case remains strong. One company measures at least 4 dB lower PAPR for a 24-RB DFT-s-OFDM WUS than for CP-OFDM. It also measures about 1.2 dB improvement when the WUS bandwidth grows from 12 to 24 RBs. Another company reports about 8.2 dB PAPR at the 10^-3 point for a fractional-DFT base layer, which is roughly 3 dB below CP-OFDM. But several companies ask us to check the multiplexing conditions. The network may frequency-multiplex WUS with other CP-OFDM channels in the same symbol. The composite waveform then takes the higher PAPR, removing the advantage. One summary is that the PAPR relevance for the sequence definition question is low. Another calls the benefit negligible under realistic multiplexing.
PAPR gain is conditional on exclusive symbols : The low-PAPR advantage only survives if the WUS has the symbol to itself. But we also want to multiplex WUS efficiently with other transmissions, which conflicts with that condition.It matters most for network energy, not coverage : Lower PAPR means less power amplifier back-off. This supports network energy saving rather than link budget improvement, so we need to weigh it against resource overhead.Report it consistently or not at all : One company proposes a common reporting method. Companies should report PAPR as a CCDF at 10^-3 and benchmark it against CP-OFDM and DFT-s-OFDM at the same bandwidth. They should report the standalone and composite signals separately. Only in this way do the numbers become comparable.Consider EVM and modulation restrictions : One company proposes asking RAN4 about coexistence between a DFT-s-OFDM based WUS and CP-OFDM signals. Would this impose modulation restrictions or affect EVM? This is a real specification consequence, and not a simulation artefact.
The #126-bis results do not establish one universal PAPR benefit. One evaluation reports at least 4.2 dB lower PAPR for a 24-RB DFT-s-OFDM WUS even when multiplexed with data. Other contributions expect little composite-waveform benefit. Allocation, relative power and the measured waveform must accompany the comparison.
Which sequence family should 6G DL WUS use?
Let's start with the three families in the feature lead's RAN1#125 proposal: Zadoff-Chu, m-sequences and Gold sequences. The proposal calls for evaluating link-level performance, including time and frequency errors, and the maximum sequence count for carrying information. The criteria also cover sequence lengths and time-frequency mapping. Further criteria include UE and base station complexity and energy consumption, overhead, and coexistence with other 6GR signals. Zadoff-Chu has the widest support. The reasons are its constant amplitude and zero autocorrelation properties, its low PAPR, and the direct reuse of NR design. Its known weakness is the delay-Doppler coupling. Under frequency offset the correlation peak shifts. This consumes cyclic shifts, and it also creates ambiguity between timing error and frequency error. Companies propose m-sequences and Gold sequences as complements because their correlation peak stays in place under frequency offset. The cost is higher cross-correlation. If they are mapped directly in the frequency domain, the PAPR is worse as well. Several companies report that the three families perform comparably when only a small number of sequences is used. So we will probably need to choose based on capacity and robustness with larger sequence pools, rather than raw detection performance.
ZC as the baseline : A large majority of companies support ZC, mainly for reuse and its CAZAC properties.m-sequence and Gold as CFO-robust alternatives : One observation explains the benefit: unlike ZC, a Gold sequence keeps its correlation peak at the same location despite frequency inaccuracy. Therefore the timing-frequency ambiguity at the correlator output disappears.Performance is similar at small pool sizes : One company reports similar detection for ZC, m and Gold with about four sequences per symbol. Two others report comparable performance. We therefore see differences only with larger sequence pools or stronger impairments.Frequency-domain mapping penalises binary sequences : m and Gold sequences have constant amplitude in their own domain. However, several companies note that mapping them directly onto subcarriers raises the time-domain PAPR. If we choose these families, this gives us a reason to use DFT spreading.Prime lengths and PRB alignment : One company recommends the prime lengths 131 and 257. Length 131 maps cleanly onto 11 PRBs, and length 257 onto about 22 PRBs. The same company also examines impairments. Under 5 ppm CFO and 2 us timing offset, the usable root pool shrinks substantially at 131. At length 257, the usable root pool stays above 96%.Do not standardise on novelty : The feature lead does not reject a single company's sequence simply because it is absent from the study list. But the sequence must show a decisive advantage before it belongs in the baseline.
The #126-bis individual results continue to disagree on ZC and Gold. One evaluation finds similar performance up to 256 candidates and a Gold advantage beyond that. Others favour ZC under matched resources. Root selection, cyclic-shift spacing, threshold calibration and neighbor interference explain part of this spread.
The current comparison is therefore between sequence families and complete detectors. A large candidate pool needs FDR assessment across non-target sequences, including difficult pairs. Noise-only FAR and a favorable MDR curve do not establish isolation between UE groups.
Is Zadoff-Chu capacity enough, or does 6G need new sequence types?
Before we judge sequence capacity, we need to decide what the wake-up indication should address. If it addresses subgroups, then a few dozen to a few hundred sequences suffice, and ZC is more than adequate. If it addresses individual UEs, the requirement changes by orders of magnitude. One company strongly supports per-UE indication. It argues that a real deployment would need 10^3 to 10^4 sequences per wake-up occasion for per-UE indication. It also argues that ZC cannot provide this. Therefore it proposes an extended ZC, based on a degree-3 polynomial phase sequence. Its proposed design offers roughly a hundredfold capacity increase and better Doppler resilience. But another company disagrees. It recommends rejecting extended ZC, because the gain under residual CFO is typically below 0.5 dB for higher complexity. We also have other proposals to compare. One is a quaternary S(1) sequence with a much larger set than binary Gold sequences. Another is a DFT-spread reduced-order MLS, reported to outperform other candidates by at least 3 dB at 2 ppm CFO. A third is a frequency-domain OOK, which is less a sequence family than a detection strategy.
Capacity requirement follows the addressing decision : Before choosing a sequence family, RAN1 needs to decide whether wake-up targets a subgroup or an individual UE. The two options lead to completely different sequence pool sizes.CFO robustness is the second axis : One set of results assumes 5 ppm. Under that assumption, adding repetitions or receive antennas cannot compensate for a sequence that is not intrinsically CFO-robust. Those techniques only add SNR.FD-OOK is a complexity argument : One proposal encodes information in the position of energy in the frequency domain, rather than in a correlation peak. Under integer CFO, this turns the two-dimensional time-frequency search into a one-dimensional search. In that analysis, it saves about 97% of the detection complexity.Product codes reduce hypotheses : A vertical and horizontal coding proposal encodes bits independently in frequency and in time. Detection then separates into two smaller problems. This gives us another way to increase payload while limiting the number of correlations.Sequence count trades against detection : Several companies identify the same cost. Increasing the number of candidate sequences degrades detection performance, and it raises UE power. So even if the sequence family supports more capacity, we still need to account for its detection cost.
How should sequences map onto OFDM symbols?
Let's use M, the number of sequences per OFDM symbol, to compare the three mapping options. With M below one, a single longer sequence spans several symbols. This maximises processing gain, and several companies favour it for coverage. With M equal to one, one sequence occupies one symbol. This is the common baseline. With M above one, several shorter sequences fit inside a symbol. One company favours this because it avoids exponential codebook growth with payload and suits low-complexity receivers. Two other companies evaluate it with M of 2 or 4, following the Rel-19 chip structure. But another company objects to M above one for a specific implementation reason. Intra-symbol segmentation is incompatible with frequency-domain receiver processing. It also offers little benefit when the WUS spans multiple symbols anyway.
Longer sequences buy coverage : A length-264 sequence across two symbols gives about 1.1 dB more gain than a length-132 sequence with two repetitions. This is the cleanest evidence for the M below one case.Shorter sequences buy flexibility : With several sequences per symbol, we can grow the payload linearly without an exponentially larger sequence pool. This keeps the number of correlations bounded.Slot boundaries are a practical constraint : Several companies propose keeping DL WUS within one slot to simplify scheduling, while allowing a configurable starting symbol.Multi-symbol mapping interacts with the definition domain : Here you can see a practical consequence of the definition-domain choice. Segmented frequency-domain mapping loses the correlation property that the whole design relies on.Repetition should stay configurable : Several companies converge on the same mechanism. It is a baseline resource unit, plus a configurable repetition factor, for example 1, 2, 4 or 8. We can use this to balance coverage against latency and overhead.
RAN1 #126-bis recorded support for one WUS sequence in one OFDM-symbol duration. Reducing connected-mode overhead remains open. This agreement does not select the definition domain, a final sequence length, or every proposed sub-symbol and multi-symbol construction.
Repetition and segmentation need separate treatment. Repetition sends the same information and permits combining or early stopping. Segmentation sends different payload portions, so the wake-up decision needs a rule for missing or inconsistent segments. Its error probability includes every required segment.
How many information bits should DL WUS carry, and how should they be mapped?
Companies agree that the Rel-19 limit of 5 bits is too small, but they disagree on the replacement. The feature lead summarised the views as ranging from 5 to 20 bits, with a logarithmic mean of about 10. Later, the feature lead observed that most proposals cluster around 10 plus or minus 2 bits, once auxiliary functions are included. To assess these proposals, let's look at one company's saturation argument. Beyond roughly 6 bits, or 64 subgroups, both the further false wake-up reduction and the resulting power saving become negligible. Under this argument, we gain very little from a payload above about 8 bits. Another company reaches a similar conclusion from a different direction. It proposes at most 32 subgroups for idle mode, because the benefit beyond that is marginal when the false alarm rate is 1%. For connected mode it allows up to 64, because the arrival probability is much higher there. A third company proposes 6 bits, that is 63 subgroups plus an all-UE codepoint. The company sees this as a unified baseline that fits a single-antenna budget. At the other end of the range, one company wants enough capacity for per-UE indication. Another targets 12 to 19 bits per symbol, using a multi-layer structure.
Size the payload from the grouping benefit : The purpose of extra bits is to reduce false wake-ups. Once false alarms dominate the false wake-up rate, reducing group size with more bits no longer helps.Every bit costs coverage and complexity : One set of results shows roughly 1.5 dB extra required SNR from 1 bit to 6 bits. The larger payload also adds blind hypotheses and raises baseband power. Two companies warn against unbounded payload for this reason.Per-UE indication changes the whole design : One company argues that per-UE wake-up removes the paging PDCCH step entirely. The UE can then go straight to RACH. We would then have a different procedure, not just a bigger payload. Three other companies make the same observation.Spectral efficiency is a legitimate objection : Two companies point out that a sequence-based signal needs far more resource elements per information bit than PDCCH. Therefore, at some payload, the sequence approach loses to a DCI-based one. A third company puts that crossover at around 10 bits.Detection type matters as much as payload : Two companies distinguish full blind detection from configured detection. With full blind detection, the UE tests every possible sequence; with configured detection, it tests only its assigned sequences. The former costs significantly more power and requires higher SNR for the same payload.
Codepoint or bitmap?
Let's start with codepoint mapping, which assigns one sequence per subgroup and is the approach in Rel-19 LP-WUS. Bitmap mapping assigns one bit per subgroup, allowing the network to wake several subgroups at once. To choose between them, we need the traffic arrival probability. One analysis shows clearly how these arrival statistics determine the optimal scheme. Codepoints are more efficient in idle mode, where the per-PO paging rate is around 1% or less. Bitmaps are more efficient in connected mode, where arrival rates above 10% per monitoring occasion are realistic. For this reason, two companies advocate studying bitmaps for connected mode. Three others prefer codepoints for their simplicity. There is also a third option, called segmented mapping. It splits a larger payload across several sequences that the transmitter sends one after another. Several companies propose it as a way to keep the number of hypotheses per detection manageable.
Codepoints suit rare events : Suppose the network is likely to indicate at most one subgroup per occasion. A codepoint plus an all-subgroup fallback codepoint then gives the most resource-efficient encoding.Bitmaps suit frequent events : If several groups likely need to wake together, a codepoint scheme either wakes everyone or needs several occasions. Both approaches waste energy.Segmentation is a complexity control : If we split bits across sequences, we replace one large hypothesis set with several small ones. We pay through detection time and error propagation between segments.The schemes converge at the extremes : One observation describes a continuum. As the number of subgroup combinations grows, a codepoint scheme becomes a bitmap scheme. As the number of segments decreases, a bitmap scheme becomes a codepoint scheme. So we need to choose where to operate between those extremes.Keep the provisioning method common if possible : One company proposes a single information provisioning method across RRC states. The company wants to avoid two detection procedures in the same device. This is the counter-argument to state-specific optimisation.
What should the extra bits actually be used for?
Once we have more payload than subgrouping needs, we can consider a long list of candidate functions. The first is PDCCH blind decoding reduction. Here the WUS indicates the aggregation level, the CCE locations or the candidate subset, so the UE can search less after waking. The second is short message indication for SI update, ETWS and CMAS. In that case the UE does not need to decode the paging DCI for a common notification. The third is TRS or on-demand reference signal availability, so the UE can refine synchronization before demodulating. The fourth is SCell dormancy or fast carrier activation. The fifth is cell DTX/DRX or PRACH resource adaptation. But one company, supported by two others, argues for restricting the content. The WUS should carry only necessary information. They argue against including rare events such as SI update notifications. Carrying this information on every occasion costs coverage even when those events do not occur.
Wake-up first, everything else conditional : Two companies propose prioritising the wake-up indication. They would add functions only if those functions do not compromise robustness or false alarm behaviour.Blind decoding reduction has the strongest case : PDCCH blind decoding dominates connected-mode power. Telling the UE where to look therefore directly helps reduce that cost. It is also the single most widely proposed addition to the payload.Rare events are a poor fit : The argument here is that WUS incurs the cost on every transmission. We should therefore leave rare-event information out, because its expected benefit per bit is tiny.Synchronization assistance is attractive but overlaps other agendas : Indicating TRS availability, or triggering an on-demand reference signal, can remove the early wake-up penalty. However, it depends on decisions taken in the initial access and DL control agenda items.Decoding differentiation may be needed : The feature lead raised one further question. Should the UE use one hypothesis to decode wake-up information, but multiple hypotheses for other information? The aim is to prevent other payload content from reducing wake-up bit reliability.
For SI modification and ETWS/CMAS, proposals separate cell-common monitoring from subgroup monitoring. The benefit is avoiding paging PDCCH reception just to read a short message. The cost is extra monitoring or false notification. SI acquisition and emergency notification have different consequences and need separate evaluation.
For reference signals, implicit association avoids new payload bits: a WUS transmission is associated with a configured additional signal before paging. Explicit indication adds flexibility when that signal is unnecessary. Both approaches depend on the eventual synchronization and paging design.
How many sequence candidates does one UE actually test?
Two counts describe different costs. The cell has a pool of transmittable sequences, while a UE has sequences that target it. A larger cell pool does not automatically require every UE to correlate against the entire pool. The detector can nevertheless use non-target sequences for rejection or threshold estimation, so both counts and processing behavior need reporting.
RAN1 #126-bis recorded 32, 64, 128 or 256 as alternatives for the maximum cell pool per sequence resource. Down-selection remains pending. The recorded maximum targeting one UE is eight. The same cell candidate pool is reused across sequence resources.
Detector design still matters. Target-only correlation can keep work proportional to the assigned set. A full-search CFAR detector may process other candidates to estimate or reject competing signals. Candidate counts alone therefore do not establish receiver energy.
One evaluation increases the UE target set from one to sixteen and raises candidate/synchronization hypotheses from 153 to 2448. Its cell-pool increase alone does not change that workload. Another receiver uses full search and therefore ties complexity to the transmittable pool. Both results depend on their detector assumptions.
The recorded payload assumptions for link-level simulation are 6, 8 and 12 bits, with other values allowed. These are total information assumptions for grouping and any additional content. They do not mean that each sequence resource independently delivers twelve bits with eight detection hypotheses.
How should the UE synchronize before detecting DL WUS?
Let's start with the principle RAN1 agreed at RAN1#124-bis. RAN1 should study at least the 6GR sync signals for UE synchronization before DL WUS reception. RAN1 would study an additional synchronization method only if those signals prove insufficient. This is a deliberate reversal of the 5G approach, where LP-SS was introduced up front. Well over a dozen companies believe that reusing SSB or its PSS/SSS components is sufficient. They also argue that a second always-on signal would undo the network energy saving that WUS is supposed to deliver. A handful of companies hold the minority position. They believe a dedicated EE-mode synchronization signal may still be needed. Their main reason is to reach the lower residual errors that make sequence detection cheap. The practical advice here is to wait until the SSB periodicity and structure are fixed. We should then discuss whether we need an additional synchronization signal, because the answer depends entirely on those decisions.
Reuse is the default : Under the agreed approach, we consider an LP-SS equivalent only if the 6GR sync signals prove insufficient.Bandwidth compatibility is a hard requirement : If EE processing can only open 5 MHz, the sync signal used in that state must fit. One company notes that the Rel-19 11-PRB LP-WUS bandwidth was actually narrower than PSS/SSS, which would have prevented measurement.The gap between SSB and WUS is the real variable : With a 160 ms SSB periodicity, the accumulated drift between the last sync and the WUS occasion determines the impairment. One company calculates up to 2.8 us of timing error under that assumption, while another argues the error stays within 1 us.Accuracy differs between main radio and EE processing : One company notes that fewer receive chains change SSB detection accuracy. The main radio and the low-power path therefore achieve different synchronization accuracy. Therefore a single assumption for both is optimistic.Sparse SSB forces early wake-up : Two companies point out that relying on a distant SSB forces the UE to wake early and stay awake. This erodes exactly the deep sleep benefit that WUS is meant to create.
What residual timing and frequency error should be assumed?
For same-carrier DL WUS evaluations in FR1 and around 7 GHz, RAN1 #126 assumes maximum timing error of 1 us and frequency error of 2 ppm. Actual errors are uniformly distributed within those limits. The study additionally considers solutions for 2 us and 5 ppm, including processing-timeline relaxation. Earlier discussions challenged the original 2 microseconds and 5 ppm limits as pessimistic. Their point is that the receiver has just processed SSB. One company proposes 2 ppm and 1 us right before WUS reception. Another goes further, with about 0.6 ppm and 0.6 us. The company bases its reasoning on NR performance. There, the frequency accuracy after SSS detection is typically better than 0.5 ppm, and after PBCH decoding better than 0.1 ppm. It then adds the 0.05 ppm per second oscillator drift model of TR 38.869. A third company distinguishes the initial and calibrated states. It distinguishes an initial synchronization error of 2 us and 5 ppm from a calibrated error of 1 us and 2 ppm. At RAN1#125 the feature lead responded in a different way. Instead of arguing about a single number, it defined two alternatives explicitly. In Alt 1, we expect the UE to process the preceding SSB. This uses either an accuracy-plus-drift model, or a flat 1 us and 1 ppm. In Alt 2, we do not expect the UE to process the preceding SSB. The values are then 2 us and 5 ppm.
Make the synchronization behaviour explicit : The impairment number follows from what we assume the UE does. If we state whether it always processes the preceding SSB, we remove most of the disagreement.The drift model matters more than the initial error : With drift at 0.05 ppm per second, long gaps between SSBs can make accumulated error dominate the initial accuracy. That is why the SSB periodicity discussion feeds directly into this one.Model the error as a distribution : The feature lead proposed modelling timing and frequency errors as uniform variables. These variables use the worst-case residual values as limits, so the simulation does not always assume the maximum error.Accuracy targets differ by function : One company proposes a target for RRM measurement. For this function, the company says we should assume the UE achieves no worse than 2 ppm. RSRP accuracy degrades sharply beyond that value, even if wake-up detection could tolerate a larger error.State the power cost of better synchronization : The UE can achieve lower residual error, but it must spend energy on SSB processing. The agreement allows lower values with corresponding power assumptions, helping us compare the options fairly.
Is integer CFO at 7 GHz a real problem?
Yes. Let's calculate the offset to see why this becomes a new technical problem. At 7 GHz, a 5 ppm residual frequency error is 35 kHz. That exceeds the 30 kHz subcarrier spacing, so the correlator cannot treat it as a fractional rotation. It is an integer subcarrier shift, and it changes which subcarriers the sequence occupies. Several companies raise this problem. For a correlation-based detector, the consequence is a joint search over timing and frequency hypotheses. This two-dimensional search has complexity proportional to the number of CFO hypotheses times the FFT cost. A frequency-domain energy detector needs only a one-dimensional search. One company adds a further effect. At 30 kHz SCS, a 5 ppm offset at 7 GHz can drive the effective signal-to-interference ratio to 0 dB through inter-carrier interference. The receiver can mitigate this only by first correcting the offset in the time domain.
The problem is created by the impairment assumption : If residual error is 1 to 2 ppm rather than 5 ppm, the offset stays below one subcarrier at 7 GHz. The integer CFO problem then largely disappears. This links the sequence design debate directly to the synchronization debate.Two-dimensional search is expensive : If the UE tests every timing and frequency hypothesis combination, its correlation load multiplies. That is the cost we want to avoid in EE processing.Energy detection sidesteps phase : Frequency-domain OOK avoids the phase problem: unknown phase from timing uncertainty does not affect accumulated energy. Therefore the search collapses to one dimension.Report complexity, not just performance : Several companies propose that detection complexity under integer CFO becomes a mandatory reporting item. The report should include multiply-accumulate counts, FFT sizes and search dimensionality. Otherwise, we may credit a design for good BLER without accounting for its search cost.Sequence choice can help : Sequences with a correlation peak position invariant to frequency offset reduce the number of frequency hypotheses the UE must test. Zero-padded and interpolated constructions also reduce that count.
Should DL WUS carry its own synchronization function?
Let's distinguish two ways WUS could support synchronization. The first is self-synchronization. Here the UE can detect WUS without prior SSB assistance, just as it can detect PSS. One company argues this is feasible because the requirement resembles PSS: a few bits under wide synchronization uncertainty. It adds that a nearby SSB before a paging occasion is not guaranteed. The second version uses the WUS as an aperiodic synchronization signal for what follows it. After detecting the WUS, the UE already has fresh timing and frequency for the paging PDCCH or the scheduled PDSCH. Several companies propose this. One of them notes that the CAZAC autocorrelation of a ZC base layer supports timing acquisition naturally. Frequency acquisition also becomes feasible, once there are at least two repetitions. But there is an overhead objection. If WUS must support synchronization, we need a fixed sequence portion in every transmission. This raises the overhead on a signal whose overhead is already contested.
Self-synchronization removes the early wake-up penalty : If the UE does not need to receive SSB first, it can stay in deep sleep until the WUS occasion. That is where the largest remaining energy saving sits.Aperiodic synchronization helps the step after wake-up : Even if WUS is not self-synchronizing, the UE can use it to refresh timing before paging or data reception. This reduces the latency and the energy of the wake-up transition.It costs a fixed part of the payload : A sequence portion reserved for synchronization cannot carry information. We therefore need to balance synchronization support against payload capacity.Do not use WUS for periodic measurement : One company argues that event-triggered WUS should not support periodic RRM measurement. The UE should use periodically transmitted reference signals for that measurement instead.The answer depends on the SSB design : 6G may end up with frequent, narrow and cheaply detectable sync signals. In that case the argument for a self-synchronizing WUS weakens considerably. Several companies therefore want to wait for progress in initial access before deciding this.
What does residual frequency error actually cost in dB?
We've considered which ppm value to assume. Now let's use the RAN1 #126 results to see what each assumption costs. At 3.5 GHz, SNR degradation is roughly 0.8 dB for 2 ppm and 1.8 dB for 3 ppm. It rises to 3.3 dB for 4 ppm and 5 dB for 5 ppm.
The cost is not linear. Moving from 2 ppm to 3 ppm costs about a decibel, and moving from 4 ppm to 5 ppm costs nearly two. With a pessimistic assumption, we allocate several decibels of coverage budget to an error the UE rarely experiences after processing SSB.
One company proposes changing the maximum residual error from 5 ppm to 2.5 ppm for the study. Using those numbers, we recover roughly 4 dB relative to the pessimistic assumption, comparable to doubling the signal bandwidth.
A pessimistic assumption is not a safe one : If we assume 5 ppm, we require 5 dB of margin that the sequence design may never need. Providing that margin through repetitions costs network resources and latency.The cost is comparable to the design levers : Four decibels is what a doubling of bandwidth buys. So we should give the synchronization assumption as much attention as the bandwidth choice.
The 2 ppm baseline still needs receiver work at 7 GHz. It corresponds to 14 kHz, or about 0.467 of a 30 kHz subcarrier. For ZC, CFO can move energy into another cyclic-shift candidate. Root restrictions and frequency hypotheses can reduce ambiguity, but both affect capacity or processing cost.
SSB processing also needs evaluation at the intended operating point. A single PSS/SSS sample may be sufficient with two Rx branches and fail with one at low SNR. A claimed synchronization guarantee must therefore include sample count, channel, receiver and failure probability.
How should MDR, FAR and FDR be defined and targeted?
Before comparing detection results, let's check the definitions; they determined the outcome of several technical arguments. Through RAN1#124-bis, companies reported missed detection rates against incompatible definitions of false alarm. Some counted only noise-triggered detections. Others also counted detections of another UE's sequence. The false alarm target determines the detection threshold, so those results were not actually comparable. RAN1#125 fixed this with a clean pair of definitions. The false alarm rate is the rate at which the UE detects any targeting DL WUS sequence, given that no DL WUS sequence was transmitted. The false detection rate is the rate at which the UE detects any targeting sequence, given that a different sequence was transmitted. The RAN1 #126-bis evaluation pairs are MDR 1% with max(FDR, FAR) 1%, and MDR 0.5% with max(FDR, FAR) 5%. The signal design must be compared at these paired operating points. The feature lead also asks companies to report how different FAR and FDR values affect UE energy saving and network resource overhead.
Separate noise errors from sequence errors : They have different causes and different fixes. We address noise-driven false alarms through threshold and processing gain. We address sequence-driven false detections through sequence design and pool size.A false alarm is cheaper than a missed detection : A false wake-up makes the UE monitor unnecessarily for one cycle. A missed wake-up adds a full paging cycle of latency. That's why one company proposes 0.1% MDR with 10% FAR for idle mode. Another accepts 5 to 10% FAR.Relaxing FAR buys coverage : One company compares two operating points. The required SNR for 0.5% MDR with 5% FAR is similar to that for 1% MDR with 1% FAR. So we can balance the two metrics rather than tighten both together.Do not forget procedural false wake-up : One company identifies a third category: the UE correctly detects its group's sequence, but the page targets another member. Group granularity causes this wake-up, even though detection worked correctly. This explains why payload size affects power saving.A warning on definitions : We may tune a design for a 1% noise-only false alarm. But if we count cross-sequence detections, its false wake-up probability in the field can be roughly ten times higher. That is why the cross-sequence target belongs in the design criteria.Keep MDR tighter than the triggered channel : The UE detects WUS and then decodes PDCCH, so the combined reliability is the product of the two. For this reason the WUS target has to be stricter than the PDCCH BLER target. Otherwise the overall paging performance degrades.
The two recorded operating points allow a reliability-versus-resource comparison. They do not make FAR and FDR interchangeable. A threshold must satisfy the larger of the two, and the reported MDR must correspond to that threshold.
Additional control functions need their own error consequences evaluated. A false paging wake-up costs receiver energy. A false cell-state change or beam update can leave UE and network with different assumptions. Confirmation, validity time and recovery procedures belong in that assessment.
How much network resource should DL WUS consume?
The evaluations suggest that a sensible signal design needs very little overhead. Let's examine the most detailed set of system overhead figures. Consider idle mode at the agreed reference SNR of about -7.1 dB. There, a 5-bit WUS triggering paging monitoring takes 0.06% to 0.12% of system resources. An 8-bit WUS takes 0.06% to 0.19%. The exact value depends on the number of receive antennas. For connected mode the figures are even smaller. They are around 0.02% at a 40% traffic arrival rate per monitoring occasion, and about 0.05% at a 10% arrival rate. You should also compare WUS with the existing DCI-based features. In idle mode, DL WUS and a PEI-like PDCCH consume comparable system overhead. In connected mode, DL WUS and DCP also consume comparable overhead. At the same time, the sequence-based version saves substantially more UE power. These results address the main overhead objection to adding an always-configured downlink signal.
Overhead is a fraction of a percent : Under realistic configurations, the WUS costs less than half a percent of system resources. This is the same order as the DCI-based features it would replace.Unused resources must be reclaimable : Two companies propose making configured but unused WUS time-frequency resources immediately available for dynamic scheduling. Otherwise the configured overhead becomes a permanent capacity loss.Spectral efficiency is the honest metric : Two companies propose reporting bits per MHz per ms. We can then compare sequence-based designs and PDCCH-based alternatives on equal terms. The comparison is then not based on power saving alone.Multiplexing with SSB is efficient : One company proposes frequency-multiplexing WUS with SSB in the same symbols, avoiding additional time-domain overhead. Another points out that FDM complicates simultaneous UE reception. TDM within a short window is simpler for both the UE and network.Beam sweeping multiplies the cost : In multi-beam deployments, the network must repeat WUS per beam, so overhead scales with the beam count. This is one reason several companies want the number of monitoring occasions per cycle kept small.Guard bands may be needed : Several companies raise the need for guard subcarriers between the WUS and adjacent transmissions. One of them estimates roughly six subcarriers. That figure limits the leakage under 5 ppm CFO at 7 GHz.
Is it better to spend bandwidth or time?
For the same detection performance, choose more bandwidth over more time. A wider, shorter DL WUS is more energy efficient for both the UE and network than a narrower, longer one. This is the clearest resource result from RAN1 #126. It gives us a reason to avoid long repetition structures when extending coverage.
Consider how long the receiver must stay awake: it runs throughout the occasion. A wider signal delivers the same energy in fewer symbols, so the receiver front end runs for less time. Energy per detection follows the duration far more closely than it follows the occupied bandwidth.
A short, wide occasion occupies fewer symbols, giving the scheduler more room around it. A long, narrow occasion reserves a thin band across many symbols, fragmenting the resource grid for other transmissions in those slots.
Width and length are not symmetric : Both increase collected energy, but only a longer duration keeps the receiver awake longer. We therefore cannot treat them as interchangeable when calculating energy consumption.It constrains the sequence choice : If we meet the target through repetition, we use the less energy-efficient resource. The same reasoning favours sequence families that support a wider single-shot allocation.Containment within a slot follows : The proposal to keep DL WUS within one slot follows the same reasoning, even with a configurable starting symbol. Crossing a slot boundary complicates scheduling to obtain a gain we could already achieve through wider bandwidth.
Frequency packing also needs a transmit-power assumption. With fixed total WUS power, four simultaneous FDM blocks receive about 6 dB less power per block. Sixteen blocks receive about 12 dB less. Extra repetition needed to recover coverage can consume the network sleep benefit.
For multiplexed occasions, distinguish the network resource grid from the UE reception requirement. RAN1 #126 allows TDM, FDM and mixed arrangements for study, while requiring no more than one monitoring occasion at a time for a UE. FDM alone does not imply simultaneous wideband reception.
What does DL WUS do in RRC IDLE/INACTIVE, and how much does it save?
RAN1#124-bis agreed to study the 6GR OFDM sequence based DL WUS in RRC idle state. Its purpose is to wake up the UE, for at least paging. Let's group the study topics so you can follow what the procedure needs to cover. It includes the UE energy saving gain, the latency impact, and the network overhead, complexity and energy consumption. It also includes distributed and clustered PO/PF, and the association between the WUS monitoring occasion and the paging occasion. Further items are the UE behaviour after waking up, the indication granularity, and the number of information bits. The list continues with the monitoring periodicity and occasions, and with multi-beam operation including QCL assumptions. Finally, it covers false alarm and missed detection consequences, other RRC states and other functionalities. It also asks whether WUS and paging use the same carrier or different carriers. When you read the large reported energy saving gains, check the conditions behind them. The RAN1#124-bis feature lead observation gives the following figures against I-DRX with PEI. The gain is 32.3% to 37% when the UE reaches deep sleep, and about 73% with ultra-deep sleep. Against I-DRX without PEI, it is about 61% in deep sleep. At RAN1#125 the observation was refined. Against I-DRX with PEI, the gain reaches 52.5% when the UE also performs RRM measurement through EE processing. However, it is only about 22% when measurement stays in the main radio. This comparison gives us the most important result in this agenda: measurement handling strongly affects the gain.
Figure 7. Idle mode operation. Removing paging PDCCH decoding gives a smaller saving. Keeping the main radio asleep through sync and measurement gives the larger saving.
The gain depends on what else the UE must wake for : You can see this in one set of results. If the UE offloads only serving-cell measurement, the gain collapses as soon as it needs neighbour cell measurement. In some configurations it even drops to negative values. With full offloading, however, it stays between roughly 60% and 90%.Deep versus ultra-deep sleep is not a free choice : Ultra-deep sleep gives the lowest sleep power. However, it carries a transition energy of tens of thousands of relative units, and transition times of up to 1.6 s. One company therefore finds that deep sleep can outperform ultra-deep sleep at high wake-up rates.Wake-up rate is the dominant parameter : The effective wake-up rate is the sum of the true paging rate for the group and the false alarm rate. With 1% false alarm rate and 0.1% group paging rate, false alarms account for most wake-ups.Paging rate assumptions were standardised : RAN1#125 converged on a common model. The per-UE paging rates are 1%, 0.1%, 0.01% or 0.001%, referenced to a 1.28 s cycle. We then derive the group rate from the number of UEs per group, allowing comparisons across companies.Latency should be reported alongside energy : Several companies note the role of the wake-up delay from a deep sleep state. The delay includes ramp time and limits how deeply the UE can sleep for a given service.DL WUS as the single idle-mode scheme : A large group of companies support sequence-based DL WUS as the single idle-mode scheme. Their reason is that it achieves much larger power saving than a PDCCH-based PEI, at comparable resource overhead.
How should WUS occasions relate to paging occasions?
Let's start with Rel-19, where configuration associates one wake-up occasion with up to four paging occasions. For 6G, we need to revisit the association because RAN2 is redesigning the paging structure. RAN2 is considering both distributed and clustered PO/PF patterns. Two companies propose aligning the WUS monitoring periodicity with the paging periodicity. Another company proposes that the UE monitors one time occasion per paging cycle. That occasion may contain one or more contiguous monitoring occasions. The same company warns that increasing the number of occasions within a cycle hurts power saving. A fourth company proposes clustering DL WUS and paging occasions within one SSB periodicity. The WUS then indicates dynamically which paging occasions actually carry a paging message. The base station can then group its transmissions more closely and sleep longer between them. A fifth company makes a similar proposal for flexible paging occasions. It reports that this lets a Category 2 base station reach deep sleep instead of light sleep between paging occasions. This substantially reduces idle-mode sleep power.
Keep the number of occasions per cycle small : One evaluation looks at 16 subgroups, at a 1% paging probability and a 1% false alarm rate. With one monitoring occasion, the power saving benefit is 47%. With two occasions, the benefit falls to roughly zero; with four, it becomes negative.Dynamic PO selection is a network energy play : If we make the paging occasion location depend on WUS, the network can cluster its paging transmissions. This is a base station saving, rather than a UE saving.The design must cover both PO patterns : RAN2 may adopt distributed or clustered PO/PF. Several companies therefore propose a flexible WUS association that accommodates whichever pattern RAN2 chooses.Same carrier as paging is the baseline : Several companies propose that the WUS and paging use the same carrier. They cite complications and unclear gains otherwise. However, several other companies want the multi-carrier case studied.Beam association follows SSB : One company proposes using the SSB as the QCL reference. This applies to both the group WUS and the UE-specific WUS, as a starting point. This lets the UE handle beams in the same way as for paging.
RAN1 #126-bis agreed that, for paging at least in RRC idle, WUS monitoring has the same periodicity as paging. This fixes the cycle relationship while leaving the detailed occasion-to-PO mapping open. Monitoring for other functions is discussed separately.
What should the UE do immediately after waking up?
Let's first look at the baseline that a large majority of companies support. The UE monitors the paging PDCCH, and then the paging PDSCH, exactly as it does today. One contribution explains why: the network can address several UEs at once and handle emergency call-back. The procedure also handles UEs with and without a USIM. The alternatives are more aggressive. One company proposes that the UE monitor only PDCCH or go directly to PDSCH. The same company argues that the paging message becomes redundant if the WUS carries UE-dedicated information. The UE can then start the RACH procedure immediately. Another company proposes that, after a UE-specific WUS, the UE monitor UE-specific DCI such as a PDCCH order. It does not receive the paging PDSCH at all.
Keep the paging procedure as the baseline : We already understand the two-step PDCCH plus PDSCH procedure, and it covers cases that a wake-up indication alone cannot handle.Per-UE indication enables a shortcut : If WUS uniquely identifies the UE, the paging message adds nothing. Going straight to random access then removes an entire reception step, and its latency.The shortcut has a capacity price : Per-UE indication requires thousands of sequences per occasion. We therefore simplify the procedure at the cost of a more demanding sequence design.Additional synchronization before paging : A large group of companies propose an additional synchronization or reference signal before the paging occasion. The aim is to reduce the latency of the WUS-triggered reception. This is the same idea as using the WUS itself for synchronization.Behaviour should follow indication granularity : One observation links post-wake-up behaviour to whether the indication is group-level or UE-level. Therefore the two cases may need different procedures, rather than one compromise.
For paging at least in RRC idle, the #126-bis agreement requires paging PDCCH monitoring after a positive DL WUS indication. Direct paging PDSCH reception remains for further study. Identity-based WUS triggering random access also remains a proposal, with false triggers and access handling still needing evaluation.
Should WUS occasions be TDMed or FDMed, and how are beams handled?
Let's compare the proposals for multiplexing monitoring occasions. One company proposes time-division multiplexing as the 6G baseline, with the need for frequency-division multiplexing left for further study. Another company disagrees, and wants both studied at the same level. It argues that FDM lets the wide bandwidth around 7 GHz be used properly. It also gives the base station more chances to sleep. Half a dozen companies see value in FDM. Their main reason is that it increases the number of monitoring occasions, without extending the time the base station must stay awake. Their argument focuses on network energy saving rather than UE energy saving. For beams, companies broadly agree that idle-mode operation must support multiple beams, with SSB as the QCL reference. But each beam increases WUS overhead, so several companies want a limit on the total number of occasions.
TDM is simpler for the UE : Time-multiplexed occasions require no retuning and fit the existing paging structure. This explains the proposal to use TDM as the baseline.FDM is better for the network : Packing occasions in frequency shortens the awake window at the base station and increases addressing capacity without more symbols.Beam sweeping is the hidden multiplier : With K beams and M occasions, the resource cost is the product of the two. One company therefore proposes studying an upper bound on that product to prevent excessive UE power consumption.Combined TDM and FDM structures : One company proposes combining TDM and FDM to reduce system overhead and relax the payload requirement. More occasions mean fewer subgroups within each occasion.Association rules must follow the multiplexing choice : We need to define WUS-to-PO association together with the choice of TDMed, FDMed or combined occasions.
What do the #126-bis idle results actually isolate?
The #126-bis results separate wake-up signaling from measurement offloading. With a 1.28 s I-DRX cycle and deep or light sleep, the reported means differ substantially depending on which activity moves into EE processing. Comparing the same activities on both sides prevents measurement gains from being attributed entirely to the wake-up sequence.
For serving-cell measurement only, DL WUS plus EE measurement gives mean gains of 27.17% to 32.43% against PEI with non-EE measurement. Changing only serving-cell processing while keeping DL WUS gives 26.19% to 34.21%. These comparisons measure different changes and cannot be added.
Keeping serving-cell measurement in non-EE processing reduces the reported mean gain of WUS over PEI to 2.23% to 8.68% in the deep-sleep comparison. With neighbors also measured by non-EE processing, moving serving-cell measurement alone gives 17.13% to 19.2%.
RAN1 adopted the collected observations in principle, with their figures and assumptions, and allowed later refinement. They summarize the submitted configurations. They do not guarantee the same gains for every UE, paging load or measurement requirement.
Should RRM measurement be moved into EE processing?
Now let's examine measurement offloading, where we can find the largest remaining energy saving. RAN1 has agreed to study it in both RRC states. For idle mode, RAN1#124 agreed to study serving cell and neighbouring cell RRM measurement by EE processing, based on 6GR measurement signals. The study covers the energy saving gain, the coverage and accuracy, and the neighbour cell identification and evaluation. It also covers cell number limitations, inter-cell interference, and the impact on EE processing complexity. A note clarifies that the UE does not have to couple measurement in EE processing with DL WUS monitoring. For connected mode, RAN1#124-bis agreed the equivalent study for serving and neighbouring cell measurement. It also added measurement metrics, and the question of specification impact. The motivation is straightforward: if the UE still wakes its main radio every cycle to measure, WUS removes only a small energy cost. The difficulty is that measurement involves several operations, and some are harder than others to adapt for low-power processing.
Measurement offloading is what makes WUS worthwhile : The RAN1#125 observation gives an idle-mode gain of 22% in one case, and 52.5% in the other. The difference comes from whether the UE measures through the main radio or EE processing.Serving cell measurement is nearly free : The UE has already synchronized to PSS/SSS in EE processing. The UE then needs only a small additional step to compute RSRP. This explains the broad support for the feature lead's observation that additional complexity is marginal.Neighbour cell measurement is a different problem : The UE needs cell detection, measurement configuration storage, and control logic to choose which cell and frequency to measure. It may also need interference cancellation.Cell search may not belong in EE processing : One company proposes studying two options for cell search. The UE could use an enhanced EE state or wake the main radio infrequently. Another company proposes non-EE processing for search in asynchronous and inter-frequency cases, while keeping measurement in EE processing.Specification impact is uncertain : One company argues that this should be left to UE implementation. The company sees no need for explicit specification support. However, two other companies expect RAN2 and RAN4 impacts, if the accuracy or the requirements differ.
Is serving cell measurement by EE processing feasible?
The evidence supports serving cell measurement in EE processing. But you need to check accuracy carefully at low SNR with a single receive antenna. One company reports RSRP accuracy within 2 dB at SINR -6 dB, and within 3 dB at -7.1 dB. The company obtains these results with a single SSB sample, 2 Rx and AWGN. Another company uses a 2 us timing offset and a 2 ppm frequency offset at 3.5 GHz. At -6 dB SNR, plus or minus 1.5 dB accuracy requires three samples with 1 Rx or two with 2 Rx. For plus or minus 3 dB, a single sample is enough either way. At -8 dB SNR, the sample counts roughly double. A third set of results is the most cautionary. With 1 Rx and 1, 2 or 5 ppm CFO, it obtains about 2.5, 3.2 and 9.5 dB accuracy. The evaluation uses four SSBs in a burst at 160 ms periodicity. It concludes that 2 dB accuracy may not be reachable with 1 Rx. To reach it, the UE must compensate the frequency error, or RAN4 must relax the requirement. A fourth company reports 2.79 dB with EE processing, against 1.63 dB without it, at -6 dB. This quantifies the penalty directly.
Two receive antennas make the difference : Most of the reported failures to reach the accuracy target occur with 1 Rx at low SNR and large frequency error.Frequency error dominates accuracy : The accuracy goes from 2.5 dB at 1 ppm to 9.5 dB at 5 ppm. This progression brings us back to the synchronization assumption: it also determines measurement accuracy.Averaging is the available remedy : More SSB samples improve accuracy predictably. The cost is more EE processing occasions. So we need to balance measurement energy against accuracy, rather than classify the method as simply feasible or infeasible.The complexity increment is small : The UE already has timing and PSS/SSS information for the serving cell. It only needs the additional RSRP or RSRQ calculation beyond synchronization.RAN4 may need to be consulted : Two companies raise the possibility of relaxing the accuracy requirement specifically for EE processing. This is a specification question, rather than a design one.
Where does neighbour cell measurement and cell search hit its limit?
Let's compare the potential gains with the additional work the UE must perform. One company moves both serving and neighbour cell measurement into EE processing. It reports about 45.6% energy saving without weighting. When the company weights the need for neighbour measurement at a 30% probability, the figure is 35.4%. For serving cell only, it is about 21%. Another company reports 24.4% to 32.6% for both, against 14.1% to 18.9% for serving cell only. But other companies identify specific complexity costs. A third company describes neighbour cell measurement as computationally intensive. It requires cell detection, stored measurement configuration, and control logic to decide when to measure which frequency and cell. That company therefore questions whether the UE can perform neighbour cell measurement in EE processing at all. A fourth company argues that it also adds successive interference cancellation and cell search. Both conflict with the low-power design constraint. The fourth company proposes first studying simplified conditions with a limited number of neighbours and sufficient RSRP separation. The aim is to establish the power budget boundary. The compromise emerging at RAN1#125 is to study intra-frequency neighbour measurement with explicit limits.
Limit the number of cells : One company proposes limiting the count to a small number per frequency, for example four. The UE would use physical cell identities it already obtained in the non-EE state. Another company suggests a list of about 16 cell identities, in order to bound the search.Limit the timing uncertainty : In a synchronous intra-frequency deployment, the neighbour SSB arrives within a few microseconds of the serving SSB. The UE therefore needs only a small search window. One company notes that this is what makes the intra-frequency TDD case tractable.Separate detection from measurement : The RAN1#125 direction asks whether the UE should detect and identify cells through EE processing or non-EE processing. Meanwhile, measurement of already-identified cells stays in EE processing.Asynchronous and inter-frequency cases are harder : Both cases widen the search window, and both add retuning. Several companies therefore propose that the UE wake its main radio infrequently instead of extending EE processing.Relaxation is the alternative, not the equal : Before choosing offloading, compare it with measurement relaxation. Neighbour measurement relaxation by a factor of 4 or 16 can give energy saving comparable to EE-processing measurement. However, it degrades the cell reselection delay and the coverage. So we cannot treat the two approaches as interchangeable.Storage is a real cost : Two companies note that the UE must buffer neighbour cell measurement configuration while the main radio sleeps. This increases its buffer requirement. That conflicts with the aim of minimising active memory in this state.
What power model applies to multi-cell measurement in EE processing?
Don't automatically apply the agreed EE processing power values to multi-cell measurement. Those values describe wake-up sequence detection. RAN1#125 spent considerable effort on this. The discussion converged on two parts. First, the existing EE processing relative power values apply to serving cell measurement. This assumes sequence-related processing, with frequency and time compensation. Second, a small table scales the power for intra-frequency multi-cell measurement. In the synchronous case, the factor is about 1.5 times for eight cells, 1.2 times for four cells, and 1.1 times for two cells. The count includes the serving cell. These are slot-averaged values; we do not scale the sleep power. Values for the asynchronous case were left for further study. There, two companies propose 1.7 and 1.4 times for eight and four cells respectively. If we include cell search, the proposed scaling rises to about 2 times for eight cells and 1.7 for four.
Scaling is modest for synchronous intra-frequency : Measuring eight synchronous cells costs about half as much again as measuring one, because the correlations reuse the same timing hypothesis window.Asynchronous costs more : Without a common timing reference, the UE must search a wider window per cell. This explains the additional 0.2 times factor.Cell search is the expensive part : The step from measurement-only to measurement-plus-search is larger than the step from four cells to eight. This supports keeping search out of EE processing, where possible.Inter-frequency adds switching cost : One company proposes a model for inter-frequency measurement. The base term is the per-layer measurement power, times the number of layers. The model then adds a switching power term for each transition, using the micro sleep power for switching.Light sleep needed a fix : One company pointed out an inconsistency in the model. EE processing at 5 MHz with 1 Rx would consume more in light sleep than in micro sleep. The company therefore proposed applying the same antenna-count scaling to light sleep to keep the model consistent.IoT may need its own transition model : One company proposes an optional model for IoT devices. The transition energy and time would be 15000 units and 800 ms. The baseline is 40000 units and 1600 ms. The company argues that a simpler device has less state to save and restore.
Which RRM measurement assumptions were aligned at #126-bis?
The agreed RRM evaluation setup isolates measurement of known cells. It covers serving-cell and intra-frequency RRM in idle and connected states. Cell identification and search are excluded, so the results cannot establish their feasibility in EE processing. This separates the cost of periodically measuring an already known cell from discovering a new one while the main receiver sleeps.
The setup uses NR PSS/SSS, TDL-C with 300 ns delay spread, one Tx or one layer, and one or two Rx antennas. SCS is 15 kHz at 700 MHz and 30 kHz at the other frequencies. The reference speed is 3 km/h, while other speeds may be reported.
Maximum frequency error before measurement is 2 ppm, uniformly distributed between its negative and positive limits. The RRM operating points are -6 and -8.1 dB. Around 7 GHz and extended coverage, the SNR still needs further discussion. An applied interfering cell is 3 dB stronger than the measured cell.
Companies still need to state averaging samples, measurement cycle and the sliding-window size. They also need to explain differences from regular processing. Otherwise a low-power result may hide extra sampling time or a relaxed measurement requirement.
Neighbor measurement also needs comparison with relaxation. In the collected deep/light-sleep results, EE neighbor measurement gives mean gains of -7.02% to 4.8% against relaxed non-EE measurement. The energy advantage is therefore not universal. Reselection delay and measurement availability remain part of the trade-off.
How should DL WUS trigger PDCCH monitoring in RRC CONNECTED?
Let's follow the procedure RAN1 agreed at RAN1#124-bis. The UE monitors DL WUS periodically using network configuration. After detection and a time offset, the UE starts PDCCH monitoring for a time duration. The study then covers the remaining details. These include the duration, the offset and whether the UE monitors WUS during that duration. They also include how the UE stops PDCCH monitoring, and how it stops and starts WUS monitoring. Finally, they cover whether the trigger applies per cell or per cell group, and whether one or more WUS configurations are needed. This framework covers operation both with and without C-DRX. We can handle the difference through configuration within the same mechanism. The reported gains are substantial. The RAN1#125 observation records up to 21.1% for FTP3 and 64.2% for IM traffic, when the WUS monitoring periodicity equals the C-DRX cycle. When the periodicity is shorter than the cycle, it records up to 53% for FTP3, 70% for IM and 23% for VoIP. Against C-DRX with DCP, the gain reaches up to 55% for FTP3. However, the same observation notes a catch. Several of these gains come with increased latency. Read the periodicity split carefully: the source contributions assign the same values the other way round. The figure below sets the two side by side.
Figure 8. Connected mode. The two options are configurations of one timer-based framework. The main radio sleep state has the largest effect on the reported gain. The meeting record and source contributions disagree on the periodicity split.
Here's how to read the percentages: each gives the reduction in UE power consumption from adding DL WUS. In each case, we compare against a baseline without DL WUS. For the first two rows that baseline is C-DRX alone. For the last figure the baseline is C-DRX with Rel-16 DCP. Because DCP already provides a wake-up mechanism, improving on that baseline by 55% is a stronger claim than the same gain over plain C-DRX. The label in brackets is the traffic model, and each model carries its own C-DRX setting. You can find those settings in the bullets below.
You can explain the spread between traffic models by checking their settings. IM gains the most. With a long C-DRX cycle and infrequent packets, most IM on-durations cause unnecessary wake-ups that WUS can skip. VoIP gains the least. A 40 ms cycle carrying near-periodic packets has very little to skip. In addition, the WUS occasions themselves consume part of the saving. Also read "Up to" as the best case across companies and configurations, not an average.
Let's examine the periodicity split more carefully, because each extra WUS monitoring occasion consumes energy. Each occasion is cheap, because it runs in EE processing at 5 MHz with 1 or 2 Rx and no blind decoding. But four low-cost occasions still consume more energy than one. The contributions behind these numbers say so directly. One company reports 15.2% to 40.1% for FTP3 and 70.2% for IM when the WUS periodicity equals the C-DRX cycle, together with a latency loss. It then reports 3.1% to 21.1% for FTP3 and 64.2% for IM when the periodicity is shorter, together with a latency gain. In these results, a shorter periodicity improves latency at the cost of energy. The same company states this in the same form at RAN1#124, at RAN1#124-bis and at RAN1#125.
Notice that this reverses the assignment in the observation. The observation places 21.1% and 64.2% in the equal-periodicity row. The contributions give that pair only for shorter periodicity. We should therefore treat these values as a range of reported outcomes. This inconsistent periodicity split does not tell us which direction the gain changes.
Next, check how deeply the main radio sleeps while the UE monitors WUS; this strongly changes the gain. One company changes only the sleep state, keeping the scheme, traffic and C-DRX (160, 8, 100) baseline fixed. Light sleep gives 22.67%, and deep sleep gives 57.21%. Another company reports ranges "for various MR sleep states". Those ranges exceed the gap between its two periodicity rows. Also compare latency: several gains come with increased delay, so the percentage alone is insufficient.
Main radio sleep state is the real variable : The largest single effect comes from how deeply the main radio sleeps during WUS monitoring. It matters more than periodicity or whether we configure DRX. One company holds the scheme, the traffic and the baseline fixed, and reports 22.67% for light sleep against 57.21% for deep sleep. The comparison baselines are the C-DRX settings agreed at RAN1#123. Read each set as cycle, on-duration timer and inactivity timer. The values are VoIP (40, 8, 10) ms and FTP3 (160, 8, 100) ms. They are instant message (320, 8, 100) ms and XR (16, 10, 4) ms for the other models. For idle mode, the baseline is I-DRX of 1.28 s.Compare at equal triggering periodicity : Two companies propose a fair baseline. When we study WUS without C-DRX, we should compare it with WUS using C-DRX at equivalent triggering periodicity. Otherwise the comparison measures the periodicity, rather than the scheme.Latency can improve or degrade : One company reports latency loss when the WUS periodicity equals the DRX cycle and latency gain when it is shorter. Another reports a 5.25 ms latency increase for FTP with 29.2% saving. With two enhancements combined, it reports a 74.5% latency reduction for IM traffic.Report the delay distribution, not the mean : Consider one contribution's results with a 30 ms packet delay budget. Several schemes meet the requirement on average, but they fail at the 90th percentile. Only WUS without C-DRX met it at both points.Cell group versus cell : Several companies propose that the trigger applies at cell group level. They would leave per-cell indication for further study. However, another company proposes that per-cell indication is useful for the no-C-DRX case.One active configuration as baseline : One company proposes a single active DL WUS configuration at a time as the baseline. The company would leave multiple configurations for further study. However, several other companies argue that multiple functionalities may each need their own configuration.
With C-DRX or without C-DRX?
You can relate these two options to Rel-19 LP-WUS option 1-1 and option 1-2. In option 1-1, detection causes the UE to monitor during the next configured on-duration. In option 1-2, detection starts a PDCCH monitoring timer, independently of the DRX cycle. In 6G, the argument for the C-DRX-free variant is that it is a superset. One argument is that the UE can start a PDCCH monitoring timer on detection without a DRX configuration. We can configure that timer to reproduce on-duration behaviour, making this the more general design. Another company argues the same. That company adds that the network no longer needs to maintain DRX and WUS timing jointly, simplifying scheduling. Companies that favour keeping C-DRX focus on reachability and familiarity. One company prioritises WUS with C-DRX as the foundational architecture, in order to guarantee UE reachability. Another argues that measurement is cheaper in 6G, so aligning WUS and C-DRX may have no real drawback. Several companies also observe that with matched configuration, the power saving is comparable either way.
They are configurations of one framework : One argument is that RAN1 should define a single discontinuous monitoring framework covering both cases. The agreed procedure follows that direction. RAN2 reached the same conclusion in parallel. It agreed on a single active DRX configuration at a time. RAN2 also identified a 5G problem: the many mechanisms across releases, including DRX, LP-WUS option 1-1, option 1-2 and DCP. Its aim is a single discontinuous monitoring framework. That framework covers periodic wake-up monitoring, and the follow-up PDCCH monitoring.The C-DRX-free variant is the superset : If the timer-based trigger can reproduce on-duration behaviour, specifying only the general case avoids two sets of procedures.Measurement decoupling is the real benefit : Two companies stress a further effect of removing the C-DRX cycle. It also removes the implicit tie between the measurement periodicity and the PDCCH monitoring periodicity. They see no intrinsic relationship between these periodicities and argue for decoupling them in a Day-1 design.Fallback and reachability need care : One company proposes a timer-based fallback to keep the UE reachable even if WUS detection fails repeatedly. That failure is the main risk of removing the periodic on-duration.RAN2 owns part of the answer : Several companies note that the timer definitions themselves are RAN2 territory. RAN1 should therefore settle the physical layer behaviour and leave timer naming and configuration to RAN2.
R1-2606981 conveys the RAN2 #135 agreement for WUS configured together with C-DRX. The UE has one set of DL-monitoring cycles and timers, with no separate WUS cycle. If WUS does not indicate wake-up, the UE does not start C-DRX active time; details remain open.
Measurement periodicity is a separate issue for RAN4. It may equal or differ from that shared DL-monitoring cycle. Earlier simulations with a shorter WUS cycle remain useful comparisons, but they do not establish a second cycle for the together-with-C-DRX procedure.
The without-C-DRX case remains disputed in the individual contributions. Equal monitoring and measurement assumptions can give similar performance with either framework. Reported advantages from shorter cycles must therefore be separated from advantages caused by removing C-DRX itself.
Should WUS be monitored during the active time?
Let's look at WUS inside active time, because it changes the signal's purpose. Outside the active time, the WUS answers the question "should I start monitoring". Inside the active time, it could answer "should I keep monitoring". In that role it replaces PDCCH skipping and search space set group switching, rather than complementing them. One company makes the strongest case with numbers. Applying WUS monitoring during the C-DRX inactivity timer gives 29.2% power saving for FTP traffic. The cost is a 5.25 ms latency increase. The gain is large because the 6G baseline has a 100 ms inactivity timer that otherwise forces continuous PDCCH monitoring. Another company proposes studying three uses of the WUS during monitoring periods. The uses include ending skipping early and ending the inactivity timer early. The third is triggering the next monitoring attempt with information that reduces blind decodes. But companies also raise practical objections. One company proposes postponing the discussion, because it functionally overlaps skipping, search space switching and go-to-sleep mechanisms. Another asks us to check whether EE processing can run during active time at all.
It replaces skipping rather than complementing it : During a skip window, the UE can monitor a cheap sequence instead of an expensive PDCCH. If the hardware allows it, this is strictly better. This explains the proposal to use WUS as a unified monitoring adaptation framework.Simultaneous monitoring is not assumed : Several companies say we should not expect the UE to monitor WUS and PDCCH in the same symbol. This limits the implementation requirement.The overlap with 2-stage DCI is real : In the DL control agenda, one option for a 2-stage DCI is a sequence-based first stage. Two companies note the similarity to WUS and propose studying whether the same sequence can serve both purposes.Overhead grows with monitoring density : One company notes that WUS monitoring inside the active time helps only with appropriate configuration. Frequent WUS occasions inside the active window continuously consume network resources.A phased approach is proposed : One company suggests a phased approach. For the baseline phase, the UE suspends WUS monitoring during the PDCCH window. The company would study monitoring during that window later. This lets us progress with the basic design while leaving the additional behaviour for later.
RAN1 #126-bis agreed to study the use case, necessity and benefit of monitoring WUS during active time. This includes when WUS and PDCCH monitoring start and stop. It is a study agreement, so simultaneous monitoring and replacement of existing mechanisms are not selected behaviors.
With C-DRX, active time means C-DRX active time. Without C-DRX, it means the PDCCH monitoring period. PDCCH skipping, SSSG switching, monitoring-configuration selection and blind-decoding reduction are handled with this operation discussion under agenda 10.6.1.2.
How does the UE stop PDCCH monitoring and resume WUS monitoring?
Let's start with the timer, which almost all companies support as the baseline. The UE stops monitoring when a network-configured timer expires. That timer is associated with the PDCCH monitoring duration. It works in the same way as the DRX inactivity timer today. The remaining debate is whether an explicit signal should also end the window early. A large group of companies support studying an explicit DCI or MAC CE indication. This is essentially the existing PDCCH skipping indication, reused to resume WUS monitoring. One contribution frames the question more carefully. It asks whether we need additional layer 1 schemes to delay restarting WUS monitoring after PDCCH monitoring ends. We need to weigh energy savings, latency and signalling overhead from the associated fallback procedures. Another company proposes using WUS itself to indicate that monitoring should stop. This works only if the UE monitors WUS during active time.
Timer as baseline, signalling as enhancement : The timer guarantees that the UE returns to low power even if it misses signalling. This makes the timer a reliable default.Explicit termination saves the tail : The inactivity timer can be 100 ms long. If the network knows there is no more data, ending the window early provides a large part of the connected-mode gain.Resumption timing matters as much as termination : One proposal for the connected mode is that WUS monitoring resumes as soon as PDCCH monitoring ends. This avoids a gap where the UE neither sleeps nor remains reachable through low-power monitoring.Fallback behaviour must be defined : Some schemes rely on a signal to change state. For each scheme, we need to define what the UE does if it misses that signal. That's why we cannot simply replace the timer.RAN2 alignment : A C-DRX related timer may stop PDCCH monitoring. One position is that RAN2 should handle those details. RAN1 should confine itself to the physical layer triggering behaviour.
Should RLM/BFD and CSI measurement also move to EE processing?
To understand why companies want to include radio link monitoring, let's follow the energy calculation. The UE may offload serving cell measurement for RRM only. If RLM still requires periodic non-EE processing, the UE cannot obtain the full saving. EE processing offers a 35.6% to 69.6% measurement-related saving. The UE loses that saving if it still wakes the main radio on the RLM schedule. Another company makes the same point from the C-DRX angle. In NR, the UE performs RLM once per C-DRX cycle by default. Therefore leaving it in the main radio eliminates the benefit of offloading RRM. Two further companies agree that offloading RRM alone gives limited gain in connected mode. The counter-arguments are about accuracy and scope. One company proposes postponing the RLM and BFD study, until RLM and BFD are themselves defined for 6G. Another argues that beam failure detection needs precise measurements. That company argues for low priority because the low-power path has reduced measurement accuracy. A third company prefers finishing the already-agreed measurement studies before adding more.
Partial offloading gives partial gains : Any measurement that remains in the main radio sets a minimum wake-up frequency for that radio. It therefore caps the achievable saving, regardless of how good the wake-up signal is.RLM is easier than neighbour measurement : The argument is that serving cell RLM is simpler than neighbour cell measurement. The UE already has synchronization and configured resources, so adding RLM is a smaller step than you might expect.SINR estimation is the open question : One company reports SINR accuracy within about 2.5 dB at -7.1 dB. This comes from one SSB sample with 2 Rx in AWGN. The calculation uses RSRP over RSSI minus RSRP for SINR. The result suggests feasibility, but only under favourable conditions.CSI is a different order of complexity : Two companies point out that CSI-RS processing needs multi-port channel estimation, codebook search and link adaptation calculations. This is far beyond SSB processing. Therefore they propose keeping EE processing to SSB-based measurements.Bandwidth is a hard limit for CSI : One company notes that CSI-RS bandwidth may exceed what EE processing can receive. That limit applies regardless of processing complexity.
RRM accuracy does not establish RLM reliability. RLM must relate a measured quantity to the main receiver's hypothetical PDCCH decoding performance. Different Rx counts and noise estimators can change that mapping even when RSRP error looks acceptable.
The #126-bis agreement starts by evaluating the SNR/SINR difference between EE and regular processing in connected mode. It uses the same basic PSS/SSS channel setup and 2 ppm frequency-error model. Sample counts and measurement cycles are reported separately; 7 GHz and extended-coverage SNR remain open.
BFD measurement and CSI relaxation remain separate proposals. Skipping CSI reports or periodic SRS after a negative WUS decision can save energy, but their resource and validity rules need coordination. Those proposals do not establish multi-port CSI estimation in EE processing.
What extra functions should DL WUS carry in connected mode?
With an expected payload beyond Rel-19's five bits, companies have proposed many connected-mode functions for 6G DL WUS. So far, RAN1 has begun listing them for study, rather than selecting among them. Let's focus first on the four functions with the most support. The first is reducing PDCCH blind decoding, by indicating the aggregation level, the CCE or the candidate subsets. The second is indicating SCell wake-up, or fast carrier activation and deactivation. The third is triggering on-demand reference signals, either for high-order QAM demodulation or for L1 measurement and reporting. The fourth is dynamically indicating the active period, or adapting C-DRX parameters. We also have less common proposals to consider. One is using the WUS sequence as the first stage of a 2-stage DCI. Another is using it as a dynamic control for clustered common signal transmission. A third is using it for BWP switching indication. Keep the same limitation in mind for every proposal: each function consumes payload, and payload consumes coverage.
Blind decoding reduction is the best-supported : It directly reduces the dominant connected-mode power cost and needs only a few bits.SCell and carrier control is a natural fit : Rel-16 DCP already carried an SCell dormancy indication. Rel-19 LP-WUS then dropped it. Restoring it in 6G WUS would therefore fill an existing functional gap.On-demand reference signals close the demodulation gap : If the UE wakes from deep sleep, its channel estimate is stale. The network can therefore trigger a TRS-like signal together with wake-up, removing a separate wait.C-DRX parameter adaptation belongs partly to RAN2 : The feature lead noted that C-DRX timers and parameters are subject to RAN2 discussion. RAN2 discusses both whether to adjust them and how. RAN1 should therefore focus on whether the physical layer can carry the indication.Avoid recreating DCI : The more control information the WUS carries, the closer it gets to being a small DCI. Such a DCI has worse spectral efficiency. Two companies raise this objection repeatedly.
What still limits additional WUS functions?
Additional connected-mode functions need a benefit after error handling and resource costs are included. The available #126-bis other-function summary still contains an open candidate list. It does not confirm adoption. Each candidate needs a defined indication, UE action and recovery path before its benefit can be compared with existing control signaling.
For connected mode, proposed functions include cell DTX/DRX interaction, carrier dormancy, additional signals, throughput reduction, uplink-request acknowledgement, beam updates, SPS reception and configured-grant control. These remain candidates. The number of proposed functions does not determine the final payload.
Fast control also needs a recovery rule. A wrong indication of cell activity or a beam update can affect several subsequent procedures. A bounded validity time or a protected follow-up indication may help, but its energy and latency cost must be counted.
How deep does the UE sleep between WUS occasions, and what decides that?
Let's distinguish the agreed power model from the UE's sleep-state choice. The model lists states and costs; it does not tell the UE which state to select. Micro sleep has relative power 45, no transition energy and no transition time. Light sleep has relative power 20, transition energy 100 and a 6 ms transition. Deep sleep has relative power 1, transition energy 450 and a 20 ms transition. Ultra-deep sleep has relative power 0.015, but its transition energy is 15000 or 40000 units, with a transition time of 800 ms or 1600 ms. The UE implementation chooses the state, without signalling or a specification rule for that choice. That is also why the evaluation results appear as ranges. When you read a gain "for various MR sleep states", the contribution has repeated the same simulation for each assumed state.
To understand the choice, start with how long the UE can sleep. One contribution links sleep power to the sleep type, which depends on the allowed sleep duration or wake-up latency. We then calculate how long the energy saving takes to offset the transition cost. Moving from micro sleep to light sleep costs 100 extra energy units and saves 25 units per ms. The UE recovers that cost after about 4 ms. Moving from light sleep to deep sleep costs 350 extra units, and it saves 19 units per ms. The UE therefore recovers that cost after about 18 ms. In addition, the 20 ms transition must fit inside the gap. Moving from deep sleep to ultra-deep sleep saves less than one unit per ms. Recovering that transition cost takes roughly 15 to 40 seconds. The same contribution gives the latency side. The wake-up delay from deep sleep is 10 to 20 ms, while from ultra-deep sleep it is 900 to 1800 ms.
We can draw two conclusions. First, the UE can use ultra-deep sleep in idle mode with a long I-DRX cycle, but cannot reach it in connected mode. Second, the network does not need to tell the UE how long it may sleep. The gap is deterministic, because it follows from the configured WUS periodicity, the time offset and the C-DRX timers.
Keep one more constraint in mind: the UE can perform EE processing only during a sleep state. It adds a relative power on top of that sleep state, and it must not trigger a transition out of it. That explains the three agreed power values: 10 during micro sleep, 12 during light sleep and 15 during other sleep. Each entry to or exit from EE processing during deep or ultra-deep sleep adds 15 units of overhead. The ramp is 2 ms. In other words, the UE picks its sleep state first. Checking WUS then adds a cost within the chosen sleep state without waking the UE.
The model lists costs, not a rule : The agreements fix the relative power, the transition energy and the transition time of each state. They do not say which state to enter. The UE implementation makes that choice.The gap length decides : The UE picks the deepest state whose break-even and ramp time fit the sleep opportunity. As a rough guide, a gap of a few ms justifies light sleep; a few tens of ms justifies deep sleep.Ultra-deep sleep is an idle-mode option : The UE needs seconds of sleep to offset the transition energy. One company therefore finds that deep sleep can outperform ultra-deep sleep at high wake-up rates.EE processing does not wake the UE : It runs inside the sleep state, at 10, 12 or 15 relative power depending on which state that is. The WUS check adds power consumption within that state without causing a transition.Ranges in the results are sleep-state assumptions : A reported spread such as 3.1% to 21.1% is not a confidence interval. The company has repeated the same evaluation for micro, light and deep sleep.
Would a longer WUS cycle with the sleep duration in the payload save more?
You might expect a longer WUS cycle to save energy, and the initial reasoning is correct. Fewer occasions consume less energy, and a longer guaranteed sleep lets the UE use a deeper state. But the saving saturates quickly, and the network cannot deliver the instruction when it would help most.
Let's calculate the saturation first. In deep sleep, the UE consumes 1 relative power per ms, and each EE processing occasion costs roughly 35 relative-power-ms. The average power over a cycle of length T is therefore about 1 plus 35 divided by T. At a 40 ms cycle that is 1.88. At 160 ms it is 1.22. At 320 ms it is 1.11, and at 640 ms it is 1.05. Extending from 40 ms to 160 ms saves 35%. Extending from 160 ms to an infinite cycle saves at most 18% more. At that point, the underlying sleep power dominates the UE's energy cost. Only ultra-deep sleep offers lower power, but its break-even takes 15 to 40 seconds. No connected-mode cycle reaches that duration.
Figure 9. Extending the WUS cycle has diminishing returns. Once sleep power dominates the occasion cost, the curve approaches the deep sleep floor. Further extension adds latency with little energy saving.
Now consider how the network could deliver that instruction. DL WUS is event-triggered: the network sends it only when it has paging or data for the UE or subgroup. One contribution states this directly. In the absence of pending traffic, no DL WUS is transmitted. Therefore the UE cannot rely on its presence at any particular monitoring occasion. We need a "sleep for a long time" instruction when there is no traffic, but the network sends nothing then. To carry it, the network would have to transmit in the quiet case as well. The same contribution makes that argument against using DL WUS for RRM measurement, and the mechanism is identical here. If we guarantee periodic transmission, we turn the on-demand wake-up signal into a periodic reference signal. We lose the efficiency of using resources only when data needs delivery.
A sleep hint in the payload can help after positive detection. The UE then knows data is coming, but does not know how soon. One company proposes carrying that gap in the WUS payload itself. The gap runs from the DL WUS occasion to the start of PDCCH monitoring. It would be short for urgent data, and long for background traffic. The UE can then choose the optimal sleep state for its main radio rather than leave it idle. Another company makes a similar point for SCell dormancy. A dormancy indication in DL WUS lets the UE sleep longer or use a deeper state.
In agenda terms, we are discussing dynamic adaptation of the monitoring cycle. The study list already includes this through dynamic active-period indication or C-DRX parameter adaptation. It beats a statically long cycle in one specific case. Consider bursty traffic where the network knows a long quiet period is coming. It can use a short cycle when latency matters and a long cycle during the quiet period. That is mostly a latency win at equal energy, rather than an energy win. Two costs apply. Every bit of payload costs coverage, at roughly 1.5 dB from 1 bit to 6 bits, and it adds blind hypotheses. In addition, any scheme that changes state on a signal needs a defined behaviour for a missed signal. If the UE wrongly believes it may sleep for several cycles, the network cannot reach it during those cycles.
The returns saturate : Extending the cycle helps until the occasion cost is small against the sleep power. After that, the curve approaches the sleep power floor, and further extension gives almost no additional saving.Latency is the binding constraint : A longer cycle trades reachability for energy directly. We must limit cycle length to meet the delay budget, especially at the 90th percentile.The instruction cannot be sent when it is needed : The network sends WUS only when there is traffic. It therefore cannot use WUS to tell the UE about a quiet period. Making WUS periodic would remove the benefit of on-demand transmission.The payload helps after detection, not before : The network can indicate the gap to PDCCH monitoring or an SCell dormancy state. The UE can then put its main radio into deeper sleep. This helps in the one window where the UE cannot predict the gap.It is already on the list : Dynamic active-period indication and C-DRX parameter adaptation are among the proposed connected-mode functions. However, the feature lead noted that the timers themselves are RAN2 territory.Every bit costs coverage : A sleep-duration field is not free. It consumes payload and therefore coverage. We also need fallback behaviour for a missed or false indication.
How should DL WUS coexist with cell DTX/DRX, PDCCH skipping and SSSG switching?
Let's start with the Rel-19 coexistence limits. When LP-WUS is configured with cell DTX, the UE is not expected to monitor LP-WUS during the cell DTX inactive time. In addition, LP-WUS works with legacy PDCCH skipping and search space set group switching, without enhancement. For 6G, companies aim higher because they are designing network and UE energy saving together, instead of in successive releases. A large group of companies proposes studying the interaction with network energy saving features. One item is using the WUS to adapt cell DTX/DRX. Another is defining UE behaviour during cell DTX active and inactive time. A third is aligning the WUS wake and sleep opportunities with the network's discontinuous transmission and reception. A fourth is adapting the WUS configuration quickly, based on the network energy state. To assess the skipping and switching interaction, consider one company's numerical results. With sparse PDCCH monitoring alongside WUS, the company reports roughly 29% and 10% additional saving for two C-DRX configurations. With even sparser monitoring, the figures rise to about 40% and 15%.
Align the two sleep patterns : If the network is asleep when the UE is awake, both sides lose. Aligning cell DTX/DRX with the WUS monitoring pattern is the cheapest joint optimisation available.Avoid duplicated monitoring adaptation features : The strongest simplification proposal uses one WUS-based framework to replace legacy PDCCH skipping and search space group switching.Skipping indications can resume WUS monitoring : Several companies propose reusing the DCI-based skip indication. It would send the UE back to WUS monitoring. This would let us reuse existing signalling without adding another indication.Coexistence is partly another agenda's problem : Two companies note that the DL control agenda already handles PDCCH skipping and search space switching. We therefore need coordination with that work.The UE cannot be woken by a sleeping cell : The WUS occasion may fall inside a cell DTX inactive period. In that case the wake-up cannot happen. We must therefore coordinate the constraints on the two configurations.
Is WUS the same idea as a Wi-Fi or Bluetooth wake-up radio?
Let's compare DL WUS and UL WUS separately, because they resemble different short-range mechanisms. First, we need to distinguish a wake-up radio from scheduled wake-ups. Wi-Fi has one. IEEE 802.11ba adds a companion receiver that sits beside the main radio. The access point sends an on-off keying wake-up packet in roughly 4 MHz, at 62.5 kbps or 250 kbps. It generates multi-carrier OOK so that an ordinary 802.11 transmitter can produce the packet. The companion receiver is an envelope detector. It needs no FFT, phase tracking or channel estimate. The design target is under a milliwatt. The packet carries an address, so the station wakes its main radio only for a packet addressed to it. Bluetooth has no such receiver in the specification. Bluetooth achieves scheduled wake-ups through timing instead. A LE peripheral advertises briefly on three advertising channels and sleeps in between. Once connected, both ends use connection events at an agreed interval. Peripheral latency lets the device skip a number of these events. BR/EDR does the same thing with page scan and inquiry scan windows, and with sniff mode. So Wi-Fi is the analogue of a wake-up signal, and Bluetooth is the analogue of DRX.
For downlink, you can recognise the Wi-Fi architecture in 5G LP-WUS. Rel-18/19 LP-WUS used a separate low-power receiver, an OOK waveform, and its own always-on synchronization signal. That is close to the 802.11ba architecture. That architecture also brought a coverage cost. The design assumed a separate receiver with a noise figure several dB worse than the main radio. Its coverage target ended up at Msg3 PUSCH level, with entry and exit conditions to handle the cell edge. 6G takes a different approach. The EE processing state uses a low-power mode of the same receiver, with the same noise figure. The signal is an OFDM sequence rather than OOK. So 6G keeps a low-cost detection step to decide whether the higher-power processing should wake up. But it does this without the separate radio in Wi-Fi. We can understand the reason by comparing coverage distances. A wake-up radio that only has to cross a room can afford to be a few dB less sensitive than the main radio. A cell cannot accept that loss so easily. This agenda's coverage discussion addresses the 4.5 to 8 dB gap to the reference PDCCH.
For uplink, reverse the roles; Bluetooth now gives us the closer comparison. An advertising peripheral sends a short packet from a low-power device to a more capable listener. UL WUS uses a similar arrangement to reach a sleeping cell. The proposals in this agenda item follow the same logic on the receiving side. One asks for a design that permits non-coherent energy-based detection, so that the base station can use a separate low-power receiver. Another proposes a narrowband format of length 127 at 1.25 kHz subcarrier spacing, occupying about 159 kHz. A narrow signal is cheap to listen for. But remember an advantage the Bluetooth advertiser has over the UE. It transmits into an unlicensed band, with no timing advance, no power control, and no cell that it has to be synchronized to.
Figure 10. Wi-Fi uses a wake-up detector; Bluetooth uses scheduled wake-ups. 6G DL WUS uses detection within the main receiver. UL WUS reverses the transmission direction.
Now let's examine why starting the cellular procedure is harder. A short-range device that sends a wake-up frame is already associated, and it is already synchronized. A UE that wants to wake a cellular cell may be neither. Before sending UL WUS, the UE needs downlink timing and frequency synchronization, a transmit power and the UL WUS configuration. A sleeping cell may transmit none of the three. This creates a circular dependency. An out-of-synchronization UE most needs an on-demand SSB, but it needs synchronization before it can transmit UL WUS. That is why this agenda item spends most of its effort on deployment scenarios, rather than on the signal itself. Read the scenario grid as a comparison of what the cell transmits before the UE makes its request.
Next, consider interference and regulation. A wake-up radio in unlicensed spectrum shares the band under listen-before-talk rules. The UE sends UL WUS in licensed spectrum toward a cell it may never have detected. We then face two problems. A UE that cannot measure pathloss cannot set a sensible transmit power. Its signal may therefore be too weak for detection or strong enough to interfere with neighbours. Also, the discussion has not settled whether spectrum regulation permits blind uplink transmission toward an undetected cell. One contribution states the design concern in a single line. The situation where any UE can wake any cell at any time should be avoided.
Only Wi-Fi actually has a wake-up radio : 802.11ba adds a second receiver: an envelope detector with a sub-milliwatt target. It detects an addressed OOK packet to trigger wake-up. Bluetooth has no such receiver. It uses scheduled advertising and connection events, which is the analogue of DRX rather than of a wake-up signal.5G copied the Wi-Fi architecture, and 6G did not : LP-WUS used a separate low-power receiver, an OOK waveform and its own always-on sync signal. 6G detects an OFDM sequence in the EE processing state of the same receiver, with the same noise figure.Coverage is what breaks the analogy : For a room-scale link, we can accept a few dB less sensitivity at little cost. We cannot do that so easily for a cell. The 4.5 to 8 dB gap to the reference PDCCH is the whole DL WUS coverage argument.The sleeping entity is reversed on the uplink : In the short-range case the goal is device battery life. For UL WUS the goal is base station energy, and the UE is the one that pays.The hard part is the bootstrap, not the detector : Before transmitting, the UE needs timing, transmit power and configuration. A sleeping cell may supply none of them. An advertising Bluetooth device needs none of the three.Licensed spectrum changes the rules : There is no listen-before-talk equivalent here. Therefore transmit power, inter-cell interference and spectrum regulation all become open questions.
If a base station serves many UEs, can it ever sleep long enough for UL WUS to help?
You're right to question whether a busy base station can sleep. That concern limits where UL WUS helps. A loaded macro cell always has some UE that needs scheduling, measurement, mobility support or data. Such a cell will not enter a deep sleep, and no wake-up signal will change that. We should therefore look for its benefit in the idle parts of a deployment.
You can see this distinction in the scenario framework. DS#2 is the multi-cell and multi-carrier case. There, cell or carrier #1 always transmits sync signals, PBCH and SIB1. Cell or carrier #2 is the one that goes quiet. In other words, there is a coverage layer and a capacity layer. The UE stays reachable through the always-on layer. It asks for the capacity layer only when it needs the capacity. One company compares this with an existing arrangement. If the UE can transmit toward cell or carrier #2 at all, that cell is effectively an SSB-less SCell. The standalone case, DS#1, is the harder one. Proposals mainly target limited conditions such as coverage holes or night-time operation.
We also need to distinguish different levels of base station sleep. The agreed study is not only about switching a base station off. It also covers adapting the number of active antenna TRxRUs to one half and one quarter of the total, and adapting the associated circuitry. We can arrange these states in order: full operation, reduced TRxRUs, low-power receive mode, then deep sleep. Each deeper state saves more static power but costs coverage and wake-up time. The working assumption records both facts. It states plainly that a base station operating with reduced active TRxRUs operates with reduced coverage.
Finally, check whether the sleep duration is long enough to offset the transition cost. The deep-sleep to active transition time is around 40 ms for a Category 1 base station. One company argues that shorter times are not feasible, because of internal subsystem dependencies. UL WUS therefore saves energy when requests are rare and sleeps are long, but not when requests are frequent. This also explains the concern about request frequency. A poorly implemented UE could ask for additional transmissions often enough to increase network energy consumption, instead of reducing it.
A loaded macro cell is not the target : Some UE always needs scheduling, measurement or mobility support. That cell stays awake, and UL WUS does not change it.The capacity layer is the target : DS#2 keeps cell or carrier #1 always on, and lets cell or carrier #2 sleep. The closest existing analogue is an SSB-less SCell.Sleep is a ladder, not a switch : Full operation, reduced TRxRUs, a low-power receive mode, and deep sleep are four different states. Each deeper state saves static power but reduces coverage.Only long sleeps pay : The deep-sleep to active transition is around 40 ms for a Category 1 base station. The sleep must therefore last long enough to offset that transition cost.Request frequency is itself a risk : A UE that asks too often can increase network energy consumption rather than reduce it. This explains the proposal for a rate limit or threshold condition.
What is UL WUS for, and is it even needed?
While DL WUS saves UE energy, UL WUS aims to save network energy. Let's examine how it would do that. The network energy saving direction in 6G is to transmit common signals less often. This means a longer synchronization signal periodicity, on-demand PBCH and SIB1, and deeper base station sleep between transmissions. One company quantifies both the saving and the latency cost. Extending the SSB and SIB1 periodicity to 160 ms gives 33% to 80% network energy saving, depending on the base station category. However, the cell detection latency grows by a factor of eight. UL WUS is the mechanism that lets a UE ask for those transmissions when it actually needs them. The network can then stay quiet by default while avoiding unacceptable access delays. But companies disagree on whether this justifies a new physical layer feature. One company questions the necessity of the agenda item altogether. It notes that on-demand sync signals and on-demand SIB1 are being handled in the initial access agenda. It also notes that there was no consensus on a low-power radio mode in the base station power model. Finally, the base station wake-up time is around 40 ms for a Category 1 base station. The expected latency benefit may therefore disappear. Another company goes further, and proposes deprioritising UL WUS. A third proposes postponing the discussion until the PRACH design is settled. Its reason is that it is not yet clear what distinguishes an UL WUS from a PRACH preamble.
The purpose is network sleep, not device sleep : Unlike DL WUS, the direct beneficiary is the base station, and the UE pays in latency, transmit power and complexity.The gain depends entirely on the baseline : One analysis attributes most of the network energy saving to the longer SSB periodicity itself. The additional gain from on-demand SIB1 is smaller. It ranges from about 4% to about 44%, depending on the assumed 6G baseline configuration.Scope overlap is a live problem : Several companies raise the risk of duplicated or inconsistent work. They see this risk across the WUS, initial access and uplink agenda items. One company therefore proposes clarifying the scope explicitly.The use cases go beyond system information : The first group of use cases is on-demand SSB, PBCH, SIB1 and other system information. Companies also propose on-demand PRACH resources, on-demand CSI-RS and waking a base station from low-power mode. Another use case is indicating uplink data arrival, or the absence of uplink data during cell DTX. Two more are selecting PUSCH resources and parameters, and indicating a new beam for beam failure recovery.The counterargument is network-triggered alternatives : Two companies repeatedly note that the network can trigger on-demand transmissions itself for connected-mode UEs. This is more efficient, and it has lower latency than waiting for a UE request. Therefore much of the motivation disappears in that state.
Which use cases are now on the candidate list?
At RAN1 #126, RAN1 agreed a candidate list. We can now use that list to examine necessity, which earlier discussions debated without an agreed list. The list separates idle and inactive mode from connected mode. For connected mode, the candidates extend well beyond asking a cell to wake up.
The four candidates are 6GR SS/PBCH, SIB1, PRACH and a DL reference signal. Each replaces something the network would otherwise provide on a fixed schedule. The pattern is the same in each case. The UE requests it on demand, so the network avoids the cost of periodic transmissions that usually have no listener.
For connected mode, start with the same four requests and add five candidates beyond cell wake-up. In these candidate uses, the UE can indicate either the presence or absence of uplink data. It can select a PUSCH resource or a transmission parameter. It can support measurement based on the UL WUS itself. It can indicate a new beam for beam failure recovery, if that is supported for 6GR.
The list widens the feature well past a wake-up : If the signal selects a PUSCH resource or reports a new beam, we are effectively designing a lightweight uplink control channel. We then need to decide whether one signal should support that whole range of functions.A no-data indication is the cheapest entry : Indicating the absence of uplink data costs one transmission and can save the network a scheduled grant. It also weakens the argument that UL WUS only benefits the base station.Candidate is not agreed : RAN1 agreed to study these candidates, not to adopt them. We still need to resolve the necessity debate described above.
Which UL WUS deployment scenarios are feasible?
Let's use the scenario framework from RAN1#124 to organise the deployment cases. It has guided every subsequent discussion. DS#1 is a standalone cell. There, the UE obtains the UL WUS configuration from that cell, or from the specification. DS#1 has three sub-cases. In DS#1a, the cell transmits nothing before UL WUS. In DS#1b, the cell transmits always-on sync signals, with or without PBCH, but no SIB1. In DS#1c, the cell transmits sync signals with PBCH and periodic SIB1. DS#2 is a multi-cell or multi-carrier case. There, the UE obtains the configuration from cell or carrier #1, which always has sync signals, PBCH and SIB1. DS#2 also has three sub-cases. In DS#2a, cell/carrier #2 transmits nothing. In DS#2b, cell/carrier #2 transmits sync signals, with or without PBCH, but no SIB1. In DS#2c, it also has periodic SIB1. The study asks RAN1 to consider the coverage target and applicable RRC states. It also asks how the UE acquires synchronization and determines transmit power. To assess feasibility, check what downlink signals exist before the UE sends its request.
Figure 11. The UL WUS scenario grid. Companies dispute feasibility mainly in the leftmost column. For the other columns, they debate necessity.
Feasibility tracks downlink availability : The more the cell transmits before the UL WUS, the more of the four questions the UE can answer. This makes feasibility straightforward for DS#1c and DS#2c, while DS#1a remains the hardest case.Three things are always needed : The UE needs downlink timing and frequency synchronization, a transmit power determination and the UL WUS configuration. If a scenario cannot supply all three, we cannot make it work regardless of the potential energy saving.Necessity is separate from feasibility : Several scenarios are feasible but lack a clear benefit. One company repeatedly argues that a UE-triggered transmission adds complexity without benefit if the network can trigger the transmission itself.RRC state applicability differs : Where SIB1 is absent, the UE cannot complete random access. We therefore treat those scenarios as idle and inactive mode cases. One company observes this for DS#1b.Multi-TRP is a fourth dimension : A proposal at RAN1#124 introduced DS#3 for multi-TRP, with four sub-cases including a TRP-cluster level SFN variant. RAN1 did not agree to it. One reason is that a transparent TRP simply reduces to DS#1 or DS#2. Several companies propose treating multi-TRP deployments as variants. There, TRP-common signals are always on, and TRP-specific transmissions are on-demand. However, several other companies propose postponing this. They want the relevant discussion to settle TRP transparency to the UE first.
DS#1a: nothing transmitted on the cell before UL WUS
Here we find the largest network energy saving, but also the most fundamental feasibility problems. RAN1 has now recorded both sides. Let's read the agreed-style observation from RAN1#125 as three separate points. The first point is synchronization. The majority of companies expressed the concern that the UE cannot discover the cell. It also cannot acquire downlink timing and frequency synchronization, even with GNSS assistance. However, some companies claimed that a GNSS-capable UE can use GNSS to derive timing and frequency. The second point is transmit power. The majority expressed the concern that the UE cannot determine transmit power without downlink signals. Some companies claimed the UE could use pre-configured or pre-defined parameters instead. Others noted that such parameters may lead to excessive interference and energy consumption. The third point is regulation. Some companies call for further study of spectrum regulation. Does it allow a UE to transmit in licensed spectrum toward a cell the UE has not detected? One contribution adds the sharpest framing. The situation where any UE can wake any cell at any time should be avoided.
GNSS does not solve synchronization : The objection is that the UE cannot directly translate GNSS timing into accurate downlink or uplink synchronization. What matters is the relative timing between the UE and the base station. In addition, the base station location may not be available.Transmit power cannot be pre-defined well : Without a pathloss estimate, we cannot choose a reliable pre-configured power. It may be too low for detection or too high, causing interference to neighbours. In addition, the base station output power is deployment dependent.Regulation is a genuine open item : Blind uplink transmission in licensed spectrum toward an undetected cell is not obviously permitted. The discussion therefore identifies this as a point to confirm before continuing design work.A bounded special case may survive : One company proposes limiting the scenario to a specific case. A stationary UE with stored historical access information could reasonably assume that a cell exists at a known location. Another proposes studying limited conditions such as coverage holes or night-time operation.Several companies want it closed : One company proposes concluding that DS#1a is infeasible. Two others propose not prioritising or deprioritising it, while a fourth proposes ending further study.
DS#1b: sync signals but no SIB1
Let's examine DS#1b closely, because it contains the main practical work. RAN1 reached an agreement on it at RAN1#124-bis. If the cell transmits always-on sync signals with PBCH, the UE can acquire downlink timing and frequency synchronization. It does so at least from those signals and the PBCH. If the cell transmits sync signals without PBCH, RAN1 leaves synchronization acquisition for further study. In both cases the UE can determine transmit power at least from the sync signals. It also needs information to determine transmit power, if that information is available. Two further study items follow. First, can the network deliver this information, for example through PBCH, or can the specification predefine it? Second, what minimum information size and content does UL WUS transmission and operation need, and how can the UE obtain it? To understand the without-PBCH disagreement, check which timing information the UE has. PSS and SSS give symbol timing and coarse frequency. However, they do not give frame boundaries. Therefore the UE cannot determine when a transmission occasion actually occurs.
PBCH is what turns coarse timing into usable timing : Several companies observe that, without PBCH, the UE knows symbol timing but not slot or frame boundaries. Those are exactly what an uplink occasion needs.Prioritise the with-PBCH case : Half a dozen companies propose prioritising the with-PBCH variant, which is now the practical direction.The configuration size is the hard constraint : One company notes that the minimum Rel-19 UL WUS configuration is over 120 bits of mandatory fields. Another puts it at over 100 bits. Either way, this does not fit into a MIB. A third company estimates at least 15 bits for the transmit power information alone.A new lightweight carrier may be needed : Proposals include a compact PBCH field with a lookup table index. Others are a SIB0 scheduled by the SSB, a split or segmented SIB1, or a common PDCCH without a scheduled PDSCH. For every option, account for the new broadcast payload needed to carry the configuration. Its transmission consumes part of the energy saving we want.Sub-band and per-band profiles : One company proposes pre-defined per-band specification profiles. These require no signalling at all. The proposal adds a 5-bit PBCH field for cell-specific adaptation. The company argues that this cuts the configuration acquisition latency by roughly an order of magnitude, compared to SIB1-only delivery.
DS#1c: a fully always-on cell
You'll find the technical feasibility more straightforward here, as RAN1#125 recorded. The UE can acquire downlink timing and frequency synchronization from the always-on 6GR SSB transmitted by the standalone cell. It can also obtain the information necessary for UL WUS transmission and operation. Finally, it can determine transmit power at least from the SSB and the periodic SIB1. We therefore need to focus on necessity. The cell is already transmitting sync signals, PBCH and SIB1 periodically. What does a UE request add? Four answers are proposed. First, the UE could request temporarily denser SSB through periodicity adaptation to speed up measurement or beam recovery. The second is on-demand SSB repetitions for coverage enhancement. The third is on-demand other system information. Fourth, a connected-mode UE could indicate uplink data arrival during a cell DTX non-active period. However, one company objects on two grounds. In idle mode, more frequent transmissions than the default are not needed. In addition, a poorly implemented UE could request additional sync signals very often. Those frequent requests would increase network energy consumption instead of saving it.
Feasibility is not in question : The cell already transmits everything the UE needs, so we can focus on costs and benefits.Periodicity adaptation is the most credible use : One company reports the effect of requesting a temporary 5 ms SSB burst. The UE awake time falls from 60 ms to 15 ms, giving about a 31% power reduction. In a high-speed train case, it also reduces the handover travel distance from 55.5 m to 1.7 m.Uplink data arrival during cell DTX : Several companies propose using UL WUS for urgent uplink data notification during a cell DTX non-active period. The UE otherwise cannot send a scheduling request in that period.Guard against request storms : The concern about frequent requests is legitimate. We therefore need a rate limit or threshold condition for any such mechanism. One company proposes exactly this, with a latency-budget-triggered request.Overlap with uplink resource request : Two companies note that another agenda item already studies uplink resource requests. An UL WUS data indication could duplicate that work.
DS#2a/2b/2c: multi-cell and multi-carrier
For multi-cell scenarios, start with the Rel-19 on-demand SIB1 arrangement. There, an anchor cell provides the configuration, and the UE transmits toward the energy-saving cell. RAN1#124-bis agreed the DS#2b feasibility observation in the same shape as DS#1b. It added two cases. When the UE transmits toward cell/carrier #1, it can synchronize and determine power from that cell. When it transmits toward cell/carrier #2 with PBCH present, it can synchronize from cell/carrier #2, or, subject to feasibility, from cell/carrier #1. In DS#2a, cell/carrier #2 transmits nothing. There, the observation records that the UE can synchronize and determine transmit power from cell/carrier #1. This holds at least when the two are synchronized, co-located and in the same band. We still need further study for non-co-located or different-band cases. One contribution helps us assess the timing margin. Assume a maximum 3 us timing difference between the two cells. Then the cyclic prefix of most 5G NR PRACH formats already covers the misalignment.
Co-location and band identity are the enabling conditions : If both cells are synchronized, co-located and in the same band, the UE can use cell/carrier #1 as its timing and pathloss reference. The RAN1 #126 study also covers non-co-located cells, with timing, power, beam and interference conditions still needing resolution.The trigger condition is unsolved for DS#2a : One observation identifies the key difficulty: without downlink from cell/carrier #2, the UE has no metric to use. It cannot decide when transmitting toward that cell is worthwhile. RSRP from cell/carrier #1 does not tell the UE about reception at cell/carrier #2.SSB-less SCell is the closest existing analogue : One company argues that if the UE can transmit toward cell/carrier #2, that cell is effectively an SSB-less SCell. Requirements already exist for such a cell. Therefore the motivation for on-demand SSB on it disappears.DS#2c is largely redundant : Suppose cell/carrier #2 has its own SSB, PBCH and SIB1. Several companies argue that this is equivalent to DS#1c and needs no separate study.Discovery signals as a middle ground : One company proposes that the network transmit a discovery signal on cell/carrier #2. The UE can then detect its presence and coverage. This moves DS#2a closer to DS#2b at low cost.
The RAN1 #126 study already extends DS#2a to non-co-located cells. A predefined transmit power, wide or omni beam, or beam sweeping is available for study. Interference mitigation, detection performance and narrow-beam determination remain open. Co-location is therefore not a universal prerequisite.
The anchor SSB can provide timing when the cells are synchronized and the UE can maintain that timing, including an underlay-coverage case. Unsynchronized cells require further work on offsets, inter-cell distance and timing advance. The duration for retaining timing and configuration also remains open.
Individual proposals add power offsets, geographic assistance and resource or signature planning. A common power offset cannot generally reproduce the target cell's pathloss. Likewise, a long PRACH cyclic prefix does not by itself establish frequency accuracy or permission to transmit.
How does the UE get the UL WUS configuration before it has SIB1?
Let's examine the configuration size, the most concrete unresolved problem in the UL WUS agenda. We face an information capacity limit, not just a choice of preferred signalling. The Rel-19 configuration for requesting on-demand SIB1 is over 120 bits of mandatory fields. The MIB carried in PBCH has nowhere near that capacity. We must either shrink the configuration substantially or deliver it another way. Otherwise, the standalone scenario cannot work. RAN1 has captured five candidate mechanisms for study. The first is pre-configuration or pre-definition in the specification. The second is PSS/SSS, or a light synchronization signal if one is supported. The third is PBCH, including the PBCH DMRS. The fourth is a broadcast PDSCH, such as a split SIB1. The fifth is a common PDCCH. As you compare these mechanisms, check the limitation of each one. Pre-definition removes network flexibility in placing the signal within the carrier. PBCH delivery consumes MIB capacity that other functions also want. A new SIB0 adds a broadcast transmission that consumes part of the energy saving. A common PDCCH requires the UE to monitor control channels before it has system information.
Quantify the minimum first : Several companies propose analysing how few bits are actually needed. They reject simply starting from the Rel-19 field list. One contribution offers a concrete candidate of about 24 mandatory bits. These cover waveform identity, sequence length, subcarrier spacing and offset, and cyclic shift. They also cover the root set, power index and occasion period. With optional fields, the total extends to about 34 bits.Index into a specification table : One proposal defines parameter sets in a specification lookup table. PBCH then needs to carry only a row index. This is the most economical way to keep both flexibility and small payload.Beware of the circularity : One company identifies the circular dependency clearly. UEs that need an on-demand SSB are typically out of synchronization. However, transmitting an UL WUS requires synchronization. So we cannot start the procedure using the very on-demand signal that the UE is trying to request.Delivery latency matters as much as size : One estimate covers a compact PBCH-level delivery. It reduces the configuration acquisition latency to roughly 37 ms in DS#1b. SIB1-only delivery means a much longer wait. Keep this latency in the comparison, because we want on-demand operation without degrading access latency.Unify the configuration across purposes : Two companies propose a single UL WUS configuration. It would serve on-demand SSB, PBCH, SIB1 and other system information. The UE would use different preambles or sequences within a shared occasion to indicate its request. This avoids a separate configuration for each purpose.
How are the DS#1b configuration options being narrowed?
RAN1 #126 kept all five mechanisms and added criteria for comparing them. Pay attention to two changes: the study explicitly allows combinations, and it names a reference configuration for comparing payload requirements.
None of the five comfortably carries the whole configuration. With combinations in scope, we can consider how to split the fields across mechanisms. A few PBCH bits can select a predefined parameter set, while a synchronization signal can carry a coarse index. We can therefore divide the payload across them.
SIB26, the NR on-demand SIB1 configuration, is the agreed reference. It gives us a real configuration for a comparable task. We can now check small-payload claims against that known configuration instead of an estimate.
We need to compare four criteria, each favouring different choices. Network configuration flexibility favours signalling the parameters. Network and UE energy saving favours predefinition because the network need not transmit those parameters. UE complexity favours whatever the UE already decodes. Signalling overhead favours the smallest payload, which is usually predefinition again.
Predefinition wins on cost and loses on flexibility : Three of the four criteria favour putting parameters in the specification. The remaining criterion is configuration flexibility, which matters to the operator. A fixed placement gives the operator no freedom to move it when planning the carrier.The DMRS route is now explicit : The study explicitly names PBCH DMRS alongside PBCH itself. By selecting a DMRS sequence, the network can convey a few bits without consuming MIB capacity needed by other functions.
The #126-bis contributions give widely different payload estimates because they retain different flexibility. Some use a small index into predefined profiles. Others retain resource placement, power control, response monitoring and cell-access information and reach roughly 200 to 240 bits. These are different configuration designs.
The configuration carrier also needs adequate coverage. A large common DCI can require repetitions, while a light SIB adds PDSCH reception and broadcast overhead. Packing it beside SSB in frequency can preserve network sleep time but still consumes resources and UE receive energy.
The information study covers resource size and location, synchronization-signal association, power, sequence or format, response monitoring and cell access. Each field needs classification as implicit, predefined, profile-indexed or explicitly signaled. A compact bit count is meaningful only with that classification.
Should UL WUS be a PRACH preamble or a new signal?
Most companies propose starting from the PRACH preamble, so let's examine what additional requirements UL WUS might need. This is also what Rel-19 did for the on-demand SIB1 request. The feature lead's proposal reflects this. It asks only whether additional performance requirements are needed beyond the 6GR PRACH. The feature lead gives two examples: base station receiver architecture and robustness to uplink synchronization error. The arguments for something new are specific, rather than general. One company proposes a narrowband format. Its configuration has length 127 at 1.25 kHz subcarrier spacing, and it occupies about 159 kHz. The company reports about 8.17 dB of link budget gain over baseline PRACH. That is enough to keep detection reliable, even when the base station receives with half its normal antenna count. The same contribution proposes an augmented m-sequence construction. The company proposes this construction for robustness under large frequency offset. It reports about 1 dB better sensitivity than Zadoff-Chu, at a frequency offset of twice the subcarrier spacing. Another company argues for a design that permits non-coherent energy-based detection. In that case the base station can use a separate low-power receiver.
Reuse avoids a second access signal : If a base station must monitor both PRACH and separate UL WUS occasions, it saves less energy. A single set of occasions with partitioned preambles gives us a better energy-saving arrangement.Partitioning is the practical middle ground : Several companies propose distinguishing UL WUS from ordinary random access. They propose dedicated occasions or preamble partitions within the PRACH framework. The base station can then use one detector while keeping the functions separate.Coverage is the recurring requirement : One company proposes coverage equivalent to PRACH, regardless of the RRC state. Another proposes that UL WUS must meet its targets at 3 to 6 dB worse SNR than baseline PRACH. About 3 dB of this comes from reduced base station antennas. A further 2 to 3 dB comes from a relaxed low-power receiver.CFO tolerance is scenario-specific : In anchor-assisted scenarios, one company proposes assuming a worst-case uncertainty of plus or minus 0.3 ppm. This combines the UE oscillator drift with the frequency errors of both cells. At 7 GHz it is about 2.1 kHz. That is significant against a narrowband design.Capacity requirements vary by use case : One company gives us a useful scale for sequence capacity. A pure cell wake-up needs one sequence. An additional indication needs about eight. Integration with PRACH functionality needs about 64. We can use these counts to size the sequence design for the selected use cases.Sequence to cell mapping : One company notes that an UL WUS may be heard by several cells. It therefore proposes mapping a sequence of PRACH preambles from the cell identity. Only the intended cell would then wake. This problem does not arise for ordinary random access.
The individual papers broadly use PRACH as the idle/inactive starting point, while some connected-mode proposals also consider PUCCH, SRS or SR enhancement. Reusing a sequence family still leaves occasion partitioning, request identity and response behavior to define.
A cell-common request and a UE-specific request need different handling. Several UEs can request the same common broadcast without needing separate identities. A request for a UE-specific grant needs identification and collision handling. The request semantics therefore determine useful sequence capacity.
After a request, the UE also needs a response window and a failure rule. Network wake-up delay may justify waiting before PDCCH monitoring starts. Retransmission, backoff, maximum attempts and fallback remain proposed procedure details; an unanswered request cannot leave UE behavior undefined.
How much network energy does UL WUS actually save?
Before choosing a reported gain, let's understand why the numbers vary so widely. At the optimistic end, one company reports the overall network energy saving. The company reports about 49.9% and 41.6% for standalone cell wake-up cases, and about 40.3% and 32.9% for anchor-assisted cases. The evaluation shows a 45% to 59% reduction in non-active base station power. Another company reports up to 40.8% for standalone on-demand SIB1 in DS#1b. It also reports up to 43.3% for on-demand SSB in the spatial domain. A third reports 10% to 27% for Category 1 base stations, 7% to 17% for Category 2, and 10% to 24% for Category 2+. At the pessimistic end, a fourth company counts the overhead as well. It includes both configuration transmission and uplink signal detection costs. With it included, the gain of on-demand SIB1 for idle and inactive mode is limited. It is about 3.7% with a 20 ms SSB periodicity, and 6.5% with 160 ms. To understand the different results, look at their baselines. Most of the gain comes from the increased SSB periodicity itself. The additional contribution of on-demand SIB1 ranges from about 4% to about 44%. That range depends entirely on the assumed 6G baseline.
The baseline determines the answer : Against an NR-style 20 ms always-on baseline, the gains look enormous. However, a 6G baseline already has long periodicity, clustering and frequency multiplexing. When you use that 6G baseline, the gains shrink dramatically.Count the cost of the configuration : The network may need a larger PBCH or a new SIB0 transmission to carry UL WUS configuration. We must subtract that transmission cost from the saving. That is what drives the much lower figures at the pessimistic end.Waking the whole cell beats waking one channel : One comparison covers anchor-assisted on-demand cell activation, where both SSB and SIB1 are on-demand. The comparison shows substantially more saving than on-demand SIB1 alone. The reason is that the always-on sync signal is what keeps the base station from sleeping.Latency is the counterweight : The UL WUS occasion periodicity bounds acquisition delay. The UE therefore needs frequent occasions to send a request with little delay. However, frequent occasions prevent the network from entering deep sleep. One contribution states this tension directly.UE cost is small when requests are rare : One company reports the UE side of the cost. When the UE transmits UL WUS infrequently, the impact on UE power consumption is negligible. This supports UL WUS in low-mobility, low-load conditions but weakens the case under high mobility.Align the assumptions before comparing : One proposal is to align the simulation assumptions across deployment scenarios and use cases. Given the spread of results, aligning these assumptions is arguably the most useful next step.
What must a comparable UL WUS evaluation include?
RAN1 #126-bis agreed reporting templates for on-demand SS/PBCH, SIB1, their combined request and connected-mode uplink-data use cases. They make the baseline explicit before comparing gains. This is evaluation alignment, not selection of those use cases for normative support. The templates also expose whether a reported saving comes from longer broadcast periods, different network sleep behavior or the request mechanism itself.
Each result needs the deployment scenario, RRC state, BS category and reference set. It also needs SSB/SIB1/RACH configuration, multiplexing, network load, request rate, WUS resources and configuration-delivery assumptions. SIB1 reference periodicity is 20 or 160 ms.
Both network and UE energy gains or losses must be reported with latency, throughput or QoS where applicable. A request rate needs its reference period. Results must also state what the network transmits after the request and for how long.
UL data indication needs comparison with SR, BSR and configured grants. One proposal reports 7% to 36% network saving against an SR baseline in DS#1c, but this depends on partial BS activation. Other contributions question the incremental benefit. The BS model and coverage compensation must accompany the claim.
Should the base station have a low-power receive mode, and how is it modelled?
Finally, we need to check whether the base station can monitor WUS with less power than full reception. Much of the UL WUS argument depends on this. RAN1#124 agreed to study adapting the number of active antenna TRxRUs to one half and one quarter of the total. It also agreed to study adapting the associated circuitry. However, it left the power model itself for further study. By RAN1#125 a working assumption had taken shape. Base station power is the sum of a dynamic part and a static part. The dynamic part follows TR 38.864 for active transmission or reception, and it is zero in sleep. The static part follows one of two options. Option 1 uses the relative power of the current sleep state. Option 2 scales the static power by the fraction of active TRxRUs, using a scaling factor. It also uses separate transition energies for the active and inactive fractions. Option 2 applies only to the Set 4 reference configuration, with more than 64 TRxRUs. Keep two notes in mind when you use this model. First, the specification bases its signal and channel properties on the assumption that the base station uses all its TRxRUs. But this does not require the base station to use them all for UL WUS reception. Second, a base station operating with reduced active TRxRUs operates with reduced coverage.
Reduced antennas means reduced coverage : The working assumption now states this explicitly. We can therefore include the uplink coverage cost when assessing network energy saving.The UE pays for the network's saving : One observation identifies who pays: a low-power receive mode shifts the energy burden to the UE. The UE must compensate for the link budget loss through higher transmit power or repetitions. This worsens the uplink and downlink coverage imbalance. It also raises inter-cell interference at the cell edge.Wake-up time may negate the benefit : One company notes a hardware limit. Category 1 performance for the deep-sleep to active transition is roughly 40 ms. The company argues that internal subsystem dependencies prevent shorter times, even with radio-only operation in a low-power mode.Transition time partitioning is now explicit : The working assumption offers ramp-down and ramp-up splits of the total transition time. The RAN1 #125 evaluation agreement uses 30% ramp-down and 70% ramp-up. Check the ramp-up share, because it dominates the latency the UE experiences.Which signals survive in the reduced mode : One company proposes a minimal definition for the reduced mode. A base station with reduced active TRxRUs can still transmit at least the 6G synchronization signal and the DL WUS. PBCH is left open. It can also receive at least PRACH preambles and UL WUS. We can use this as a starting point for defining reduced-mode operation.Narrowband uplink design as compensation : The narrowband UL WUS proposal explicitly targets this coverage loss. Concentrating the uplink energy into a narrow band recovers link budget. This compensates for the link budget loss from fewer receive antennas.
Update Note
- 2026-10-16 - Updated DL design, payload, synchronization, detection metrics, paging, EE measurement, connected operation, additional functions and UL WUS evaluation from the available RAN1 #126-bis TDocs; added Agreed Items and individual references.
- 2026-08-30 - Subsections added under DL WUS coverage target, DL WUS synchronization and DL WUS network resource, from the RAN1 #126 contributions of the nine tracked companies.
- 2026-08-29 - Subsections added under DL WUS coverage target, what UL WUS is for, UL WUS configuration before SIB1 and Reference, from the RAN1 #126 moderator summaries.
Reference
- R1-2601725 (RAN1#124) : Final summary of 6GR DL WUS sequence design (Moderator, Ericsson)
- R1-2601723 (RAN1#124) : Final summary on 6GR DL WUS operation in RRC states (Moderator, vivo)
- R1-2601660 (RAN1#124) : Summary #3 of uplink WUS and operation for 6GR (Moderator, LG Electronics)
- R1-2600045 (RAN1#124) : On the design of WUS with OFDM based sequence (Nokia)
- R1-2600157 (RAN1#124) : Design of WUS with OFDM based sequence (Huawei, HiSilicon)
- R1-2600215 (RAN1#124) : Design of WUS with OFDM based sequence (Ericsson)
- R1-2600517 (RAN1#124) : Discussion on design of 6GR DL WUS with OFDM based sequence (vivo)
- R1-2601242 (RAN1#124) : Design of downlink WUS with OFDM based sequence (MediaTek)
- R1-2601285 (RAN1#124) : DL WUS Design (Qualcomm)
- R1-2600201 (RAN1#124) : Discussion on the signal design of DL WUS (OPPO)
- R1-2600457 (RAN1#124) : Discuss on DL WUS with OFDM based sequence (ZTE, Sanechips)
- R1-2600841 (RAN1#124) : Design of 6G DL WUS with OFDM based sequence (Apple)
- R1-2600769 (RAN1#124) : Discussion on design of DL WUS with OFDM based sequence (Samsung)
- R1-2600359 (RAN1#124) : Design of WUS with OFDM based sequence (Tejas Networks)
- R1-2600046 (RAN1#124) : On WUS operation in different RRC states (Nokia)
- R1-2600518 (RAN1#124) : Discussions on 6GR DL WUS operation in RRC states (vivo)
- R1-2600158 (RAN1#124) : WUS operation in RRC states (Huawei, HiSilicon)
- R1-2601243 (RAN1#124) : WUS operation in RRC states (MediaTek)
- R1-2601210 (RAN1#124) : Discussion on WUS operation in RRC states (Google)
- R1-2600312 (RAN1#124) : Discussion on design of WUS with OFDM based sequences (CATT)
- R1-2600458 (RAN1#124) : Discuss on DL WUS operation (ZTE, Sanechips)
- R1-2600159 (RAN1#124) : UL-WUS and Operation (Huawei, HiSilicon)
- R1-2600203 (RAN1#124) : Discussion on 6GR UL WUS and operations (OPPO)
- R1-2600217 (RAN1#124) : Uplink WUS and operation (Ericsson)
- R1-2600519 (RAN1#124) : Discussions on 6GR uplink WUS and operation (vivo)
- R1-2601244 (RAN1#124) : Uplink WUS and operation (MediaTek)
- R1-2600459 (RAN1#124) : Discuss on UL WUS and operation (ZTE, Sanechips)
- R1-2600558 (RAN1#124) : Discussion on UL WUS and operation for 6GR (LG Electronics)
- R1-2603446 (RAN1#124-bis) : Final Summary of 6GR DL WUS sequence design (Moderator, Ericsson)
- R1-2603452 (RAN1#124-bis) : Final summary on 6GR DL WUS operation in RRC states (Moderator, vivo)
- R1-2603343 (RAN1#124-bis) : Summary #3 of uplink WUS and operation for 6GR (Moderator, LG Electronics)
- R1-2601845 (RAN1#124-bis) : On the design of WUS with OFDM based sequence (Nokia)
- R1-2601939 (RAN1#124-bis) : Design of WUS with OFDM based sequence (Huawei, HiSilicon)
- R1-2601902 (RAN1#124-bis) : Design of WUS with OFDM based sequence (Ericsson)
- R1-2602027 (RAN1#124-bis) : Discussion on design of 6GR DL WUS with OFDM based sequence (vivo)
- R1-2602617 (RAN1#124-bis) : Design of downlink WUS with OFDM based sequence (MediaTek)
- R1-2603026 (RAN1#124-bis) : DL WUS Design (Qualcomm)
- R1-2602444 (RAN1#124-bis) : Discussion on the signal design of DL WUS (OPPO)
- R1-2602647 (RAN1#124-bis) : Discuss on DL WUS with OFDM based sequence (ZTE, Sanechips)
- R1-2602670 (RAN1#124-bis) : Design of 6G DL WUS with OFDM based sequence (Apple)
- R1-2602199 (RAN1#124-bis) : Discussion on design of DL WUS with OFDM based sequence (Samsung)
- R1-2602092 (RAN1#124-bis) : Design of WUS with OFDM based sequence (Tejas Networks)
- R1-2602923 (RAN1#124-bis) : Discussion on WUS operation in RRC states (Google)
- R1-2602513 (RAN1#124-bis) : Discussion on design of WUS with OFDM based sequences (CATT)
- R1-2602548 (RAN1#124-bis) : Discussion on UL WUS and operation for 6GR (LG Electronics)
- R1-2605063 (RAN1#125) : Summary #2 of 6GR DL WUS design (Moderator, Ericsson)
- R1-2605094 (RAN1#125) : Summary #3 on 6GR DL WUS operation in RRC states (Moderator, vivo)
- R1-2605057 (RAN1#125) : Summary #3 of uplink WUS and operation for 6GR (Moderator, LG Electronics)
- R1-2603531 (RAN1#125) : On the design of WUS with OFDM based sequence (Nokia)
- R1-2604273 (RAN1#125) : Design of WUS with OFDM based sequence (Huawei, HiSilicon)
- R1-2603667 (RAN1#125) : Design of WUS with OFDM based sequence (Ericsson)
- R1-2603658 (RAN1#125) : Discussion on design of 6GR DL WUS with OFDM based sequence (vivo)
- R1-2604358 (RAN1#125) : Design of downlink WUS with OFDM based sequence (MediaTek)
- R1-2604124 (RAN1#125) : Discussion on the signal design of DL WUS (OPPO)
- R1-2603703 (RAN1#125) : Discuss on DL WUS with OFDM based sequence (ZTE, Sanechips)
- R1-2603870 (RAN1#125) : Design of 6G DL WUS with OFDM based sequence (Apple)
- R1-2604196 (RAN1#125) : Discussion on design of DL WUS with OFDM based sequence (Samsung)
- R1-2603770 (RAN1#125) : Design of WUS with OFDM based sequence (Tejas Networks)
- R1-2603532 (RAN1#125) : On WUS operation in different RRC states (Nokia)
- R1-2603659 (RAN1#125) : Discussions on 6GR DL WUS operation in RRC states (vivo)
- R1-2604274 (RAN1#125) : WUS operation in RRC states (Huawei, HiSilicon)
- R1-2603704 (RAN1#125) : Discuss on DL WUS operation (ZTE, Sanechips)
- R1-2604126 (RAN1#125) : Discussion on 6GR UL WUS and operations (OPPO)
- R1-2603669 (RAN1#125) : Uplink WUS and operation (Ericsson)
- R1-2603662 (RAN1#125) : Discussions on 6GR uplink WUS and operation (vivo)
- R1-2603705 (RAN1#125) : Discuss on UL WUS and operation (ZTE, Sanechips)
- R1-2604061 (RAN1#125) : Discussion on UL WUS and operation for 6GR (LG Electronics)
- R1-2605479 (RAN1#126) : Summary #1 on 6GR DL WUS operation in RRC states (Moderator, vivo)
- R1-2605480 (RAN1#126) : Summary #2 on 6GR DL WUS operation in RRC states (Moderator, vivo)
- R1-2606749 (RAN1#126) : FL Summary #1 on WUS operation with other functionalities (Moderator, Apple)
- R1-2606781 (RAN1#126) : Summary #1 of 6GR DL WUS design (Moderator, Ericsson)
- R1-2606782 (RAN1#126) : Summary #2 of 6GR DL WUS design (Moderator, Ericsson)
- R1-2606783 (RAN1#126) : Summary #3 of 6GR DL WUS design (Moderator, Ericsson)
- R1-2606784 (RAN1#126) : Summary #4 of 6GR DL WUS design (Moderator, Ericsson)
- R1-2606821 (RAN1#126) : Summary #1 of uplink WUS and operation for 6GR (Moderator, LG Electronics)
- R1-2606822 (RAN1#126) : Summary #2 of uplink WUS and operation for 6GR (Moderator, LG Electronics)
- R1-2606823 (RAN1#126) : Summary #3 of uplink WUS and operation for 6GR (Moderator, LG Electronics)
- R1-2606824 (RAN1#126) : Summary #4 of uplink WUS and operation for 6GR (Moderator, LG Electronics)
- R1-2605304 (RAN1#126) : Design of WUS with OFDM based sequence (Huawei, HiSilicon)
- R1-2605305 (RAN1#126) : WUS operation in RRC states (Huawei, HiSilicon)
- R1-2605306 (RAN1#126) : UL-WUS and Operation (Huawei, HiSilicon)
- R1-2605313 (RAN1#126) : WUS operation with other functionalities (Huawei, HiSilicon)
- R1-2605315 (RAN1#126) : Design of WUS with OFDM based sequence (Ericsson)
- R1-2605316 (RAN1#126) : WUS operation in RRC states (Ericsson)
- R1-2605317 (RAN1#126) : Uplink WUS and operation (Ericsson)
- R1-2605318 (RAN1#126) : WUS operation with other functionalities (Ericsson)
- R1-2605397 (RAN1#126) : On the design of WUS with OFDM based sequence (Nokia)
- R1-2605398 (RAN1#126) : On WUS operation in different RRC states (Nokia)
- R1-2605399 (RAN1#126) : On Uplink WUS and corresponding operation (Nokia)
- R1-2605400 (RAN1#126) : WUS Operation with other functionalities (Nokia)
- R1-2605846 (RAN1#126) : Discussion on design of WUS with OFDM based sequence (Samsung)
- R1-2605847 (RAN1#126) : Discussion on WUS operation in RRC states (Samsung)
- R1-2605848 (RAN1#126) : Discussion on Uplink WUS and operation (Samsung)
- R1-2605849 (RAN1#126) : WUS Operation with Other Functionalities (Samsung)
- R1-2605922 (RAN1#126) : Discussion on the signal design of DL WUS (OPPO)
- R1-2605923 (RAN1#126) : Discussion on 6G WUS operation in different RRC states (OPPO)
- R1-2605924 (RAN1#126) : Discussion on WUS with other functionalities (OPPO)
- R1-2605925 (RAN1#126) : Discussion on 6GR UL WUS and operations (OPPO)
- R1-2606036 (RAN1#126) : Design of 6G DL WUS with OFDM based sequence (Apple)
- R1-2606037 (RAN1#126) : 6G DL WUS operation in RRC states (Apple)
- R1-2606038 (RAN1#126) : On 6G UL WUS and operation (Apple)
- R1-2606039 (RAN1#126) : On WUS operation with other functionalities (Apple)
- R1-2606148 (RAN1#126) : Design of downlink WUS with OFDM based sequence (MediaTek Inc.)
- R1-2606149 (RAN1#126) : WUS operation in RRC states (MediaTek Inc.)
- R1-2606150 (RAN1#126) : Uplink WUS and operation (MediaTek Inc.)
- R1-2606151 (RAN1#126) : WUS operation with other functionalities (MediaTek Inc.)
- R1-2606390 (RAN1#126) : DL WUS Design (Qualcomm Incorporated)
- R1-2606391 (RAN1#126) : DL WUS Operation (Qualcomm Incorporated)
- R1-2606392 (RAN1#126) : UL WUS Design and Operation (Qualcomm Incorporated)
- R1-2606393 (RAN1#126) : WUS Operation with Other Functionalities (Qualcomm Incorporated)
- R1-2606516 (RAN1#126) : Discussion on design of WUS with OFDM based sequence (NTT DOCOMO, INC.)
- R1-2606517 (RAN1#126) : Discussion on WUS operation in RRC states (NTT DOCOMO, INC.)
- R1-2606518 (RAN1#126) : Discussion on Uplink WUS and operation (NTT DOCOMO, INC.)
- R1-2606519 (RAN1#126) : Discussion on WUS operation with other functionalities (NTT DOCOMO, INC.)
- R1-2606735 (RAN1#126) : WUS operation with other functionalities (MediaTek (Shenzhen) Inc.)
- R1-2606790 (RAN1#126) : Discussion on design of WUS with OFDM based sequence (Samsung)
- R1-2606811 (RAN1#126) : DL WUS Design (Qualcomm Incorporated)
- R1-2606981 (RAN1#126-bis) : LS on WUS/C-DRX (RAN2, vivo)
- R1-2607014 (RAN1#126-bis) : Evaluation of DL WUS sequence candidate configurations and UE-specific monitoring candidate numbers (USTB)
- R1-2607030 (RAN1#126-bis) : Discussion on 6G Design of WUS with OFDM based Sequence (FUTUREWEI)
- R1-2607031 (RAN1#126-bis) : Discussion on 6G WUS Operation in RRC States (FUTUREWEI)
- R1-2607032 (RAN1#126-bis) : Discussion on 6G Uplink WUS and Operation (FUTUREWEI)
- R1-2607077 (RAN1#126-bis) : On the design of WUS with OFDM based sequence (Nokia)
- R1-2607078 (RAN1#126-bis) : On WUS operation in different RRC states (Nokia)
- R1-2607079 (RAN1#126-bis) : On Uplink WUS and corresponding operation (Nokia)
- R1-2607080 (RAN1#126-bis) : WUS Operation with other functionalities (Nokia)
- R1-2607094 (RAN1#126-bis) : Further discussion on 6GR DL WUS with OFDM based sequence (Quectel)
- R1-2607126 (RAN1#126-bis) : Discussion on design of WUS with OFDM based sequence (Spreadtrum, UNISOC)
- R1-2607127 (RAN1#126-bis) : Discussion on WUS operation in RRC states (Spreadtrum, UNISOC)
- R1-2607128 (RAN1#126-bis) : Discussion on Uplink WUS and operation (Spreadtrum, UNISOC)
- R1-2607129 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (Spreadtrum, UNISOC)
- R1-2607171 (RAN1#126-bis) : Discussion on the sequence design for DL WUS in 6GR (CMCC)
- R1-2607172 (RAN1#126-bis) : Discussion on the DL WUS for 6GR (CMCC)
- R1-2607173 (RAN1#126-bis) : Discussion on uplink WUS and operation (CMCC)
- R1-2607174 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (CMCC)
- R1-2607223 (RAN1#126-bis) : Discussion on Downlink WUS with OFDM based sequence for 6GR (Xiaomi)
- R1-2607224 (RAN1#126-bis) : Discussion on Downlink WUS in RRC states for 6GR (Xiaomi)
- R1-2607225 (RAN1#126-bis) : Discussion on Uplink WUS and operation for 6GR (Xiaomi)
- R1-2607226 (RAN1#126-bis) : Discussion on other functions for 6GR WUS (Xiaomi)
- R1-2607266 (RAN1#126-bis) : Discussion on the signal design of DL WUS (OPPO)
- R1-2607267 (RAN1#126-bis) : Discussion on 6G WUS operation in different RRC states (OPPO)
- R1-2607268 (RAN1#126-bis) : Discussion on WUS with other functionalities (OPPO)
- R1-2607269 (RAN1#126-bis) : Discussion on 6GR UL WUS and operations (OPPO)
- R1-2607292 (RAN1#126-bis) : Design of WUS with OFDM based sequence (Ericsson)
- R1-2607293 (RAN1#126-bis) : WUS operation in RRC states (Ericsson)
- R1-2607294 (RAN1#126-bis) : Uplink WUS and operation (Ericsson)
- R1-2607295 (RAN1#126-bis) : WUS operation with other functionalities (Ericsson)
- R1-2607358 (RAN1#126-bis) : Discussion on design of 6GR DL WUS with OFDM based sequence (vivo)
- R1-2607359 (RAN1#126-bis) : Discussions on 6GR DL WUS operation in RRC states (vivo)
- R1-2607360 (RAN1#126-bis) : Summary #1 on 6GR DL WUS operation in RRC states (Moderator (vivo))
- R1-2607361 (RAN1#126-bis) : Summary #2 on 6GR DL WUS operation in RRC states (Moderator (vivo))
- R1-2607362 (RAN1#126-bis) : Discussions on 6GR uplink WUS and operation (vivo)
- R1-2607363 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (vivo)
- R1-2607379 (RAN1#126-bis) : Discussion on DL WUS with OFDM based sequence (ZTE Corporation, Sanechips)
- R1-2607380 (RAN1#126-bis) : Discussion on DL WUS operation (ZTE Corporation, Sanechips)
- R1-2607381 (RAN1#126-bis) : Discussion on UL WUS (ZTE Corporation, Sanechips)
- R1-2607382 (RAN1#126-bis) : Discussion on WUS with other functionalities (ZTE Corporation, Sanechips)
- R1-2607423 (RAN1#126-bis) : Discussion on design of WUS with OFDM based sequence (CATT)
- R1-2607424 (RAN1#126-bis) : Discussion on WUS operation in RRC states (CATT)
- R1-2607425 (RAN1#126-bis) : Discussion on uplink WUS and operation (CATT)
- R1-2607426 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (CATT)
- R1-2607457 (RAN1#126-bis) : Discussion on uplink WUS and operation for 6GR (Sharp)
- R1-2607477 (RAN1#126-bis) : Design of WUS with OFDM based sequence (Huawei, HiSilicon)
- R1-2607478 (RAN1#126-bis) : WUS operation in RRC states (Huawei, HiSilicon)
- R1-2607479 (RAN1#126-bis) : UL-WUS and Operation (Huawei, HiSilicon)
- R1-2607486 (RAN1#126-bis) : WUS operation with other functionalities (Huawei, HiSilicon)
- R1-2607499 (RAN1#126-bis) : Discussion on WUS design with OFDM-based sequence (Lenovo)
- R1-2607519 (RAN1#126-bis) : Discussion on WUS Operation with Other Functionalities (FUTUREWEI)
- R1-2607583 (RAN1#126-bis) : Discussion on design of WUS with OFDM based sequence (Samsung)
- R1-2607584 (RAN1#126-bis) : Discussion on WUS operation in RRC states (Samsung)
- R1-2607585 (RAN1#126-bis) : Discussion on Uplink WUS and operation (Samsung)
- R1-2607586 (RAN1#126-bis) : WUS Operation with Other Functionalities (Samsung)
- R1-2607633 (RAN1#126-bis) : Discussion on DL WUS operation in RRC states (1Finity)
- R1-2607683 (RAN1#126-bis) : Discussion on design of WUS with OFDM based sequence (NEC)
- R1-2607684 (RAN1#126-bis) : Discussion on WUS operation in RRC states (NEC)
- R1-2607685 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (NEC)
- R1-2607702 (RAN1#126-bis) : Discussion on the design of WUS based on OFDM sequence (HONOR)
- R1-2607703 (RAN1#126-bis) : Discussion on WUS operation in RRC states (HONOR)
- R1-2607704 (RAN1#126-bis) : Discussion on Uplink WUS and operation (HONOR)
- R1-2607708 (RAN1#126-bis) : Discussion on Design of WUS with OFDM based sequence (Panasonic)
- R1-2607709 (RAN1#126-bis) : Discussion on WUS operation in RRC states (Panasonic)
- R1-2607710 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (Panasonic)
- R1-2607719 (RAN1#126-bis) : Design of WUS with OFDM based sequence (Tejas Networks Limited)
- R1-2607720 (RAN1#126-bis) : Uplink WUS and operation (Tejas Networks Limited)
- R1-2607738 (RAN1#126-bis) : Uplink WUS and operation for 6GR (Panasonic)
- R1-2607740 (RAN1#126-bis) : WUS operation in RRC states (Lenovo)
- R1-2607741 (RAN1#126-bis) : WUS operation with other functionalities (Lenovo)
- R1-2607742 (RAN1#126-bis) : DL WUS and operation in 6GR (InterDigital, Inc.)
- R1-2607743 (RAN1#126-bis) : WUS operation in RRC states for 6GR (InterDigital, Inc.)
- R1-2607744 (RAN1#126-bis) : Uplink WUS and operation for 6GR (InterDigital, Inc.)
- R1-2607745 (RAN1#126-bis) : WUS operation with other functionalities (InterDigital, Inc.)
- R1-2607752 (RAN1#126-bis) : Discussion on design of WUS with OFDM based sequence (EURECOM)
- R1-2607840 (RAN1#126-bis) : Discussion on design of DL WUS with OFDM based sequence for 6GR (LG Electronics)
- R1-2607841 (RAN1#126-bis) : Discussion on DL WUS operation in RRC states for 6GR (LG Electronics)
- R1-2607842 (RAN1#126-bis) : Discussion on UL WUS and operation for 6GR (LG Electronics)
- R1-2607843 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (LG Electronics)
- R1-2607859 (RAN1#126-bis) : WUS operation in RRC states (China Telecom)
- R1-2607905 (RAN1#126-bis) : Design of downlink WUS with OFDM based sequence (MediaTek Inc.)
- R1-2607906 (RAN1#126-bis) : WUS operation in RRC states (MediaTek Inc.)
- R1-2607907 (RAN1#126-bis) : Uplink WUS and operation (MediaTek Inc.)
- R1-2607908 (RAN1#126-bis) : WUS operation with other functionalities (MediaTek Inc.)
- R1-2607920 (RAN1#126-bis) : Discussion on UL-WUS Aspects in 6G (NEC)
- R1-2607932 (RAN1#126-bis) : Discussion on design of WUS with OFDM based sequence (Google)
- R1-2607933 (RAN1#126-bis) : Discussion on WUS operation in RRC states (Google)
- R1-2607934 (RAN1#126-bis) : Discussion on uplink WUS and operation (Google)
- R1-2607935 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (Google)
- R1-2607936 (RAN1#126-bis) : Disscussion on Design of WUS with OFDM based sequence (Sharp)
- R1-2607937 (RAN1#126-bis) : Discussion on WUS operation in RRC states (Sharp)
- R1-2607938 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (Sharp)
- R1-2607983 (RAN1#126-bis) : Discussion on 6G DL WUS design (Kyocera Corporation)
- R1-2607984 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (Kyocera Corporation)
- R1-2608043 (RAN1#126-bis) : On design of WUS with OFDM based sequence (Sony)
- R1-2608044 (RAN1#126-bis) : Discussion on WUS operation in RRC states (Sony)
- R1-2608045 (RAN1#126-bis) : Discussion on the Uplink WUS and operation (Sony)
- R1-2608085 (RAN1#126-bis) : Discussion on design of WUS with OFDM based sequence (ETRI)
- R1-2608086 (RAN1#126-bis) : Discussion on WUS operation in RRC states (ETRI)
- R1-2608087 (RAN1#126-bis) : Discussion on uplink WUS and operation for 6GR (ETRI)
- R1-2608088 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (ETRI)
- R1-2608223 (RAN1#126-bis) : Design of 6G DL WUS with OFDM based sequence (Apple)
- R1-2608224 (RAN1#126-bis) : 6G DL WUS operation in RRC states (Apple)
- R1-2608225 (RAN1#126-bis) : Uplink WUS and operation (Apple)
- R1-2608226 (RAN1#126-bis) : On WUS operation with other functionalities (Apple)
- R1-2608227 (RAN1#126-bis) : FL Summary #1 on WUS operation with other functionalities (Moderator (Apple))
- R1-2608228 (RAN1#126-bis) : FL Summary #2 on WUS operation with other functionalities (Moderator (Apple))
- R1-2608362 (RAN1#126-bis) : Discussion on design of WUS with OFDM based sequence (NTT DOCOMO INC.)
- R1-2608363 (RAN1#126-bis) : Discussion on WUS operation in RRC states (NTT DOCOMO INC.)
- R1-2608364 (RAN1#126-bis) : Discussion on Uplink WUS and operation (NTT DOCOMO INC.)
- R1-2608365 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (NTT DOCOMO INC.)
- R1-2608433 (RAN1#126-bis) : DL WUS Design (Qualcomm Incorporated)
- R1-2608434 (RAN1#126-bis) : DL WUS Operation (Qualcomm Incorporated)
- R1-2608435 (RAN1#126-bis) : UL WUS Design and Operation (Qualcomm Incorporated)
- R1-2608436 (RAN1#126-bis) : WUS Operation with Other Functionalities (Qualcomm Incorporated)
- R1-2608480 (RAN1#126-bis) : Discussion on UL WUS (ASUSTeK)
- R1-2608539 (RAN1#126-bis) : Discussion on WUS operation in RRC states (CEWiT)
- R1-2608540 (RAN1#126-bis) : Discussion on uplink WUS and operation (CEWiT)
- R1-2608541 (RAN1#126-bis) : Discussion on WUS operation with other functionalities (CEWiT)
- R1-2608631 (RAN1#126-bis) : Summary #1 of 6GR DL WUS design (Moderator (Ericsson))
- R1-2608632 (RAN1#126-bis) : Summary #2 of 6GR DL WUS design (Moderator (Ericsson))
- R1-2608633 (RAN1#126-bis) : Summary #3 of 6GR DL WUS design (Moderator (Ericsson))
- R1-2608634 (RAN1#126-bis) : Summary #4 of 6GR DL WUS design (Moderator (Ericsson))
- R1-2608684 (RAN1#126-bis) : Summary #1 of uplink WUS and operation for 6GR (Moderator (LG Electronics))
- R1-2608685 (RAN1#126-bis) : Summary #2 of uplink WUS and operation for 6GR (Moderator (LG Electronics))
- R1-2608686 (RAN1#126-bis) : Summary #3 of uplink WUS and operation for 6GR (Moderator (LG Electronics))
- R1-2608687 (RAN1#126-bis) : Summary #4 of uplink WUS and operation for 6GR (Moderator (LG Electronics))
- R1-2608701 (RAN1#126-bis) : Summary #3 on 6GR DL WUS operation in RRC states (Moderator (vivo))
- R1-2608702 (RAN1#126-bis) : Summary #4 on 6GR DL WUS operation in RRC states (Moderator (vivo))
- R1-2608707 (RAN1#126-bis) : Discussion on WUS operation in RRC states (CATT)
- R1-2608720 (RAN1#126-bis) : Discussion on Downlink WUS in RRC states for 6GR (Xiaomi)
- R1-2608770 (RAN1#126-bis) : Summary #5 on 6GR DL WUS operation in RRC states (Moderator (vivo))
- R1-2608771 (RAN1#126-bis) : Final summary on 6GR DL WUS operation in RRC states (Moderator (vivo))
- R1-2608782 (RAN1#126-bis) : Summary #5 of uplink WUS and operation for 6GR (Moderator (LG Electronics))
- R1-2608783 (RAN1#126-bis) : Summary #6 of uplink WUS and operation for 6GR (Moderator (LG Electronics))
- R1-2608792 (RAN1#126-bis) : Final summary of uplink WUS and operation for 6GR (Moderator (LG Electronics))