We all are aware of the generations of network technology. It started with 1G, 2G, 2.5G, 3G, and 4G, and now the latest buzz is about 5G. While a lot of our hopes are set on the exciting new services that 5G will bring, did you know that 5G was first widely deployed in 2019?
With this blog, let’s explore what 5G is and how it is being tested on virtual machines. Here I’ll focus on one small part of the Radio unit called the M-plane. We will look at the basic functions of the M-plane and then steps to test the M-plane on a virtual machine with some sample outputs. Let’s Start!
Introduction:
5G networks are cellular networks in which the service area is divided into small geographical areas called cells. All 5G wireless devices in a cell communicate by radio waves with a cellular base station via fixed antennas, over frequency channels assigned by the base station. A technical distinction between 4G and 5G is that 4G uses CDMA and CPRI for front haul connections, while 5G employs OFDM and eCPRI.
The solution includes support for various 3GPP bands, especially the low and mid bands like Band 71,29, and 40. It can be customized for other bands as well.
For more information, you can visit the link.
The basic view of the 5G core network
Let’s talk about the RU (Radio Unit)
RU(Radio Unit): RU is the radio hardware unit that converts radio signals sent to-and-from the antenna into a digital signal for transmission over packet networks. Besides handling the digital front end (DFE) and the lower PHY layer, it also handles digital beamforming. RU designs for 5G are supposed to be “inherently” intelligent, but size, weight, and power consumption are the key considerations.
Visit this link for more information on this
.
There are four traffic classes or planes in RU.
- S-plane(Synchronization)
- C-plane(control)
- U-plane(user)
- M-plane(Management)
We will talk in detail about the M-plane, that is, the Management Plane.
The M-plane specification of O-RAN (Open RAN) is an open-source standard. M-plane is a server-client communication, based on Network configuration Protocol (Netconf). The software runs on the netconf server, and the netconf client connects to the server to manage the RU.
NETCONF Protocol:
You can read more about Netconf protocol here: RFC 6241: Network Configuration Protocol (NETCONF)
M-plane Architecture:
The O-DU and NMS correspond to Neconf-Client monitors and control the O-RU which is a Netconf server. Through the above controllers, M-plane manages everything in O-RU.
In the O-RAN specifications, two models are defined for the management plane: hierarchical and hybrid. Let’s know in brief about them-
- Hierarchical Model: In this model, O-DU or O-RU-controller, that is, the Netconf client is directly connected to O-RU through an SSH connection. NMS is connected through the O-DU controller. And O-RU is managed by O-DU. The O-DU is a Sudo-user that accesses all parts of the O-RU.
- Hybrid Model: In this model, O-DU netconf client is connected to O-RU. And, the NMS netconf client is directly connected to O-RU through an SSH connection. One or more NMS and O-DUs manage the O-RU at the same time.
M-plane supports both architectures as per the O-RAN standard specification. But the M-plane design or development still depends on the vendor’s requirements.
M-plane has two important components: the SIL code and the Backend Code.
SIL code is based on YANG files. And Backend is developed for features supported by M-plane defined in the specification.
YANG is a Data Modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
For more information read: YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF) RFC 6020
The O-RU M-plane supports some of these basic YANG models:
- Software Management
- Configuration Management
- Fault Management
- Performance Management
- File Management
There are several YANG models defined by Yuma-works. We can use any version of the O-RAN standard and develop an M-plane to support YANG defined in that version.
Let’s look at an example that supports version 3.0 of the O-RAN standard specification of an M-plane.
The basic functions of an M-plane are:
- Start-up Function: In this, O-RU will establish a connection between O-DU or NMS (netconf-client) through a call-home procedure.
- Manual setting of Transport Layer addresses
- Allocation of Transport Layer addresses by DHCP server.
- Call-home procedure:
The above diagram is a procedure for a call home. The DHCP server will give all the information related to the surrounding netconf clients(O-DU) to the netconf server(O-RU). Once the server gets the information, it will start sending TCP connection requests to those IPs, and if any client is listening on the same port it will be connected to the netconf server. During the connection, the server will exchange the capabilities, i.e., all features or YANG models the server supports.
For more information, you can read the O-RAN m-plane specification.
Once the connection is established, the Client gets the information or can start configuring O-RU using the below functions.
- Software Management:
The O-RU software is managed via an O-DU/NMS and M-Plane’s NETCONF client. In a multi-vendor RAN environment, a NETCONF client of a certain vendor must manage the Software files of an O-RU heavily dependent on another vendorʼs implementation. So a mechanism is needed where the SW management is independent of O-RU implementation or vendor. The Software Management in this consists of the following steps:
- Software Inventory
- Software Download
- Software Installation/Upgrade
- Software Activation
- Configuration Management:
In this function, an O-DU/NMS netconf client sets O-RU parameters required on the C/U plane and S-plane and gets status via the M-plane. This configuration is achieved by using a standard message (RPC) specified in Netconf. NETCONF specifies <edit-config> and <get-config> as standard messages for setting parameters and getting parameter values, respectively. Sending these messages to an O-RU makes it possible to set various types of parameters and to get information on the parameters stored on the O-RU and the status of that equipment.
- Fault Management:
This function gives information about the Fault- alarms generated in the O-RU. Netconf client manages O-RU faults via this function. In the event of some sort of problem on the O-RU side such as temperature going beyond a threshold level, problem with synchronization, etc.
The O-RU notifies the Netconf client by sending notification messages defined by the Netconf protocol with the following detailed information:
- Fault ID
- Location of fault occurrence
- Locations affected by the fault
- Severity of fault
- New fault occurrence or a fault that has already been resolved.
- File Management:
This function is used to keep track of all the files related to O-RU. Via this, the Netconf client, O-DU, can upload and download the files and manipulate them.
This function supports the following features:
- File Upload
- File Download
- Retrieve File list
- Performance Management:
This function will collect information related to the radio or antenna unit, like measurements related to activation and deactivation. Collecting and reporting measurement results. It stores the information in one file called performance_mgmt.csv file. This file is later used by the Netconf client.
All the above basic functions are developed in the M-plane and tested on Virtual machines and Real RU boards. There is always a scope for more features that can be developed and tested.
The M-plane software as a netconf server usually runs on the Linux OS. You can run the Netconf-server by following the instructions below:
Testing on VM (Linux System only):
- Install the Yuma-pro SDK. Reference: https://docs.yumaworks.com/en/latest/install/index.html
- Install yumapro-server and Mplane-specific code
- After installation- Run the netconf server:
->$ sudo netconfd-pro
->$ sudo zmq_services.py (this script is responsible for the services related to M-plane using the zmq socket library)
- On another VM Run netconf client: on another VM also yumapro-sdk should be installed to run the client.
-> $ sudo yangcli-pro ncport 22 server=<server-ip> user=<server-username> password=<server-password>
After connecting the Client to the server you can check all yang model-related functions using Create, Merge, and x-get commands, etc.
Example: Below image shows the x-get operation of interfaces. It will show all the interfaces available on the VM. Yangcli-pro is a client-side application to connect the Netconf server using the Netconf protocol, which also comes with yumapro-sdk.
How to use and run other operations using yangcli-pro Yuma yangcli Manual – Yuma123 Wiki
Sample Output:
Conclusion:
The purpose of this blog was to provide a brief overview of 5G, and some of its components. Especially the M-plane – based on my working experience in the field. I hope you find it useful as a starting point in discovering and learning about 5G.
If you wish to know more about it and want to interact with our team, feel free to drop us your interest here: https://vayavyalabs.com/contact-us/
