Toward Open and Intelligent Wireless Networks
Initiatives towards vRAN

vRAN virtualization Open RAN

Shinji Mizuta and Anil Umesh
Radio Access Network Development Department

Yoshihiro Nakajima and Yuya Kuno
Core Network Development Department

Abstract
There is growing demand for high processing performance in wireless base station equipment as bit rates and capacity continue their upward trend in Long-Term Evolution and fifth-generation mobile communications system networks. To meet this demand, NTT DOCOMO has been using purpose-built hardware and software. At the same time, technical innovation in cloud computing for web services has been remarkable as reflected by ongoing improvements in hardware performance and increasing decoupling of hardware and software provided via virtualization and cloud-computing technologies. These innovative technologies should lead to superior wireless base-station design and solutions so that a more disaggregated and efficient Radio Access Network (RAN) can be achieved. The development and commercialization of such equipment is moving forward as RAN virtualization is becoming predominant. This article describes NTT DOCOMO initiatives toward RAN virtualization technology.

01. Introduction

  • NTT DOCOMO began providing services under the ...

    Open

    NTT DOCOMO began providing services under the fifth-generation mobile communications system (5G) in March 2020 and has been expanding the 5G coverage area ever since. To roll out 5G while making maximum use of existing Long-Term Evolution (LTE) base-station equipment, we have developed the bare minimum amount of hardware (HW) together with software (SW) to run on that hardware and added both to existing LTE base-station equipment to achieve 5G services.

    There has also been tremendous technical innovation in the IT field. As a result, there have been rapid gains in the performance of general-purpose hardware, in the effective use of hardware resources by decoupling hardware and software using virtualization technology, and in the omnipresent use of common cloud technology by leveraging standard and de-facto cloudification and orchestration platforms. Additionally, to achieve high-performance data encryption, AI, and machine-learning*1 technologies, specialized “hardware accelerators” for various types of computing are now being developed and marketed.

    General-purpose hardware as used in the IT field and virtualization technology based on hardware accelerators customized for wireless processing are starting to be applied to wireless base stations in a network transformation towards the virtualization of the Radio Access Network (RAN)*2, or virtualized RAN (vRAN)*3 for short. The use of general-purpose hardware in virtualization and cloudification and the effective use of vRAN technology are expected to reduce infrastructure investment. With the idea of maximizing this the benefits of the vRAN, in February 2021 NTT DOCOMO jointly launched with other partners having various vRAN-related technologies an initiative for collaborative co-creation solutions called the 5G Open RAN ECosystem (OREC)*4. For more information, refer to the opening article of this special issue [1]. Since NTT DOCOMO had already introduced virtualization technology for the core network*5, such development and operational experience is becoming a key asset and input for the introduction of the vRAN.

    In this article, we describe the technical issues that must be addressed to achieve the vRAN and NTT DOCOMO’s approach to addressing those issues. To solve problems that came to light based on our experience in core-network virtualization, such as the short support period usually given to general-purpose products and the ending of the product support period for deployed equipment, we also describe the importance of standardization and initiatives toward standardization.

    1. Machine learning: Technology that enables computers to acquire knowledge, decision criteria, behavior, etc. from data, in ways similar to how humans acquire them from perception and experience.
    2. RAN: The network consisting of radio base stations and other equipment placed between the core network (see *5) and mobile terminals to control the radio layer.
    3. vRAN: Refers to the virtualization of the RAN. May also be used as a term indicating a virtualized wireless base station.
    4. OREC: An initiative of NTT DOCOMO and partner companies that aims to roll out open radio access networks overseas to facilitate the construction of networks flexible enough to meet diversified needs.
    5. Core network: A network consisting of packet transfer equipment, subscriber information management equipment, etc. that typically interconnects other networks. Mobile terminals communicate with the core network via the RAN.

    • 02. RAN Virtualization Technology

  • 2.1 Network Functions Virtualization Technology

    Open

    Network functions virtualization (NFV) relies on the offering of a virtualization layer on top of general-purpose hardware based on IT virtualization and orchestration technology*6. The virtualization layer exposes virtual resources that can be composed and used to run applications, including network function software applications. NFV transforms the way network operators can deliver communication services; in the past such communication services had conventionally been provided by dedicated hardware and software optimized for satisfying the high-reliability and high-performance requirements of systems operated by telecom operators. NFV supports the decoupling of hardware and software, which in turn enables the rapid deployment and provision of new network functions simply by deploying and/or updating the software that implements the network function behavior. In addition, the use of open source software and agile development techniques cultivated in the IT field can provide additional benefits such as shortening the time-to-service*7 to service launch.
    At NTT DOCOMO, we have been researching and developing NFV technology and promoting its standardization by the European Telecommunications Standards Institute (ETSI)*8 NFV*9 Industry Specification Group since the first half of the 2010s. In parallel, NTT DOCOMO has been introducing virtualization technology into the core network of the commercial network since FY2015. By the end of FY2020, the virtualization rate of core network equipment for LTE and beyond exceeded 50%, and the 5G core network deployed in FY2021 became fully virtualized [2]. NTT DOCOMO has reaped the following four benefits through NFV in the core network [3].

    1) Improved economic performance of network function equipment

    There had been equipment and telecom software for each equipment vendor and network function and it had been necessary to perform maintenance for each piece of equipment and each package of telecom software. However, our NFV technology enabled us to run telecom software from multiple vendors on a unified virtualization platform, which improved cost performance, unified and simplified operations and maintenance, and enabled the use and sharing of low-cost general-purpose hardware.

    2) Quick deployment of new services

    NFV shortened the time-to-service by eliminating the preparation and installation of dedicated hardware when introducing a new service.

    3) Improved communication service connectivity during times of congestion

    In the event of congestion*10, e.g., caused by a natural disaster or a sudden concentration of traffic, NFV enabled the network functions capacity to be automatically increased in a short period, thereby improving connectivity for consumer communication services.

    4) Improved reliability of communication services

    The use of low-cost hardware enabled the construction of redundant hardware configurations on which telecom software could be automatically loaded to maintain normal operations upon detecting hardware failures. This enabled the automatic recovery of network functions in a short time (auto-healing), and such a capability eliminated the need to dispatch personnel for immediate maintenance work on site while achieving high maintainability and high reliability of consumer communication services.

    2.2 Expected Effects of Introducing vRAN

    Recent advances in IT virtualization technology, general-purpose hardware, and hardware accelerators have broadened the domains in which virtualization can be applied. It has even become possible to apply virtualization to baseband*11 processing on the radio layer, where high-level service requests such as high performance and sensitive real-time requirements are even more demanding than those of the core network. With this in mind, a number of domestic and overseas operators have begun initiatives toward the deployment and commercialization of the vRAN using virtualization technology. The expected effects of introducing the vRAN are summarized as follows (Figure 1).

    text

    Figure 1  Expected effects of introducing vRAN

    1) Optimal combination of RAN solutions by decoupling hardware and software

    • Improved cost performance of network functions through use of general-purpose hardware
    • Improved performance and reduced power consumption by using up-to-date hardware
    • Extension of RAN capabilities and services by focusing on software updates only
    • Easy introduction of new vendors

    2) Simple and intelligent RAN operation and maintenance through virtualization and automation

    • Facility construction with software shortens the time-to-service and improves flexibility of deployment*12 by making maximum use of an already installed hardware and software resource pool*13
    • Expanded scope of remote maintenance work and reduced on-site work by leveraging remote software management capabilities
    • Improved connectivity of communication services by expanding their capacity to flexibly address fluctuating traffic demand
    • Improved reliability by recovering automatically from hardware and software failures in a short period
    • Handling of traffic fluctuations by using a RAN Intelligent Controller (RIC)*14

    3) Infrastructure sharing and unified operations from edge to core network (Figure 2)

    • Achieving a unified virtualization platform and unified operations wherein the virtualization of RAN applications bridges between the edge and core network and enables end-to-end 5G network deployment
    • Stable and long-term operation of a virtualization platform
    • Provision of orchestration on an end-to-end (E2E) basis
    text

    Figure 2  Infrastructure sharing and common operations from edge to core network

    The features obtained by a virtualized RAN in addition to those of a virtualized core network will simplify the installation at edge sites of service platforms that need to be installed at locations nearer to users, as envisioned using multi-access edge computing (MEC)*15. This and other use cases of added value are expected.

    2.3 Issues in Meeting vRAN Requirements through NFV Technology

    To maximize the benefits of the vRAN described above, it is necessary to resolve the technical issues that arise from specific RAN requirements in addition to those that arose in the virtualization of the core network.

    1) Issues (1): Issues in achieving an optimal combination of solutions by decoupling hardware and software

    (a) Support of high-performance and real-time processing executed using general-purpose hardware and software

    In conventional base-station equipment, computationally intensive processing on the radio layer requiring real-time characteristics became feasible through dedicated hardware such as optimized field-programmable gate array (FPGA)*16 and application-specific integrated circuit (ASIC)*17 devices and dedicated software. Instead, in the vRAN, conventional base-station-equipment architecture featuring such tightly coupled hardware and software must be achieved using general-purpose hardware and software running on that hardware. In particular, it is necessary to reduce fluctuations in the time sensitivity of processes on the radio layer that affect base-station performance and to achieve low latency. To this end, optimized general-purpose hardware must be selected, high-performance and time-sensitive software must be implemented to meet such requirements, and the necessary execution environment fulfilling all these requirements must in turn be supported by the virtualization platform. For functions and components having particularly severe processing requirements, studies must also be conducted on optimizing software processing even further or on offloading some of the radio-layer processing to an hardware accelerator. Finally, high-performance and high real-time sensitive processing must be achieved while dealing with the problem of tightly coupled hardware and software that has been (since now) typically assumed for fulfilling extreme performance requirements.

    (b) Construction of a mechanism supporting the installation of base-station equipment

    In virtualizing the core network, it has been possible to consolidate and install relevant core network functions at few centralized sites (data centers). However, in the case of RAN, many more compact and distributed base-station sites (e.g., placed in a room within a building or outdoors) become necessary to cover the required radio coverage. As a result, required performance, installation space, and power limitations greatly differ depending on the involved network functions to deploy at a target location. General-purpose hardware also needs to be able to withstand severe conditions such as high dust environments and extreme temperatures. In short, a mechanism is needed that can support scalable and flexible installation formats under such a variety of installation environments while ensuring an efficient decoupling of software and hardware.

    2) Issues (2): Issues in achieving simple and intelligent RAN operation and maintenance through virtualization and automation

    (a) Management of virtual resources provided to RAN applications

    On the one hand, in conventional base-station equipment, base-station functions are coupled to specific hardware, so hardware and software can be managed as a set and maintenance can be conducted on that set. On the other hand, in the vRAN, in which virtual resources are provided from multiple hardware devices, the RAN application management system dynamically requests the virtual resources needed and runs RAN applications on those virtual resources. In the latter, software and virtual resources are managed independently. To maintain base-station functions under these conditions, there is a need to associate software, virtual resources (logical), and hardware (physical). There is also a need to handle new hardware components, such as hardware accelerators, in a unified manner together with other virtual resources.

    (b) Support of maintenance and operation use cases

    With conventional base-station equipment, operation methods such as hardware configuration, installation, and maintenance differ among vendors. Now, with virtualization, if these different operation methods were to be simply implemented without making any changes, and if an attempt would be made to support them all, the volume of development and amount of testing would certainly increase and not be bearable by the network operator. Therefore, there is a need to both promote the integration of more automation into the operations support systems and standardize solutions that clearly identify the functional splits and boundaries of systems to integrate. This is a necessary step to ensure unifying operational and maintenance procedures for all systems involved in the vRAN deployment.

    (c) Reduction in on-site work and manual operations

    An entire workflow must be designed to achieve automation in processes ranging from the construction of base stations to be distributed nationwide and creation of virtualization platforms. It is particularly important to minimize on-site work and expand the scope of automation by expanding the scope of software control when migrating to the vRAN. For this reason, it is essential that construction work including the kitting*18 of general-purpose equipment, and provision of spare parts be standardized to reduce on-site work and that various types of interfaces (IFs) be set up to operate and manage this equipment remotely.

    3) Issues (3): Issues in achieving infrastructure sharing and unified operations from edge to core network

    (a) Support of diverse applications by a unified virtualization platform

    To support the deployment of new network functions in the future, a vRAN virtualization platform will have to support the deployment and execution of base-station functions, core-network functions, and higher-level services. Additionally, the execution-environment capability of the platform will require both supporting virtual machine (VM)-based network function deployments as well as container *19-based network function deployments, whose use has increased. To make operations more efficient, there will also be a need for a virtualization environment that can support application requirements in each network domain.

    (b) Achieving long-term operation of virtualization platforms distributed nationwide

    With the vRAN commercialized, we can expect many small-scale virtualization sites to be distributed nationwide, so how to go about maintaining and managing those platforms is an important issue. It will be necessary to upgrade and maintain a virtualization platform periodically to cope with the introduction of new general-purpose hardware and new hardware accelerators, need for security updates, evolution of applications, etc. All version upgrades of virtualization platforms must also be carried out without interrupting any communication services. At the same time, taking into account recent development trends in container platforms, it will be necessary to make short-term upgrades including those to the platforms, but it is unrealistic to expect an operator to carry out large-scale upgrades and development, etc. continuously. A mechanism that can execute long-term and stable platform operations would therefore be desirable.

    1. Orchestration technology: Technology for managing and mediating the connectivity of essential resources and networks to automate the operation and management of applications and services.
    2. Time-to-service: A term used in a variety of fields that, in this article, refers to the period running from the start of development or facility construction to the launch of actual services.
    3. ETSI: Refers to European Telecommunications Standards Institute, an organization, based in Europe, concerned with the standardization of telecommunications technology.
    4. NFV: principle of separating network functions of a telecommunications carrier network from general-purpose hardware through virtualization technology.
    5. Congestion: A state where communication requests are concentrated inside a short time and exceed the processing capabilities of the network, thereby obstructing communications.
    6. Baseband: The band of information signals before/after converting to/from the radio frequency band on the transmitting/receiving side in wireless communications. It is usually a low frequency band achieved through digital signal processing.
    7. Deployment: The process of arranging and rolling out applications and their execution environments and placing them in a usable state.
    8. Resource pool: A grouping mechanism for bundling and managing infrastructure resources such as computers, computer CPUs, and memory, and arrange them for subsequent use.
    9. RIC: The controller that makes the RAN intelligent.
    10. MEC: An approach for installing servers, storage devices, etc. at locations nearer to users within a mobile communications network to provide low-latency services with high real-time characteristics.
    11. FPGA: A large-scale integrated reconfigurable circuit array of hard-wired cells that can be logically and freely designed.
    12. ASIC: An integrated circuit designed and fabricated for a specific application.
    13. Kitting: In this article, it describes the act of installing applications in equipment such as servers and making various types of settings and registrations to put those applications in a state ready to use.
    14. Container: A type of computer virtualization technology in which a dedicated area (the container) is created on a host OS, and the necessary application software is run in the container.

    • 03. Addressing Open Issues: Approaches

  • At NTT DOCOMO, we will combine the knowledge and expertise ...

    Open

    At NTT DOCOMO, we will combine the knowledge and expertise that we have obtained to date in the virtualization and operation of the core network and development and operation of radio base stations aiming at addressing the issues described above and achieving our vRAN goals. In particular, we will adopt two approaches: vRAN standardization activity in the Open RAN (O-RAN) ALLIANCE*20 and ETSI NFV and interoperability testing in a multi-vendor environment through OREC.
    For Issues (1), “Issues in achieving an optimal combination of solutions by decoupling hardware and software,” there will be a need to study, in cooperation with RAN application vendors and general-purpose hardware vendors, the optimal implementation of applications and optimization of their performance. We will promote these activities within OREC and describe them later in this article.

    Next, for Issues (2), “Issues in achieving simple and intelligent RAN maintenance through virtualization and automation,” and Issues (3), “Issues in achieving infrastructure sharing and unified operations from edge to core network,” our experience in developing core-network virtualization processes has led us to recognize the prime importance of standardizing interfaces and information models*21 between the vRAN and associated systems, and in achieving unified operation and maintenance of the vRAN. On the basis of this recognition, we will promote the standardization of the vRAN. We point out that standardization will enable various types of products provided by multiple vendors to be combined. Additionally, if the support period for a particular product in a product configuration is coming to an end, a different product conforming to the same standard on the market can be used to minimize the impact on other products in that configuration and on surrounding systems. Furthermore, to avoid fragmentation of specifications related to NFV with the same objective among standardization organizations within the industry and to make maximum reuse of the NFV-related specifications that NTT DOCOMO has been actively pushing for standardization, we will promote more coordination among standardization organizations.

    Standardization activities related to the virtualization and orchestration support for the vRAN are progressing in O-RAN Work Group 6 (WG6). The latest developments in this standardization effort are described later in the article. The standardization items that NTT DOCOMO must take up on the basis of the overall architecture of O-RAN (Figure 3) are summarized below. Please see Sections 4 and 5 and a past article [4] in NTT DOCOMO Technical Journal for details on each component shown in the figure.

    text

    Figure 3  Overall O-RAN architecture

    • Interface between Service Management and Orchestration (SMO) and multi-vendor applications implementing the O-RAN O-CU-CP/O-CU-UP/Near-real time RIC/O-DU functions (O1 in Figure 3)
    • Interfaces between SMO and a multi-vendor virtualization platform, referred as O-Cloud, which contains Deployment Management Services (DMS)/Infrastructure Management Services (IMS) functions (O2dms/O2ims in Figure 3)
    • Unified operations through SMO and multiple virtualization platforms (instantiation*22, scaling*23, healing*24, termination*25)
    • Common information models for SMO-managed vRAN applications, virtualization platforms, and packages toward automated operations
    • A unified end-to-end virtualization platform that can support core network functions, the vRAN, MEC, etc.
    • Stable interfaces maintaining backward compatibility with current operation systems and related interconnected systems and information flow between systems
    • Functional splits and interface specifications that show high extensibility while making maximum reuse of the operator’s assets
    1. O-RAN ALLIANCE: An industry and standardization group founded by NTT DOCOMO and leading overseas operators in February 2018 aiming at achieving an open and intelligent RAN for the 5G era.
    2. Information modeling: The modeling of a system to make it easier to handle by corresponding management systems.
    3. Instantiation: Refers to the generation of a virtual machine. Indicates a sequence of operations from installing a virtual machine on a physical machine, making virtual network settings, and booting the virtual machine to start up the software and putting it into a usable state through various settings.
    4. Scaling: The optimization of processing power by increasing or decreasing virtual machines that configure communications software whenever processing power of that software is insufficient or excessive in accordance with hardware or virtual-machine load conditions.
    5. Healing: A procedure for restoring communications software to a normal state in the event of a hardware or VM failure by moving the VM to (or recreating the VM on) hardware operating normally.
    6. Termination: The process of bringing a virtual machine to a close.

    • 04. Latest Developments in O-RAN WG6 Standardization

  • At O-RAN, standardization related to virtualization and orchestration ...

    Open

    At O-RAN, standardization related to virtualization and orchestration are mainly being conducted in the Cloudification & Orchestration WG (O-RAN WG6).
    O-RAN WG6 specifications and reports consist of: General Aspects and Principles (GAP) defining overall concepts; Orchestration Use Cases (ORCH-UC), which defines use-case and information flow between the specified functions; and other interface specifications that specify data models and protocols.
    Details on each of the above specifications and reports are given as follows.

    1) GAP

    In WG6, function names such as O-Cloud are defined and the relationships among those functions are described. Two types of GAP documents are delivered: O2GAP, specific to concepts related to the O2 interface, and AAL-GAP, specific to concepts about the Acceleration Abstraction Layer (AAL)*26.

    2) ORCH-UC

    For O-Cloud, Network Function (NF)*27, and Near-RT RIC Application (xApp)*28, typical use cases related to Provisioning*29, Fault Management*30, and Performance Management*31 are specified.

    3) Interface specifications

    As specified by O-RAN WG6, O2 is the reference point*34 between SMO and O-Cloud and AAL is the abstraction layer for the provision of hardware accelerators by O-Cloud to NF Deployment. The interface specifications cover the reference point and abstraction layer on various further detailed aspects. For instance, the O2ims interface document specifies the interfaces exposed by the O-Cloud IMS on the O2; the AAL Forward Error Correction (FEC)*32 specification details an AAL Profile for FEC, and AAL High-PHY*33 another AAL profile for the hardware acceleration of High-PHY functions. The specification of the protocol and data models for the O2dms interface exposed by the O-Cloud DMS on the O2 is currently in progress.
    The constituent elements of the vRAN are NF Deployment that specifies the virtual resources of vRAN applications, O-Cloud that serves as the virtualization platform providing virtual resources to NF Deployment, and SMO that operates and manages NF Deployments and O-Cloud (Figure 3).

    4.1 SMO

    The SMO functional block consists of Federated O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO), which operate, manage, and orchestrate O-Cloud and NF Deployment as logical functions, respectively. FOCOM is capable of inventory management*35, and alarm management*36 for O-Cloud, while NFO is capable of lifecycle management, alarm management, and performance management of NF Deployments on the O-Cloud.

    4.2 O-Cloud

    O-Cloud consists mainly of the following logical functions: the O-Cloud Node, which provides virtual resources to NF Deployment; DMS, responsible for the management of NF Deployments; IMS, which manages O-Cloud Node and other O-Cloud infrastructure components including DMS instances; and HW Accelerator Manager that manages hardware accelerators. O-Cloud Node, in turn, consists of computing resources, network resources, and storage resources, where computing resources include AAL functions (described later). Possible solutions of DMS are assumed to be, for instance, Kubernetes®*37 or OpenStack®*38. As previously introduced, DMS expose its services and connects to SMO via the O2dms interface, while IMS connect to the SMO over the O2ims interface. IMS mainly provide inventory management, alarm management, and performance management for O-Cloud Node and deployment of DMS instances.

    4.3 Hardware Accelerator

    One of the key specification focuses of O-RAN WG6 is on the support of hardware accelerators, which are typically required to implement the vRAN. In this context, AAL includes a hardware accelerator as physical equipment, AAL Profile for achieving various types of processing using the hardware accelerator, and AAL Interface (AALI) between AAL Profile and the vRAN application. The HW Accelerator Manager manages AAL Profiles supported by hardware accelerations that are part of the O-Cloud.
    Two major acceleration types for offloading radio processing to the hardware accelerator are look-aside acceleration and inline acceleration. The former offloads parts of radio layer 1 and particularly coding/decoding having high processing load, while the latter offloads all of radio layer 1. For either type, specifications are progressing to facilitate virtualization and orchestration.
    Going forward, the plan at O-RAN WG6 is to complete O2dms interface specifications, AAL use-case specifications, and a vRAN application package and to deliver specifications with clear functional splits and function definitions, which are key for network operators who consider fully interoperable multi-vendor vRAN deployment.

    1. AAL: A layer decoupling the hardware and software of hardware accelerators installed on the O-Cloud. It is being defined by O-RAN to enable hardware accelerators from different vendors to be combined with software and accessible by specifying standard formats, interfaces, etc..
    2. NF: Logical unit for identifying individual network functions, such as base stations, switches, and relay equipment, which configure a system.
    3. xApp: An application running on a near-real time RIC platform.
    4. Provisioning: The work of setting hardware and software for running network resources deemed necessary for providing services.
    5. Fault Management: The procedures and functionality related to the handling of faults and failures in a system such as by obtaining a list of alarms for a managed object, issuing alarm notifications, and deleting alarms.
    6. Performance Management: The procedures and functionality related to measurement and monitoring by registering, obtaining, and sending out performance measurements information of managed objects.
    7. FEC: A scheme that adds redundant information on the transmitting side and uses that information on the receiving side to correct errors generated during data transmission.
    8. High-PHY: Functionality covering the processing of higher functions of the radio physical layer, which in O-RAN framework is implemented by the O-DU.
    9. Reference point: A conceptual point at the conjunction of two non-overlapping functional groups. It is typically used in standardization processes for establishing the boundaries of functional blocks and/or functions and specify relevant interfaces.
    10. Inventory management: The managing of resource status and usage conditions of physical equipment, virtualized network equipment, etc.
    11. Alarm management: The managing of faults (alarms) in physical equipment, virtualized network equipment, etc.
    12. Kubernetes®: A container orchestration tool for managing containers towards a large-scale environment configured with multiple servers. Kubernetes® is open source software.
    13. OpenStack®: Cloud-infrastructure software that uses server virtualization technology to run multiple virtual servers on a single physical server. It can allocate virtual servers to different user cloud services. OpenStack® is open source software.

    • 05. NTT DOCOMO’s Standardization Activities

  • NTT DOCOMO has been actively promoting the standardization ...

    Open

    NTT DOCOMO has been actively promoting the standardization of core network virtualization at ETSI NFV. To maximize the reuse of existing ETSI NFV specifications and avoid fragmentation of NFV standards and specifications with the same objective within the industry, we have been studying and comparing O-RAN specifications and ETSI NFV specifications, as shown in Figure 4. Specifically, O-RAN WG6 is specifying O2dms interface while ETSI NFV is analyzing any gaps between O-RAN specifications and ETSI NFV specifications on the basis of ETSI GR NFV-IFA 046.

    text

    Figure 4  Relationship between O-RAN and ETSI-NFV specificationse

    Looking towards to the future, the goal is to standardize an integrated and unified NFV platform able to cover from RAN to the core network, as shown in Figure 5. For the distributed equipment making up a base station, requirements and features that are unique to each functional block need to be considered, such as the limited length and constrained delay in the fronthaul between the base station and radio unit (RU)*39. We will therefore continue to study optimal deployment scenarios taking into account such requirements and features. NTT DOCOMO considers the following points to be important in promoting O-RAN and ETSI-NFV standardization.

    5.1 Positioning of ETSI-NFV-defined NFV Orchestrator in SMO

    In O-RAN specifications, SMO becomes a huge functional block that includes the functionality specified by 3GPP Service & Systems Aspects WG5 (3GPP SA5)*40 regarding Operations Support System (OSS)*41 and Element Manager (EM)*42/Network Function Management Function (NFMF)*43 as well as the NFV Orchestrator (NFVO)*44 (Figure 4) functionality defined by ETSI NFV. Therefore, to achieve an SMO supporting a multi-vendor environment, dividing up the SMO framework into more granular functional blocks in the standardization process is considered essential. Since the OSS functional blocks differ between operators in terms of existing assets, operational workflow, and external equipment to be connected to, current discussions are pointing out the difficulty of handling all the relevant functionality only by the SMO, and as a result, there exists the possibility that typical OSS functions will not be included in SMO solutions.

    While O1 termination is assumed to be EM/NFMF, as currently defined by 3GPP SA5, the deployment scenario has been to provide NF and EM as a single set from a vendor, but simplifying this process by deploying general-purpose EM (Generic EM) is desirable. In terms of virtualization, SMO would then take on the role of a Generic EM functional block that terminates O1 and a NFVO functional block that terminates O2.

    text

    Figure 5  Integrated NFV Platform from RAN to core network

    5.2 Relationship between O-Cloud and CISM/Virtual Infrastructure Manager of ETSI NFV

    The O2dms interface is currently being specified in O-RAN, and the finalization of detailed specifications is forthcoming. In terms of ETSI NFV specifications, two platforms having a deep relationship with DMS are being specified: Container Infrastructure Service (CIS)*45 and CIS Manager (CISM)*46 as a container platform and Virtual Infrastructure Manager (VIM)*47 and NFV Infrastructure (NFVI)*48 as a VM*49 platform. The management entities (i.e., CISM and VIM) are considered to correspond to DMS (Figure 4) functionality. For O2dms, studies are now being conducted on the use of ETSI NFV specifications such as ETSI GS NFV-SOL 018 [6], which specifies the interfaces produced by the CISM; ETSI GS NFV-SOL 014 [7], which specifies the data model of virtualized resource descriptors that can be used over the interfaces produced by the VIM; and ETSI GS NFV-SOL 003 [8], which specifies the interfaces produced by the virtual network function manager (VNFM)*50 regarding VNF management, and that can be leveraged as an abstraction above the other aforementioned interfaces. These studies will determine whether VNFM functionality will belong to SMO or O-Cloud. The ETSI NFV will study the entire functionality of IMS and will extend the ETSI NFV specifications so that NFV could support IMS or a related function.

    1. RU: As one unit of equipment making up a base station, it converts digital signals to be transmitted to radio signals and received radio signals to digital signals. It also amplifies transmission power, transmits/receives radio signals at antenna elements, and executes processing necessary to generate beams in massive MIMO.
    2. 3GPP SA: At 3GPP, the working group that specifies service requirements, architecture, security, codecs, and network management.
    3. OSS: Operations support system for operators to aid in discovering faults and congestion in a mobile communications network and controlling and taking measures against those problems. For communications operators, the OSS executes fault management, configuration management, charging management, performance management, and security management or some of the above for a network or system so that provided services can be used.
    4. EM: A functional block responsible for FCAPS (Fault, Configuration, Accounting, Performance, and Security) management and monitoring for individual units of network equipment
    5. NFMF: A function that provides management services for one or more NFs.
    6. NFVO: A system that executes IMS of virtual resources spanning multiple VIMs over which VNF and network services can be deployed and managed.
    7. CIS: A container execution environment for executing container software as defined by ETSI NFV and a platform for providing computing resources and network resources in containers. An individual CIS instance corresponds to a Worker Node in Kubernetes®.
    8. CISM: A system that manages CIS resources as defined by ETSI NFV.
    9. VIM: The system that manages the physical resources on a virtualization platform consisting of physical computers, physical storage, and physical networks.
    10. NFVI: As defined by ETSI NFV, the totality of all hardware and software components that build up the environment in which VNFs are deployed. Serves as a collective term for the general-purpose servers, storage devices, and network devices comprising a cloud platform and for the software on the virtualization layer for virtualizing those physical resources.
    11. VM: A computer that is virtually constructed within a physical computer by software means.
    12. VNFM: A management system that executes lifecycle control such as initiation and termination of VNFs.

    • 06. Activities at OREC

  • Since there are many implementation-dependent functions ...

    Open

    Since there are many implementation-dependent functions not specified in standards and optional functions that are specified in standards, there is a need to align options and interfaces to combine a variety of products and conduct testing to develop vRAN solutions that can provide 5G services on a commercial level. In addition to promoting standardization at O-RAN and ETSI NFV, NTT DOCOMO is focusing its attention on the following points at OREC.

    1) Creation of guidelines for operational workflow and network design toward the provisioning of vRAN solutions

    Considering that a variety of products can be combined from diverse vRAN application vendors, hardware accelerator vendors, and O-Cloud vendors, we are creating guidelines on achieving multi-vendor interoperability to cover various types of operational workflow and network designs. While a redundant configuration for the network and management nodes is essential in a cloud environment, it may not be possible to achieve suitable redundancy at a base-station site due to the installation environment, which would mean many cases in which the network disconnects or only a management node goes down. Due to such issues, the need arises for a variety of options, so studies in design guidelines are also proceeding from this viewpoint. The architecture of specific open-network initiatives targeted by NTT DOCOMO is shown in Figure 6. With a focus on VNFM, we will work to maximize the use of ETSI NFV specifications by making various interfaces open with the end goal to achieve interoperability between vRAN applications and virtualization platforms delivered by multiple vendors.

    2) Provisioning of testing environments for end solutions and E2E function/performance testing

    To use a variety of new technologies in the vRAN, operational testing in terms of both functionality and maintenance is essential. To facilitate the use of hardware accelerators in new ways, performance testing will also be necessary. Testing of optimal hardware configurations at small-footprint base-station sites will likewise be necessary. We are now working on providing these testing environments to cover E2E testing from terminals to core networks.

    text

    Figure 6  Open networking targeted by NTT DOCOMO

    Three combinations of vRAN applications, virtualization platforms, general-purpose servers, and hardware accelerators are being tested at the OREC Shared Open Lab (Figure 7). Verification of communications in a 5G Stand Alone (SA) configuration has been completed, not only for look-aside hardware accelerators, the commercialization of which is in progress, but also for inline hardware accelerators. We plan to accelerate these testing activities towards commercial-level quality testing while aiming to meet the performance targets described in the opening article of this special issue [1].

    text

    Figure 7  vRAN testing environment

    • 07. Conclusion

  • This article provided an overview of NFV, described the effects ...

    Open

    This article provided an overview of NFV, described the effects of introducing virtualization in the RAN, and the issues surrounding implementation, and presented NTT DOCOMO‘s approach to addressing these issues. The article also described the current status of standardization at O-RAN, NTT DOCOMO‘s standardization activities, and initiatives at OREC.

    NFV has already produced positive effects in the deployment of NTT DOCOMO‘s core network. To adapt such a vision and assets to make it extensible to also cover the virtualization of the RAN, we are working and promoting standardization and OREC activities as our two key approaches. Both standardization and OREC are evolving and aiming for a world that can achieve optimal combinations of solutions applicable to a variety of future network requirements. As a means to this goal, we will promote vRAN development together with our partners and conduct testing at the OREC Shared Open Lab. We will also contribute to standardization by expanding use cases and specifying interfaces so that functions that are key to operators can be provided and integrated easily, yet guaranteeing stability of the system for long-term telco support.

  • REFERENCES

    Open
    1. [1] D. Hiratsuka et al.: “Initiatives toward Open RAN,” NTT DOCOMO Technical Journal, Vol. 24, No. 1, Mar. 2023.
      https://www.docomo.ne.jp/english/corporate/technology/rd/technical_journal/bn/vol24_1/001.html
    2. [2] H. Tamura et al.: “Migration to ETSI NFV Stage 3 Specification–compliant Multivendor MANO Configuration on Network Virtualization Platform,” NTT DOCOMO Technical Journal, Vol. 23, No. 4, pp. 74–86, Apr. 2022.
      https://www.docomo.ne.jp/english/binary/pdf/corporate/technology/rd/technical_journal/bn/vol23_4/vol23_4_010en.pdf
    3. [3] T. Kamada et al.: “Practical Implementation of Virtualization Platform in NTT DOCOMO Network,” NTT DOCOMO Technical Journal, Vol. 18, No. 1, pp. 20–28, Jul. 2016.
      PDFhttps://www.docomo.ne.jp/english/binary/pdf/corporate/technology/rd/technical_journal/bn/vol18_1/vol18_1_004en.pdf (PDF format:1,694KB)
    4. [4] S. Abeta et al.: “O–RAN Alliance Standardization Trends,” NTT DOCOMO Technical Journal, Vol. 21, No. 1, pp. 38–45, Jul. 2019.
      PDFhttps://www.docomo.ne.jp/english/binary/pdf/corporate/technology/rd/technical_journal/bn/vol21_1/vol21_1_006en.pdf (PDF format:1,376KB)
    5. [5] ETSI GS NFV–SOL 018: “Profiling specification of protocol and data model solutions for OS Container management and orchestration.”
    6. [6] ETSI GS NFV–SOL 014: “YAML data model specification for descriptor–based virtualised resource management,” May 2021.
    7. [7] ETSI GS NFV–SOL 003: “RESTful protocols specification for the Or–Vnfm Reference Point,” Jul. 2021.

VOL.24 NO.1

Go to top of the page