Training Guide

vRAN Introduction Training Guide

240-00-0153
Revision 1.0

© 2019

200 Ames Pond Drive | Tewksbury, MA 01876 | Office: 855.709.0701 | Fax: 978.482.0636
WWW.ALTIOSTAR.COM
 vRAN Introduction Training Guide

Copyright
© Altiostar Networks, Inc. 2019. All rights reserved. No part of this document may be
reproduced in any form without the written permission of the copyright owner. The Altiostar
logo is a trademark and a service mark of Altiostar Networks, Inc. All other trademarks are the
property of their respective owners.

Disclaimer
The information contained in this document is the property of Altiostar Networks, Inc. and is
subject to change without notice as part of the company continuous process and methodology
improvement. Altiostar reserves the right to make changes in the design of its products or
components as progress in engineering and manufacturing may warrant. It is the responsibility
of the customer to satisfy itself as to whether the information contained herein is adequate and
sufficient for particular use of a user. It is the further responsibility of each user to ensure that
all applications of Altiostar products are appropriate and safe based on conditions anticipated
or encountered during use. This document does not create any additional obligation for
Altiostar and does not constitute additional warranties and representations.

Revision 1.0 240-00-0153 2 of 53

 vRAN Introduction Training Guide

Table of Contents

CHAPTER 1: vRAN INTRODUCTION .......................................................................................... 8

1 vRAN Overview.......................................................................................................... 8
1.1 Mobile Operator Landscape ................................................................................... 9
1.2 Present RAN Architecture – Distributed RAN..........................................................10
1.3 Path from Traditional RAN to vRAN........................................................................11
1.4 Altiostar is a Leading Contributor to the Open vRAN Projects .................................11
1.4.1 Membership of Different Consortium.................................................................11
1.4.2 Dedicated Staff..................................................................................................12
1.4.3 Recognition .......................................................................................................12
1.4.4 Rakuten Press Release .......................................................................................12
1.5 vRAN Architecture.................................................................................................13
1.6 eNB Functional Split ..............................................................................................14
1.7 Functional Components.........................................................................................14
1.7.1 3rd Party Remote Radio Head (RRH) and Antenna ...............................................14
1.7.2 Radio Interface Unit (RIU) ..................................................................................14
1.7.3 virtual Distributed Unit (vDU) .............................................................................15
1.7.4 virtual Centralized Unit(vCU) ..............................................................................15
CHAPTER 2: TRANSPORT FOR vRAN .......................................................................................17
2 Transport for vRAN Overview....................................................................................17
2.1 Support for IPv4 and IPv6 for BackHaul, and Mid Haul Networks ............................17
2.2 Reliable Control plane Transport at Mid Haul .........................................................17
2.3 Advantages of FrontHaul over Ethernet .................................................................17
2.4 Transport Requirements........................................................................................18
2.5 Packet Priority for BackHaul, MidHaul and FrontHaul Networks..............................18
2.6 Midhaul Network ..................................................................................................18
2.6.1 Latency Requirement.........................................................................................18
2.6.2 Bandwidth Requirement ....................................................................................18
2.7 Fronthaul Network................................................................................................19
2.7.1 Latency Requirement.........................................................................................19
2.7.2 Bandwidth Requirement ....................................................................................19
2.8 Dimensioning and Capacity Detail ..........................................................................20

Revision 1.0 240-00-0153 3 of 53

 vRAN Introduction Training Guide

2.8.1 General .............................................................................................................20

2.8.2 Resource Requirements: vCU .............................................................................20
2.8.3 Resource Requirements: vDU.............................................................................20
CHAPTER 3: NFV ARCHITECTURE ............................................................................................21
3 NFV Architecture Overview.......................................................................................21
3.1 Network Function Virtualization Overview.............................................................21
3.2 Advantages of Network Function Virtualization......................................................22
3.3 OpenStack and NFVI..............................................................................................23
3.4 OpenStack Users, Tenants, and Roles.....................................................................24
3.5 Common Nova Terminology ..................................................................................24
3.6 Cisco NFVI Architecture .........................................................................................25
3.7 Reference Architecture / Logical Connection Diagram of GC ...................................26
3.8 Rakuten Mobile Network Architecture ...................................................................27
3.9 Management of Altiostar vRAN .............................................................................29
3.10 Availability Features ..............................................................................................30
3.10.1 Automatic VM Recovery .................................................................................30
3.10.2 Controller Node Redundancy ..........................................................................31
3.10.3 Compute Node Redundancy ...........................................................................31
3.10.4 ToR Switch Redundancy..................................................................................31
4 Hardware Equipment’s Introduction .........................................................................31
4.1 Antenna................................................................................................................31
4.2 Remote Radio Head (RRH) .....................................................................................32
4.3 Radio Interface Unit (RIU) ......................................................................................34
4.4 Remote Electrical Tilt (RET) Support.......................................................................35
CHAPTER 5: MANAGEMENT OVERVIEW .................................................................................37
5 Management Overview.............................................................................................37
5.1 Self-Establishment of New LTE Cells.......................................................................37
5.1.1 eNB Pre-Provisioning .........................................................................................37
5.1.2 vEMS Commissioning.........................................................................................37
5.1.3 vEMS Configuration ...........................................................................................40
5.1.4 vRAN Auto Commissioning.................................................................................41
5.2 Capacity and Dimensioning....................................................................................42
5.3 vEMS Hardware.....................................................................................................43

Revision 1.0 240-00-0153 4 of 53

 vRAN Introduction Training Guide

CHAPTER 6: SON OVERVIEW ..................................................................................................44

6 SON Overview ..........................................................................................................44
6.1 Automatic Neighbor Relations (ANR) .....................................................................44
6.2 Physical Cell Identity (PCID) Conflict Detection.......................................................45
6.3 Random Access Channel (RACH) ............................................................................45
6.3.1 RSI Conflict Detection and Resolution.................................................................46
6.3.2 Zero Correlation Zone (ZCZ) Optimization...........................................................46
6.4 Mobility Load Balancing (MLB)...............................................................................47
6.5 Mobility Robustness Optimization (MRO) ..............................................................48
6.6 Multi-Cell Interference Management (MCIM) ........................................................48
6.7 Minimization of Drive Test (MDT) ..........................................................................50
6.7.1 Immediate MDT.................................................................................................50
6.7.2 Logged MDT ......................................................................................................50
6.7.3 RRC Connection Establishment Failure (RCEF).....................................................50
6.7.4 Radio Link Failure (RLF) ......................................................................................50
6.7.5 Management MDT.............................................................................................50
6.7.6 Signaling MDT....................................................................................................51
6.7.7 MDT Data ..........................................................................................................51
6.7.8 Configuring and Activating MDT for the selected eNBs through EMS ...................51
CHAPTER 7: ACRONYMS.........................................................................................................52
7 Acronyms .................................................................................................................52

Revision 1.0 240-00-0153 5 of 53

 vRAN Introduction Training Guide

List of Figures
Figure 1: Mobile Data Traffic per Month................................................................................... 8
Figure 2: Average Mobile Connection Traffic per Month ........................................................... 8
Figure 3: Mobile Operator Landscape....................................................................................... 9
Figure 4: Distributed RAN .......................................................................................................10
Figure 5: Path from Traditional RAN to Virtual RAN .................................................................11
Figure 6: CTO Choice Award ....................................................................................................12
Figure 7: Rakuten Press Release ..............................................................................................13
Figure 8: vRAN Architecture ....................................................................................................13
Figure 9: vRAN Functional Split ...............................................................................................14
Figure 10: Deployment flexibility with Ethernet Fronthaul .......................................................17
Figure 11: High-Level NFV Framework.....................................................................................21
Figure 12: Cisco NFVI Full POD ................................................................................................23
Figure 13: Cisco NFVI Micro POD .............................................................................................24
Figure 14: Detail Cisco NFVI Architecture for Rakuten MNO .....................................................25
Figure 15: Cisco NFVI Node Functions .....................................................................................26
Figure 16: Physical Reference Architecture for vDU and vCU to Cell Site...................................26
Figure 17: GC Site Logical Connectivity with Cell Site and CDC..................................................27
Figure 18: Logical Deployment view of Rakuten Mobile Network with NFV Architecture ..........28
Figure 19: Rakuten vRAN Automation Architecture .................................................................28
Figure 20: VMs Connection to Management Network and Internal Network ............................30
Figure 21: Antenna and Flexible Integrated Antenna Site .........................................................31
Figure 22: AHEH Interface .......................................................................................................33
Figure 23: Single RIU Deployment Example .............................................................................34
Figure 24: RIU Bottom View ....................................................................................................35
Figure 25: AHEH Port 1 Connectivity for AISG2.0 .....................................................................36
Figure 26: Macro eNB Management Architecture ....................................................................38
Figure 27: eSON Architecture ..................................................................................................44

Revision 1.0 240-00-0153 6 of 53

 vRAN Introduction Training Guide

List of Tables
Table 1: Antenna Technical Data .............................................................................................32
Table 2: AHEH Technical Data .................................................................................................33
Table 3: AHEH Interface Detail ................................................................................................34
Table 4: RIU Technical Specification ........................................................................................35
Table 5: RIU Connection Quick Reference................................................................................35
Table 6: Sample Mapping of the Information at OSS ................................................................39

Revision 1.0 240-00-0153 7 of 53

 vRAN Introduction Training Guide

CHAPTER 1: vRAN INTRODUCTION

1 vRAN Overview
The insatiable demand for bandwidth is driving the evolution of today's wireless networks.
Based on Cisco-VNI projections, over 2016 to 2021, global mobile data consumption will
increase by a factor of seven at a compound annual growth rate of 46%.

