# Resource-Efficient Multicast URLLC Service in 5G Systems
## 1 Introduction  
Ultra-Reliable Low-Latency Communications (URLLC) is a new type of service supported in 5G systems. While URLLC Quality of Service (QoS) requirements on latency and reliability depend on the application, the typical values considered by 3 GPP are 1-10 ms for latency and \(1\times 10^{-4}\)-\(1\times 10^{-9}\) for reliability [1]. In Releases 15/16, 3 GPP has developed a New Radio (NR) access technology that enables unicast URLLC service, i.e., the delivery of a data stream to/from a single User Equipment (UE). For that, NR supports mini-slots, new robust Modulation and Coding Schemes (MCSs), fast Hybrid Automatic Repeat Request (HARQ), etc. Many emerging applications, such as factory automation, electric power distribution, and intelligent transportation systems, require the support of _multicast URLLC_ (_mURLLC_), i.e., the delivery of the same data from a base station (called gNB) to a group of UEs with strict requirements on latency and reliability. The straightforward approach to enable multicast is to convert a multicast stream into multiple unicast streams addressed to each UE, which manifold increases the channel resource consumption. Being inefficient for a low number of UEs, it becomes completely unsuitable for massive mURLLC because it increases delays above those required for the UEs served last. To save channel resources and reduce delays, since Release 17, NR supports new mechanisms that enable native multicast for different traffic types, e.g., voice and IPTV. Release 18 only slightly enhances multicast functionality, e.g., by enabling data reception in inactive state and dynamic switching between multicast/unicast transmission [2], while Release 17 adds new multicast mechanisms to the NR protocol stack [3; 4; 5; 6] and system architecture [7]. The detailed description and analysis of the novelties can be found in recent papers [8; 9; 10; 11], which mainlyfocus on multicast broadband traffic. In contrast, this paper focuses on those mechanisms and algorithms that are needed for mURLLC. The first mechanism that improves reliability is _multicast HARQ_. If a multicast packet has not been delivered to some UEs, the gNB can schedule a HARQ retransmission that can be addressed either to the original multicast UE group or to a particular UE. HARQ retransmissions can be carried out either based on the feedback from UE(s) or blindly. Note that 3 GPP specifications do not define how to select the number of HARQ retransmissions and their parameters (e.g., MCS). The second mechanism enables several ways in which UEs can provide feedback about the decoding status (success or failure) of previous transmissions. This feedback is needed to perform conditional HARQ retransmissions, i.e., to decide on a transmission retry based on the set of the UEs to which the data have not been delivered yet. However, the 3 GPP specifications do not describe how to configure such feedback. In addition to these two mechanisms, in this paper, we study various transmission parameters selection algorithms, which are left for implementation by vendors. Specifically, since Massive Multiple Input Multiple Output (M-MIMO) is a key feature of 5G systems, the gNB shall implement algorithms that select a precoder, allocate frequency resources, and select a single MCS for each multicast transmission. Without proper configuration of the multicast mechanisms and the above-mentioned transmission parameters, either the strict reliability and latency requirements may be not satisfied or the channel resource consumption is too high, which limits the cell capacity. Despite being important, the area of mURLLC has not been well addressed in the literature. Many works evaluate the performance of new multicast mechanisms [12; 13; 14; 15] and propose new transmission parameters selection algorithms [16; 17; 18; 19; 20]. However, these works only consider multicast broadband traffic (e.g., file transfer, IPTV) with moderate latency and reliability requirements, while mURLLC imposes much stricter requirements.