Technical Document

vRAN Solution Technical Description

Release 1.0
Revision 1.0

© 2018

200 Ames Pond Drive | Tewksbury, MA 01876 | Office: 855.709.0701 | Fax: 978.482.0636
WWW.ALTIOSTAR.COM
 vRAN Solution Technical Description

Copyright
© Altiostar Networks, Inc. 2018. 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 Release 2.5 2 of 14

 vRAN Solution Technical Description

Table of Contents
1 Introduction .......................................................................................................Error! Bookmark not defined.
2 vRAN Solution Description ....................................................................................................................... 5
2.1 Architecture ................................................................................................................................................5
2.2 eNB Functional Split..................................................................................................................................5
2.3 Functional Components............................................................................................................................6
rd
2.3.1 3 party RRH (Remote Radio Head) & Antenna ............................................................................................... 6
2.3.2 RIU (Radio Interface Unit) .................................................................................................................................... 6
2.3.3 eNB-vDU (eNB virtual Distributed Unit) .............................................................................................................. 6
2.3.4 eNB-vCU (eNB virtual Centralized Unit) ............................................................................................................. 7
2.4 Transport Requirements ...........................................................................................................................7
2.4.1 Midhaul network ..................................................................................................................................................... 7
2.4.2 Fronthaul network .................................................................................................................................................. 8
3 Capacity & Dimensioning Detail ............................................................................................................... 9
4 vEMS ........................................................................................................................................................... 10

Revision 1.0 Release 2.5 3 of 14

 vRAN Solution Technical Description

List of Figures
Figure 1: Global Mobile Data Consumption ................................................................... Error! Bookmark not defined.
Figure 2: vRAN Architecture ............................................................................................................................................ 5
Figure 3: vRAN Functional Split ..................................................................................................................................... 5

Revision 1.0 Release 2.5 4 of 14

 vRAN Solution Technical Description

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

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

Figure 1: vRAN Architecture

1.2 eNB Functional Split

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

Figure 2: vRAN Functional Split

Revision 1.0 Release 2.5 5 of 14

 vRAN Solution Technical Description

1.3 Functional Components

1.3.1 3rd party RRH (Remote Radio Head) & Antenna
RRH (Remote Radio Head) & 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 CPRI (Common Public Radio Interface).

Integration & validation is performed between Altiostar’s RIU and the operator selected vendor’s RRH
before the deployment of the solution.

1.3.2 RIU (Radio Interface Unit)

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 & de-compression of frequency domain IQ symbols to/ from eNB-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 using GPS antenna
- Synchronization of the local frequency using 1588v2 PTP 8265.1 telecom profile, in the absence
of GPS antenna
- Support for phase & frequency holdover when the primary source of synchronization, i.e. GPS
antenna, fails
- Support for upto 4 external alarms inputs, for receiving & relaying the alarms generated by the
cell-site based equipment
Using CPRI it interfaces with RRH and using Altiostar’s IPC (Inter Process Communication) (over
Ethernet) it interfaces with eNB-vDU VNF.

1.3.3 eNB-vDU (eNB virtual Distributed Unit)

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

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

- LTE-RLC (LTE L2 functionality)

Revision 1.0 Release 2.5 6 of 14

 vRAN Solution Technical Description

- 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 eNB-vCU VNF.

Number of RIUs, which can be served by a single instance of eNB-vDU VNF, are determined based on the
deployment requirement and allocation of the virtual resources to the single instance of eNB-vDU VNF.

1.3.4 eNB-vCU (eNB virtual Centralized Unit)

eNB-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 eNB-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 & performance counters/ KPIs towards vEMS
- Receiving configuration changes from vEMS and enforcing the same
Using Altiostar’s IPC (over IP/ Ethernet) it interfaces with eNB-vDU. It interfaces with EPC (Enhanced
Packet Core) functions over 3GPP based S1 interface & other eNBs over 3GPP based X2 interface.

Number of vDU-VNF instances, which can be served by a single instance of eNB-vCU VNF, are
determined based on the deployment requirement and allocation of the virtual resources to the single
instance of eNB-vCU VNF.

1.4 Transport Requirements

1.4.1 Midhaul network
1.4.1.1 Latency Requirement
Altiostar’s vRAN solution can tolerate upto 50 msec of latency + jitter for the midhaul transport network,
i.e. between eNB-vCU and eNB-vDU, without any significant impact on the performance.

1.4.1.2 Bandwidth Requirement

Altiostar’s IPC between eNB-vCU and eNB-vDU contributes to approximately 20% of overhead and
hence, the general requirement for the midhaul transport bandwidth is approximately 20% on top of

Revision 1.0 Release 2.5 7 of 14

 vRAN Solution Technical Description