Figure 1: Mobile Data Traffic per Month

Average traffic per mobile connection will increase from 1GB to 5.4GB.

Figure 2: Average Mobile Connection Traffic per Month

Revision 1.0 240-00-0153 8 of 53

 vRAN Introduction Training Guide

This will challenge service providers’ ability to address this demand and satisfy the needs of
their high-value customers.

1.1 Mobile Operator Landscape

Figure 3: Mobile Operator Landscape

As the revenues from voice and Internet data services are plateauing, operators are looking for
new market opportunities such as IOT, Immersive reality to drive next phase of revenue
growth.
In near future wireless networks will have billions of connected devices generating massive
amounts of signaling traffic and exponential increase in network bandwidth requirements.
In order to address this explosion in connected devices and data consumption, efficiently and
economically, wireless network operators need to maximize the spectral efficiency of their
networks, improve Quality of Experience (QoE) of their subscribers while simultaneously driving
down Capital Expenditure and Operating Expenditure (Total Cost of Ownership).
Traditional RAN can’t achieve this goal. New RAN architectures are required that promote
innovation through openness, programmability, and automation.

Revision 1.0 240-00-0153 9 of 53

 vRAN Introduction Training Guide

1.2 Present RAN Architecture – Distributed RAN

Distributed RAN or DRAN is most widely RAN architecture deployed world over today.

Figure 4: Distributed RAN

This architecture suffers from shortcomings that are briefly described in this section.
• Proprietary Architecture – Current RAN architectures are closed in nature with Baseband
hardware on proprietary ASIC platforms interconnected with Remote Radio Heads (RRHs)
over proprietary CPRI protocol implementation
• Inability to execute compute-intensive applications - Limited processing capacity at
baseband meant that it is not suitable to run any compute-intensive applications.
• Bundled Hardware/ Software Procurement - Operators have no say, in the selection of
baseband and radio hardware, both had to be purchased as a bundle from the same
vendor.
• Lack of Innovation - Closed approach to RAN stifles innovation and prevents the
development of a robust RAN hardware/ software eco-system.
• Lack of inter-site co-ordination features - Dense networks requires inter-site co-ordination
to achieve enhanced mobility and cell edge performance. Current Distributed RAN
platforms lack features for such co-ordination.
The Distributed RAN architecture cannot cope with the challenges of explosive growth in
devices, data consumption, and declining revenues.
Note: C-RAN Architecture
Many of the operators and vendors at the early stages of LTE rollouts, recognized the need for
inter-site co-ordination features for overall better network performance. The solution
envisaged by industry involved re-locating baseband units centrally serving a cluster of
remotely located RRHs. These RRHs communicate with centralized BBUs using CPRI Fronthaul
transport, which requires dark fiber.
Smaller Asian nations with abundant dark fiber such as Japan and South Korea were early
adapters of C-RAN architecture. These early CPRI C-RAN networks helped establish benefits of
inter-site coordination.

Revision 1.0 240-00-0153 10 of 53

 vRAN Introduction Training Guide

1.3 Path from Traditional RAN to vRAN

In this section, we will briefly discuss how the current RAN architecture will evolve to virtual
RAN to meet the challenges being faced by industry and generate new revenue streams
through innovative services.
This evolution will be achieved by using a software-intensive function to bring intelligence at
the eNB for smart scheduling, analytics and through LTE-Advanced features such as CoMP and
inter-site Carrier Aggregation.

Figure 5: Path from Traditional RAN to Virtual RAN

• RAN architecture evolution aided by NFV technology whereby baseband functions are
decoupled from underlying hardware and deployed on NFV infrastructure.
• Software programmability and Network automation enabled via NFV.
• Reduced time to market as new services can be quickly realized in the SW without the need
for hardware changes.
• Open interfaces to foster development of robust hardware and software eco-system.
• C-RAN like features for inter-site co-ordination over packet transport. No need for point to
point Dark fiber.
• Software upgradeable to 5G without the need to forklift underlying hardware.

1.4 Altiostar is a Leading Contributor to the Open vRAN Projects

Altiostar is a leading contributor to different projects and initiatives to realize Operator vision of
virtualized RAN with Open interfaces. Altiostar’s efforts have been recognized by the leading
industry forums.
1.4.1 Membership of Different Consortium
• O-RAN: Open RAN-– Created through the merger of XRAN and Open RAN initiatives -
https://www.o-ran.org/

Revision 1.0 240-00-0153 11 of 53

 vRAN Introduction Training Guide

• ETSI: European Telecommunications Standards Institute -

https://www.etsi.org/about/etsi-worldwide

• 3GPP: 3rd Generation Partnership Project- https://www.3gpp.org/

• GSMA: GSM Association -https://www.gsma.com/

• TIP: Telecom Infra Project - An initiative of Facebook and leading operators around the
world - https://telecominfraproject.com/

• IEEE: Institute of Electrical and Electronics Engineers- https://www.ieee.org/

1.4.2 Dedicated Staff

• Full-time staff dedicated to validation of Fronthaul interface between Altiostar vDU and
3rd party RRUs.
• Full-time staff dedicated to validation of Fronthaul interface between Altiostar vCU and
3rd party vDUs.
• We contribute resources to different forums working towards Open RAN eco-system.
1.4.3 Recognition
• CTO Choice award at the MWC 2017 recognizing Altiostar efforts to bring about open
RAN architecture.

Figure 6: CTO Choice Award

1.4.4 Rakuten Press Release
http://www.altiostar.com/rakuten-launches-first-real-world-end-to-end-tests-in-a-fully-
virtualized-cloud-native-mobile-network/

Revision 1.0 240-00-0153 12 of 53

 vRAN Introduction Training Guide

Figure 7: Rakuten Press Release

1.5 vRAN Architecture

As illustrated in Figure 8, Altiostar’s vRAN architecture consists of eNB virtual Centralized Unit
(vCU), eNB virtual Distributed Unit (vDU), virtual EMS (vEMS), Radio Interface Unit (RIU) and 3rd
party Remote Radio Head (RRH) and Antennas.

Each cell-site may have multiple 3rd party RRHs and Antennas. These are connected to a single
RIU over CPRI. Multiple such RIUs interface with a single instance of an vDU, which can be run
in an edge data center cloud. Multiple such vDU instances interface with a single instance of an
vCU, which can be run in a centralized data center cloud. Multiple such vCU instances interface
with a single instance of vEMS, which can be run in a centralized data center cloud. vDU and
vCU can be run in the same data center cloud.

Figure 8: vRAN Architecture

Revision 1.0 240-00-0153 13 of 53

 vRAN Introduction Training Guide

1.6 eNB Functional Split

Figure 9 below illustrates Altiostar’s vRAN architecture’s functional split between vCU, vDU, RIU
(Radio Interface Unit) and 3rd party RRH.

Figure 9: vRAN Functional Split

1.7 Functional Components

1.7.1 3rd Party Remote Radio Head (RRH) and Antenna
Remote Radio Head (RRH) and Antennas, from 3rd party vendor, are directly procured by the
operator. It receives time domain IQ (16-bit I and 16-bit Q) symbols from the Altiostar’s RIU for
each antenna port. Altiostar’s RIU interfaces with 3rd party RRH using open standard Common
Public Radio Interface (CPRI).
Integration and validation is performed between Altiostar’s RIU and the operator selected
vendor’s RRH before the deployment of the solution.

1.7.2 Radio Interface Unit (RIU)

RIU is a ruggedized device that supports wider temperature range. It is IP65 compliant device
meant for outdoor deployment. It supports the lower part of the PHY (LTE L1 functionality).
Following are the major functions supported by RIU:
• Compression and de-compression of frequency domain IQ symbols to/ from vDU
• Conversion of frequency domain IQ symbols to time domain IQ symbols
• PRACH processing of the filtered time domain samples
• Supports three CPRI rate 5 interfaces towards RRH and one 10G Ethernet interface
towards vDU
• Synchronization of the local timing of OCXO using GPS antenna
• Synchronization of the local frequency using 1588v2 PTP 8265.1 telecom profile, in the
absence of GPS antenna
• Support for phase and frequency holdover when the primary source of synchronization,
that is GPS antenna, fails
• Support for upto 4 external alarms inputs, for receiving & relaying the alarms generated
by the cell-site based equipment

Revision 1.0 240-00-0153 14 of 53

 vRAN Introduction Training Guide

Using CPRI it interfaces with RRH and using Altiostar’s IPC (Inter Process Communication) (over
Ethernet) it interfaces with vDU VNF.

1.7.3 virtual Distributed Unit (vDU)

vDU is an VNF (Virtual Network Function) that run on an Intel Architecture based COTS server,
running kernel-based virtual machine (KVM), managed by OpenStack Virtual Infrastructure
Management (VIM) software. Following are the major functions supported by vDU:

• Upper part of the LTE-PHY (LTE L1 functionality)

• LTE-RLC (LTE L2 functionality)
• LTE-MAC (LTE L2 functionality)
• If hardware accelerator is available, offloads some of the LTE-PHY layer sub-
functions, e.g. FEC (Forward Error Correction)
Using Altiostar’s IPC (over Ethernet) protocol it interfaces with RIU. Using Altiostar’s IPC (over
IP/ Ethernet) it interfaces with vCU VNF.

Number of RIUs, which can be served by a single instance of vDU VNF, are determined based on
the deployment requirement and allocation of the virtual resources to the single instance of
vDU VNF.
1.7.4 virtual Centralized Unit(vCU)
vCU is an VNF (Virtual Network Function) that run on an Intel Architecture based COTS server,
running kernel-based virtual machine (KVM), managed by OpenStack Virtual Infrastructure
Management (VIM) software. Following are the major functions supported by vDU:

