The RAN workload is a prime example of providing deterministic performance and service reliability, operating in real-time to manage the full range of resources for UEs. There are many infrastructure settings required for RAN workload to run stably and deterministically. The infrastructure settings include:
- BIOS settings—An example of some of its required settings is in the Addendum.
- OS & CaaS OS settings—An example of required settings is in the Addendum.
- Tuned-adm settings—Maintaining real-time performance of the system is crucial; the real-time profile should be used as described in the Addendum.
- NUMA settings—All IOs of each RAN function should be tied to a specific NUMA.
- Disable NTP and stable PTP—The real-time TTI scheduling needs micro-second precision; thus, NTP should be disabled and PTP should run stably. Only NICs that support PTPv2 should be used. The appropriate firmware and driver versions are required to keep the PTP stable.
- Number of SRIOV VFs per PF for Fronthaul—The number of SRIOV VFs will depend on Fronthaul compression rate. To prevent overflow and packets loss, use the appropriate number of SRIOV VFs per PF.
- Fronthaul-specific options—Only vendor-supported optics should be used.
- vSwitch and Port-Group settings—If virtualization is used to host RAN functions, spoof check should be used, and trust for VFs should be disabled.
- PTP time-scale—The Grandmaster, DU, and RU should all use UTC timescale rather than TAI. Any discrepancies could cause packets dispatched by DU to reach RU outside the receive window.
RAN configurations
- Antenna ports and eAxCs settings—The settings are applicable per cell and important for SAP connections between DU and RU. The eAxCs should be distinct from one cell to another if there are multiple carriers over the same logical fronthaul link with same VLAN and mac-address.
- Fronthaul downlink delay parameters—If M-Plane is disabled, FH delay parameters should be adjusted manually to compensate the receive errors caused by network jitters on both ends (RUs and DUs).
- Fronthaul IQ compression—The fronthaul IQ compression settings should match on both DU and RU.
- Dynamic section of UL—This setting should be enabled if supported by both DU-L1 & RU.
- Cell and band configuration—The 4T4R Cells with 100 MHz carrier bandwidth and 30 kHz Sub-Carriers provide the most appropriate cell configuration for user throughput and performance benchmarking.
- Preamble format—It is preferred to use contention-free preambles during uplink sync acquisition to simplify the integration.
- PLMN ID, U-Plane Security, NSSAI (SST, SD)—Because these settings are individually set on 5G Core, CU and DU, it is advised to cross-verify these settings.
- RAN stack defects and stability—The disaggregated RAN is emerging for both Look-aside and Inline L1 architectures. All individual components should be thoroughly unit tested. Any introduction of optimization could destabilize the stack; thus, the changes should be introduced with high care and thoughtfully.
5G NR SA Test-Tools configuration
- Variations in setup architecture, network topology, and devices—Any upgrades to testing tools or RAN Stack could cause a considerable architecture change. It might impact changes in physical network links or the topology.
- Custom UI—Test tools normally provide highly customized interfaces designed to simplify user interactions. However, a general understanding of a tool from one vendor may not fully apply to a tool from another vendor, even if they serve the same function.
- Scaling test-tools—It is recommended to evaluate the scale of the test tools before scaling the RAN Stack. Intermittent or last-minute scaling of tools could impose unknown challenges. For example, upgrading tools might require more hardware resources, a different architecture, or network topology.
- Adoption of Open hardware components and Cloud-native architecture in SW—It is recommended to rely more on Open HW and CNFs-based Test-Tools. Custom hardware or components could impose a longer lead time while procuring the equipment or longer recovery time if any part fails.
Standards with multiple parameter options
- Multiple options for a configuration parameter—The number parameters in the disaggregated RAN could be optional or open to set any value from the applicable list of values, which could cause non-alignment of parameters and impose an integration challenge. For example, standard/jumbo Ethernet frames in fronthaul, VLAN Priority (0-7), or the same or split VLAN for C/U plane.
- Customized FAPI for P5 and P7—FAPI control and user interfaces allow vendor-specific verbs, which make each L2 non-compatible with other L1.
- No standards for power saving—There are no standard interfaces defined to enable energy efficiency in the DU or RU.
- Standards are evolving—The evolving standards for disaggregated RAN create several challenges for RAN-function integrations.
- No specific guidance on Power Consumption by RAN—There is no specific guidance on power consumption limits available to achieve a reasonable bits per watt performance. Standard committees should establish guidance and examples.