Ultra-Reliable Low-Latency Communication (URLLC)
Support for high reliability and low latency services like autonomous driving.
5G networks are being architected to support three service categories:
- eMBB (Enhanced mobile broadband): High bandwidth internet access suitable for web browsing, video streaming, and virtual reality. This is the Internet access service we are used to with smartphones.
- mMTC (Massive machine type communication): Narrowband Internet access for sensing, metering, and monitoring devices.
- URLLC (Ultra-reliable low latency communication): Services for latency sensitive devices for applications like factory automation, autonomous driving, and remote surgery. These applications require sub-millisecond latency with error rates that are lower than 1 packet loss in 10⁵ packets [ITU-R M.2410.0].
New techniques need to be devised to meet the stringent latency and reliability requirements for URLLC. This post examines such techniques.
Grant free uplink access
Uplink transfer for a new transmission adds a lot of latency. The following sequence is followed:
- The UE receives new data for transmission in the uplink.
- The UE then waits for the prescheduled opportunity to transmit the Scheduling Request (SR).
- The UT send a Scheduling Request (SR) to the base station.
- The base station then sends a Scheduling Grant (SR) via the PDCCH.
- The UE responds to the grant and transmits the data on the PUSCH.
The following figure illustrates the excessive latency involved in this transfer. The UE needs to resort to this high latency approach as all uplink transmissions need to be orthogonal. This implies that no two UEs can transmit at the same time. This results in the UEs always depending upon the base station to assign resources that will not result in interference.
URLLC services will use a grant free uplink resource to transmit data. This is shown in the following sequence diagram. Here the UE just transmits on receiving new data it does not need to wait for the base station to assign resources.
Multi-Access Analog Fountain Codes (MF-AFC)
Grant free Non-Orthogonal Multiple Access (NOMA) is possible using coding techniques that jointly decode multiple transmissions at the base station. On such technique is described in the paper Multi-Access Analog Fountain Codes. The following quote from the paper describes MF-AFC.
In the proposed scheme, referred to as multiple access analog fountain code (MA-AFC), each user uses an AFC code to generate a potentially limitless number of coded symbols. As the sum of coded symbols from various users is received at the destination, the received signals at the destination can be seen as coded symbols of an equivalent AFC code with a larger code degree. As a result, the standard belief propagation (BP) decoder can be used to jointly decode all the users at the destination.
5G NR latency examples
The TDD and FDD tables underscore the reduction in latency when grant free schemes are used.
Preempting eMBB (Enhanced Mobile Broadband)
URLLC services can reduce downlink latency by preempting eMBB transmissions. The downlink MAC scheduler can steal resources from prescheduled eMBB resources to transmit URLLC data. A preemption indicator will be used to notify the UE about the URLLC stealing.
Reliability through diversity
Diversity on a link improves reliability. The following figure shows the relationship between the error rate (X-axis) and gain needed to compensate for fading (Y-axis).
- On a single diversity channel (blue line), you need a 90 dB gain to obtain a 1 in billion error rate.
- An 8-way diverse channel (red line), your gain requirement drops to 18 dB for the same 1 in billion error rate.
Coding for short blocks
URLLC will require sending of very short messages in the 10 to 100-bit range. Channel coding schemes like LDPC and Polar codes need to be fine-tuned short messages. Candidate coding schemes for URLLC are benchmarked in the following figure.
Note that coding techniques for URLLC need to be benchmarked against the PPV limit as the Shannon limit does not apply for such messages.
If you found this post useful please let us know by clicking the 👏 below.
This blog was brought to you by VisualEther. VisualEther helps you generate call flow diagrams from Wireshark output.