• LTE-PDCP (LTE L3 functionality)

• LTE-RRC (LTE L3 functionality)
• LTE-RRM (LTE L3 functionality)
• Termination of 3GPP based S1, i.e. S1-MME interface (using S1-AP protocol) and S1-U
interface (using GTP-U protocol)
• Terminates 3GPP based X2, i.e. X2-C interface (using X2-AP protocol) and X2-U interface
(using GTP-U protocol)
• SON (Self Organizing Network) features
• Syslog generation
• IPSec for backhaul security
• Various backhaul transport related features, such as, marking DSCP of the uplink packet
based on QCI of the bearer, user-plane overload control, etc.
• Generation of fault notification and performance counters/ KPIs towards vEMS
• Receiving configuration changes from vEMS and enforcing the same

Revision 1.0 240-00-0153 15 of 53

 vRAN Introduction Training Guide

Using Altiostar’s IPC (over IP/ Ethernet) it interfaces with vDU. It interfaces with EPC (Enhanced
Packet Core) functions over 3GPP based S1 interface and other eNBs over 3GPP based X2
interface.
Number of vDU-VNF instances, which can be served by a single instance of vCU VNF, are
determined based on the deployment requirement and allocation of the virtual resources to
the single instance of vCU VNF.

Revision 1.0 240-00-0153 16 of 53

 vRAN Introduction Training Guide

CHAPTER 2: TRANSPORT FOR vRAN

2 Transport for vRAN Overview
This chapter provides information about the vRAN transport network priorities.

2.1 Support for IPv4 and IPv6 for BackHaul, and Mid Haul Networks
Altiostar vRAN SW supports both IPv4 and IPv6 at all its networks.

2.2 Reliable Control plane Transport at Mid Haul

In order to ensure that there is no loss of control plane traffic at the Fronthaul; this traffic is
transported over SCTP.

2.3 Advantages of FrontHaul over Ethernet

In the following section, we understand the key benefits of using Ethernet versus CPRI that
requires dedicated point to point links.

Figure 10: Deployment flexibility with Ethernet Fronthaul

• Ethernet protocol could be carried over a variety of transports media such as metro
fiber ring, point-to-point microwave, non-line of sight wireless systems, GPON, vDSL, or
dark fiber.
• Tremendous flexibility to an operator by supporting various types of deployment
scenarios encountered in a network as shown in the figure above.

Revision 1.0 240-00-0153 17 of 53

 vRAN Introduction Training Guide

• Use of lower-cost equipment and shared use of infrastructure with fixed access
networks.
• Obtain statistical multiplexing.
• Helps optimize network performance through monitoring.

2.4 Transport Requirements

2.5 Packet Priority for BackHaul, MidHaul and FrontHaul Networks

Altiostar vRAN SW supports packet prioritization via standard protocols like VLAN PCP marking
and DSCP marking to ensure that high priority packets are delivered reliably and within
expected latencies at Backhaul, Midhaul, and Fronthaul networks. This can be configured as per
operator’s transport network characteristics.

2.6 Midhaul Network

2.6.1 Latency Requirement
Altiostar’s vRAN solution can tolerate upto 50 msec of latency + jitter for the midhaul transport
network, that is between vCU and vDU, without any significant impact on the performance.

2.6.2 Bandwidth Requirement

Altiostar’s IPC between vCU and vDU contributes to approximately 20% of overhead and hence,
the general requirement for the midhaul transport bandwidth is approximately 20% on top of
LTE OTA (Over The Air) bandwidth requirement. The LTE OTA bandwidth requirement of an vCU
instance is governed by the number of sectors served by one instance of the vCU and LTE OTA
peak/ average throughput of the each sector.

Below is an example calculation for the OTA bandwidth requirement for one instance of vCU:

• 4T4R 20 MHz FDD

• 12 sectors served by one instance of vCU
• DL 256 QAM and UL 64 QAM support
• DL throughput
o Peak DL throughput/ sector = 380 Mbps (based on conducted testing in lab)
o Peak DL throughput/ vCU = 12 * 380 = 4.560 Gbps
o Average (estimated) DL throughput/ sector = 133 Mbps
o Average (estimated) DL throughput/ vCU = 12 * 133 = 1.596 Gbps
• UL throughput
o Peak UL throughput/ sector = 75 Mbps (based on conducted testing in lab)
o Peak UL throughput/ vCU = 12 * 75 = 900 Mbps
o Average (estimated) UL throughput/ sector = 33 Mbps
o Average (estimated) UL throughput/ vCU = 12 * 33 = 396 Mbps

Revision 1.0 240-00-0153 18 of 53

 vRAN Introduction Training Guide

For UL, in addition to the user-plane data, provision for additional bandwidth will be required
for accommodating “management plane traffic” related to various alarms, notification,
performance counter reporting, reporting of debug and syslogs and so on.

Based on the above calculation, the midhaul transport network bandwidth requirement can be
derived. Please note that the above is for illustration purpose only and each operator may have
their own criteria for calculation of average sector/ eNB throughput based on the OTA peak
sector/ eNB throughput.

2.7 Fronthaul Network

2.7.1 Latency Requirement
Altiostar’s vRAN solution can tolerate upto 250 usec of latency + jitter from the vDU to OTA
transmission.

vDU to OTA transmission latency budget = (edge cloud data center switching delay + jitter) +
fronthaul transport Delay + RIU processing time + RRH processing time = 250 usec
vDU to OTA transmission latency budget = (edge cloud data center switching delay + jitter) +
fronthaul transport delay + 45 (RIU processing time) + 70 usec (example RRH processing time) =
250 usec

[(edge cloud data center switching delay + jitter) + fronthaul transport delay] budget = 250 – 45
– 70 = 135 usec.
The above formula can be used to verify if the deployment can meet the fronthaul latency
requirement or not, example- if the “edge cloud data center switching delay + jitter” is within
35 usec then for fiber based fronthaul, upto 20 km of distance can be supported (transmission
delay through the fiber for a given refractive index = 5 usec/ Km). Or if the “edge cloud data
center switching delay + jitter” is known then the maximum length of the fronthaul transport
can be determined.

2.7.2 Bandwidth Requirement

The fronthaul transport bandwidth is depends upon the LTE OTA (Over The Air) bandwidth
requirement. The LTE OTA bandwidth requirement of an vDU instance is governed by the
number of sectors served by one instance of the vDU and LTE OTA peak/ average throughput of
the each sector.

Below is an example calculation for the OTA bandwidth requirement for one instance of vDU:

• 4T4R 20 MHz FDD

• 6 sectors served by one instance of vDU
• 16 bits (8-bit I and 8-bit Q) frequency Domain IQ samples transferred over fronthaul
• Per antenna port bandwidth requirement = 300 Mbps
• Per sector bandwidth requirement = 300 * 4 = 1.2 Gbps

Revision 1.0 240-00-0153 19 of 53

 vRAN Introduction Training Guide

• Per 6-sector bandwidth requirement = 1.2 * 6 = 7.2 Gbps

Based on the above calculation, the fronthaul transport network bandwidth requirement per
vDU instance can be derived.

2.8 Dimensioning and Capacity Detail

2.8.1 General
The virtual resources, in terms of processing power required for the vCU and vDU depends
upon multiple factors such as, number of LTE carriers, bandwidth for each of the LTE carrier,
type of the x86 processor used and so on. For the dimensioning detail, following radio and Intel
Architecture based server specifications are considered:
• Radio specification: 4T4R 20 MHz FDD; Single carrier
• Server specification:
o Processor: 2 * Skylake SP-Gold 6148 (20 cores @ 2.4 GHz)
o Hardware Accelerator (for vDU only): 2 * Intel Vista creek FPGA acceleration (one /
socket). Each Vista Creek to have 2x25G

Following table provides capacity information for one eNB, which consists of a single instance
of vCU and two instances of vDU.
Parameter Value
Number of eNB 1
Number of vCU VNF instance 1
Number of vDU VNF instance 2
Total number of sectors supported 12
Max number of RRC connected users per sector 700
Max number of VoLTE users per sector 256
Sector Throughput with Max number of RRC connected UEs DL: ~120 Mbps
UL: ~40 Mbps
2.8.2 Resource Requirements: vCU
Each instance of vCU will require 6 pCPUs for supporting upto 12 sectors of 4T4R 20 MHz FDD
radio.

2.8.3 Resource Requirements: vDU

Each instance of vDU will require 9 pCPUs for supporting upto 6 sectors of 4T4R 20 MHz FDD
radio. This is assuming the use of hardware accelerator to offload some of the LTE-PHY sub-
functions.

Revision 1.0 240-00-0153 20 of 53

 vRAN Introduction Training Guide

CHAPTER 3: NFV ARCHITECTURE

3 NFV Architecture Overview
In this chapter, the following concepts are explained:

• NFV Overview and its Advantages

• OpenStack and its Relationship with NFV

• OpenStack Concepts

• Altiostar NFV Architecture, Management, Availability, Dimensioning

3.1 Network Function Virtualization Overview

Figure 11: High-Level NFV Framework

NFV offers a new way to design, deploy and manage different network functions in operator
networks. NFV decouples network functions from proprietary hardware. NFV utilizes standard
virtualization technologies such as OpenStack, VMWare etc that run on top of commercial of
the shelf compute, storage and networking hardware.
NFV is expected to reduce the CapEx, OpEx, and Time to market for the operators. It is also
expected to foster roll out of innovative services.

