5G Telecom Network – O-RAN M Plane – Part 3

Introduction

In earlier blogs, I have briefly recapped the 3GPP defined 5G architecture and O-RAN architecture with the list of each architecture element's functionalities and the interfaces between them.

O-RAN architecture adds a few more function nodes and interfaces; among them are SMO, O-DU and O-RU. Those logical functions and the interfaces between them made up Open FH CUS plane and Open FH M plane.

Open FH M plane is well defined in O-RAN Management Plane Specification 12.0. The document name is O-RAN.WG4.MP.0-R003-v12.00

In this blog, I will explain about M-Plane deployment options, which are based on either Hierarchical model or Hybrid model. NEFCONF is the protocol used for management of O-RU and is also briefly discussed.

M-plane architectural model

O-RAN defines 2 models that basically differ on where the "O-RU Controller" should be, on SMO or O-DU.

Hierarchical model: the O-RU is controlled by 1 or more O-DU. (O-DU is controlled by SMO)
Hybrid model: O-RU is controlled by SMO. There may be an IP traffic route to O-DU where, O-DU provides routing table/ NAT to O-RU for controlling message from SMO.

The following details the hierarchical model and hybrid model. Notice that for hierarchical model, NETCONF Server is placed on O-RU. NETCONF Server responses to request initiated by NETCONF Client placed on O-DU. For Hybrid mode, NETCONF Server is placed on O-RU and responses to request initiated by NETCONF Client placed on both O-DU and SMO.

Source: What is The M-Plane in Open RAN? - Moniem-Tech

The following are functionalities of M-Plane:

start-up installing
software management
Management Plane Specification
Configuration management
Performance management
Fault management
File management

NEFCONF protocol

The Network Configuration Protocol (NETCONF) is a network management protocol allowing a network management system (NMS) to deliver, modify, and delete configurations of network devices

The NETCONF architecture

Basic NETCONF network consists of two roles: client and server.

A client can be a script or an application running on an NMS, and provides the following functions:
- Manages network devices using NETCONF.
- Sends RPC requests to a NETCONF server to query or modify one or more parameter values.
- Learns the status of a managed device based on the alarms and events sent by the NETCONF server of the managed device.
A server, typically a network device, maintains information about managed devices and responds to the client-initiated requests.
- When receiving a request from a NETCONF client, the NETCONF server parses the request and sends a reply to the client.
- If a fault or another type of event occurs on a managed device, the NETCONF server reports an alarm or event to the client through the notification mechanism. This allows the client to learn the status of the managed device.

Source: What Is NETCONF? Why Do We Need It? - Huawei

NETCONF operations

The base protocol defines the following protocol operations:

Operation	Description
<get>	Retrieve running configuration and device state information
<get-config>	Retrieve all or part of a specified configuration datastore
<edit-config>	Edit a configuration datastore by creating, deleting, merging or replacing content
<copy-config>	Copy an entire configuration datastore to another configuration datastore
<delete-config>	Delete a configuration datastore
<lock>	Lock an entire configuration datastore of a device
<unlock>	Release a configuration datastore lock previously obtained with the <lock> operation
<close-session>	Request graceful termination of a NETCONF session
<kill-session>	Force the termination of a NETCONF session

NETCONF messages

NETCONF uses Extensible Markup Language (XML)-based data encoding for the configuration data and protocol messages, and uses a simple remote procedure call (RPC) mechanism to implement communication between a client and a server.

3 types of NETCONF messages:

RPC invocations (<rpc> messages),
RPC results (<rpc-reply> messages), and
event notifications (<notification> messages).

Structure of a complete NETCONF YANG request/invocation message. Source: What Is NETCONF? Why Do We Need It? - Huawei

Basic NETCONF session

The basic NETCONF session would include Hello Message, request/invocation messages, request to terminate session. Notice that NETCONF is carried overed by SSH. Thus we also have SSH session request/termination message

YANG data modeling language

As we have NETCONF as the protocol, we also have YANG as data modeling language (defined by RFC-6991).

YANG can distinguish between configuration and status.
YANG is hierarchical.
YANG model is a yang file (the extension is .yang) and can be read by pyang tool (or Notepad++)
YANG can be parsed to XML format using YIN tool.

YANG elements

