Function splitting is nothing new now. Its concept was first mentioned in 3GPP R14. 3GPP R15 released the definition and introduced new terms, interfaces and functional modules.
But in open ran, why do Ru, Du and Cu functionsHas the concept of splitting become so important?
This article will give you a comprehensive understanding of what, what, how and when.
The previous ran architecture (2G, 3G and 4G) was based on "monolithic" building blocks, and there was little interaction between logical nodes. However, in the initial stage of new radio (NR) research, it is considered that dividing GNB (NR logical node) between central unit (Cu) and distributed unit (DU) can bring flexibility.
Flexible hardware and software allow scalable, low-cost network deployment, provided that hardware and software components can interoperate and can be mixed and matched with different vendors. The separated architecture (between central and distributed units) allows coordination of performance characteristics, load management, real-time performance optimization, and can adapt to various use cases and QoS to be supported (i.e. games, voice, video).
Why does open ran adopt a separate architecture?
The following figure shows the current industry view. Nokia believes that the only effective division is between Ru and Du, and indicates that time will prove whether the integration of one supplier's Du and another supplier's Cu will bring flexibility and low cost.
conclusion: if the interface between hardware and software components is open, function splitting will save costs.
In the 5g ran architecture, the BBU function is divided into two functional units: the distributed unit (DU) responsible for processing high real-time protocols and the central unit (Cu) responsible for processing non real-time, RRC, PDCP and other high-level protocols.
In 5g c-ran, Du's server and related software can be hosted in the site itself or in the edge cloud (data center or central office), depending on the availability of transmission and forward interface. The server and related software of the Cu can be placed in the same location as the Du or hosted in the regional cloud data center. The actual division between Du and Ru may vary depending on the specific use case and implementation.
: a radio unit responsible for handling DFE and some PHY layer functions. The key considerations in its design are size, weight and power consumption.
: the distributed unit close to Ru mainly handles RLC, MAC and some PHY layer functions. The logical node includes a subset of ENB / GNB functions, depending on the function splitting option, and its operation is controlled by the Cu.
: the central unit responsible for handling RRC, PDCP and other high-level protocols. GNB is composed of a Cu and a Du, which are connected to Cu through fs-c and fs-u interfaces of CP and up respectively. A Cu with multiple DUS will support multiple GNBS. The separation architecture enables the 5g network to use different protocol stack distribution between Cu and Du according to the mid stream availability and network design. The Cu can centrally manage multiple DUS through the intermediate transmission interface.
Centralized baseband deployment allows load balancing between different Rus, which is why in most cases, Du will be paired with Ru to perform all intensive processing tasks. Edge centric baseband processing provides low latency, seamless mobility with real-time interference management, and optimal resource optimization.
The industry believes that the underlying interface connecting Ru and Du is ecpri to provide the lowest delay, and the forward delay is limited to 100 microseconds.
It should be noted that Du / Cu splitting is hardly affected by the type of infrastructure. The new interface is mainly the F1 interface between Du and Cu. They need to be interoperable across different suppliers to truly realize open ran. Midhaul connects Cu and Du.
The 4G / 5G core is connected to the Cu through backhaul, and the 5g core can be 200 km away from the Cu at most.
For delay sensitive services, based on appropriate preamble availability,
Mac-phy splitting is the preferred solution.
In option 7 split architecture, Du handles modules with RRC / PDCP / RLC / Mac and higher PHY functions, while Ru handles modules with lower phy and RF functions. The Cu function can be embedded on the same server as the Du, or it can be pushed to the network together with the openran controller or aggregator as a virtualized aggregation entity.
Split 8 is a CPRI interface based on industry standards. For traffic split 8, all functions except RF (from PHY to RRC layer) are processed by Du, while RF layer is located in radio.
This division is very effective in 2G and 3G. In 2G and 3G, the traffic rate is much lower, which can be easily completed on X86 servers, while allowing operators to use cost optimized Ru. The improvement of traditional split-8 is that in order for Ru to run multiple technologies on the same FH interface, they now need to use the traditional CPRI interface replaced by ecpri between Ru and Du.
This approach allows traffic aggregation from Ru centralization to achieve seamless migration from traditional LTE ecosystem to NR ecosystem.
Ran Du is located between Ru and Cu and performs real-time L2 function (baseband processing). In the o-ran alliance working group, Du is proposed to support multi-layer Ru. In order to correctly process digital signals and speed up network traffic, FPGA can be used. Although hardware acceleration is considered a necessary condition for 5g, it is not so necessary in previous technologies such as 2G, 3G and even 4G.
Hardware accelerators around FPGA and GPU have also received attention to accelerate real-time sensitive processing at the bottom of 5g radio baseband. Ericsson and Nokia are studying GPU based acceleration for some vran workloads, especially 5g m-mimo and AI.
Main conclusions: different splits apply to different use cases.
How new radio (NR) functions are divided in the architecture depends on some factors related to the radio network deployment scheme and the expected support use cases. There are three key elements:
In order to make full use of the separated architecture, all solutions need to support 2G, 3G, 4G and 5g baseband functions. In order to meet the best delay support requirements, the baseband function separated from the hardware should be deployed on nfvi or as a container. MNOS can use any VM requirement or orchestration to enable these functional splits.
Disclaimer: This article comes from the Internet
Reprinted from“Sdnlab / 5G communication”, support the protection of intellectual property rights. Please indicate the original source and author for reprint. If there is infringement, please contact us for deletion.
Specific QoS support needs to be provided for each service (such as low latency and high throughput in urban areas) and real-time / non real-time applications.
Support the load requirements of specific user density and specific geographical areas.
Available transport networks with different performance levels.