Revision 1.0 240-00-0153 21 of 53

 vRAN Introduction Training Guide

Innovation in the services deployed using custom hardware is constrained by hardware

capabilities. On the other hand with NFV, the functions run in SW on top of general-purpose
hardware, therefore, it is possible to roll out any new features quickly without any changes to
the underlying hardware infrastructure.
In order to accelerate the progress, several service providers have come together under aegis
of ETSI Industry Specification Group NFV (ETSI ISG NFV) to develop requirements and standards
for network function virtualization in telecom networks. For example, ETSI MANO.
OpenStack is an open source virtualization platform that enables service providers to deploy
virtual network functions (VNFs) on white labeled commercial off the shelf hardware platforms.
ETSI NFV standards have been developed around OpenStack, therefore, many operators have
adopted OpenStack as a method to build NFV Infrastructure.

3.2 Advantages of Network Function Virtualization

• Virtualization: Network services like EPC, IMS, RAN, Firewalls, Load balancers, and so on
can be launched as virtual machines in commodity hardware.
• Orchestration: Manage virtual routers, switches and network services from a single
point.
• Programmable: Network configurations, Iptables and policies can be programmed with
schemas.
• Dynamic Scaling: Increase and decrease the network resources for a VNF, based on
utilization of CPU, power, and bandwidth.
• Hardware Scaling: Increasing the number of compute nodes available in the cluster on
the fly without impacting other services.
• Automation: Create templates to onboard virtual network functions and configure
network services.
• Visibility: Monitor network resources and connectivity.
• Performance: Optimize network device utilization.
• Multi-tenancy: Network services can be managed from multiple projects.
• Service Integration: Network services like vEPC, vIMS, firewalls and load balancers can
be service chained.
• Openness: Full choice of Modular plugins.

Revision 1.0 240-00-0153 22 of 53

 vRAN Introduction Training Guide

3.3 OpenStack and NFVI

This section provides overview of OpenStack, Cisco VIM, deployed across Rakuten MNO.

Cisco NFVI is deployed for hosting different VNFs. NFVI architecture is delivered using point of
delivery (POD). In easy term POD can be defined as logical instiaitaion of workload with similar
affinity or functions. NFVI software is supplied by Cisco and it is referred as Cisco Virtualized
Infrastructure Manager (CVIM). NFVI hardware is from Quanta which is defined into different
SKU.

Cisco NFVI deployed for this project support following types of PODs:
• Full POD Architecture
• Micropod POD Architecture

Full POD Architecture: This is complete scalable POD with dedicated Openstack Controller,
Compute and Storage into separate nodes. Number of compute nodes can be scalable
depending upon requirements.

Figure 12: Cisco NFVI Full POD

Micropod POD Architecture: MicroPOD uses 3 nodes as combined controller, compute and
storage functions. Any additional node will function as compute nodes.

Revision 1.0 240-00-0153 23 of 53

 vRAN Introduction Training Guide

Figure 13: Cisco NFVI Micro POD

3.4 OpenStack Users, Tenants, and Roles

There are three types of Keystone objects:
User – Someone or something that can gain access through Keystone. Users have credentials
that can be checked like passwords or API keys.
Tenant – Also called Project in Nova. A project aggregates a number of resources such as some
machines in Nova, number of images in Glance, few networks in Neutron. Users are bound to a
tenant by assigning them a role on that tenant.
Role – Number of privileges or rights a user has or actions they are allowed to perform. For
example, a user with an admin role can only take admin actions. Users can be added to any role
either globally or in a tenant. In the first case, user can access the resources in all tenants as
implied by the role, in the second case the user has limited access to the resources of the
corresponding tenant.

3.5 Common Nova Terminology

Some of the common Nova terms used are listed below:
• Server – A system that is being deployed within OpenStack and generally referred to as an
instance.
• Flavor – A resource template that specifies the disk space, base memory, and CPU
requirements. It is specified during the creation of an instance so that OpenStack knows
which resources to provide to the instance. A default set of flavors is included in the
standard setup.
• Reboot – OpenStack supports both a software and hardware reboot of the server. In a soft
reboot, the operating system is signaled to restart which allows for graceful shutdown of all
the processes. A hard reboot simply restarts the system.

Revision 1.0 240-00-0153 24 of 53

 vRAN Introduction Training Guide

• Rebuild – A process that removes all data on the server and replaces it with the specified
image. The server ID and the IP addresses remain the same for the rebuilt instance.
• Resize – A feature of Nova that allows you to convert the flavor of an existing server to a
different flavor.

3.6 Cisco NFVI Architecture

For Rakuten MNO, we selected Cisco VIM 3.0 supporting Quanta servers as server hardware for
management node, controller node, storage node and compute node. Cisco VIM 3.0 is based on
Openstack Queens. Cisco NFVI supports either OVS or SR-IOV as the cloud network solution

Figure 14: Detail Cisco NFVI Architecture for Rakuten MNO

As it is explained in the above section there are three types of high level POD architecture
supported by Cisco VIM: Full standard POD architecture, Hyper converged architecture,
Micropod architecture. We selected Full standard Pod architecture for CDC and Micropod
architecture for GC.

After the installation finishes, Cisco VIM provides OpenStack services using Docker™ containers
to allow for OpenStack services and pod management software updates. The following diagram
shows the functions and services managed by each Cisco NFVI nodes.

Revision 1.0 240-00-0153 25 of 53

 vRAN Introduction Training Guide

Figure 15: Cisco NFVI Node Functions

Note: For more details on CDC and GC NFVI Architecture refer to Cisco HLD.

3.7 Reference Architecture / Logical Connection Diagram of GC

Refer to Cisco Documentation for further details.

The Physical Reference Architecture for VDU and VCU and the interface information for each
connectivity points are below.

Figure 16: Physical Reference Architecture for vDU and vCU to Cell Site

Revision 1.0 240-00-0153 26 of 53

 vRAN Introduction Training Guide

The GC Site Logical Connectivity with Cell Site and CDC is summarized as below.

Figure 17: GC Site Logical Connectivity with Cell Site and CDC

Group Center (GC) NFVI Architecture is described as follows and there are four types of GC
SKUs.
• GC SKU1: vDU VNF runs, which requires FPGA acceleration

• GC SKU2: The other VNFs run, which does not requires FPGA acceleration and vCU runs
on this GC SKU2.

• GC SKU3: For management node

• GC SKU4: Both vDU VNF and the other VNFs run as standby compute node

There are 12 types of GC sites depending on how many cell sites should be handled on GC.

3.8 Rakuten Mobile Network Architecture

The Rakuten Mobile Network is fully virtualized Telecloud which provides zero
footprint, fully automated and software defined RAN network to serve tens of millions
of subscribers.

Rakuten is working with partners such as Altiostar, Nokia, Cisco, Innoeye, Quanta,
Intel, and so on to work on designing, developing and integrating to launch a new
network in 2019.

Revision 1.0 240-00-0153 27 of 53

 vRAN Introduction Training Guide

Figure 18: Logical Deployment view of Rakuten Mobile Network with NFV Architecture

Figure 19: Rakuten vRAN Automation Architecture

• The Rakuten Mobile Network architecture is hierarchically divided into Central Data
Center (CDC), Group Center (GC) and Cell Site. Between GC and CDC, there’s one
additional level of data center, Zone Center (ZC), which is mainly used for aggregation
where routing functions will be deployed, and hence it’s not in scope of this document.

• CDC will host packet core from Cisco, IMS from Nokia, NFV management from Cisco, OSS
from InnoEye, BSS from NEC, RAN EMS from Altiostar and other signaling platforms.

• Group Center (GC) will host vRAN functions, including Virtualized Distributed Unit (vDU)
and Virtualized Central Unit (vCU) from Altiostar. In future, it can also provide zero

Revision 1.0 240-00-0153 28 of 53

 vRAN Introduction Training Guide

latency services with massive capacity to host next generation applications such as AR,
VR, real-time gaming servers and intelligent caching and internet offloading.

• Cell Site will host RRH from Nokia and RIU from Altiostar.

• In each data center, all network functions are deployed as VNF instances on one
horizontal NFVI.

• The NFVI layer consists of software defined programmable infrastructures with

distributed carrier grade Telecloud platforms. The NFVI layer is built using x86 Intel
processors with compute platforms from Quanta. Cisco VIM software will instantiate
cloud resources and manage the entire lifecycle of the geographically distributed PODs.

• All services will be deployed and managed from a single VNF Orchestrator using the NSO
from Cisco. This will require deployment of automated workflow for each service so that
NSO can manage the lifecycle if these services.

Rakuten NFV C-RAN solution is designed to use commercial off-the-shelf Intel based hardware.
The infrastructure management SW requires that the CPU is from the Intel Xeon family.

Rakuten NFV C-RAN solution requires 10GE Top-of-Rack (ToR) switches to establish the
infrastructure and tenant networks. It also requires 1GE switches to establish the different
management networks. The main requirement for these switches is that they are managed
switches and the number of ports per switch depends on the number of compute nodes being
provisioned. As an example, with a cluster of 20 compute servers and two control servers, we
recommend a ToR switch with 48 ports 10GE plus 4 ports 40GE for the uplink.

3.9 Management of Altiostar vRAN

Altiostar solution includes an EMS for management of Altiostar’s eNB with support for Fault,
Performance and Configuration management.

VNF Manager supports Vi-VNFM interface to the virtual infrastructure manager (VIM) based on
the ETSI NFV MANO specifications.
vCU VNF is a single VM VNF. vCU is connected to the following networks:
• Management Network
• Backhaul Network
• Midhaul Network
Management network connection uses VirtIO type port, whereas connectivity to Backhaul and
Midhaul networks are over SR-IOV ports.

