5G/NR - RAN Architecture                                           Home : www.sharetechnote.com

 

 

 

 

Overall Architecture of NR RAN (Radio Access Network) would not look much different from LTE RAN Architecture. However getting into details, you would start seeing some differences as well. You see different name of each node and interface. MME/S-GW in LTE is replaced by AMF/UPF in NR and X2/S1 in LTE are replaced by Xn/NG-C/U in NR. Different name would mean different protocol and implemenation. Among all of these differences, out of the most outstanding one would be that the gNB internal structure is split into two parts called CU (Central Unit) and DU (Distributed Unit) as shown below and these two entities are connected by a new interface called F1 (For the details of F1 Intreface, refer to 38.473).

 

 

 

 

 

Where to split between CU and DU ?

 

My first question when I head of this split was 'exactly at which point the split happens ?'. For now, it seems to be dependent on how you implement it. Theoretically you can split at every layers in the protocol stack. You will find the detailed descriptions about the details on all the possible split options in TR 38.801 - 11.1.1,11.1.2, but it seems that the most common and agreeable split line seems to be as shown below.

 

 

 

Then you may have this question. Why this option (i.e, splitting between RLC and PDCP) is preferred (at least preferred at the time of writing, May 2018) ? it is justified in TR 38.801 as follows :

  • This option will allow traffic aggregation from NR and E-UTRA transmission points to be centralized.  Additionally, it can facilitate the management of traffic load between NR and E-UTRA transmission points.  
  • Fundamentals for achieving a PDCP-RLC split have already been standardized for LTE Dual Connectivity, alternative 3C. Therefore this split option should be the most straightforward option to standardize and the incremental effort required to standardize it should be relatively small

 

 

 

Why the Split ?

 

Then a next question would be 'Why we need to think of this kind of split ?'. I think the simple answer would be 'it is because this split helps to virtualize the network functionalities'. Virtualization usually mean flexibility and cost reduction. With this kind of split, we can think of a RAN implementation as illustrated below. At least as of now, it would be difficult to virtualize the lower layer of gNB(PHY/MAC/RLC), but you would be able to put higher layer protocol stack (PDCP and above) into a open hardware and software-based protocol stack.

 

 

 

 

Any Concerns on the Split ?

 

Looks fancy and sound good, but isn't there any concern about this kind of implementation ? For any new technology, we always see both 'hype' and 'concern'. Only time will tell you.  Followings are some of the commonly raised concern that I see in various readings.

  • Performance Issue : Even though we see ever increasing performance of those open hardware (e.g, HP / DELL Server) in one side, we see ever increasing requirement of throughput and latency on the other side (i.e, throughput and latency requirement proposed in NR). The questions is whether the speed of the open hardware evolution is fast enough to catch up the speed of the requirement evolution.
  • Ownership of Troubles : In deploying this kind of split architecture, it is highly likely that the hardware (i.e, server) and software (protocol stack) comes from different vendors. Then an important question (concern) would come out. Who is going to be responsible if some problem happens ? Of course, you would see some obvious hardware problems and some obvious software problems, but in reality there are a lot of problem sitting at the borderline between software and hardware(i.e, it is hard to clearly point out the root cause). As everyone can understand, nobody would like to take responsibilities for troubles. You would go through a lot of ping-pongs among different stakeholders (i.e, Network Operators, Hardware vendor, software (protocol stack) vendors).
  • Security Issues : I don't think I need to say much on this. Whenever we talk about 'open system and software based system', the first concern is about security.

 

 

 

Reference

 

[1] What is a virtual RAN?

[2] vRAN Tech Hits Resistance at SK Telecom

[3] 5G NR gNB Logical Architecture and Itís Functional Split Options

[4] Functional Split Options for Centralized RAN with Imperfect Backhaul