Open RAN, as defined by O-RAN Alliance, builds on the Split RAN and Virtual RAN technologies but is not the same as either Split RAN or Virtual RAN. The architecture of the Open RAN, as defined by the O-RAN Alliance, is shown below.
A Radio Access Network that qualifies as Open RAN for the O-RAN Alliance has at least the following seven characteristics:
1) The fronthaul (connecting the RU to the DU) follows Option 7-2 of O-RAN specifications and implies that the RU implements the defined lower physical layer functionality (PHY-Low), while the DU implements the upper physical layer functionality (PHY-High), and the two communicate with each other using a protocol defined by the O-RAN Alliance.
2) The infrastructure elements (the DU, the CU control plane, and the CU user plane) are responsive to off-board, possibly third-party intelligence, as defined by the O-RAN Alliance architecture and implies quite a change in the traditional architecture, where most of the functionality is directly implemented inside the infrastructure elements.
3) Platforms external to these infrastructure elements, specifically the RAN Intelligent Controllers (RICs) and the Service Management and Orchestration (SMO), interface with infrastructure elements using protocols defined by the O-RAN Alliance.
4) External applications (called xApps and rApps) use the services of the RICs to communicate with the infrastructure elements to exert fine-grained control over the behavior of the RAN.
5) The infrastructure elements are expected to be containerized network functions that run on a distributed, virtualized environment called the O-Cloud. An orchestrator that is a part of the Service Management and Orchestration (SMO) framework onboards the software and descriptors for the RAN infrastructure elements and manage their lifecycle (instantiation, scaling, healing, shutdown). The interface between the orchestrator and the O-Cloud is standardized and follows the Network Functions Virtualization (NFV) standards set by the European Telecommunications Standards Institute (ETSI).
6) The RICs and the apps communicate with the infrastructure elements using a standardized protocol (E2) defined by the O-RAN Alliance.
7) The architecture allows the external applications to incorporate operator-defined policies, machine learning algorithms, and external (enrichment) information pertinent to network operation in a standardized manner.
An O-RAN Alliance Open RAN will support all the above characteristics. However, Open RAN is still in its infancy. Much progress has been made, but Open RAN specifications are still being defined. As a result, we expect various facets of Open RAN gradually make their way into the network. For instance, support for Option 7-2x specified open fronthaul might be implemented before the RICs and their ecosystem for applications. Infrastructure elements may initially support only subsets of the functionality defined by the E2 interface. Infrastructure vendors may initially provide RICs, but the interface between the RIC and the infrastructure elements may remain proprietary in the short term. The capabilities that the infrastructure elements/RIC open up to the apps may be limited. All these are relatively common phases that a new technology goes through during its maturation. However, all seven of the characteristics above are needed to deliver on the operators’ dream ultimately and the O-RAN Alliance’s vision of a “… truly open, intelligent, virtualized, and fully interoperable RAN.”