vEMS is a 4 VM VNF, which has 2 Access Node (AN) VMs running in Active/Standby mode and 2
Data Node (DN) VMs running in Active/Standby mode.

Revision 1.0 240-00-0153 29 of 53

 vRAN Introduction Training Guide

These VMs are connected to a management network and another internal network as shown
below.

Figure 20: VMs Connection to Management Network and Internal Network

Connection to management and internal networks are over VirtIO ports.

Altiostar also supports direct integration with G-VNFM of the operator for lifecycle
management of vCU VNF.

3.10 Availability Features

The eNB must guarantee a carrier-grade high availability SLA. Accordingly, the solution
supports capabilities to overcome typical fault events.

3.10.1 Automatic VM Recovery

The vRAN solution must guarantee carrier-egrade high availability. Any failure in the hardware
infrastructure such as NIC connection being down, cables to Compute Node being unplugged,
power failure and so on might lead to the failure of VMs in a particular Compute Node.

In such a scenario, the sectors in the failed Compute Node will not be reachable which leads to
service loss to the customer. During this time, the disaster recovery process is enabled and
creates new VMs on a different Compute Node and the affected sectors come up without
operator intervention to minimize the service downtime for the customers.

The total time for the VMs to be created on a different Compute Node and restoration of full
service on the affected sector is around 5 minutes.

Revision 1.0 240-00-0153 30 of 53

 vRAN Introduction Training Guide

3.10.2 Controller Node Redundancy

Controller nodes are deployed in redundant (1+1) configuration and support automatic failover.

3.10.3 Compute Node Redundancy

Compute nodes can be deployed in M + N node configuration (or SN+ configuration) to ensure
that there is spare HW capacity available to take over the work in case of compute node
failures.

3.10.4 ToR Switch Redundancy

ToR switches are deployed in (1+1) redundant configuration with support automatic failover.

4 Hardware Equipment’s Introduction

This chapter provides an overview of the following:
• Antennas
• Remote Radio Head (RRH)
• Radio Interface Unit (RIU)
• Remote Electrical Tilt (RET) Support

4.1 Antenna
The RRH is tightly attached to the antenna with TCC block set.

Figure 21: Antenna and Flexible Integrated Antenna Site

Revision 1.0 240-00-0153 31 of 53

 vRAN Introduction Training Guide

The below table provides Antenna technical data.

16dBi 17dBi
Frequency Range (MHz) 1730 -1845
Impedance 50Ω
Polarization Type Dual, Slant ±45˚
Gain (dBi) 16.0 17.0
3dB Horizontal 62˚ ± 5 62˚ ± 5
Beam-Width Vertical 10.5˚ ± 1.5 7.0˚ ± 1
Electrical Down Tilt Range 0˚ - 15˚ / 1˚step 0˚ - 12˚ / 1˚step

Internal RET Electronic Control Module

RET Motor Configuration
RET Motor is internal to antenna and not field replaceable

Antenna Control Interface Internal RET, AISG2.0 No Daisy chain function

Table 1: Antenna Technical Data

4.2 Remote Radio Head (RRH)

Nokia AHEH is used as RRH in this project, which supports 4T4R, Band 3, up to 40W per pipe.
AHEH technical data is shown below.

AHEH
Supported Frequency bands 3GPP band 3
Frequencies DL 1805-1860 MHz, UL 1710-1765 MHz
Number of TX/RX paths/pipes 4/4
Instantaneous Bandwidth IBW 55 MHz
Occupied Bandwidth OBW 55 MHz
Supported LTE Bandwidth LTE5MHz, 10MHz, 15MHz, 20MHz
Output Power Max 40 W, Min 8W

Dimensions (mm) Height x width x depth 337 x 295 x 140

Volume (M3) 13.9 l

Weight (kg) 15.5 kg
Supply Voltage / Voltage Range DC-48 V / -36 V to -60 V
300 W [ETSI 24 h weighted load mix for nominal
Typical Power Consumption power]
498 W [100% RF load]
Antenna Ports 4TX/4RX, 4.3-10

Revision 1.0 240-00-0153 32 of 53

 vRAN Introduction Training Guide

AHEH
Optical Ports 2 x RP3-01/CPRI 9.8 Gbps
AISG2.0 and AISG3.0 from ANT1, 2, 3, 4 and RET
ALD Control Interfaces
(Power supply ANT1 and ANT3)
Other Interfaces EAC (MDR26)
Tx monitor port No
Installation Mounted on antenna
Ingress protection class IP65
Salt fog Telcordia GR-487-CORE
Earthquake ETSI EN 300 019-2-4, Class 4.1, Zone 4
Wind driven rain MIL – STD – 810G, method 506.5, procedure 1.
Operational Temperature Range -40°C to 55°C
Surge protection Class II 5kA
Table 2: AHEH Technical Data

Figure 22: AHEH Interface

AHEH interfaces are shown as in the above figure and the detail information is shown in the
below table.

Interface Connector type Purpose

ANT 1-4 4.3-10 Interface to antenna
DC IN 2pin circular connector Power Supply input
GND M8 or dual M5 screws Ground
OPT 1-2 SFP+ Optical interface to/from Baseband, CPRI
RET AISG C485 (8-pin circular) Remote Electrical Tilt *not used

Revision 1.0 240-00-0153 33 of 53

 vRAN Introduction Training Guide

Interface Connector type Purpose

EAC MDR26 External alarm interface
Table 3: AHEH Interface Detail

4.3 Radio Interface Unit (RIU)

The Radio Interface Unit is an outdoor, passively cooled unit that functions as a CPRI to
Ethernet gateway. When deployed it enables a connection of a three sector cell site using
Remote Radio Units (RRUs) with Common Public Radio Interface (CPRI) over an Ethernet
transport network to a remote aggregation site for higher layer radio signal processing by a
Altiostar vDU.

The RIU can be mounted on a wall using supplied mounting bracket assembly and mounting
plate. The installer is responsible for supplying and installing antennas and associated cables
and materials for site installation including the GPS, RF, CPRI, Alarm, Power and ground
cables/connector along with SPF’s and other site materials as required.

Figure 23: Single RIU Deployment Example

The RIU Technical specifications are listed in the below table.

Item Specification
Physical
305 mm x 236 mm x 60 mm (Unit Only)
Dimensions (WxHxD)
305 mm x 236 mm x 132 mm (Unit with Wall Mount Bracket)
Volume 4.1L
Weight 4.0 Kg (4.6Kg with Wall Mount Bracket)
Mounting Options Wall
Electrical
Input Power -48 VDC (-40.5 to -57 VDC)
Typical Power ~30 W (35W Max)

Revision 1.0 240-00-0153 34 of 53

 vRAN Introduction Training Guide

Consumption
Environmental
-40° to 55° C (-40° to 131° F)
Working temperature
Operating altitude -60 to 3000 m (-197 to 9,843 ft)
Relative humidity 5 to 100%
Cooling Convection (fanless)
Table 4: RIU Technical Specification

The following connectors are located on the bottom of the RIU unit.

Figure 24: RIU Bottom View

Refer to the below tab le for details of the connectors used in the RIU unit.

Connection Quantity Function

Power 1 -48VDC Supply voltage to RIU
Alarms 1 For Cabled Connection to External Input/Output alarms
Fronthaul 1 10GE SFP+ Ethernet port toward aggregation site
CPRI 3 4.9G SFP+ CPRI ports towards RRU
Ground 1 Equipment grounding
GPS 1 To connect External GPS Antenna for Timing Source Input
Table 5: RIU Connection Quick Reference

4.4 Remote Electrical Tilt (RET) Support

The RRH provide the functionality to communicate with SM via UDP port, and antenna lines
(Iuant) via RET port (RS-485). A RET device provides means to adjust the electrical tilt of one or
multiple antennas. The set of procedures to control RET antennas provides means to control
the electrical tilt of one or more RET antennas remotely. So, the RET system is advantageous to
bring flexible benefit to operator that the Cell site can perform optimization and reduce site
visit.

Revision 1.0 240-00-0153 35 of 53

 vRAN Introduction Training Guide

The RF port 1 of RRH supplies the RET control capability via the AISG2.0 control cable.

Figure 25: AHEH Port 1 Connectivity for AISG2.0

Revision 1.0 240-00-0153 36 of 53

 vRAN Introduction Training Guide

CHAPTER 5: MANAGEMENT OVERVIEW

5 Management Overview
Refer to vEMS 3.0 System User Guide for vEMS overview, features, and GUI functionalities.

5.1 Self-Establishment of New LTE Cells

Altiostar vEMS supports automated deployment of eNB solution.
5.1.1 eNB Pre-Provisioning
The eNB pre-provisioning is accomplished through a 3GPP standard Self Configuration (SC) IRP
interface supported in the vEMS. Upon finalizing the network plan, the OSS pre-provisions all
the eNBs to be managed by the corresponding vEMS instance. This task involves creating Self-
configuration Profiles at the vEMS through the SC IRP interface. Prepare the license and eNB
configuration at the OSS.

Ensure that the following details are available to create the SC Profiles for an eNB at the vEMS:

• eNB ID (20-bit eNB ID)

• Software Version (vCU and vDU SW version)

For more details on the self-configuration procedure, refer to the Altiostar Management
Integration Guide.

5.1.2 vEMS Commissioning

The high level architecture of macro eNB management in Rakuten is shown in the below
diagram. The country is geographically divided in to EAST and WEST region and each region is
geographically divided in to a number of prefectures. There can be more than one GC sites
within a prefecture. Macro eNBs runs within the GC. To know whether a GC belongs to EAST or
WEST region, one needs to look in to the region of the prefecture it belongs to.

