Although it is understood in general that virtualization and increasing complexity are inherent characteristics of 5G networks many people are surprised when they realize the significant differences of 5G RAN architecture and signaling procedures compared to what they know from LTE or UTRAN.
In this blog post series I want to highlight some details that are not immediately visible when reading the 3GPP specs.
Figure 1 shows a virtualized gNB and the protocols it uses to communicate with its internal entities as well as with the UE and peer entities in neighbor network elements/functions.
The core of the whole thing is the gNB-Central Unit for the Control Plane (gNB-CU CP). This function communicates directly with the UE using the NR RRC protocol. It also "talks" to the 5G Core Network represented by the AMF using the NGAP, a protocol very similar to the S1AP known from E-UTRAN. Neighboring 5G base stations are contacted using the XnAP, neighboring eNBs can be reached by using X2AP.
The other virtual functions of the gNB are the Central Units for User Plane (gNB-CU UP) and the Distributed Units (gNB-DU). While the gNB-CU UP is responsible for handling the transport of payload the gNB-DUs deal with all the allocation of radio resources, especially the scheduling. As a result the lower layer radio interface protocols, especially RLC and MAC terminate in the gNB-DUs.
For the RAN monitoring tools and the 3GPP Minimization of Drive Test (MDT) feature this means that RRC and Logged Measurement Reports sent by UEs will be available at gN-CU CP while all uplink radio quality measurements and call-related user plane metrics is only available at the gNB-DU - see figure 3.
And today, there is no 3GPP-standardized procedure to correlate this measurement information collected by different virtual gNB functions.
The full impact of the 5G RAN virtualization becomes even more evident when looking at Figure 3. It shows a single gNB-CU CP in charge of controlling several gNB-CU UPs and gNB-DUs.
In a live network deployment a single gNB-CU CP will control hundreds of gNB-DUs and maybe several gNB-CU UPs. This is why it is misleading to compare the connectivity of a gNB-CU CP with that of a LTE eNB. Rather it could be compared with a UTRAN RNC controlling a similar number of 3G base stations.
Looking back into figure 1 we see that the F1AP is used for communication between gNB-CU CP and its gNB-DUs while the E1AP is the protocol that connects the gNB-CU CP with surrounding gNB-CU UPs.
Call-related control plane procedures of F1AP and E1AP are very similar to what is known from NGAP. There is a UE context established between the gNB-CU CP and the gNB-DU. On F1-U a GTP tunnel is established for user plane transport. At the same time an E1 Bearer Context in gNB-CU CP and gNB-CU UP keeps track of the most relevant user plane transport parameters.
All in all for setting up a single subscriber connection in the virtualized 5G RAN there are significantly more signaling transactions necessary than in E-UTRAN. Figure 4 shows a practical example.
The volume and complexity of signaling information is increasing when the UE moves or is redirected to virtual functions within one gNB e.g. due to load balancing.
The next blog post of this series will dive deeper into details of such call scenarios.
Stay tuned...
Related Posts:
In this blog post series I want to highlight some details that are not immediately visible when reading the 3GPP specs.
Figure 1 shows a virtualized gNB and the protocols it uses to communicate with its internal entities as well as with the UE and peer entities in neighbor network elements/functions.
 |
| Figure 1: Virtual Network Functions and Protocols in 5G RAN (click on the image to see full size) |
The other virtual functions of the gNB are the Central Units for User Plane (gNB-CU UP) and the Distributed Units (gNB-DU). While the gNB-CU UP is responsible for handling the transport of payload the gNB-DUs deal with all the allocation of radio resources, especially the scheduling. As a result the lower layer radio interface protocols, especially RLC and MAC terminate in the gNB-DUs.
For the RAN monitoring tools and the 3GPP Minimization of Drive Test (MDT) feature this means that RRC and Logged Measurement Reports sent by UEs will be available at gN-CU CP while all uplink radio quality measurements and call-related user plane metrics is only available at the gNB-DU - see figure 3.
 |
| Figure 2: Distribution of un-correlated RAN measurement tasks among different gNB virtual functions (click on the image to see full size) |
And today, there is no 3GPP-standardized procedure to correlate this measurement information collected by different virtual gNB functions.
The full impact of the 5G RAN virtualization becomes even more evident when looking at Figure 3. It shows a single gNB-CU CP in charge of controlling several gNB-CU UPs and gNB-DUs.
In a live network deployment a single gNB-CU CP will control hundreds of gNB-DUs and maybe several gNB-CU UPs. This is why it is misleading to compare the connectivity of a gNB-CU CP with that of a LTE eNB. Rather it could be compared with a UTRAN RNC controlling a similar number of 3G base stations.
 |
| Figure 3: 5G RAN Connectivity (click on the image to see full size) |
Looking back into figure 1 we see that the F1AP is used for communication between gNB-CU CP and its gNB-DUs while the E1AP is the protocol that connects the gNB-CU CP with surrounding gNB-CU UPs.
Call-related control plane procedures of F1AP and E1AP are very similar to what is known from NGAP. There is a UE context established between the gNB-CU CP and the gNB-DU. On F1-U a GTP tunnel is established for user plane transport. At the same time an E1 Bearer Context in gNB-CU CP and gNB-CU UP keeps track of the most relevant user plane transport parameters.
All in all for setting up a single subscriber connection in the virtualized 5G RAN there are significantly more signaling transactions necessary than in E-UTRAN. Figure 4 shows a practical example.
 |
| Figure 4: 5G RAN Call Trace in NETSCOUT Session Analyzer (click on the image to see full size) |
The next blog post of this series will dive deeper into details of such call scenarios.
Stay tuned...
Related Posts:
- The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 2
- 3G4G: Open RAN, OpenRAN and O-RAN
