A scheduler that serves eMBB and URLLC on the same carrier eventually has to overwrite an allocation it has already granted. It grants a large downlink allocation, and then an urgent packet arrives that cannot wait for the next slot. The only resources fast enough are the ones already allocated. So the gNB transmits over them and repairs the damage afterwards. I found this feature strange until I stopped reading it as a scheduling mechanism. It is not one. It is a HARQ repair mechanism, and everything below follows from that.

• Executive Summary
• What problem does downlink pre-emption solve ?
• Why does the UE have to be told after the fact ?
• How is the pre-emption indication configured ?
• How does the UE read the 14 bits ?
• What are the limits of the mechanism ?
• How does it compare with uplink cancellation ?
• Reference

Executive Summary

What problem does downlink pre-emption solve ?

Start with the timing, because the timing is the whole problem. A downlink grant is decided at the start of a slot, and an eMBB PDSCH may occupy most of that slot. A URLLC packet that arrives one symbol later cannot wait for the next scheduling opportunity. Its latency budget is measured in a fraction of a millisecond.

The scheduler therefore has two choices, and only one of them is fast. It can wait, and miss the latency target. Or it can transmit the urgent data on resources that are already allocated to somebody else. The second choice is what NR calls pre-emption, and it is a deliberate collision.

Figure 1. Pre-emption is not a scheduling decision that involves the eMBB UE. It is a decision taken after that UE has already been told what to expect.

Notice what the eMBB UE knows at this point, which is nothing. It was given a grant, and it demodulates the whole allocation as if the grant still held. Across the pre-empted region it recovers noise, and it has no way to tell that region from a deep fade.

• Pre-emption is a collision by design : The gNB knowingly transmits one UE's data over another UE's allocation. Nothing is negotiated, and nothing is renegotiated.
• The cause is latency, not capacity : A scheduler with spare resources and no deadline would never do this. It is the deadline that removes the alternatives.
• It is always the slower service that is interrupted : eMBB tolerates a retransmission and URLLC does not. That asymmetry is what makes the trade acceptable.
• The indication cannot prevent anything : By the time the UE can be told, the symbols have already been transmitted. The mechanism exists to limit the damage.

Why does the UE have to be told after the fact ?

This is the part I had backwards for a long time. I assumed the indication existed so the UE could decode the current transmission better. It cannot. That transport block is already lost, and no signalling recovers it. The indication exists to protect the next one.

HARQ in NR is soft combining. The UE keeps the log-likelihood ratios from a failed transmission, and it adds them to the ratios from the retransmission. Two weak copies of the same coded bits then make one strong copy. The method assumes that every stored ratio is a noisy observation of the transmitted bit.

Pre-emption breaks that assumption. Across the pre-empted region the stored ratios are not noisy observations of anything. They describe a different UE's data. They are also confident, because the interfering signal is strong rather than weak. Combining them therefore biases the decoder towards the wrong answer, and it does so with weight.

So the retransmission can fail even though it arrived cleanly. That is the failure the indication prevents. 38.213 states it as an assumption rather than as an instruction. The UE may assume that no transmission to it was present in the indicated parts. A sensible receiver then discards those ratios instead of combining them.

• The current transport block is already lost : No signalling recovers it. The indication is about the retransmission and nothing else.
• Confident wrong data is worse than no data : A pre-empted resource element carries a strong signal that means something else. Its log-likelihood ratio is large and it points the wrong way.
• The spec gives an assumption, not an algorithm : 38.213 says the UE may assume nothing was sent there. What the receiver does with its soft buffer is implementation.
• This is why the feature is optional : A UE that never combines across transmissions gains nothing from it. The gain exists only in the HARQ buffer.

How is the pre-emption indication configured ?

DownlinkPreemption is used to configure the UE to monitor PDCCH for the INT-RNTI (interruption). Four things have to be agreed before any of it works. Which RNTI to watch, how the 14 bits are laid out, how long the whole DCI is, and where inside it this UE should look.

The last one is the interesting one. DCI format 2_1 is group-common, so a single transmission serves many UEs at once. Each UE is given an offset into the shared payload, and it reads only its own 14 bits. That is what positionInDCI is for, and it is configured per serving cell.

The RRC definition is short, and it is reproduced below.

DownlinkPreemption ::=                      SEQUENCE {

    int-RNTI                                RNTI-Value,

    timeFrequencySet                        ENUMERATED {set0, set1},

    dci-PayloadSize                         INTEGER (0..maxINT-DCI-PayloadSize),

    int-ConfigurationPerServingCell         SEQUENCE (SIZE (1..maxNrofServingCells))

                                                OF INT-ConfigurationPerServingCell,

    ...

}

INT-ConfigurationPerServingCell ::=         SEQUENCE {

    servingCellId                           ServCellIndex,

    positionInDCI                           INTEGER (0..maxINT-DCI-PayloadSize-1)

}

Taken from TS 38.331 v17.7.0. The IE is unchanged since Rel-15, and no release up to Rel-19 has added a field to it.

The extension marker at the end matters less than it looks. A later release can add fields after it without changing anything above. So far none has. What the later releases did instead was copy the pattern into new features. Availability indication for DCI format 2_5 has positionInDCI-AI-r16. Uplink cancellation for DCI format 2_4 has its own positionInDCI-r16. Cell DTX for DCI format 2_9 has positionInDCI-cellDTX-r18. Downlink pre-emption is the Rel-15 original that all of them follow.

