The eMBB user was streaming 4K video at 800 Mbps.
Suddenly, a URLLC packet arrived for a robot arm in the same cell.
The network didn’t wait. It grabbed the slot and gave it to the robot — while the video user saw a tiny glitch.
That’s called preemptive scheduling, and it’s how 5G serves two opposite worlds at once.
In a 5G gNB, time is sliced into slots. Normally, an eMBB user gets a full slot to download data. But URLLC cannot wait. A factory command or an autonomous car alert must go out in under 1 ms.
So 3GPP introduced preemptive scheduling (also called “URLLC puncturing”). Here’s how it works in simple terms:
The gNB schedules an eMBB transmission for a full slot.
Before the slot ends, an urgent URLLC packet arrives.
The gNB takes a tiny chunk from that eMBB slot — a mini-slot — and inserts the URLLC data right there.
The eMBB user’s slot is “punctured” — a few resource blocks are overwritten. The eMBB transmission fails in those punctured bits.
The eMBB user later gets a retransmission (HARQ) for the damaged part, and the URLLC packet meets its 1 ms deadline.
What it means in real life:
· The URLLC robot gets its command in 0.5 ms.
· The eMBB video user notices nothing — maybe a slight stutter if too many puncturings happen.
· The network keeps both services happy, but eMBB throughput decreases slightly with every punctured slot.
Why engineers must care:
If URLLC traffic grows, eMBB capacity shrinks. The network must balance slot allocation. Too much puncturing and the eMBB user will complain about slow speed, even with full bars.
KEY TAKEAWAY
5G doesn’t just separate services — it lets URLLC “steal” from eMBB in real time. Preemptive scheduling is the tiny interruption that keeps robots safe and videos smooth. It’s not a bug; it’s the design.
CTA
Have you seen a cell where URLLC traffic ate into eMBB throughput? What was your clue — high retransmission rate, or something else?
I wouldn’t use a HARQ retransmission spike alone to identify pre-emption. Poor RF can produce that too. If the trace exposes DCI 2_1, I’d check the indicated PRBs and OFDM symbols, then compare that interval with HARQ feedback and eMBB goodput. That gives us something more specific to investigate. I’d also keep the robot’s application deadline separate from radio scheduling latency: puncturing alone doesn’t prove the command reached the application on time.
Very nice !! Simple way to picture it: imagine watching a movie, and someone urgently needs 2 seconds of your screen for an emergency alert. The system doesn’t ask it briefly cuts in, delivers the alert, then gives your screen back. Tiny flicker for you, but the alert always gets through.
That’s basically preemptive scheduling URLLC briefly steals from eMBB to hit its 1ms deadline.
And it’s not a bug if eMBB throughput dips slightly during high URLLC activity, that’s the network working exactly as designed.
DCI 2_1 is not only the detection signal, it is what makes the mechanism work. When the gNB punctures eMBB resources it sends the preemption indication so the eMBB UE knows exactly which PRBs and symbols carried nothing for it, and the UE discards those soft bits instead of feeding them into HARQ combining. Without that indication the corrupted LLRs poison the combined buffer and the retransmission itself can fail. So the post’s “a few bits fail and HARQ fixes it later” only holds because of DCI 2_1, and that is why hicelltek is right that it is the thing to read in a trace.
The “network grabs the slot” picture is downlink only in Rel-15 terms. Uplink pre-emption is a separate mechanism, the UL cancellation indication in DCI 2_4 introduced in Rel-16, where the gNB tells an eMBB UE to cancel an already-granted uplink transmission. Different signalling, different UE behaviour, worth keeping apart when you are diagnosing.
On the CTA, the clean discriminator between puncturing and poor RF is this: puncturing raises eMBB first-transmission BLER while CQI and SINR stay flat, because the TB is being overwritten regardless of channel quality. RF degradation moves CQI and SINR as well. A HARQ spike with flat CQI points at pre-emption; a HARQ spike with falling CQI points at the radio. Vendors also expose pre-emption counters, but the exact counter is vendor and release specific, so pull it from your MOM rather than assume a name.
Last, the “URLLC grows, eMBB shrinks” framing assumes pre-emption is the only tool. For sustained URLLC load the scheduler should not be puncturing on every packet; that is what configured grant, reserved resources, and dedicated mini-slot scheduling are for. If you see continuous puncturing eating eMBB throughput, that is a scheduling design choice to revisit, not an inevitable tax.