Revision 1.0 240-00-0153 37 of 53

 vRAN Introduction Training Guide

Figure 26: Macro eNB Management Architecture

OSS is responsible for instantiating EMS instances in CDC. Rakuten has 2 CDCs, one for EAST
region and one for WEST region, currently. EMS instances in a CDC manage eNBs in the same
geographic region of the CDC it belongs to. All the eNBs in a particular GC site will be managed
by the same EMS instance. An EMS instance can manage eNBs in more than one GC sites. An
EMS instance can manage GC site (eNBs) from multiple prefectures – as long as prefectures
belongs to same region. Similarly, GC sites within a prefecture can be mapped to multiple EMS
instances, provided same GC site is not mapped to more than one EMS instance.
Note: eNB management architecture for small (micro) cell will be slightly different, as the eNBs
are not running in GC sites. Instead small cell eNB will run in CDCs. There will be separate EMS
instances to manage small cell eNBs.

5.1.2.1 EMS Instantiation Logic

OSS is responsible for instantiating and managing EMS instances. Each EMS instance is sized
and configured to manage up to a maximum number of cell sectors. Current estimated capacity
of EMS instance is 9000 sectors. OSS will make this value configurable as it could change in the
future.

Rakuten deploys different types of GC sites (Type A to F, Type XA to XF for example). These
sites are planned for different cell/sector capacities based on hardware and fiber connections
to cell sites. For example, type A GC is planned for 144 sectors and type XA for 288 sectors
Note: These are just sample GC type names and sector capacities. Please get the up to date
value for GC site types and sector capacity from Rakuten.

To perform the vEMS commissioning procedures, ensure to complete the radio network
planning exercise and to provision the OSS with the following information:

Revision 1.0 240-00-0153 38 of 53

 vRAN Introduction Training Guide

• GC site details
• Mapping of eNBs and the corresponding GC sites managing the eNBs
• Mapping of GC sites and the corresponding vEMS hostnames managing the GC sites
• DHCP servers
Refer to the following sample mapping of the information at the OSS:
GC Site eNBs
EMS
(GC Site ID) (20-bit eNB IDs)
vEMS-1 GC Site – 1 1,2,3,4,5,6,7,8,9,10
(hostname of the vEMS) GC Site – 2 11,12,13,14,15,16,17,18,19,20
GC Site – 3 21,22,23,24,25,26,27,28,29,30
GC Site – 4 31,32,33,34,35,36,37,38,39,40
GC Site – 5 41,42,43,44,45,46,47,48,49,50
vEMS-2 GC Site – 6 51,52,53,54,55,56,57,58,59,60
(hostname of the vEMS) GC Site – 7 61,62,63,64,65,66,67,68,69,70
GC Site – 8 71,72,73,74,75,76,77,78,79,80
GC Site – 9 81,82,83,84,85,86,87,88,89,90
GC Site – 10 91,92,93,94,95,96,97,98,99,100
vEMS-3 GC Site – 11 101,102,103,104,105,106,107,108,109,110
(hostname of the vEMS) GC Site – 12 111,112,113,114,115,116,117,118,119,120
GC Site – 13 121,122,123,124,125,126,127,128,129,130
GC Site – 14 131,132,133,134,135,136,137,138,139,140
GC Site – 15 141,142,143,144,145,146,147,148,149,150
Table 6: Sample Mapping of the Information at OSS

OSS is responsible for assigning a particular GC site to an EMS instance. OSS needs to know
max sector capacity of the GC sites. OSS will find an EMS instance, which can accommodate
those sectors without exceeding the max sector capacity of the EMS instance. When binding
GC sites to EMS instances, we only use up to 90% of the sector capacity for an Instance. This is
done to make some space for future expansion of some GC sites. OSS will also need to find EMS
instance which can serve the GC based on the region GC belongs to (EAST or WEST). Region of
the GC is figured out based on region of the prefecture where the GC is located. If there is no
EMS instance in the CDC to assign the GC site, OSS will instantiate a new EMS instance in the
CDC to assign the EMS instance.

Based on the information in Table 1, the OSS also derives the mapping of eNBs and the
corresponding vEMS hostname managing the eNBs. Upon commissioning the vEMS, all the
eNBs, to be managed by this vEMS, need to be pre-provisioned in the vEMS by the OSS. For the
steps involved in vEMS commissioning, refer to the following sections.

Note: The OSS needs to configure the FQDN information of the vEMS managing the GC sites, on
the DHCP server. For more information, contact Cisco/InnoEye teams working on Automtaion
Project.

Revision 1.0 240-00-0153 39 of 53

 vRAN Introduction Training Guide

5.1.2.2 Instantiating New EMS Instance

OSS can either trigger automatic instantiation of new EMS instantiation of new instances based
on executing algorithm specified above or it can notify the administrator by providing alarms
indicating the capacity threshold crossing for EMS instances. If the second scheme is used,
then administration will have to trigger instantiation of new EMS instance through OSS.

5.1.2.3 De-commissioning GC and Moving GC from one EMS to another

When a GC site is de-commissioned, OSS should remove the assignment of that GC site from its
bounded EMS instance. used_sector_capacity of that EMS instance must be adjusted by
subtracting max-sector of the GC site which got decommissioned.

5.1.2.4 Changing GC Site Types and GC Max-Sector Capacity

As indicated in the previous section, each GC site type is assigned a max-sectors capacity, which
will be preconfigured in the OSS. OSS should support following changes and adjust
used_sector_capacity for all affected EMS instances accordingly.

• Type of a particular GC site is changed, which changes the max-sector of that GC site
• max-sector value of a particular GC-site type is changed
• New GC site type is added

5.1.3 vEMS Configuration

Upon completion of the vEMS instantiation, the OSS needs to configure the vEMS through the
North Bound Interface (3GPP IRP and SNMP). Refer to the following sections for the
configuration details.

5.1.3.1 Notification IRP Subscription

In the vEMS, all the IRP related notifications are sent through Notification IRP. Hence, the vEMS
expects OSS to subscribe for notifications through the 3GPP standard SOAP interface.

5.1.3.2 SMTP Configuration

The vEMS has a provision to send an email to the designated users about any fault or incident
occurring in the vEMS. Perform the SMTP configuration to allow the vEMS for communicating
with an email server, for sending emails. The following details required for this configuration:
• SMTP server IP Address or Hostname
• Email Addresses of the designated users
• Authentication details if required.

5.1.3.3 SNMP Target Registration (Optional)

The vEMS supports SNMP notification forwarding to northbound applications. This support
includes forwarding of eNB and vEMS self-monitoring notifications through SNMP v1/v2c/v3.
The OSS needs to register with vEMS for receiving these notifications.

Revision 1.0 240-00-0153 40 of 53

 vRAN Introduction Training Guide

5.1.3.4 Licensing Information

The vEMS requires a valid license. The vEMS provides a SOAP interface for license management.
The OSS uses this interface for importing a license into the vEMS. Also, the eNB requires a
license. The OSS uses the same interface for importing an eNB license into the vEMS.

5.1.4 vRAN Auto Commissioning

Perform the below steps to complete vRAN Auto-Commissioning process.

1. Installation at the Radio site is completed that (involves installing Radios and the RIU
units at the site) and the equipment is powered on.
2. On SW boot up at the RIU, It identifies its own serial number.
3. It also sends out a DHCPV6 request with device type as Macro. The DHCPV6 response
received from the DHCPV6 server contains the EMS FQDN, specific to this GC site (the
DHCPV6 was configured with this FQDN as a part of GC site infrastructure brings up by
the NSO).
4. The RIU now sends a Power up notification to the EMS with its identity (serial number).
EMS forwards the same notification to OSS. If this RIU is the first RIU to be powered up,
to be managed by a given eNB instance, then this eNB instance is not yet running.
5. EMS sends RIU Initialized Notification with Procedural state as “Initialized” to OSS.
Procedural state “Initialized” represents that EMS is not managing any RIU with this
serial number.
6. On reception of this notification, the OSS identifies the eNB ID, to manage this RIU, and
triggers eNB network service instantiation (6) towards the NSO. In order to do this, it
needs the following parameters:
a. eNB (corresponding to the RIU serial number)ID – part of the Radio network
planning output provisioned into OSS.
b. GC site ID – part of the Radio network planning output provisioned into OSS.
c. EMS FQDN (to be provided as part of vCU VNF instantiation)
d. vCU FQDN (to be provided as part of vDU instantiation)
e. All Static IPv6 addresses for VNF interfaces and FQDNs assigned for the VNF.
The NSO then triggers relevant VNF instantiation: that is vCU instantiation (6a) followed
by vDU instantiation (6d).

On completion of instantiation, it gets the VNF record with assigned IPv6 addresses and
hostnames. It then uses this information to update the DNS server with the DNS records
for the vCU (6b) and the vDU (6d). There would be a standard way to convert
Hostnames to FQDN by adding suitable prefix/suffixes.
7. On successful instantiation, the vDU registers with the vCU VNF using the vCU FQDN
provided to it during its instantiation by the ESC.
8. The vCU sends an eNB up notification to the EMS.

Revision 1.0 240-00-0153 41 of 53

 vRAN Introduction Training Guide