The DCI itself is monitored in a Type3 common search space, alongside the other group-common formats. Its size is not derived from a field list, unlike a scheduling DCI. It is configured directly, which is why dci-PayloadSize exists at all.

• One DCI serves a group : INT-RNTI is shared. The gNB sends one transmission and every configured UE decodes the same bits.
• positionInDCI is what makes sharing work : Without an offset per UE, a group-common payload would have no way to address anyone inside it.
• The payload size is configured, not derived : Group-common DCIs carry no field list to compute a length from, so RRC states the length.
• It is per serving cell : int-ConfigurationPerServingCell has one entry per cell, so a UE with carrier aggregation reads several regions from one DCI.
• The IE has not changed since Rel-15 : Every later group-common DCI copied the same shape, and each of those carries a release-suffixed field of its own. This one never needed one.
• Monitoring costs power : The UE has to decode an extra PDCCH candidate set on every monitoring occasion, whether or not anything was pre-empted.

How does the UE read the 14 bits ?

Fourteen bits is a very small budget for a region that may span a whole bandwidth part. The design accepts that, and gives the resolution to time rather than to frequency. You will see the indication described as telling the UE which resource elements were pre-empted. It does not. It names a part of a region, and the parts are large.

The region has to be defined before the bits mean anything. In time it is the monitoring periodicity of the search space where DCI format 2_1 is monitored. In frequency it is the active downlink bandwidth part. The 14 bits then divide that rectangle, and timeFrequencySet decides how.

Figure 2. The choice is between resolution in time and resolution in frequency. set0 puts all fourteen bits on time. set1 halves that resolution, and in return the UE learns which half of the band was affected.

The two options suit different deployments. A cell where URLLC traffic takes narrow allocations across the whole band gains little from frequency resolution. A cell where URLLC is confined to part of the carrier gains a great deal. The shorter the monitoring periodicity, the smaller each time part becomes, so the choice interacts with the search space configuration.

• The reference region is not fixed : It follows the monitoring periodicity and the active bandwidth part. Change either and every bit means something different.
• set0 gives time resolution only : Fourteen time parts and one frequency part. The UE learns when, and it assumes the whole band.
• set1 gives some frequency resolution : Seven time parts and two frequency parts. The UE learns roughly when and which half.
• A set bit is an assumption, not a measurement : It tells the UE it may assume nothing was sent to it there. It does not describe what was sent instead.
• Coarse indication costs throughput : A part that is only partly pre-empted is discarded whole. Good soft information is thrown away with the bad.

What are the limits of the mechanism ?

You will see pre-emption described as a way to protect eMBB throughput. It protects it a little, and late. Every limit below has the same source. The indication arrives late, and it says little. None of them is a defect. They are the cost of a feature that has to work without changing anything the scheduler already did.

The first limit is timing. The indication refers to a region that has already been transmitted, so the first transport block cannot be recovered. The second is granularity. One bit covers a part that may be several symbols wide and half a bandwidth part tall. The third is scope. Pre-emption indication tells a UE that resources were taken, and never why, and never by whom.

There is also a limit that is easy to miss. The mechanism protects HARQ combining, so it helps only where combining happens. A transmission that is not retransmitted gains nothing. Neither does one that is retransmitted with a different redundancy version and decoded on its own.

• It is reactive by construction : The UE cannot be warned in advance, because the gNB decides after the grant has been sent.
• Granularity is coarse and configurable : The time part follows the monitoring periodicity, so faster monitoring gives finer parts and costs more UE power.
• It protects the retransmission only : The benefit appears in the second decode. The first one is already lost when the indication arrives.
• It says nothing about the cause : The UE learns that a region is unreliable. It does not learn that URLLC took it, and it does not need to.

How does it compare with uplink cancellation ?

The uplink has the same collision and a better answer. In the downlink the gNB is the transmitter, so by the time it decides to pre-empt, it can act immediately and tell the affected UE later. In the uplink the UE is the transmitter, so the gNB can reach it before it starts. That single difference is why one mechanism reports and the other prevents.

Reading the two together makes each one clearer. Uplink cancellation costs the eMBB UE a whole transmission, and it protects the urgent one completely. Downlink pre-emption costs the eMBB UE part of a transport block, and it protects nothing at the time. Both are the best available answer given who holds the transmitter.

• The direction decides the design : The node that transmits is the node that can act in time. In the downlink that is the gNB, and the UE is only informed.
• One reports and one prevents : DCI 2_1 describes the past. DCI 2_4 changes the future, and its timing requirement is far tighter.
• Both are group-common : Each uses its own RNTI and a configured position in a shared payload, for the same reason.
• They solve one problem from two ends : A network running URLLC beside eMBB usually configures both, because the collision happens in both directions.

Reference

38.213 clause 11.2 defines the UE behaviour and the reference region. 38.212 clause 7.3.1.3.2 defines the DCI format itself. 38.331 carries the DownlinkPreemption configuration reproduced above.

[1] 3GPP TS 38.213 : NR; Physical layer procedures for control

[2] 3GPP TS 38.212 : NR; Multiplexing and channel coding

[3] 3GPP TS 38.331 : NR; Radio Resource Control (RRC) protocol specification

[4] 3GPP TS 38.214 : NR; Physical layer procedures for data

• DCI Format 2_1 field list
• DCI Format 2_4, the uplink counterpart
• Type3 common search space
• URLLC