JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, OCT 2023
1
O-RAN: Analysis of Latency-critical Interfaces and Overview of Time Sensitive Networking Solutions
arXiv:2607.27448v1 [cs.NI] 29 Jul 2026
Esteban Municio, Gines Garcia-Aviles, Andres Garcia-Saavedra and Xavier Costa-Pérez
Abstract—5G and B5G/6G foundations heavily rely on virtualization technologies, and virtualized Radio Access Networks (vRANs) are one of their major keystones. However, while vRANs have been traditionally suffering from significant hardware/software coupling, next generation vRANs aim for open, standardized interfaces and multi-vendor, interoperable components to enable truly flexible deployments following the cloudnative principles. In this line, the O-RAN Alliance is promoting a novel Open RAN architecture to further boost flexibility and cost efficiency. In order to reduce costs and effectively achieve the promised disaggregation levels, O-RAN must ensure shared, integrated transport networks in opposition to dedicated, overprovisioned links from traditional approaches. However, keeping deterministic performance requirements in such cost-effective networks (i.e., general-purpose Ethernet networks), especially in those interfaces that are time-critical, is a challenge. In this article, we review the most relevant Time Sensitive Networking (TSN) standards that may bring compelling benefits to O-RAN, (i.e., IEEE 802.1CM, IEEE 802.1Qbu and IEEE 802.1Qbv) for providing determinism over cost-efficient networks. We explore the design space for a TSN-enabled O-RAN architecture, reporting on the requirements and deployment options and finally, we discuss on the opportunities and challenges that O-RAN will face when adopting TSN technologies to fully open the vRAN ecosystem. Index Terms—O-RAN, TSN, 5G, 6G, vRAN
I. I NTRODUCTION Future cellular networks are pushing towards flexible, disaggregated and open architectures to truly materialize the concepts of network softwarization under the promise of higher efficiency and reduced costs. New functionalities include multivendor network function split, on-demand network slicing provision, and real-time, end-to-end control of the physical infrastructures [1]. A major world-wide, carrier-led efforts to standardize next generation virtualized Radio Access Network (vRAN) architectures is done by the O-RAN Alliance, a consortium of industry and academia that aims for opening the rigid hardware-software coupling [2]. One of the main features proposed by the new O-RAN architecture is the possibility of a fully-fledged virtualization of the network infrastructure. All components of the O-RAN architecture may be deployed in the O-RAN Cloud (O-Cloud) platform, which allows network operators to orchestrate the physical and virtual functions over a flexible cloud computing platform. Such O-RAN functionalities (e.g., standardized interfaces, infrastructure sharing or automated instantiation) aim to considerably reduce the operational and fixed costs for Esteban Municio and Gines Garcia-Aviles are with i2CAT Foundation. Andres Garcia-Saavedra is with NEC Laboratories Europe. Xavier Costa-Perez is with i2CAT Foundation, NEC Labs Europe and ICREA.
network operators. Among these, avoiding network overprovisioning and enabling cost-effective networks is fundamental to improve the efficiency of the deployments. These are however ideas not devoid of challenges. The O-RAN ”7-2x” functional split imposes strict latency and throughput requirements, specially in the interfaces carrying fronthaul traffic. While legacy and current interfaces, for example, Common Public Radio Interface (CPRI) and enhanced CPRI (eCPRI), heavily rely on such network overdimensioning at the design phase to cope with a relatively predictable traffic demand, the new sharing and openness levels of O-RAN may significantly modify traditional assumptions on the transport network. Therefore, advanced traffic mechanisms to provide real, strict deterministic performance over multiple timecritical flows in cost-efficient networks such as multi-purpose Ethernet networks are required. To provide such determinism, guaranteeing upper bounds on end-to-end latency and latency variation, Time Sensitive Network (TSN) mechanisms have been used in IEEE 802.1 networks since more than a decade ago [3]. Some TSN features such as Frame Preemption (IEEE 802.1Qbu [4]) are nowadays proposed to provide strict packet prioritization in the fronthaul. However, in O-RAN use cases where transport networks are expected to be extensively shared, strict priority mechanisms are not sufficient. This is the case, for example, when high traffic load causes a significant increase in ”fanin” delay (i.e., time-critical packets with the same priority arrive to a bridge at different ingress ports but depart from the same egress port), which may cause that the end-to-end packet delay exceeds the maximum allowed (typically 100µs) by the O-RAN OpenFronthaul [5]. In such cases, advanced TSN scheduling mechanisms, such as Time-Aware Shaping (IEEE 802.1Qbv [4]) may be used to ensure that multiple highpriority flows can efficiently share an Ethernet-based transport network without losing any determinism1 . TSN will play a crucial role in reducing deployment costs in O-RAN deployments. First, the use of expensive, dedicated point-to-point fiber links in the fronthaul can be avoided by deploying a programmable, multi-purpose and inexpensive TSN-enabled Ethernet bridged network. Secondly, worldwide existing legacy Ethernet-based cellular infrastructure can be integrated within the O-RAN ecosystem by making it TSNcapable. Indeed, the benefits of using TSN to support the fronthaul have been already acknowledged by the industry, triggering the standardization of IEEE 802.1CM for the use of TSN in the fronthaul [6]. Besides reducing costs, the adoption of TSN in the fronthaul enables the fronthaul-backhaul con1 802.1Qbv and 802.1Qbu amendments are now included in 802.1Q-2018
JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, OCT 2023
vergence (Crosshaul), while enabling statistical multiplexing gain and avoiding the wavelength-dependence and inefficiency of traditional CPRI fronthauls [7]. In this paper, we revisit the well-established ideas of TSN to apply them in the context of O-RAN, seeking for opportunities and challenges that TSN standards can bring to the O-RAN ecosystem to reduce costs. We do this by first, mapping the TSN mechanisms to the O-RAN architecture, analyzing which interfaces can benefit from TSN, and presenting the different integration alternatives. Secondly, we summarize the O-RAN time-sensitive requirements and challenges, introducing then different deployment options and analyzing the alternatives for integrating TSN in the available O-RAN open-source components. To conclude, a discussion on the opportunities and research gaps is provided, summarizing the findings and the challenges ahead.
2
SMO
Non RT Control loops
R1
Non-Real Time RIC
Framework
Near RT Control loops
xApps xApps xApps ...
Near-Real Time RIC Slave
O-eNB
rApps
...
PTP Grand Master
CUC
Boundary Clock
A1
O2
rApps rApps
5G Core O1
AMF
CNC
E2
UPF NG-C NG-U
O-gNB O-CU-CP
Boundary Clock
Boundary Clock F1-c
O-CU-UP F1-u
RT Control Loops
Boundary Clock
O-DU OF M-Plane
OF CUS Plane
X2/Xn-c
X2/Xn-u
Slave
O-RU
Other O-eNB/O-gNB
O-Cloud
II. M APPING TSN ONTO O-RAN A. A Time-Sensitive Networking Primer The aim of TSN is to enable bounded latency and Packet Delay Variation (PDV), and ultra-reliable packet delivery to different flows coexisting in 802.1 Ethernet networks (low-cost and ubiquitous) [8]. This means that in TSN-enabled networks, the minimum latency may not necessarily be lower than in priority-based ones. However, the PDV is deterministic and limited to a certain time-window. Among the different existing TSN standard amendments included in the IEEE 802.1Q-2018 revision [4], there are two main TSN extensions that stand out when affecting the performance of time-critical transport: Frame Preemption (802.1Qbu) and Time-Aware Shaping (802.1Qbv). 1) IEEE 802.1Qbu Frame Preemption: The 802.1Qbu amendment is usually coupled with the IEEE 802.3br Interspersing Express Traffic amendment to enable the interruption of an on-going frame transmission to transmit one or more higher-priority frames. To this end, the standard allows timecritical ”preempting” frames with high priority to suspend the transmission of possibly on-going lower-priority ”preemptable” frames in order to reduce the queuing delay of the preempting frame. This necessarily causes the fragmentation of the preempted frame and requires additional reassembling, but it significantly reduces the degree of interference between flows. However, there are limits to frame preemption. It occurs only if at least 60 bytes of the preemptable frame have been transmitted and at least 64 bytes (including CRC) remain to be transmitted. The worst-case preemption latency is defined by the minimum fragment size (124 bytes), which cannot be preempted [4]. 2) IEEE 802.1Qbv Time-Aware Shaping: The 802.1Qbv queuing algorithm controls all the queues of a given port in the bridge by opening and closing the ”transmission gates” following a rotating schedule. This schedule is synchronized with the other bridges’ schedules and consists of an 8-bit tuple acting as a gate control list for the different ports. Traffic classes are mapped to the different queues, and only one traffic class is allowed to transmit at a given time. In order to prevent that large frames from one queue transmit during the next
TSN-Qualified O-RAN Interface TSN-Optional O-RAN Interface
Standard O-RAN Interface
Fig. 1: O-RAN architecture and its integration with TSN. schedule entry, 802.1Qbv envisages the use of Guard Intervals (GI) between entries [4]. This results in a TDMA-like behavior that eliminates interference between queues and highly reduces or completely removes PDV [9]. B. Open RAN Architecture O-RAN architecture organizes LTE and NR RANs following the view depicted in Fig. 1. It introduces two novel components, the non-Real-Time (non-RT) RAN Intelligent Controller (RIC) and the near-Real-Time (near-RT) RIC. The non-RT RIC is typically hosted by the Service Management and Orchestration (SMO) and performs management and control operations at large time scales (seconds or minutes). On the other hand, the near-RT RIC performs management and control of the RAN at smaller time scales (between 10ms and 1s) through the xApps, microservices supporting custom logic to optimize the management of radio resources. The near-RT RIC controls the E2 nodes, namely, O-RAN Centralized Units (O-CUs), O-RAN Distributed Units (O-DUs) and O-RANcompliant LTE eNBs, and can be hosted at the edge co-located with the E2 nodes or fully decoupled if the latency constraints are fulfilled. This allows for different deployment flavors that can be changed over time according to the particular operator needs at any given time [2]. The functional split selected by O-RAN is ”7.2x”, which balances O-RUs simplicity (lighter and less power-hungry) and traffic reduction in the fronthaul [10]. This split keeps the Fast Fourier Transform (FFT), cyclic prefix and precoding (optional) in the O-RU, and the remaining functions are executed in the O-DU (MAC and RLC). O-RUs offloading the precoding to the O-DU are called Category A and those that perform it, are Category B. C. When TSN meets O-RAN The O-RAN time-critical interfaces (marked in red and named after TSN-Qualified interfaces in Fig. 1) are the ones
JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, OCT 2023
that can highly benefit from TSN. This mainly includes the OpenFronthaul Control, User and Synchronization (CUS) plane and Management (M) plane, the F1-c/F1-u interfaces that interconnect O-DUs with O-CUs and the transport data plane interface (NG-U) that interconnects O-RAN with the core network. The NG-U interface is by default time-sensitive compliant since it is usually implemented through largescale optical transport networks that provide low-latency communication and determinism through wavelength isolation. However the OpenFronthaul CUS and M planes and F1u/F1-c interfaces, which are under the umbrella of the nearRT RIC, often use overdimensioned point-to-point links to ensure the latency budget. To reduce costs, operators can adopt TSN to deploy these interfaces over an integrated Ethernet transport network that would ensure low-latency with truly deterministic guarantees for time-critical flows. Even when sharing the network with other time-critical traffic flows, such as neighboring fronthaul payload, critical edge services or external Best-effort (BE) traffic. On the other hand, implementing TSN requires additional mechanisms to control the time-sensitive streams. IEEE 802.1Qcc [11] (amendment where stream management enhancements are introduced) defines three models for TSN user/network configuration: a) fully-distributed, b) hybrid, and c) fully-centralized. While the fully-distributed model could have some niche applications (e.g., marketplace-based decentralized green radio use cases), the hybrid and fullycentralized models are the ones that may fit better in the ORAN architecture. Both TSN models envisage the use of a Centralized Network Configuration (CNC) entity, which has full view of the physical topology and can compute schedules and paths for the time-sensitive flows. The CNC acts as a Software Defined Networking (SDN) controller with extended TSN functionalities. The O-RAN architecture may natively support a CNC through its deployment in the near-RT RIC as an xApp, running a near-RT control-loop that continuously audits the performance of the flows, and re-configuring the network when the requirements are not met. While the end-nodes (i.e., talkers/listeners in TSN nomenclature) directly express their flow requirements to the CNC in the hybrid model, all flow requirements are expressed and managed by the Centralized User Configuration (CUC) entity in the fully-centralized model. The role of the CUC is to discover end-nodes, retrieve their flow requirements, and configure their TSN features. Since such operations are usually not frequent (e.g., commissioning of new equipment), the CUC may be implemented in the non-RT RIC as an rApp within the O-RAN architecture. Figure 1 includes possible locations for the CNC, CUC, and Boundary/Master-clocks, which are required to synchronize the TSN-enabled elements. Additionally, the A1 and E1 interfaces are not time-critical because of their time scales, however they can also benefit from bounded latency through shared Ethernet networks (marked in green and named after TSN-Optional interfaces in Fig. 1). Although the timing requirements are not as strict as the TSN-Qualified interfaces, interference-less and timely control would enable shorter and more accurate control-loops.
3
III. E COSYSTEM AND DEPLOYMENT OPTIONS A. The time-sensitive O-RAN ecosystem 1) OpenFronthaul: Traditional LTE and NR RAN deployments relied on the CPRI/eCPRI standards for the fronthaul interfaces [12]. Although such interfaces are standardized, the extensive modifications done by individual vendors cause a defacto lock-in between their RUs and DUs. To ensure openness, O-RAN defined the OpenFronthaul interface to ensure multivendor coexistence between O-DUs and O-RUs. The O-RAN OpenFronthaul is an entirely packet-based interface which can leverage Ethernet to transport fronthaul payloads, although it can also use Wavelength Division Multiplexing (WDM) optical networks. OpenFronthaul conforms to the eCPRI framework and shares its latency models and, by leveraging TSN, it may transport time-critical payloads along with other timecritical/BE traffic without performance degradation in a costeffective manner over Ethernet. OpenFronthaul is based on two new interfaces, the CUS-plane and M-plane. The OpenFronthaul CUS-Plane has the highest priority in the OpenFronthaul, that is, non-preemptable Expedited Forwarding (EF). It consists of i) the U-Plane, which carries the user plane IQ data precoded in the frequency domain, ii) the C-Plane, which controls the data transfer, manages the scheduling, numerology and Physical Random Access Channel (PRACH), and processes beam-forming commands, and iii) the S-Plane, which is responsible for the time, frequency and phase synchronization between the O-DUs and O-RUs. ORUs and O-DUs need to be tightly synchronized in order to be able to perform latency critical operations such as Time Division Duplexing (TDD), Carrier Aggregation (CA), MIMO or handovers. TSN mechanisms that require synchronization such as 802.1Qbv may leverage the S-Plane as well. Conversely, the M-Plane is used for providing Fault, Configuration, Accounting, Performance and Security (FCAPS) support. Some of its functions are life-cycle management, software updates or fault monitoring, and therefore it does not have the latency requirements of the CUS-Plane. Instead, M-Plane has preemptable Assured Forwarding (AF) priority. A summary of the OpenFronthaul logical planes is depicted in Fig. 2. Additionally, O-RAN extends its OpenFronthaul interface with the Cooperative Transport Interface (CTI). While TSN is able to operate a fabric of Ethernet switches with reservationbased features, CTI supports cooperation with external, shared resource-allocation-based networks (e.g., PON, WDM or DOCSIS). In this sense, CTI enables the identification and classification of fronthaul flows by the Transport Nodes (TNs) and Transport Units (TU), and allows them to process each flow according to their corresponding timing requirements. A TSN-enabled O-DU may interact with the CTI Transport Control (TC) and Transport Management (TM) planes through a TSN Agent implemented as a dApp, a concept introduced in [13] to deploy applications in the O-gNBs. 2) The O-RAN Midhaul: F1-u and F1-c: F1-u/c interfaces are commonly considered as the midhaul and are defined by the 3GPP TS 38.470 standard. O-RAN may also consider 3GPP F1-u and 3GPP F1-c as time sensitive interfaces as
JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, OCT 2023
4
Total gNB TX/Proc Delay RT Control Loops
O-DU
TSN-enabled CTI
TC-Plane
M-Plane
CUS-Plane
R4
TM-Plane
R1
O-DU
Transport Node
T34
TC-Plane
TM-Plane
T12
M-Plane
O-RU
TSN-enabled Transport Network
R2
CUS-Plane
T2a Ta3
Ra
Time
O-DU Proc. Delay C/U Plane Message
Transport Unit
R3
O-DU TX Window
T1a = T12 + T2a Ta4 = Ta3 + T34
Fig. 2: OpenFronthaul interface planes and reference points for delay management. they are under the umbrella of the near-RT RIC. F1-u/c have less stringent latency and PDV requirements and thus can be transported over a number of IP-enabled transport technologies such MPLS or SRv6. B. Requirements and Deployment Options The TSN-enabled deployment scenarios in O-RAN are heavily influenced by the timing requirements imposed by the time-sensitive interfaces. The two main requirements that must be fulfilled are the one-way delay measurement, namely, latency, and the time synchronization error, namely, Time Alignment Error (TAE). Different deployment options are allowed as long as the delay and the TAE are bounded on a maximum value. Since the tightest requirements are those of the fronthaul (e.g., typical end-to-end one-way latency is 100µs for the U-plane, and 1.5∼10ms for F1-u), next we focus on the OpenFronthaul. The timing in the OpenFronthaul interface follows the eCPRI delay management and it is tightly coupled with the air interface. Figure 2 shows the location of the standard eCPRI reference points (e.g., R1, R2, T1a, T2a, etc.), used to calculate the delays. The main idea is to ensure that TX/RX windows of the O-DU are properly aligned to support the O-RU transport characteristics, mainly derived from transport constraints and 5G NR options, for example, Channel Bandwidth and Subcarrier Spacing (SCS), U-Plane/C-Plane timing relations, and retransmission timing of the Hybrid Automatic Repeat reQuest (HARQ). An example of delay management is presented in Fig. 3. The T XW indow and RXW indow are set accounting for the ODU processing delay, medium access delay, OpenFronthaul delay (switching delay, propagation delay, etc.) and O-RU processing delay (and their estimated maximum fluctuations). The T XW indow is defined as T 1amax − T 1amin , where T 1a is the elapsing time from a bit leaving the O-DU (R1) until is received at the antenna interface (Ra). The max and min values
O-RU
O-RU RX Window
Symb Symb ... #n #n+1 ... O-RU Proc. Delay
Ra
OpenFronthaul Delay
Fig. 3: Timing relations per U/C message in DL direction.
account for the fluctuation delays, and is typically predefined based on the equipment capabilities. Equally, the RXW indow is defined as T 2amax −T 2amin . In this sense, the RXW indow must be at least long enough so that it can cope with the worst case within the T XW indow (i.e., RXW indow ≥ T XW indow + OpenFronthaul maximum delay). To support such stringent time requirements through TSN, OpenFronthaul may leverage 802.1CM [6]. 802.1CM defines mechanisms for transporting time-sensitive fronthaul streams over bridged networks2 . It consists of two interface classes: • Class 1: it refers to fronthaul interfaces that use CPRI to periodically send IQ data, regardless there is actually traffic from the O-RU or not. This results in a Constant Bit Rate (CBR) stream sent over periodic time-windows. This class may highly benefit from 802.Qbv scheduling to provide deterministic CPRI support over Ethernet networks. • Class 2: it refers to fronthaul interfaces that use eCPRI. The IQ data is transported in a more traffic-efficient packet-based stream. Unlike Class 1, data is only exchanged when there is actual user data from the O-RU. Additionally, 802.1CM requires disabling Low-Power Idle (LPI) mode to avoid the delay (wake time) when the LPI is de-asserted, and forbids the use of control protocols such as MAC control Pause (802.1Qbb). On the other hand, 802.1CM clashes with other priority-based flow control mechanisms defined in 802.1Q operating on the priorities required by fronthaul traffic. However, for those scenarios, applying 802.1Qbv traffic scheduling would allow for the co-existence of several time-sensitive flows with the highest priority. Finally, transport network bridges must meet some requirements (e.g., a minimum of 1 Gb/s ports, 2000 byte maximum PDU size, full-duplex point-to-point links, etc.), and are able to transport non-fronthaul traffic as long as the fronthaul requirements are met. 2 Fronthaul networks other than bridged networks are outside the scope of 802.1CM.
JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, OCT 2023
802.1CM also defines two fronthaul profiles to fulfill the targets of the above-mentioned classes. Profile A operates through strict priority queuing, there is not bandwidth limitation and the maximum frame size is 2000 bytes. Profile B extends Profile A with 802.1Qbu Frame Preemption to reduce interference of non-fronthaul traffic over fronthaul traffic. The worst-case preemption latency is defined by a minimum fragment size of 124 bytes (1080ns in a 1Gb/s link). Since synchronization between O-RUs is crucial, O-RAN specifies four types of OpenFronthaul Low-Layer Split (LLS) topology configurations to provide synchronization [14]: • LLS-C1: This topology configuration assumes a direct point-to-point connection between O-DU and O-RU. The O-DU acts as Telecom Grand-Master (T-GM) and synchronizes through SyncE and PTP the O-RU, which acts as Telecom Slave-Clock (T-TSC). • LLS-C2: There is a multi-hop connection between the O-DUs and the O-RUs through a network of Ethernet switches, which act as Telecom Boundary-Clocks (TBCs). The maximum number of hops is limited by the error contributions of all clocks in the chain (i.e., including TAE and frequency error in the air interface). • LLS-C3: It supports network timing distribution from one or more external T-GMs located in the transport network. O-DUs (optionally) and O-RUs act as T-TSCs. • LLS-C4: It assumes all O-DUs and O-RUs have their own GNSS-based clocks and thus, the synchronization is not done through the transport network. Additionally, O-RAN supports several timing profiles to ensure synchronization interoperability among O-RAN network elements. They are: Full-path Timing Support (FTS) profile (ITU-T G.8275.1), where all elements between the TGM and the T-TSC are PTP aware devices, Partial Timing Support (PTS) profile (ITU-T G.8275.2), where some of the elements are not PTP aware, and Assisted Partial Timing Support (APTS) profile (ITU-T G.8275.2), where elements use GNSS-based clocks as primary reference source and only use PTP as backup timing source. FTS and PTS are normally used for LLS-C1/C2/C3 while APTS is intended to be used in LLS-C4 topologies. For applications such as fronthauling of Category B O-RUs over TSN networks with high TAE requirements (i.e., < 260ns), O-RAN recommends the use of the FTS profile [14]. Choosing the right timing profile, LLS topology configuration and location of the clocks in a O-RAN deployment is non-trivial. First, strict TAE requirements limit link distances and forbid certain topologies. Secondly, while centralized approaches are simpler and have lower costs since only few GMs are needed, decentralized ones do not need synchronization from the network. However they involve higher costs and are prone to GNSS signal jamming or spoofing. Two design choices for a typical O-RAN deployment (i.e., Scenario 1 with co-located O-DU/O-CU, and Scenario 2 with co-located ORU/O-DU, both configured as LLS-C3 [5]) are given in Fig. 4. Depending on the deployment scenario, the O-RU/O-RU TAE and the O-RU/O-DU TAE will vary significantly.
5
C. O-RAN Software Community and integration with TSN The O-RAN Software Community (O-RAN SC) is a partnership between the O-RAN Alliance and the Linux Foundation whose main goal is to support the software development of an Open RAN solution available to everyone. A proper alignment between the O-RAN community-driven software developments projects and the TSN working groups is therefore essential to achieve a successful integration. The O-RAN SC is mainly composed by the following software projects: • RIC Applications (RICAPP): Includes open source sample xApps and platform applications for integration, testing and demonstrations. • Near-RT RIC (RIC): Includes the near-RT RIC implementation using OpenAPI to support xApps. • Non-RT RIC (NONRTRIC): Includes the non-RT RIC implementation focusing on its interoperability through the A1 interface and closed-loop use cases. • Operations and Maintenance (OAM): Provides reference sample implementations according to the operations and maintenance O-RAN documents. • O-RAN Central Unit (OCU): Provides a baseline implementation for the O-CU, focusing on a basic E2 interface to enable integration and testing between RIC and OCU. • O-RAN Distributed Unit High Layers (ODUHIGH): Implements the functional blocks of the 5G NR L2 protocol stack defined for the standalone (SA) mode. • O-RAN Distributed Unit Low Layers (ODULOW): Provides an initial implementation of the functional blocks of the 5G NR L1 protocol stack. • Infrastructure (INF): Provides initial infrastructure building blocks to properly deploy O-RAN network functions components (i.e., real-time platform deployment). • Service Management and Orchestration (SMO): It implements the O1 (RAN Network Functions configuration and management) and the O1/VES (RAN-generated events gathering) interfaces. We focus on those containing time-sensitive communication interfaces. 1) O-RAN Fronthaul Interface Library: The O-RAN Fronthaul Interface (FHI) library is part of the ODULOW software project. This library, built on top of DPDK3 , performs U-plane and C-plane functionality according to the OpenFronthaul specification. It allows ODULOW software components to use the C-Plane and U-Plane of the O-RU, and is expected to communicate TTI events, symbol time, C-plane information as well as IQ Samples data. The current implementation relies on the xRAN library4 to provide support for transporting IQ samples between O-DU and O-RU. The library defines packet formats to transport radio samples according to the O-RAN specification. The FHI library can be made agnostic to the network interfaces, leaving TSN-enabled tasks such as frame preemption or traffic scheduling to the kernel. However, for some ultra-low latency use cases, it may be required to move such tasks to DPDK to ensure faster processing times. 3 https://www.dpdk.org/ 4 https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/ xRAN-Library-Design fh.html
JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, OCT 2023
Aggregation Transport Network
Access Transport Network (TSN-enabled) O-RU
O-RU
O-DU
O-CU
O-DU
O-CU
TSN Switch
T-GM
Fronthaul
Midhaul
Backhaul
(a)
TAE (O-RU O-DU)
TAE (O-RU O-RU)
TAE (O-RU O-RU)
TAE (O-RU O-DU)
6
O-DU O-RU
O-RU
Access Transport Network (TSN-enabled)
Aggregation Transport Network
O-CU
TSN Switch
O-DU
T-GM
Fronthaul
Midhaul
TSN Switch
O-CU
Backhaul
(b)
Fig. 4: Different deployment options and their effect on the TAE according to the O-RU and O-DU locations.
For time synchronization, the xRAN library currently supports configurations LLS-C1 and LLS-C3, and primary/secondary PTP configurations are expected to satisfy only O-DU requirements, while providing best-effort primary PTP for O-RU. This may not be sufficient to accomplish the S-plane requirements, which could lead to require additional Boundary-Clocks. Finally, while O-RAN fronthaul data can be transported over Ethernet or IPv4/IPv6, the current xRAN library implementation only supports Ethernet through VLANs. 2) O-DU High Layers: The O-DU high layers software project includes the required modules to implement the functional blocks of the 5G NR L2 in different software entities: • DU-APP: configures and manages all the operations of the O-DU by interacting with the OAM, over the O1 interface for configuration, alarms and performance management, the O-CU, on the F1 interface over SCTP, and the RIC, on the E2 interface over SCTP. • 5G-NR-RLC: provides services for communication with the O-CU through the DU-APP. • 5G-NR-MAC: responsible for sending/receiving data on the various logical channels, scheduling grants, multiplexing/de-multiplexing, and Femtocell Application Programming Interface (FAPI) communications. • O1-Module: main agent implementing the core functionality of the O-DU High Layers software. For the integration of the standard centralized/hybrid TSN architecture on the O-DU High Layers project, an additional south-bound interface between the O-DU and CNC is required. It could be O1, or an extension of E2, and its aim would be to provide the O-DU with scheduling information that will be used for i) adjust its own TX/RX windows facing the ORU, ii) align such windows with the schedules of the Ethernet switches involved in the fronthaul path. IV. D ISCUSSION To date, and inheriting from traditional 3GPP RANs, proposed O-RAN approaches are rather conservative and often consider RAN transport networks as overdimensioned pointto-point or static point-to-multi-point links to deal with the strict latency requirements in the time-sensitive interfaces. Aiming to improve cost-efficiency, future O-RAN networksharing use cases in Ethernet transport networks where multiple O-RUs/O-DUs/O-CUs use the same network to commu-
nicate one each other, require however TSN mechanisms to ensure packet delivery with fair and deterministic performance. As a summary, Table I provides an overview of the ORAN interfaces currently available in the O-RAN SC that may leverage TSN, including its encapsulation modes, latency requirements and transport technology options. The most restrictive interfaces are the OpenFronthaul CUSPlane. While the U-Plane and S-Plane may require up to 25µs for ultra-low-latency performance use cases, typical scenarios usually require 100µs. Thus, this excludes the use of DOCSIS for its use in the CUS-plane, even when using LowLatency Xhaul (LLX), and Microwave, where typically only bands above 60GHz achieve latencies lower than 250-500µs. Conversely, OpenFronthaul M-Plane has more relaxed requirements. It is worth mentioning that O-RAN also considers nonideal fronthaul networks for low UE density and slow-fading scenarios (e.g., femto-cells in rural areas) where latencies in the order of few milliseconds may have a negligible impact in the performance [5]. In the F1-u/F1-c, NG-U, A1 and E2 interfaces the latency requirements are less strict, therefore more transport technologies options are available. Additionally, although typical LTE and 5G NR deployments are nowadays based on WDM, some operators may choose Ethernet to save costs. This is demonstrated in [7], where CPRI fronthaul traffic safely coexists with backhaul traffic in the same wired switching network as a way to reduce deployment costs. In fact, the increased number of sectors in 5G NR results in many channels to be transported in the fronthaul along with the inefficient 4G CPRI legacy channels. Such a large number of channels presents a challenge in terms of costs, since traditional approaches based on WDM usually require many expensive 10∼25Gb/s optics. However, by using TSN over Ethernet in a single fiber, channels can be multiplexed and CPRI, eCPRI and external traffic can coexist achieving a reduction of Total Cost of Ownership (TCO) of 30%5 . Last and also relevant, sometimes operators just need to support legacy low-speed Ethernet-based RAN transport networks (1GE or even 100BASE-T). In such scenarios, enabling TSN would also help to manage the strict latency budgets. 5 A detailed economic analysis of a shared fronthaul deployment can be found here: https://ec.europa.eu/research/participants/documents/ downloadPublic?documentIds=080166e5b77d8419&appId=PPGMS
JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, OCT 2023
7
TABLE I: Mapping of available O-RAN interfaces with their requirements and technologies.
OF C OF U OF S OF M F1-c F1-u E2 A1 NG-U
Max. Delay 1 ms 25 µs - 1 ms 25 µs - 500 µs 100 ms 1.5-10 ms 1.5-10 ms 10 ms 500 ms 1-50ms
Max. FLR 10−7 10−7 10−7 10−6 N/A N/A N/A N/A N/A
Encapsulation
Ethernet
VLAN/eCPRI VLAN/eCPRI VLAN/PTP VLAN/NETCONF VLAN/F1AP VLAN/GTP-U VLAN/E2AP VLAN/A1AP VLAN/GTP-U
Yes Yes Yes Yes Yes Yes Yes Yes Yes
Unlike the midhaul and backhaul interfaces, the OpenFronthaul is the only interface that sets requirements in terms of Frame Loss Ratio (FLR). This is because, while the loss of a frame in the U-Plane will generally impact only a specific symbol, the loss of a C-Plane frame could possibly impact an entire slot’s worth of data. Therefore, FLR over the considered transport options is often considered negligible (except in Microwave links). Finally, the time-critical interfaces shown in Table I may all benefit from TSN whenever the network is shared with external traffic, but it is in the OpenFronthaul CUS-Plane and F1-u/F1-c interfaces where TSN could play a major role.
A. 802.1Qbu and 802.1Qbv Applying 802.1Qbu Frame Preemption is straightforward in O-RAN. It is specified in the 802.1CM Profile B and it has great impact in reducing PDV on sub-10GE links. However, standards may have neglected the benefits of applying 802.1Qbv’s scheduling approach to share cost-effective fronthaul networks with theoretically zero PDV. This is in part due to the risk of resource wasting if 802.1Qbv slots are not used. Yet this can be mitigated by jointly applying 802.1Qbu. We identify the joint 802.1Qbv/802.1Qbu implementation as a lower-cost alternative to provide time division multiplexing over Ethernet, as other solutions such as FlexE and ITUT G.8312 do. However, while the latter lacks the statistical multiplexing gain of pure strict priority approaches, 802.1Qbv in combination with 802.1Qbu can marge both worlds, ensuring deterministic delay and low delay variation, and allowing non-TSN preemptable traffic to use the excess capacity at the same time. This mechanism would enable, for example, to use the same Ethernet network for both 4G CPRI and 5G eCPRI fronthaul traffic in a cost-effective, flexible and scalable manner. Additionally, there is a potential for aligning 802.1Qbv cycles to TTIs to reduce queuing time, and in optimizing ON-OFF traffic of 4G CPRI-legacy deployments by bounding OFF times within 802.1Qbv cycles. Finally, 802.1Qbv could also be leveraged to adapt network latency budgets according to computational capabilities in the O-DU (e.g., dynamically prioritizing frames that have been delayed because of the virtualization overhead), and to possibly enable dynamic functional splits.
PON WDM Yes Yes Yes Yes Yes Yes Yes Yes Yes
DOCSIS
Microwave
mmWave
No No No Yes Yes (LLX) Yes (LLX) Yes (LLX) Yes Yes
No No No Yes Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes Yes Yes Yes Yes
TSN Qualified
TSN Optional
B. To Schedule or not to Schedule However, the debate is still open. Despite the benefits that scheduling-based TSN techniques may bring to O-RAN time-critical interfaces, there is also an inherent increase in network management complexity. First, the CUC and CNC need to be deployed in the O-RAN architecture and their interactions need to be defined. The most logical options are to deploy the CUC as an rApp in the SMO or non-RT RIC and the CNC as a xApp in the near-RT RIC. However, the 802.1Qcc specification leaves the CUC-CNC interaction in the vendors’ hands, which may require extra standardization effort from the O-RAN Alliance side. Also, while 802.Qbu only involves the re-assembling of the preempted frames in the other end of the link where it is applied, applying 802.1Qbv increases implementation complexity in the switches, and propagating schedule updates involves extra control overhead in the O1 or E2 interface. Secondly, computing schedules at the CNC entails heavy CPU-intensive loads, and near-realtime performance may be challenging for exact algorithms when the network fluctuates significantly [15]. However, this also opens interesting research paths for Artificial Intelligence and Machine Learning (AI/ML) algorithms to support CNC scheduling tasks. This includes research on both the intelligent scheduling algorithm itself and the intelligent decision algorithm that decides which algorithm suits best and where it can be executed most efficiently at any given moment for a particular scenario.
C. Additional TSN standards Besides 802.1Qbu and 802.1Qbv, O-RAN time-sensitive interfaces may also leverage other mechanisms from the TSN toolbox. For instance, IEEE 802.1Qci Per-Stream Filtering and Policing provides improvements for isolation and coordination of traffic flows, and IEEE 802.1Qch Cyclic Queuing and Forwarding, binds bounded latency to the hop-count and cycle time. Both 802.1Qci and 802.1Qch can be jointly used with 802.1Qbv to achieve more accurate control over the schedules. However, other amendments such as IEEE 802.1CB Frame Replication and Elimination for Reliability or IEEE 802.1Qca Path Control and Reservation may only be relevant on RAN transport networks with high frame error rates (e.g., based on Microwave links) or with complex heterogeneous topologies.
JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, OCT 2023
V. C ONCLUSION O-RAN time-critical interfaces certainly benefit from applying TSN to provide determinism to latency-sensitive and latency variation-sensitive streams over cost-effective Ethernet transport networks. Therefore, reduced operator costs in terms of increased deployment efficiency and less infrastructure can be achieved by replacing overdimensioned dedicated links with general-purpose TSN-enhanced Ethernet. This work summarizes the key aspects of the O-RAN/TSN blend, while providing an overview of the joint requirements and deployment options. Finally, we discuss about the potential opportunities and challenges of bringing O-RAN and TSN closer together for the purpose of allowing the O-RAN Alliance to fully reach the openness and virtualization levels it aims to. VI. ACKNOWLEDGMENT This work has been supported by the European Commission through Grant No. 101017109 (DAEMON project) and Grant No. 101097083 (BeGREEN project), by the Spanish Ministry of Economic Affairs and Digital Transformation and the European Union – NextGeneration EU, in the framework of the Recovery Plan, Transformation and Resilience (PRTR) (Call UNICO I+D 5G 2021, ref. number TSI-063000-2021-3Open6G), and by the CERCA Programme from the Generalitat de Catalunya. R EFERENCES [1] L. Bonati, S. D’Oro, M. Polese, S. Basagni, and T. Melodia, “Intelligence and learning in O-RAN for data-driven NextG cellular networks,” IEEE Communications Magazine, vol. 59, no. 10, pp. 21–27, 2021. [2] A. Garcia-Saavedra and X. Costa-Perez, “O-RAN: Disrupting the virtualized RAN ecosystem,” IEEE Communications Standards Magazine, 2021. [3] N. Finn, “Introduction to time-sensitive networking,” IEEE Communications Standards Magazine, vol. 2, no. 2, pp. 22–28, 2018. [4] IEEE, “IEEE Std 802.1Q-2018 Local and Metropolitan Area Networks: Bridges and Bridged Networks,” IEEE Computer Society, 2018. [5] O-RAN Alliance, “O-RAN Fronthaul Control, User and Synchronization Plane Specification 7 (O-RAN.WG4.CUS.0-v07.00),” Tech. Rep., 2021. [6] IEEE, “IEEE Standard for Local and metropolitan area networks: TimeSensitive Networking for Fronthaul,” IEEE Computer Society, 2018. [7] S. Gonzalez-Diaz, A. Garcia-Saavedra, A. de la Oliva, X. Costa-Perez, R. Gazda, A. Mourad, T. Deiss, J. Mangues-Bafalluy, P. Iovanna, S. Stracca et al., “Integrating fronthaul and backhaul networks: Transport challenges and feasibility results,” IEEE Transactions on Mobile Computing, vol. 20, no. 2, pp. 533–549, 2019. [8] C. Simon, M. Maliosz, and M. Mate, “Design aspects of low-latency services with time-sensitive networking,” IEEE Communications Standards Magazine, vol. 2, no. 2, pp. 48–54, 2018. [9] N. J. Gomes, P. Sehier, H. Thomas, P. Chanclou, B. Li, D. Munch, P. Assimakopoulos, S. Dixit, and V. Jungnickel, “Boosting 5G through Ethernet: How evolved fronthaul can take next-generation mobile to the next level,” IEEE vehicular technology magazine, 2018. [10] A. Garcia-Saavedra, J. X. Salvat, X. Li, and X. Costa-Perez, “WizHaul: On the centralization degree of cloud RAN next generation fronthaul,” IEEE Transactions on Mobile Computing, vol. 17, 2018. [11] IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements,” IEEE Computer Society, 2018. [12] Ericsson AB, Huawei Technologies Co. Ltd., NEC Corporation, and Nokia, “Common Public Radio Interface: Requirements for the eCPRI Transport Network V1.2,” Tech. Rep., Jun 2018. [13] S. D’Oro, M. Polese, L. Bonati, H. Cheng, and T. Melodia, “dApps: Distributed Applications for Real-Time Inference and Control in ORAN,” IEEE Communications Magazine, vol. 60, no. 11, pp. 52–58, 2022.
8
[14] O-RAN Alliance, “Synchronization Architecture and Solution Specification 1.00 (O-RAN.WG9.XTRP-SYN.0-v01.00),” Tech. Rep., Jul 2021. [15] W. Steiner, S. S. Craciunas, and R. S. Oliver, “Traffic planning for timesensitive communication,” IEEE Communications Standards Magazine, vol. 2, no. 2, pp. 42–47, 2018.
Esteban Municio received his Ph.D. degree from the University of Antwerp at imec (Belgium) in 2020. He then joined imec as postdoctoral researcher for two years. Since January 2022, he has been with i2CAT, where currently he is a research scientist in the AI-driven Systems group. His research interests are in the field of programmable open networks, Time-Sensitive Networking and ultra-reliable Industrial IoT.
Gines Garcia-Aviles received his Ph.D. degree from the University Carlos III of Madrid. Since January 2021, he has been with i2CAT, where currently he is a research scientist in the AI-driven Systems group. Gines’ research interests are RAN Softwarization, SDN and NFV technologies for future cellular networks.
Andres Garcia-Saavedra received his Ph.D. degree from the University Carlos III of Madrid in 2013. He then joined Trinity College Dublin, Ireland, as a research fellow. Since July 2015, he has been with NEC Laboratories Europe, where currently he is a principal research scientist. His research interests lie in the application of fundamental mathematics to real-life wireless communication systems.
Xavier Costa-Pérez is an ICREA Research Professor, Scientific Director at the i2CAT Research Center, and Head of 5G/6G Networks R&D at NEC Laboratories Europe. He has served on the Organizing Committees of several conferences, published papers of high impact and holds tenths of granted patents. He received his Ph.D. degree in telecommunications from the Polytechnic University of Catalonia, Barcelona, and was the recipient of a national award for his Ph.D. thesis.