9. EMS starts self-configuration process and sends “SC process created notification” to
OSS.
10. EMS sends “Request eNB license info (eNB ID)” to OSS and in turn receives license
information from OSS.
11. EMS generates eNB license and sends eNB license to vCU.
12. EMS sends “Request eNB configuration (eNB ID)” to OSS and receives eNB configuration
from OSS.
13. EMS sends “Set Configuration eNB” to vCU.
14. vCU in turn sends “vDU configuration” to vDUs.
a. vCU sends “Second Initial Boot Notification” to EMS indicating to EMS that the
configuration is successfully applied.
b. EMS collects the inventory and config data from vCU and updates the EMS database.
EMS send activation request to vCU.
c. The EMS sends “Notify SC Process completed” to OSS to indicate that the
commissioning process is concluded.
15. The EMS now responds to the Power up notification from the RIU with the identity
(FQDN) of the vDU that will manage the RIU and its connected Radios.
The RIU then initiates a connection towards this vDU and the vDU then configures the RIU and
radios.

5.2 Capacity and Dimensioning

Altiostar vEMS supports 9000 sectors in a High Availability Architecture. Sector count is based
on the following assumptions:

• PM File Processing
• eNB will send the PM files at 15 minutes interval. EMS will calculates KPI and
generate PM report (3GPP format).
• 3gpp PM reports and PM data files received from eNB will be maintained in EMS for
2 days only.
• EMS will not store any processed PM data in database.
• Around 1000 performance counters per Network Element.
• Fault Management
• 0.005 alarms per second per NE.
• Alarms will be forwarded to only one target destination (OSS).
• Only last 30 days of notifications are stored in EMS.
• vEMS Backup
• vEMS backs up configuration and inventory data on a daily basis. Configuration is full
back up where data (notification or Alarm data) is backed up in an incremental
manner where each incremental backup contains previous day data only.
• Latest two backup files only maintained in EMS.
• Last 30 days of operation audit information will be stored in EMS.

Revision 1.0 240-00-0153 42 of 53

 vRAN Introduction Training Guide

• 300 UEs can be traced at any instant (3GPP + Vendor specific parameters)
20 Simultaneous Users
• Following are the resource requirement.
CPU RAM Storage
App Node 1 20 20 GB 900 GB
App Node 2 20 20 GB 900 GB
Data Node 1 20 20 GB 3.5 TB
Data Node 2 20 20 GB 3.5 TB

5.3 vEMS Hardware

We have standardized Quanta hardware for NFVI deployment into different following SKU’s.

1. CDC SKU 1 = CDC NFVI Management node

2. CDC SKU 2 = Controller and compute node
3. CDC SKU 3 = CDC NFVI HDD storage node
4. CDC SKU4 = CDC NFVI SSD storage node
5. CDC SKU 5 = GC Ceph storage at CDC
6. CDC SKU 6 = Compute node NEC BSS
7. CDC SKU 7 = NEC OSS Baremetal (Hadoop master)
8. CDC SKU 8 = NEC OSS Baremetal (Hadoop worker)
9. CDC SKU 9 = NEC OSS Baremetal (Hadoop Zookeeper)

Revision 1.0 240-00-0153 43 of 53

 vRAN Introduction Training Guide

CHAPTER 6: SON OVERVIEW

6 SON Overview
The following diagram depicts the Self-Organizing Networks Architecture.

Figure 27: eSON Architecture

Altiostar solution offers the following SON features:

• Automatic Neighbor Relations (ANR)
• Physical Cell Identity (PCID) Conflict Detection
• Random Access Channel (RACH)
• Mobility Load Balancing (MLB)
• Mobility Robustness Optimization (MRO)
• Multi-Cell Interference Management (MCIM)
• Minimization of Drive Test (MDT)

6.1 Automatic Neighbor Relations (ANR)

Automatic Neighbor Relations (ANR) function detects missing neighbour on the basis of UE
measurement report and X2 messages. The centralized EM-SON functions in UE ANR are used
to enforce neighbour attributes depending on network conditions and operator policies. The
enforcement is done both at the time of addition of a new neighbour and periodically through a

Revision 1.0 240-00-0153 44 of 53

 vRAN Introduction Training Guide

neighbour optimization process executed at EM-SON. The neighbour optimization process is

further used to rank the neighbors on the basis of HO performance so that the lowest ranked
neighbors are removed from the neighbour list.

Altiostar’s SON ANR offers the following functionalities (automatic in closed loop fashion)
1. Neighbor Discovery and addition -both neighbor cell and X2 neighbor).
2. Neighbor parameters update as part of changes in network (both neighbor cell and X2
neighbor).
3. Neighbor Deletion based on aging/inactivity.

Altiostar’s implementation of the ANR function uses hybrid architecture with responsibilities
and decision making shared between the following two modules:
1. ANR module at vCU
2. EMSON module at EMS

Altiostar supports 512 neighbor cells per frequency for up to nine frequencies for a given cell
and 256 X2 entries for a given eNB.

6.2 Physical Cell Identity (PCID) Conflict Detection

PCI Detection function at the vCU detects and reports PCI conflict/confusion. The PCI-Detection
functions works with mobility algorithms to ensure that handovers are allowed to succeed
despite a PCI conflict/ confusion until PCI is resolved though at the cost of increased signaling
with UE as the ECGI of the cell with PCI conflict/confusion has to be resolved to ensure that HO
is being executed with the right cell.

Altiostar SON PCID uses a periodic PCID resolution of existing neighbors to detect PCID
confusion. Since using measurement reports for resolving PCID consumes bandwidth and
affects UE throughput, judicious choice of UE for such an operation should be made such that
an existing conflict situation can be identified swiftly with least number of UEs and much faster.
Altiostar SON PCID, utilizes, X2 message to warn operator of a possible PCID Collision. If an eNB
sees that any of its X2 neighbor has any serving sector with PCID same as PCID of one of its own
serving sector, the eNB raises a PCID Conflict alarm. The operator is expected to verify if there
really is a PCID Collision and take appropriate remedial actions.

6.3 Random Access Channel (RACH)

The Physical Random Access Channel (PRACH) preambles are shared amongst the User
Equipment (UEs) for initial access and handover purposes. A UE is informed about the
generation process of these preambles via parameters which are broadcast in System
Information Block 2 (SIB2). These parameters are Root sequence index, Zero correlation zone
configuration, High speed flag, PRACH frequency offset, and PRACH configuration index.

The root sequences are grouped into 838 logical root sequences and the first index of the RSI
block allocated is broadcast in every cell. The aim of assigning RSI is that each cell must have a

Revision 1.0 240-00-0153 45 of 53

 vRAN Introduction Training Guide

different Root Sequence Index (RSI) to avoid the reception of false preambles in the adjacent
eNBs as far as possible. It is assumed that RF planning tool allocates initial RSI to every cell such
that the neighboring cells have unique PRACH preambles.

The objective of RACH Optimization algorithm is to automatically detect the possibility of a RSI
collision and execute a resolution across neighboring cells. In addition, it also calculates Zero
Correlation Zone (ZCZ) index, based on the size of the cell, to determine the required number of
RSIs to generate 64 preambles in each cell.

RACH optimization helps to reduce the Access delays of UEs.

6.3.1 RSI Conflict Detection and Resolution
Depending on the size and coverage of an LTE cell – which in turn dictates the cell’s Zero
Correlation Zone (ZCZ) index – the cell requires one or a contiguous block of Root Sequence
Indices (RSIs) to generate 64 preambles. The specification has defined a total number of 838
RSIs. With a limited number of RSIs available, they will inevitably need to be reused across the
network; however, the reuse should be in such a way that immediate neighbor cells do not use
overlapping RSI blocks.

To the extent possible, this feature will assign non-overlapping blocks of RSIs to immediate
neighbor cells. However, if the available pool is already exhausted, the feature will attempt to
avoid PRACH-PRACH frequency resource overlap between immediate neighbors. This is
accomplished by considering the neighbor cells’ frequency offset values upon RSI assignments.
At registration with the eSON (centralized SON server) system, an LTE cell must provide its
initial RSI assignment. In the event that an RSI conflict (defined as a partial or complete overlap
of RSI blocks between two immediate neighbor cells) is detected, the feature is activated only
at the cell with the higher ECGI, i.e. a new RSI block will be assigned if an RSI block with no
overlap is available.

Inputs Serving Cell:

• Initial RSI assignment
• ZCZ index
• Frequency offset and PUCCH size
Neighbor Cell:
• RSI
• ZCZ index
• Frequency offset
Outputs Serving Cell:
• RSI
6.3.2 Zero Correlation Zone (ZCZ) Optimization
The ZCZ index determines the required number of RSIs to generate 64 preambles in each cell.
This feature monitors the cell’s Random Access procedures and accordingly adjusts the cell’s
ZCZ index – if required. More specifically, the feature collects the timing advance statistics from

Revision 1.0 240-00-0153 46 of 53

 vRAN Introduction Training Guide

each Random Access Response (RAR) based on which it will calculate the cell’s ZCZ index. If the
calculated value is different from the current value, the feature will assign a new ZCZ index to
the cell.

With a higher ZCZ index, a larger number of RSIs is required to generate the cell’s 64 preambles.
Accordingly, in the event the calculated ZCZ index is larger than the current index, the feature
will recalculate the cell’s RSI block. Conversely if the calculated ZCZ index is smaller than the
current index, the feature will enable the release the additional RSIs which can be used for
further allocations to different cells.

Inputs Serving Cell:

• RAR Timing Advance commands
Outputs Serving Cell:
• ZCZ index

6.4 Mobility Load Balancing (MLB)