Element	Description
module	YANG constructs a data model as a module. The module name is the same as the YANG file name.A module can import data from other modules and reference data from submodules.Import of external modules ("import" and "include"): The "include" statement enables a module or submodule to reference materials in submodules, and the "import" statement enables references to materials defined in other modules.
namespace	Namespace of the module, which is a globally unique URI. Namespaces are used during XML encoding of data.
prefix	Abbreviation of a namespace, which must be unique.
organization	Name of the organization to which YANG belongs.
contact	Contact information of the YANG module developer.
description	Functions of the YANG module.
revision	Version information of the YANG module, providing the version editing history of the module.
container	Container node, used to group related nodes into a subtree.
list	List node, used to define a sequence of list entries. Each entry is similar to a structure or record instance, and is uniquely identified by the values of its key leaf nodes (key values).
leaf	Leaf node, which contains simple data such as an integer or a character string.

A sample NETCONF "get" message: (Source: What Is YANG? - Huawei)

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="831">
  <get>
    <filter type="subtree">
      <ifm:ifm xmlns:ifm="urn:huawei:yang:huawei-ifm">
        <ifm:interfaces>
          <ifm:interface/>
        </ifm:interfaces>
      </ifm:ifm>
    </filter>
  </get>
</rpc>

A sample NETCONF "reply" message with information based on YANG model:

<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ifm xmlns="urn:huawei:yang:huawei-ifm">
    <interfaces>
      <interface>
        <name>10GE1/0/1</name>
        <index>4</index>
        <class>main-interface</class>
        <type>10GE</type>
        <position>0/0/0</position>
        <number>1/0/1</number>
        <admin-status>up</admin-status>
        <link-protocol>ethernet</link-protocol>
        <statistic-enable>true</statistic-enable>
        <mtu>1500</mtu>
        <spread-mtu-flag>false</spread-mtu-flag>
        <vrf-name>_public_</vrf-name>
        <dynamic>
          <oper-status>up</oper-status>
          <physical-status>up</physical-status>
          <link-status>up</link-status>
          <mtu>1500</mtu>
          <bandwidth>100000000</bandwidth>
          <ipv4-status>up</ipv4-status>
          <ipv6-status>down</ipv6-status>
        </dynamic>
      </interfaces>
      </interface>
</ifm>
</data>

A sample YANG model. Source: O-RAN specifications:

module o-ran-du-performance-management {
  yang-version 1.1;
  namespace "urn:o-ran:du-pm:1.0";
  prefix "or-du-pm";

  import _3gpp-common-managed-element {
    prefix "me3gpp";
  }

  import _3gpp-nr-nrm-gnbdufunction {
    prefix "gnbdu3gpp";
  }

  organization "O-RAN Alliance";

  contact
    "www.o-ran.org";

  description
    "This module defines the augmentation of the SA5 yang data model according to 28.623 and 28.541 to include the pm-count-groups information of the O-DU.
    Copyright 2020 the O-RAN Alliance.
    ";

  revision "2020-09-25" {
    description
      "version 1.0.0 - first release of O-RAN O1 for O-DU YANG models";

    reference "ORAN-WG5.MP.0-v01.00";
  }

  grouping pm-count-groups {

    list pm-count-list-drb {
      key "qci-index";

      leaf qci-index {
        type uint8 {
          range 0..255;
        }
        mandatory true;
        description
          "QoS Class Identifier defined in TS 23.401. Logical range and coding specified in TS 23.203.";
        }

      leaf pm-count-group {
        type uint8 {
          range 0..17;
        }
        mandatory true;
        description
          "Indicates which of the 17 'PmCountGroup' shall be used for this QCI index. Value 0, indicates that this QCI shall NOT be counted. If duplicated several QCI are set to same pm-count-group, they should be counted as same counter.";
      }
    }

    list pm-count-list-srb {
      key "srb-index" ;

      leaf srb-index {
        type uint8 {
          range 1..3;
        }
        description
          "Value 1, 2, 3 indicates SRB1S, SRB2S, SRB3, respectively.";
      }

      leaf pm-count-group {
        type uint8 {
          range 0|18..20;
        }
        mandatory true;
        description
          "Indicates which of the 3 'PmCountGroup' shall be used for this SRB Index. Value 0, indicates that this SRB Index shall NOT be counted. If duplicated several SRB Index are set to same pm-count-group, they should be counted as same counter.";
      }
    }
  }

  augment "/me3gpp:ManagedElement/gnbdu3gpp:GNBDUFunction/gnbdu3gpp:attributes" {
    container pm-count-groups {
      uses pm-count-groups;
    }
  }
}

References

O-RAN TS: "Management Plane Specification"

What Is NETCONF? Why Do We Need It? - Huawei

What Is YANG? - Huawei