Challenges in ORAN/ORAN Deployment.
With the move towards Open RANs, operators and integrators need to test that all the Technology works together before it goes into the live network. Best scenario of this challenge concerns the wide range of components being used by different vendors. How do you deliver the best possible service when optimising the configuration of the control plane?
Secondly Operators also need to see how this technology interacts with legacy 4G equipment in the network, and how it responds to different UE environments.
Another major challenge is, once the technology has been deployed, when a problem arises who solves it and how do you do this? With an Open RAN network, when a problem arises, you must work with multiple vendors to resolve the issue. Who takes the responsibility to resolve the issue when there are multiple vendors involved?
Performance perspective ORAN Challenges:
Below are the points to focus whenever an operator is adopting ORAN deployment to overcome the challenges:
- Meeting the Key performance Indicator in a multi-vendor environment.
- E2E network performance.
- Keeping an eye on performance when large number of UE’s connected to network with different scenarios.
- Synchronization of fronthaul (O DU to O RU connection). Here Synchronization plane plays an important role.
- PHY & MAC coordination: As we are now aware that O-RU contains some functionalities of PHY layer which we call it as Low Phy. So PHY-MAC coordination plays an important role to maintain the performance of ORAN.
To overcome the performance related challenges there are lots of use cases an operator can execute and follow, below are some of them:
- Multi-Vendor Interoperability Test for:
- System level Test
- protocol compliance tests for open interfaces and protocols
- Stability Testing
- Stress Testing
- Higher availability Testing.
4G RAN Architecture Versus 5G RAN architecture: Block Diagram
As shown in Figure above, some user plane functions in the 4G LTE core have been moved to the CU and DU, layer 2 (L2) non-real-time and layer 3 (L3) functions have been moved from the BBU to the CU, L2 real-time functions to the DU and layer 1 (L1) functions split between the DU and RU. The mapping of functions to devices results in different “split options” with regard to which layers of the protocol stack are mapped to which device. While the split between CU and DU is now formally defined by 3GPP, there are a number of split options still to be considered for the DU/RU interface.