The objective of load balancing is to distribute cell load evenly among cells or to transfer part of
the traffic from congested cells. This is done by the means of self- optimization of mobility
parameters or handover actions.
Self-optimization of the intra-LTE and inter-RAT mobility parameters to the current load in the
cell and in the adjacent cells can improve the system capacity compared to static/non-
optimised cell reselection/handover parameters. Such optimisation can also minimize human
intervention in the network management and optimization tasks.
Support for mobility load balancing consists of one or more of following functions:

• Load reporting
• Load balancing action based on handovers
• Adapting handover and/or reselection configuration
The goal of eSON MLB feature is to offload excess traffic from a highly loaded home cell to its
lightly loaded neighbor cells by tuning the home cell's Cell Individual Offsets (CIOs). Once the
load of the home cell decreases to a level considered to be no longer highly loaded, the
algorithm reverts the CIOs to their original levels that are prior to the MLB operation.

The algorithm takes care of the following steps:

1. Collect home cell’s Capacity Class Value (CCV*) at startup.

2. Collect home cell’s Capacity Value (CV*) on a periodic basis and exchange the load
information with neighbor cells.

3. Change the state and CIO value according to each cell pair’s (home cell and one of its
neighbor cells) depending on the current state and load information.

Revision 1.0 240-00-0153 47 of 53

 vRAN Introduction Training Guide

4. When CIO is changed at the home cell, a corresponding change may be made to the
neighbor cell’s CIO, depending on the current guard distance between the handover
boundaries of the two cells. This is called pairwise operation.

A heterogeneous network is comprised of types of cells with different sizes, transmit powers
and bandwidths. Load balancing in such network would have to take the capacity disparity
between these cell types into account. In SON terminology this is reflected in what is referred
to as the Capacity Class Value. As an example, if cell type A with the largest bandwidth, highest
transmit power, fastest CPU and largest compute/transport resources has a capacity of 100%,
the other cell types' capacity is scaled down (normalized) with respect to cell type A. As such a
cell with 20MHz would have 4 times the capacity of that of a 5MHz cell. As such the capacity
class value for the former cell type will be defined as 100% and the capacity class value of the
latter cell type will be defined as 25%. And thus, with a uniform traffic distribution and uniform
deployment of the two cell types across the network, the desired load split of 80%-20% can be
achieved.

eSON intra-frequency MLB algorithm is triggered when home cell’s new load information is
received. Upon receiving the home cell’s load information, the algorithm will take the following
actions per neighbor cell, the algorithm decides on
• The state of the cell pair (home, neighbor) and
• The modifications to the relevant mobility parameters that is CIOs.

6.5 Mobility Robustness Optimization (MRO)

The main functionality of Mobility Robustness Optimization (MRO) is to optimize the connected
mode mobility. MRO collects data of HO failures and ping pong HO periodically and the data
collected is used as input for corrective action. The corrective action is expected to improve the
HO performance.

MRO functionality is divided into two blocks: MRO monitoring function and MRO corrective
action function. MRO monitoring function monitors and detects radio link failures that happen
due to a too early handover, too late handover or a Handover to wrong cells. It also detects
ping pong HO which can result in inefficient use of network resources.

The corrective action is periodic and configurable.

Currently Altiostar supports MRO for intra frequency handovers only.

6.6 Multi-Cell Interference Management (MCIM)

Multi-Cell Interference Management (MCIM) is a proprietary real-time downlink interference
management. By exchanging proprietary metrics between neighbor cells, this feature provides
a tight coordination between interfering cells and their respective schedulers which results in
higher spectral efficiencies and better coverage and capacity.

Revision 1.0 240-00-0153 48 of 53

 vRAN Introduction Training Guide

In 3GPP technical specifications terminology, MCIM is a real-time Inter-Cell Interference

Coordination (ICIC) technique for the downlink direction in the frequency domain as part of the
Radio Resource Management (RRM) functions.
The feature is developed based on the idea that cell performance is impacted by both home cell
subband transmit power levels as well as the neighboring/interfering cells’ subband transmit
power levels. As such, proprietary metrics have been defined which quantify these impacts. The
estimates are then exchanged between neighboring cells periodically, after which each cell
calculates how its own power levels (on each subband) impact the total network utility and
accordingly generates a subband mask.
An example subband mask for a system with 20MHz (with 13 subbands) is as follows

The green subbands are recommended for cell edge UE transmissions possibly with power
boosting, and the red subbands (and all remaining unused green subbands) are recommended
for cell center UE transmissions.

Essentially the feature dynamically provides a set of protected set of subbands (‘green’
subbands) with higher SINR levels for the cell edge UEs. This in turn results in a higher
throughput and improved cell edge spectral efficiency.

It is important to note that the number of green subbands is also dynamically adjusted based
on the cell load and the real-time feedback on the UE throughputs. As the cell edge load
increases, a higher number of green subbands are required; conversely as the cell edge load
decreases the number of green subbands is lowered to provide more protection to the
neighboring cells.

The required inputs with their respective desired periodicities are provided below.
Input Parameters
Input parameter Default desired report period
Subband CQI report 80ms per UE
Wideband CQI report 80ms per UE
UE RSRP measurement 5.12s per UE
UE throughput 1s per UE

Accordingly, a subband mask is calculated with a desired periodicity of once every 2 seconds.

Revision 1.0 240-00-0153 49 of 53

 vRAN Introduction Training Guide

6.7 Minimization of Drive Test (MDT)

Data reported from User Equipment’s (UEs) and the eNB is used to monitor and detect
coverage problems in the network and verify Quality of Service, assess user experience from
eNB perspective, and to assist network capacity extension.

There are different types of MDT such as: Immediate MDT, Logged MDT, RCEF and RLF.

6.7.1 Immediate MDT

In Immediate MDT functionality, UE performs the measurements in CONNECTED state and
reporting of the measurements to eNB and eNB performs the measurements for MDT
purposes.

6.7.2 Logged MDT

In Logged MDT functionality, UE performs the measurements in IDLE mode and reporting to
eNB at a later point in time, by E-UTRA UE in IDLE and CONNECTED modes.

6.7.3 RRC Connection Establishment Failure (RCEF)

The RCEF log collected by UE when the RRC connection establishment failure with eNB. This
procedure is applicable only for management based MDT procedure.

6.7.4 Radio Link Failure (RLF)

The Radio Link Failure report contains information related to the latest UE RRC connection
failure with eNB. The connection failure can be Radio Link Failure (RLF) or Handover Failure
(HOF). This procedure is applicable only for management based MDT procedure.

The MDT procedure activation in EUTRAN is divided into two categories; Management MDT and
Signaling MDT. Management MDT activation and deactivation is managed by EMS and Signaling
MDT activation and deactivation is managed by MME.
6.7.5 Management MDT
Management MDT activation from EMS supports following job types. In interface for enabling
the MDT is provided in the below section.
• Immediate MDT only
• Logged MDT only
• Immediate MDT and Trace
• RLF reports only
• RCEF reports only

In eNB, based on the above job type combination, each cell will support maximum of 5
management MDT sessions in parallel. Each cell will not allow repeated or duplicate job types in
parallel.

Revision 1.0 240-00-0153 50 of 53

 vRAN Introduction Training Guide

6.7.6 Signaling MDT

MME will send the signaling MDT activation to using S1AP TRACE START or S1AP INITIAL CONTEXT SETUP
REQUEST or S1/X2 HANDOVER REQUEST UE associated signaling message with the necessary signaling
MDT activation information.

6.7.7 MDT Data

TCP streaming interface is used for transfer of MDT data to trace collection entity.

6.7.8 Configuring and Activating MDT for the selected eNBs through EMS
In EMS, MDT configuration is an extension of Subscriber Trace Configuration. Currently the total
MDT trace recording sessions allowed per job type is 300.

Revision 1.0 240-00-0153 51 of 53

 vRAN Introduction Training Guide

CHAPTER 7: ACRONYMS
7 Acronyms

Term Description
ANR Automatic Neighbor Relations
BH BackHaul
CA Carrier Aggregation
CV Capacity Value
CCV Capacity Class Value
CDC Central Data Center
CFR Call Failure Rate
CIOs Cell Individual Offsets
CoMP Coordinated Multipoint
COTS Commercial Off-The-Shelf
C-RAN Cloud Radio Access Network / Centralized Radio Access Network
DL DownLink
DPD Digital Pre-Distortion
DPDK Data Plane Development Kit
EMS Element Management System
EMSON Element Management Self Organizing Networks
vCU eNB virtual Central Unit
vDU eNB virtual Data Unit
FH FrontHaul
GC Group Center
GPON Gigabit Passive Optical Network
GTP-U GPRS Tunnelling Protocol – User plane
GUI Graphical User Interface
HA High Availability
L1 Layer 1
L2 Layer 2
L3 Layer 3
LOS Line-of-Sight
LTE Long Term Evolution
MAC Medium Access Control
MCIM Multi-Cell Interference Management
MDT Minimization of Drive Test
MLB Mobility Load Balancing
MRO Mobility Robustness Optimization

Revision 1.0 240-00-0153 52 of 53

 vRAN Introduction Training Guide

Term Description
NFV Network Function Virtualization
NIC Network Interface Card
OSS/BSS Operation Support System/ Business Support Systems
PCID Physical Cell Identity
PDCP Packet Data Convergence Protocol
PRACH Physical Random Access Channel
QoS Quality of Service
RH RedHat
RACH Random Access Channel
RLC Radio Link Control
RLF Radio Link Failure
RRC Radio Resource Control
SON Self Organizing Network
SPM Signal Processing Module
UE User Equipment
UL UpLink
VIM Virtualized Infrastructure Manager
VM Virtual Machine
VNF Virtual Network Function
vRAN Virtual Radio Access Network

Revision 1.0 240-00-0153 53 of 53