Solution 1
Solution 1
Solution 1
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.
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
List of Figures
Figure 1: Global Mobile Data Consumption ................................................................... Error! Bookmark not defined.
Figure 2: vRAN Architecture ............................................................................................................................................ 5
Figure 3: vRAN Functional Split ..................................................................................................................................... 5
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.
Integration & validation is performed between Altiostar’s RIU and the operator selected vendor’s RRH
before the deployment of the solution.
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.
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.
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:
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.
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
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.
Below is an example calculation for the OTA bandwidth requirement for one instance of eNB-vDU:
Parameter Value
Number of eNodeB 1
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:
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.
- 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.
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.
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.
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.
- 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.