A Look into 5G Virtual/Open RAN - Part 1

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.

Figure 1: Virtual Network Functions and Protocols in 5G RAN
(click on the image to see full size)

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.

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 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:

• The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 2
• 3G4G: Open RAN, OpenRAN and O-RAN

3GPP Minimization of Drive Test (MDT) Signaling at a Glance

There are growing numbers of UEs that are capable of reporting 3GPP-defined measurements for the purpose of minimization of drive test as defined in 3GPP TS 37.320. Although only a subset of the capable devices have this feature enabled it is worth to have a closer look at the signaling procedures and measurements.

3GPP MDT data can be gathered in two different modes: immediate and logged.

immediate mode – as illustrated in figure 1 - provides measurements for RAN and UE. The UE measurements are derived from RRC measurement reports. The RAN adds the power headroom reported on the MAC layer, and the Received Interference Power (RIP) measured on the physical radio interface layer at the cell`s antenna as well as, reports for the data volume, IP throughput, user plane packet delay, and packet loss measured by the eNodeB.

Figure 1: Immediate 3GPP MDT Measurements*

logged mode – an example is shown in Figure 2 - the UE stores information related to accessibility problems in IDLE mode, failures during RRC establishment, and handover random access as well as radio link failures including connection loss. The MDT events log is sent to the network when it is requested. After connection loss, the MDT logged mode report is sent after the next successful radio connection establishment.

Figure 2: Logged 3GPP MDT Measurements*

The RRC measurement samples and Radio Link Failure (RLF) reports also contain detailed location information for example, on GPS/GNSS coordinates, although the 3GPP Release 9 Technical Report TR 36.805 stated: “The extensive use of positioning component of the UE shall be avoided since it would significantly increase the UE power consumption.”

Although, the encoding of logged mode reports and immediate UE measurements are defined in 3GPP TS 36.331 (RRC), the message formatting of the immediate RAN measurement events follow different proprietary specifications of the network element manufacturers (NEMs).

It is also up to the NEMs which of the M2... M7 immediate reports are implemented and how often such measurements will be generated during an ongoing connection. 

* all parameter values shown in the figures have been chosen randomly for illustrative purpose and do not reflect the situation of a real call or network 

RRC states in 5G

Looking back at my old post about UMTS & LTE (re)selection/handovers, I wonder how many different kinds of handovers and (re)selection options may be needed now.

In another earlier post, I talked about the 5G specifications. This can also be seen in the picture above and may be easy to remember. The 25 series for UMTS mapped the same way to 36 series for LTE. Now the same mapping will be applied to 38 series for 5G. RRC specs would thus be 38.331.

A simple comparison of 5G and LTE RRC states can be seen in the picture above. As can be seen, a new state 'RRC Inactive' has been introduced. The main aim is to maintain the RRC connection while at the same time minimize signalling and power consumption.

Looking at the RRC specs you can see how 5G RRC states will work with 4G RRC states. There are still for further studies (FFS) items. Hopefully we will get more details soon.

3GPP TS 22.261, Service requirements for the 5G system; Stage 1 suggests the following with regards to inter-working with 2G & 3G

5.1.2.2 Legacy service support
The 5G system shall support all EPS capabilities (e.g., from TSs 22.011, 22.101, 22.278, 22.185, 22.071, 22.115, 22.153, 22.173) with the following exceptions:
- CS voice service continuity and/or fallback to GERAN or UTRAN,
- seamless handover between NG-RAN and GERAN,
- seamless handover between NG-RAN and UTRAN, and
- access to a 5G core network via GERAN or UTRAN.