Petar Popovski, Editor in Chief of IEEE JSAC
Published: 20 Feb 2024
Open RAN (Radio Access Network) is a topic that has been reverberating across the industry and the academia during the past years. Besides its significance in terms of business, such as lowering the bar for new entrants to the radio access equipment market, it does pose challenging questions for research and innovative engineering. Open RAN was the main theme of the IEEE JSAC special issue published in February 2024. The issue features a comprehensive article by the Guest Editors, providing a tutorial on Open RAN and a perspective on its role in the upcoming 6G wireless networks. The featured article from this special issue is:
written by researchers partially affiliated with Eurecom, France.
Low latency has been one of the hallmarks of 5G, but it has often been optimized using very simplistic models. The authors motivate this work by dissecting the latency contributions to UDP and TCP flows and showing that end-to-end low latency is difficult to guarantee within the current QoS mechanisms specified in 3GPP. They also provide a criticism on slicing, the main 5G mechanism for ensuring low latency by uncovering parts of the complex data flows in which slicing does not differentiate the low latency flows from the others. To address these problems, they propose a programmable data plane pipeline that consists of 6 elements and it is prototyped using Open RAN compatible near Real-Time Radio Intelligent Controller (nearRT-RIC), xApps, and Commercial off-the-shelf (COTS) User Equipments (UEs). This is called TC-RAN, which stands for traffic control system for software defined RAN. The benefits of TC-RAN are demonstrated experimentally and, specifically, by examining the latency in a multiplayer gaming that is affected by a greedy video traffic. The results show that, in the benchmark case, the gaming is almost stalled due to the background traffic, while TC-RAN manages to significantly improve the user experience and bring the perception of a responsive, real-time gaming.
We have asked the authors for further clarification of some of the concepts of the paper and their consequences, as well as a more general view on the latency in Open RAN.
- In your work you introduce features that go beyond the QoS features provided by 3GPP. Could you provide a simple example of it? If a single-vendor access networks attempts to support these services, what do you see as the main hindrance and how will the performance degradation manifest itself?
3GPP's current QoS mechanism does not address the problem associated with the data path, e.g. bufferbloat, and remains transparent to such problems as it is beyond its scope. As a very simple example, if two flows share the same DRB, if one is greedy, it may induce considerable latency in the second flow. We shall note that the default DRB is the one used by all of the OTT service providers, such as social networking platform, content providers, etc. Traditional priority mechanisms for this scenario failed to address the problem in wire domain for diverse reasons. Thus, new traffic control (TC) techniques have flourished aiming to tackle it e.g., Linux TC utility. In our work we try to fill this 3GPP gap, providing well known techniques in wired technologies with cellular network specificities. For example, channel variability, and thus, the throughput, or handovers represent still a challenge from a transport layer perspective, where, to paraphrase Kleinrock, we want to "keep the pipe just full, but no fuller". - Your work touches upon latency in ORAN setup and very often it is stated that latency of monolithic radio access is superior to the one of O-RAN, as the latter consists of hardware components that have not been jointly optimized. What is your take on the latency and O-RAN and how can it compete with traditional radio access in terms of latency/timing performance?
In our experience there exist some latency claims that are unfounded, especially the ones proclaimed without meticulously testing. We were able to make a transition from a non-standard RIC i.e., FlexRAN, to a fully O-RAN compliant RIC i.e., FlexRIC while reducing the latency by x50. We are now capable of sending a control message from an xApp to the RAN in less time than the latency required to decode a large LDPC segment. Indicatively, such xApp to RAN function one-way latency is 70us.
Additionally, when we move to multi-cell (interference- and/or capacity-limited) scenarios, coordinated control is required to optimize spectral efficiency (energy-performance) in presence of wireless channel, and this is where O-RAN RIC and xApp standardized solutions shine, as opposed to proprietary closed protocols.
However, it is undeniable that there exist scenarios where join optimization will beat any O-RAN solution. Our vision on this topic is similar to assembly and C programming language. While well-written assembly still beats nowadays code generated by C, the need to program in assembly is rare, even in industries where low latency is of utmost importance e.g., high frequency trading.
Therefore, we believe that if we are able to find the right abstractions and standarized them via the O-RAN alliance, the associated advantages brought by joint optimizations will decrease over time, just as the need to program in assembly did over the last half century.
Statements and opinions given in a work published by the IEEE or the IEEE Communications Society are the expressions of the author(s). Responsibility for the content of published articles rests upon the authors(s), not IEEE nor the IEEE Communications Society.