LTE OTA (Over The Air) bandwidth requirement. The LTE OTA bandwidth requirement of an eNB-vCU
instance is governed by the number of sectors served by one instance of the eNB-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 eNB-vCU:

- 4T4R 20 MHz FDD

- 12 sectors served by one instance of eNB-vCU
- DL 256 QAM and UL 64 QAM support
- DL throughput
o Peak DL throughput/ sector = 380 Mbps
o Peak DL throughput/ eNB-vCU = 12 * 380 = 4.560 Gbps
o Average (estimated) DL throughput/ sector = 133 Mbps
o Average (estimated) DL throughput/ eNB-vCU = 12 * 133 = 1.596 Mbps
- UL throughput
o Peak UL throughput/ sector = 75 Mbps
o Peak UL throughput/ eNB-vCU = 12 * 75 = 900 Mbps
o Average (estimated) UL throughput/ sector = 33 Mbps
o Average (estimated) UL throughput/ eNB-vCU = 12 * 33 = 396 Mbps
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 & syslogs, etc.

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.

1.4.2 Fronthaul network

1.4.2.1 Latency Requirement
Altiostar’s vRAN solution can tolerate upto 250 usec of latency + jitter from the eNB-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, e.g. 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

Revision 1.0 Release 2.5 8 of 14

 vRAN Solution Technical Description

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.

1.4.2.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 eNB-vDU instance is governed by the number of sectors
served by one instance of the eNB-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 eNB-vDU:

- 4T4R 20 MHz FDD

- 6 sectors served by one instance of eNB-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
- Per 6-sector bandwidth requirement = 1.2 * 6 = 7.2 Gbps
Based on the above calculation, the fronthaul transport network bandwidth requirement per eNB-vDU
instance can be derived.

1.5 Dimensioning & Capacity Detail

1.5.1 General
The virtual resources, in terms of processing power required for the eNB-vCU and eNB-vDU depends
upon multiple factors such as, number of LTE carriers, bandwidth for each of the LTE carrier, type of the
x86 processor used, etc. For the dimensioning detail, following radio & 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 eNB-vDU only): 2 * Intel Vista creek FPGA acceleration (one /
socket). Each Vista Creek to have 2x25G
1.5.2 Resource Requirements: eNB-vCU
Each instance of eNB-vCU will require 4 pCPUs for supporting upto 12 sectors of 4T4R 20 MHz FDD
radio.

1.5.3 Resource Requirements: eNB-vDU

Each instance of eNB-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.

1.5.4 Capacity Information

Following table provides capacity information for one eNodeB, which consists of a single instance of
eNB-vCU and two instances of eNB-vDU.

Revision 1.0 Release 2.5 9 of 14

 vRAN Solution Technical Description

Parameter Value

Number of eNodeB 1

Number of eNB-vCU VNF instance 1

Number of eNB-vDU VNF instance 2

Total number of sectors supported 12

Max number of RRC connected users 700

per sector

Max number of VoLTE users per 256

sector

Sector Throughput with Max number DL: ~120 Mbps; UL: ~40 Mbps
of RRC connected UEs

2 vEMS
2.1 Introduction
Altiostar vEMS 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. It is a standards compliant system, with a strong set of applications for delivering
Element Management System solutions for Altiostar eNodeB devices. It includes comprehensive FCPS
capabilities, 3GPP IRP for OSS integration and scripting support.

Altiostar vEMS implements a high availability architecture and design. “High Availability” is one of the
key requirements of any network management system.

Fault and performance measurement functions are always on, receiving notifications and performance
data from eNodeBs in its domain. If vEMS is down for a certain amount of time, it can recover the data
from eNodeBs when it comes back online. However, in the interest of monitoring the network and
identifying any issues at the earliest, vEMS should minimize the downtime.

2.2 Architecture
Altiostar vEMS has a tiered and modular architecture where client, server and data are separated with
well-defined interfaces. The vEMS client can be loaded remotely in an internet browser. For a large
network (1000s of sectors), application server and data layers could be deployed on separate nodes in a
fully redundant configuration. The vEMS consists of following components:

2.2.1 Web Client

Altiostar vEMS GUI is a web application that can be accessed using any of the well-known web browsers.
It provides GUI for all vEMS and eNodeB functions. It connects to BE over HTTP.

Revision 1.0 Release 2.5 10 of 14

 vRAN Solution Technical Description

2.2.2 Backend Server (BE)

The backend server is an application server that drives the vEMS web client and other business logic. It
performs core, server side network facing functionality tasks, such as inventory collection, maintenance
of managed objects, receiving and processing notifications and status polling.

All the BE tier modules support authorization and audit, so that it is easy to trace the various
administrative operations that result in provisioning, reconfiguration, etc.

