5G/NR - URLLC

URLLC (Ultra Reliable Low Latency)

As the name implies, this is to guarantee the traffic with Low Latency and Very High Reliability at the same time. It has to satisfy the most challenging two requirement (Latency and Reliability) simultaneously.

How Low and How Reliable it should be ?

According to RP-191584 and TR 38.913-7.9, this requirement is specified as follows : (I think this is for single hop (e.g, between UE and gNB) probably at the layer of MAC/RLC)

Reliability : up to 10^-6
Latency : 0.5 ~1 ms

In reality, I think more important performance indicator is end-to-end latency for each application and use case. Following table is the summary of the latency requirement for each application/use cases that I collected from various references listed in the reference section.

Application		Latency	Service Area	Description
VR
	360 VR Video	20 ~ 40 ms		4K (3845x2160), 60 FPS, 20~40 Mbps
		90 ~ 130 ms		8K (7680x4320), 90 FPS, 90~130 Mbps
		~10 ms		12K 3D(11520x6480),120 FPS, 500~700 Mbps
	CG VR Video	~20 ms		2K (2560x1440), 70 FPS, 30~50 Mbps
		~16 ms		4K (3840x1920), 90 FPS, 50~200 Mbps
		~10 ms		8K (7680x3840), 120 FPS, 200~800 Mbps

V2X		3~10 ms (E2E)	few meters
	Remote Driving	5 ms (E2E)		1 Mbps/DL, 20 Mbps/UL, speed ~250 km/h
	Collective Perception	3 ms (E2E)	200 m	Exchange of real-time information among vehicles
		10 ms (E2E)	500 m
		50 ms (E2E)	1000 m
Industrial Automation
	Motion Control	0.5 ~ 2 ms (E2E)
	Discrete Automation	10 ms (E2E)		~10 Mbps
	Process Automation	100 ms (E2E)		1~100 Mbps

< 22.261 v17.11 Table 7.6.1-1 KPI Table for additional high data rate and low latency service >

What is it for ?

Why we need this kind of challenging feature ? It seems that they have some use case as follows in mind when they investigated on this. Following is the use case specified in RP-191584

Release 15 enabled use case improvements

Such as AR/VR (Entertainment industry)

New Release 16 use cases with higher requirements

Factory automation
Transport Industry, including the remote driving use case
Electrical Power Distribution

How to Reduce Latency ?

To reduce the end-to-end latency, we need to reduce the latency both on RAN side and on Corenetwork side. Let's briefly think of how we can reduce the latency on each side. Some common technologies to reduce the latency on RAN and Corenetwork side can be summarized in illustration as shown below. RAN side latency reduction is relatively well described in 3GPP specification (mostly in Release 16), but Core network side technology seems to be more up to implementation. Personally I think Core network latency would play more role in terms of end-to-end latency and it would take a while and huge investment to restructure and optimize overall architecture of the core network.

As the name implies, URLLC is not only for Latency Reduction. Reliability improvement is also important to meet the super high standards of URLLC. I think this part would be even more challenging than reducing the latency. A common trick to increase the reliablity on RAN side is to use MCS table for low code rate and repetitive data transmission. Unfortunately this would result in throughput reduction, but it is not easy to think of any other means to increase reliability without sacrificing some throughput performance. In addition, we would come up with some solutions to increase the reliability on coreside (i.e, reliability over coreside data path), but as of now (Mar 2021) I don't have any specify knowledge on how to improve core side reliability. I will update on this as I learn further.

PHY/MAC Enhancement

Even though I haven't seen much of real implementation(UE and Network) and real network deployment in Release 15 as of now(Jan 2021), there are features in Release 15 that is introduced with URLLC in mind. The list of these features are well summarized in 5GAmericas white paper as follows :

Lower latency by supporting:

Higher subcarrier spacing, with shorter transmission durations.
Mini-slots with fewer number of symbols.
Frequent PDCCH monitoring reducing the latency of the layer-1 control information.
Configured-grant, which allows the UE to autonomously transmit uplink data without having to send a scheduling request and wait for the uplink grant.
Downlink preemption.

Higher reliability by supporting;

As you may guess, we would need a lot of PHY/MAC enhancement to make this possible. Those enhancement is described in RP-191584 and 38.824 V16.0.0 (2019-03). As you see, it requires the enhancement across all physical channels and MAC scheduling.

PDCCH enhancements

DCI format(s) with configurable sizes for some fields, with a minimum DCI size targeting a reduction of 10~16 bits relative to Rel-15 DCI format 0_0/1_0 and a maximum DCI size that can be larger than Rel-15 DCI format 0_0/1_0, and provide the possibility to align with the size of the DCI format 0_0/1_0 (including possible zero padding if any)
Increased PDCCH monitoring capability on at least the maximum number of non-overlapped CCEs per slot for channel estimation for at least one SCS subject to restrictions including, but not necessary limited to, those identified in TR 38.824. Enhancements for PDCCH monitoring capability on the maximum number of monitored PDCCH candidates per slot (with potential restrictions) can be further considered.

UCI enhancements

More than one PUCCH for HARQ-ACK transmission within a slot
At least two HARQ-ACK codebooks simultaneously constructed, intended for supporting different service types for a UE

PUSCH enhancements for both grant-based PUSCH and configured grant based PUSCH

For a transport block, one dynamic UL grant or one configured grant schedules two or more PUSCH repetitions that can be in one slot, or across slot boundary in consecutive available slots

Scheduling/HARQ enhancement

Out-of-order HARQ-ACK associated with PDSCHs with different HARQ process IDs
Out-of-order PUSCH scheduling associated with different HARQ process IDs, including overlapping PUSCHs and non-overlapping PUSCHs in time-domain
Methods to handle DL data/data resource conflicts for overlapping PDSCHs in time-domain, scheduled by dynamic DL assignments