Abstract

This paper is concerned with slicing a radio access network (RAN) for simultaneously serving two 5G-and-Beyond typical use cases, i.e., enhanced mobile broadband (eMBB) and ultra-reliable and low-latency communications (URLLC). Although many researches have been conducted to tackle this issue, few of them have considered the impact of bursty URLLC. The bursty characteristic of URLLC traffic may significantly increase the difficulty of RAN slicing in terms of ensuring an ultra-low packet blocking probability. To reduce the probability, we re-visit the structure of physical resource blocks orchestrated for URLLC traffic based on theoretical results. Meanwhile, we formulate the problem of slicing a RAN enabling coordinated multi-point (CoMP) transmissions for multicast eMBB and bursty URLLC service multiplexing as a multi-timescale optimization problem aiming at maximizing eMBB and URLLC slice utilities, subject to physical resource constraints. To mitigate this problem, we transform it into multiple single timescale problems by exploring sample average approximations. An iterative algorithm with provable performance guarantees is developed to obtain solutions to these single timescale problems and aggregate obtained solutions into those of the multi-timescale problem. We also design a CoMP-enabled RAN slicing system prototype and compare the iterative algorithm with the state-of-the-art algorithm to verify its effectiveness.

Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.