2.2.3 Remote Agent (RA)

Remote Agent server is responsible for processing Altiostar eNodeB performance data, calculating KPIs,
monitoring and raising performance threshold alarms and 3GPP PM XML export.

2.2.4 Database (DB) Server

The vEMS uses PostgreSQL relational database server to persist the data. All vEMS data (notifications,
statistics, reports, audit, etc.) and configuration (vEMS and eNodeB configuration, tasks, policies, etc.)
are stored in database.

2.2.5 File Server (FS)

File server is an essential component of the vEMS. The eNodeB’s FTP the performance data to the file
server which is later picked up by the remote agent for processing. File server is also used as storage for
backup files. vEMS uses VSFTP server as the File Server component. This serves the following purposes,

- Stores PM files pushed to vEMS by the eNodeB’s. PM files are stored, by default, for 2 days after
processing at vEMS. The processed data is stored in the database.
- Stores 3GPP PM XML exports. These files are stored, by default, for 2 days.
- vEMS backups – The vEMS backs up configuration and data on a daily basis. Configuration is a
full backup while data is backed up in an incremental manner where each backup contains
previous day’s data.
- Latest two configuration backups are retained. Data backups are retained for 30 days. Please
refer to vEMS backup/restore document for further details.
- File server access is made available via a proxy service running on the BE node.

2.3 High Availability Support

2.3.1 High Availability Architecture
If the network is large and involves multiple inter-networks, there will be a need to distribute the
operations of the vEMS and ensure high availability. The high availability architecture of the vEMS
addresses this need by splitting BE and DB+RA+FS servers into different nodes.

The high availability architecture supports a fully redundant configuration.

Figure 3: Highly Available Deployment

Revision 1.0 Release 2.5 11 of 14

 vRAN Solution Technical Description

Management
Floating IP
(BE NBI)

BE BE

Signaling
Floating IP
(BE SBI)

DB DB
Data
Replication
RA & File RA & File
Server Server

Private
Floating IP
(Data NBI)
Statistics
Notification
Mgmt API s
Req/Resp
eNBs
…

High availability is achieved by deploying vEMS application and data services in separate nodes in a fully
redundant configuration.

In this setup, the vEMS functions are split as follows,

 BE Node – This runs vEMS BE server

 Data Node – This runs vEMS RA, DB and File servers.
Each node has a redundant pair setup in Master-Slave configuration. BE and Data node failovers are
independent of each other. BE and Data nodes have different failover mechanisms. Data node needs to
deal with large data sets and employs replication procedures to synchronize data across master and

Revision 1.0 Release 2.5 12 of 14

 vRAN Solution Technical Description

slave nodes. And, also due to this fact data node needs to go through a recovery procedure, where it
pulls data from the master node, before it is available for failover again.

2.3.2 BE Node Failover

Primary and Standby BE servers are redundant configurations designed to serve the same functionality.
They both have access to the same data node. When primary server fails or is brought down, the
standby server takes over the functions that were being performed by the primary. The primary server
may be brought down for scheduled maintenance.

2.3.3 Data Node Failover

Similar to BE node, Primary and Standby Data nodes are redundant configurations designed to serve the
same functionality. When primary server fails or is brought down, the standby server takes over the
functions that were being performed by the primary. The primary server may be brought down for
scheduled maintenance.

The data node stores all vEMS data and configuration. It runs the following services,

1. Database (DB)
2. File Server (FS)
3. Remote Agent (RA)
4. Database HA Pool (pgpool)
Unlike BE node failover, data node failover take a layered approach. Here database is fronted with a
high availability database pool middleware (pgpool) that runs in Master/Slave configuration. The EMS
databases on primary and standby node are added to pgpool. Pgpool elects one database as the primary
and enables write operations for that node. Pgpool load balances database read operations between
primary and standby databases to improve database performance.

BE server connects to Data node services using the Data node NBI, which is a floating IP on the vEMS
private network.

2.4 Dimensioning & Capacity Detail

2.4.1 General
The virtual resources, in terms of processing power, storage required for the vEMS depends upon
multiple factors such as, storage required for number of days, type of the x86 processor used, etc. For
the dimensioning detail, following Intel Architecture based server specifications are considered:

- Server specification:
o Processor: 2 * Skylake SP-Gold 6148 (20 cores @ 2.4 GHz)
- Storage requirement:
o 30 days’ long data storage
2.4.2 Resource Requirements
Each instance of vEMS will require upto 80 pCPUs and upto 24 TB of usable storage for supporting upto
5000 LTE sectors in high availability configuration.

Revision 1.0 Release 2.5 13 of 14

 vRAN Solution Technical Description

Revision 1.0 Release 2.5 14 of 14