Please hold while we process the request.

URLLC – What to know before embracing it

Uday Parida

As we know, to meet the diverse industrial and market demands, the ITU has classified 5G into URLLC, eMBB and mMTC. As data traffic requirements are increasing every day ranging from mission-critical to massive machine connectivity, the anticipation of 5G is growing at an exponential rate. Even though such requirements open new doors to exciting features and business models, the allocation of these requirements for such intense traffic and diverse services remains a challenge for telecom industries. The release 15 mainly optimized to increase coverage and data rate for eMBB, achieving URLLC together with eMBB for these applications needs a major rethinking on how cellular networks must be designed and operated.

While learning about the spectrum and the 5G experience, 6GHz is a tipping point, which has potentially very different 5G results at higher frequencies compared to lower frequencies. Also as we know that URLLC requires low latency and high reliability for devices with both low and high mobility. Latency with 4G LTE is in four-millisecond range but for URLLC the target is one millisecond in release 15. URLLC also provides end to end security and 99.999% reliability.

Below are some technical enablers to activate URLLC communication services in 5G networks:

  • End to end network slicing, timing synchronization and positioning support
  • Multi antenna techniques
  • Flexible numerology
  • Long PUCCH
  • Low rate MCS
  • UL multi-antenna technique
  • Grant free UL transmission
  • Non-slot based scheduling
  • Pre-emption for DL
  • Flexible timing relation
  • Multi slot transmission for grant-based channel access

Above all this, designing of the physical layer (for L1) will be the most challenging thing. It’s because satisfying ultra-high reliability and low latency are two conflicting requirements at the same time. It is not an easy task.
Now as said earlier, applications related to URLLC tend to have only moderate throughput requirements but needs very high reliability and very low latency. So as per 3GPP TR 22.862, these applications can be identified as below:

  • Higher reliability and lower latency: In such applications, low latency is required but do not require very low latency. For instance, closed-loop control systems in a factory involve a controller timely sending commands to one or more devices which must respond with feedback in a specific time slot. Both the command and feedback must be transferred with very high reliability.
  • Higher Reliability, Lower latency and higher availability: This group of applications is similar to the above one but includes an additional requirement for high availability (system downtime must be very low). Example- industrial control. Such applications may achieve high reliability and high availability using wired connections rather than wireless connections. However, this may not be an attractive solution. The remote control of drones can fit into this group of applications. High availability is important to ensure that the drone is always under the control of the human operator.
  • Very low latency: Here comes the concept of tactile internet. The tactile internet supports a remote extension to the human body. For instance, it allows a surgeon to remotely operate on a patient using a mechanical arm which reacts as though it is a surgeon’s own arm. The surgeon receives both visual and tactile feedback from remote devices.
  • Higher availability: this is needed in scenarios where normally network is unavailable due to congestion or outage. An example solution is to use satellite connectivity as a back up to a normal mobile network.
  • Higher accuracy positioning: this group involves the measurement of location and subsequent signalling of the location information. It is applicable to autonomous vehicles which exchange location information with each other to avoid collisions.

Some of the challenges in the implementation of URLLC are:

  • Quality of Service (QoS) for URLLC,
  • Coexistence with eMBB,
  • URLLC Packet Design (with existing eMBB slot configuration)
  • URLLC Scheduling
  • Energy Efficiency Concern for End-User Device
  • Handover Issues for URLLC
  • Error Handling
  • Beamforming and mmWave Frequency Communications

So with these limitations how we will achieve URLLC deployment with FR1 or FR2 for different URLLC use cases?

TR 24.862,
5G E2E Technology to Support Verticals URLLC Requirements

Related posts

Sign up for our free Newsletters

For more insights not found in the blogs