Cloud Ran Solution Soldescription

Cloud RAN Solution, Solution
Documentation, Q1 2020
Cloud RAN Solution

Description
DN09229892
Issue 2-2

Cloud RAN Solution Description
The information in this document applies solely to the hardware/software product (“Product”) specified
herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective
company within Nokia Group of Companies with whom you have entered into the Agreement (as defined
below).
This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the
purposes defined in the agreement between You and Nokia (“Agreement”) under which this document is
distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form
or means without the prior written permission of Nokia. If You have not entered into an Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this
document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof.
The document has been prepared to be used by professional and properly trained personnel, and You
assume full responsibility when using it. Nokia welcomes your comments as part of the process of
continuous development and improvement of the documentation.
This document and its contents are provided as a convenience to You. Any information or statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an “as is” and “as available” basis in this document, and Nokia reserves the right to change any such
information and statements without notice. Nokia has made all reasonable efforts to ensure that the
content of this document is adequate and free of material errors and omissions, and Nokia will correct
errors that You identify in this document. Nokia's total liability for any errors in the document is strictly
limited to the correction of such error(s). Nokia does not warrant that the use of the software in the Product
will be uninterrupted or error-free.
NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE
CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA BE LIABLE FOR ANY DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS
DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS
FROM THIS DOCUMENT OR ITS CONTENT.
This document is Nokia proprietary and confidential information, which may not be distributed or disclosed
to any third parties without the prior written consent of Nokia.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document
may be trademarks of their respective owners.
Copyright © 2020 Nokia. All rights reserved.
f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this
product and only after having carefully read the safety information applicable to this product.
The safety information is provided in the Safety Information section in the “Legal, Safety and
Environmental Information” part of this document or documentation set.
Nokia is continually striving to reduce the adverse environmental effects of its products and services. We
would like to encourage you as our customers and users to join us in working towards a cleaner, safer
environment. Please recycle product packaging and follow the recommendations for power use and proper
disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia for any additional information.
2 © 2020 Nokia. Nokia confidential. DN09229892 Issue: 2-2
Table of Contents
This document has 43 pages

1 Summary of changes..................................................................... 7

2 Solution introduction.......................................................................8

3 Solution components......................................................................9
3.1 Products and versions in the solution............................................ 9
3.2 AirScale Radio Network Controllers.............................................10
3.3 AirScale 5G Cloud BTS................................................................12
3.4 Data Center HW...........................................................................13
3.4.1 AirFrame servers..........................................................................15
3.5 Nokia AirFrame Cloud Infrastructure for Real-time Applications
(NCIR).......................................................................................... 16
3.6 Switches and routers....................................................................17

4 CloudBand Application Manager (CBAM)....................................19

5 Data Center layout....................................................................... 20
5.1 DC Pods.......................................................................................20
5.2 Spine and super spine................................................................. 20
5.3 Reference configuration............................................................... 20
5.3.1 Edge DC and remote RAP/BTS sites...........................................20
5.3.2 RAP/BTS site close to Edge DC.................................................. 21
5.3.3 Minimum Edge DC configurations................................................22

6 Networking in the Data Center..................................................... 23
6.1 Network fabrics............................................................................ 23
6.2 IP networks.................................................................................. 25
6.3 Dimensioning............................................................................... 27
6.4 Availability.................................................................................... 27
6.5 Properties.....................................................................................27
6.6 DC management networks...........................................................28

7 Management................................................................................ 30
7.1 Fault and performance management........................................... 30
7.2 VNF management........................................................................ 30
7.2.1 Application lifecycle management................................................31
7.3 Data center management.............................................................31
7.4 Radio network management........................................................ 32
7.5 CBAM placement for Cloud RAN................................................. 33

8 Cloud BTS configurations............................................................ 34

9 Data center multi-tenancy............................................................ 35
9.1 DC multi-tenancy concept............................................................ 35
DN09229892 Issue: 2-2 © 2020 Nokia. Nokia confidential. 3
9.2 Shared external networks............................................................ 36
9.3 IP plans........................................................................................ 37
9.4 OpenStack configurations............................................................ 39
9.5 NCIR configurations..................................................................... 39

10 Capacity and dimensioning.......................................................... 41
10.1 Capacity of VNF services.............................................................41
10.2 Dimensioning edge DC capacity.................................................. 42
List of Figures
Figure 1 Cloud RAN Solution components......................................................... 9
Figure 2 AirScale Radio Controllers................................................................. 10
Figure 3 AirScale radio equipment................................................................... 12
Figure 4 AirFrame Rackmount..........................................................................14
Figure 5 AirFrame Open Rack..........................................................................14
Figure 6 High level NCIR architecture.............................................................. 17
Figure 7 Edge DC with remote radio sites........................................................ 21
Figure 8 Edge DC and close radio site............................................................. 21
Figure 9 Edge DC in minimum configuration.................................................... 22
Figure 10 L2 fabric in AirFrame rack.................................................................. 24
Figure 11 L3 fabric in Edge Data Center............................................................ 25
Figure 12 HW management network.................................................................. 29
Figure 13 VNF management.............................................................................. 30
Figure 14 Data Center management.................................................................. 32
Figure 15 Radio Network management.............................................................. 32
Figure 16 CBAM in Cloud RAN.......................................................................... 33
Figure 17 Multi-tenant DC connected to network services................................. 35
Figure 18 External network configuration to edge DC for Cloud RAN elements....
37
List of Tables
Table 1 Products and versions in the solution...................................................9
Table 2 AirScale BSC VNFCs......................................................................... 11
Table 3 AirScale RNC VNFCs......................................................................... 11
Table 4 AirScale 5G Cloud BTS VNFCs......................................................... 12
Table 5 AirFrame OR server vCPU capacity variants..................................... 16
Table 6 AirFrame rack capacity comparison .................................................. 16
Table 7 External networks for Cloud RAN elements....................................... 36
Table 8 Example A: Four small size VNFs in one rack................................... 37
Table 9 Example B: Two medium size VNFs in one rack................................38
Table 10 OpenStack: VNF flavors..................................................................... 39
Table 11 OpenStack: other requirements..........................................................39
Table 12 AirScale BSC capacity steps.............................................................. 41
Table 13 AirScale RNC capacity steps..............................................................41
Table 14 NFVI capacity allocations................................................................... 42
Table 15 CBAM capacity................................................................................... 42

Cloud RAN Solution Description Summary of changes
1 Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
Issue 2-2
Minor editorial changes made.
Issue 2-1
AirScale 4G Cloud BTS removed from the scope.
Issue 2-0
Table Products and versions in the solution updated with the Q2 2019 reference solution
component versions.
Chapter AirScale Radio Network Controllers updated with more information on OMS.
Table AirScale RNC VNFCs updated: AirScale RNC19 ->AirScale RNC20
Table 4G Cloud BTS VNFCs updated: 4G Cloud BTS18A → 4G Cloud BTS19; data
updated
Chapter Availability updated with information on sessions and detection intervals.
Chapter Virtual Network Function (VNF) management updated with CBAM information.
Chapter DC Multitenancy concept updated.
Chapter Dimensioning Edge DC capacity updated with information on spare AirFrame
server capacity. CBAM section was updated. Table AirScale RNC capacity steps
updated.
Editorial modifications throughout the document.

Solution introduction Cloud RAN Solution Description
2 Solution introduction
The Nokia Cloud RAN Solution introduces a tested reference configuration for the Cloud
RAN deployment. The reference blueprint described here can vary in numerous ways
depending on the needs of the operator network, where this reference blueprint can be
used as a base for the planning.

Cloud RAN Solution Description Solution components
3 Solution components
3.1 Products and versions in the solution

The Cloud RAN Solution products and their versions in the current reference
configuration are as follows:
Table 1 Products and versions in the solution
Cloud RAN Solution Q3 2019 – solution component versions
2G VNF AirScale Base Station ASBSC19
Controller
3G VNF AirScale Radio Network ASRNC20
Controller
5G VNF AirScale Cloud BTS-5G 5G19
NetAct Nokia Network / Element NetAct 19
Management System
OMS Operation and Management OMS 19.5
Server
CBAM CloudBand Application CBAM 19
Manager
Infrastructure SW Nokia AirFrame Cloud NCIR19 (RM17 migrated),
Infrastructure for Real-time NCIR19 (OR18, OR19)
Applications
Data Center HW Nokia AirFrame DC Solution NDCS RM17 migrated, OR18,
(NDCS) OR19
NADCM Nokia AirFrame Data Center NADCM19
Manager
Figure 1 Cloud RAN Solution components

Solution components Cloud RAN Solution Description
Although the CloudBand Network Director (CBND) product is available for the VNF and
DC management, the orchestration is not used in this Cloud RAN reference solution.
3.2 AirScale Radio Network Controllers

As cloud products, the AirScale BSC (ASBSC) and AirScale RNC (ASRNC) are
deployed on Nokia Data Center Solution. The scalable AirScale BSC and RNC can be
used for improving the HW utilization at the 2G/3G controller sites, and for the
modernization of the classical BSC and RNC HW.
Figure 2 AirScale Radio Controllers
The AirScale BSC and RNC can control Single RAN BTSs (SBTSs) as well as the GSM
and WCDMA components of the SBTSs. The SBTS can simultaneously provide GSM,
WCDMA and LTE services in one physical BTS.
The Operation and Management Server (OMS) provides mediation and concentration
functions for the AirScale RNC management plane operations. The OMS is typically
placed in the data center for the NetAct, and can be deployed on dedicated server HW,
or in a cloud with Nokia CloudBand Infrastructure (CBIS). The OMS is a single VNFC
service with no scaling in cloud. New OMS instances are created for added capacity.
Each OMS is capable of mediating several AirScale RNCs.
Radio Controller VNF configurations:
Both AirScale RNC and AirScale BSC have different capacity steps to choose from to
instantiate to the selected initial capacity. The final capacity of any of the scalable
components can be scaled out/in after the instantiation once the initial need is changed.
AirScale BSC VNFC configurations, showing the virtual machine types and amounts, are
as follows:

Table 2 AirScale BSC VNFCs
AirScale MIN RD1_BSC RD2_BSC RD3_BSC RD4_BSC MAX
BSC19 1100 3300 5500 8800
OMU1 1 1 1 1 1 1
RRMU1 2 2 2 2 2 2
MCMU1 2 2 2 2 2 2
BCXU2 3 3 7 11 17 17
ETMA2 2 2 3 5 7 7
ETME2 3 3 5 7 10 10
PCUM2 4 4 16 11 34 100*
*) The AirScale BSC PCUM VNFC can scale beyond the largest value used in the initial
RD4_BSC 8800 configuration.
1 Fixed capacity
2Scaled capacity
3 Configured capacity ‘Configured capacity’ means the decision for the capacity or
capability is taken in the instantiation phase and cannot be scaled afterwards.
AirScale RNC VNFC configurations, showing the virtual machine types and amounts, are
as follows:
Table 3 AirScale RNC VNFCs
AirScale MIN RC1 RC2 RC3 MAX
RNC20
SN1 3 3 3 3 3
CFPU1 2 2 2 2 2
CSPU2 2 4 6 12 24*
USPU2 2 15 29 65 77*
EIPU2 2 4 8 16 16
UVM3 0 1 1 1 1
*) The AirScale RNC CSPU and UCPU VNFCs can scale beyond the initial RC3
configuration.
1 Fixed capacity
2Scaled capacity
3 Configured capacity ‘Configured capacity’ means the decision for the capacity or
capability is taken in the instantiation phase and cannot be scaled afterwards.
The minimum and maximum data center resource consumptions of the VNFs are
described in section Capacity and dimensioning.
For more information, see:

• AirScale BSC, Operating Documentation in Discovery Center.

• AirScale RNC, Operating Documentation in Discovery Center.
3.3 AirScale 5G Cloud BTS

The Nokia edge DC with AirFrame Rackmount and AirFrame Open Rack HW and Nokia
AirFrame Cloud Infrastructure for Real-time Applications (NCIR) stack is especially
designed and optimized for the radio network purposes, which enables the best
performance for the Nokia radio products for cloud.
Nokia AirScale Cloud BTS-5G is designed for this data center setup.
In addition to the Cloud BTS VNF, referred to as central unit (CU), the AirScale Cloud
BTS-5G includes its physical distributed unit (DU) for the radio and antenna. In
documentation the DU is also referred to as radio access point (RAP).
The DU
• includes BTS radio and antenna parts and Flexi System Module or AirScale System
Module for the real-time computing.
• is based on the AirScale and Flexi System Modules used for standalone bare-metal
BTS deployments.
The CU is the BTS VNF for the non-real-time computing.
Figure 3 AirScale radio equipment
AirScale Cloud BTS-5G VNF configurations:

AirScale Cloud BTS-5G VNFC configurations, showing the virtual machine types and the
minimum and maximum amount of each VNFC, are as follows:
Table 4 AirScale 5G Cloud BTS VNFCs
5G Cloud BTS19 MIN MAX
OAM3 1 2
CPCL3 1 7
CPNB3 1 2

Table 4 AirScale 5G Cloud BTS VNFCs (Cont.)
5G Cloud BTS19 MIN MAX
UPUE2 1 72
CPUE2 1 35
CPIF3 1 2
CPNRT3 1 2
DB3 1 2
SN3 0 3
UVM3 0 1
1 Fixed capacity
2Scaled capacity
3 Configured capacity which stays for the capacity or capability agreed in the instantiation
phase. The configured capacity cannot be scaled afterwards.
The dual OAM VNFCs enable resiliency within the AirScale Cloud BTS-5G VNF.
The minimum and maximum data center resource consumptions of the VNFs are
described in section Capacity and dimensioning.
For more information, see AirScale Cloud BTS-5G,Operating Documentation in

Discovery Center.
3.4 Data Center HW

The reference solution configuration is implemented with the Nokia AirFrame Data
Center (DC) HW.
The Nokia edge DC with AirFrame Rackmount or AirFrame Open Rack HW and Nokia
AirFrame Cloud Infrastructure for Real-time Applications (NCIR) stack is especially
designed and optimized for the radio network purposes, which enables the best
performance for the Nokia radio products for cloud.
All Nokia Cloud RAN products are designed for this data center setup.
Nokia Cloud RAN Solution products include:
• AirScale BSC
• AirScale RNC
• CU of the AirScale Cloud BTS-5G
• CBAM

Figure 4 AirFrame Rackmount
Figure 5 AirFrame Open Rack
AirFrame Rackmount HW is available in two main configuration variants:
• Standard AirFrame RM
• AirFrame RM migrated
AirFrame RM setup includes:
• 20 compute nodes
• 2 controller nodes
• 2 storage nodes
• 2 data plane ToR switches (leaf switches)
• 2 management plane switches
• An optional HW management switch
• Power units

The RM migrated configuration is designed for use with the NCIR18 release and beyond.
In the migrated configuration used for Cloud RAN deployments a third controller node is
added replacing one of the compute nodes, leaving 19 compute nodes for the
applications.
In the Rackmount verification for the Cloud RAN reference solution described in this
document, the RM17 variant was used with NCIR17 (20 compute nodes and 2
controllers).
The AirFrame Rackmount provides downwards scalability and fits small edge DCs, while
the AirFrame Open Rack provides higher server density per rack and lower power
consumption for efficient scaling the edge DC upwards.
The cloud instance size evolves according to the reference infrastructure evolution, that
is now from one full RM17 rack to one full OR18 rack, and further to multi-rack
infrastructure configurations according to the future roadmap.
The higher cloud instance capacity enhances the capability for multitenancy or enhances
the capability for VNF scaling. An example is the data capacity in AirScale BSC when
PCUM VNFCs are scaled out and the scaling would not anymore be limited by the
availability of HW resources).
The AirFrame OR setup optimized for Cloud RAN VNFs includes:
• 42 compute nodes
• 3 controller nodes
• 2 leaf switches
• HW management switch
• Power units
Similarly to AirFrame RM, based on the needs, you can add more storage nodes also to
the AirFrame OR configuration optimized for Cloud RAN.
For more details, see AirFrame Data Center Solution, Operating Documentation in

Discovery Center. Select the relevant HW release.
3.4.1 AirFrame servers

The AirFrame capacity differs between the Rackmount (RM) and the Open Rack (OR)
due to different rack form factors, which impacts the number of servers that can be
installed in one rack. Within the physical rack form factors, different capacity flavors are
available according to the installed server types:
• RM17 – Broadwell processor microarchitecture
• OR18 – Skylake processor microarchitecture
• OR19 – Cascade Lake processor microarchitecture
The OR19 and OR18 have the same amount of servers in the rack, but the number of
virtual CPUs (vCPUs) is increased with corresponding effects to the rack capacity.
The performance of the Cascade Lake variant is verified with AirScale RNC. Other Cloud
RAN products will follow later with separately announced product releases. The OR19
requires NCIR18 FP3 or a later version for the infrastructure SW.
vCPU capacity
The numbers for full rack deployments are as follows:

Table 5 AirFrame OR server vCPU capacity variants
OR18 OR19
Number of servers compute 42
controller+compute 3
storage+compute 3
Number of vCPUs compute 54 70
controller+compute 40 56
storage+compute 50 66
Total vCPUs in rack 2538 3306
The following table gives a rough vCPU capacity comparison value for different AirFrame
rack variants in relation to RM17 with NCIR17A deployment.
Table 6 AirFrame rack capacity comparison
Rack type Raw vCPU capacity factor
RM17 (ref) 1
OR18 2,54
OR19 3,31
g Note: These figures do not take into account the spare capacity allocation
recommendations for recovery and upgrade purposes (for example, one spare server
and 85% VNFI allocation)
Memory
The memory amount in OR19 is cost- and performance-optimized for Cloud Radio VNF
needs. Although the increased vCPU capacity in the OR19 means the average memory
and VM root disk space for individual VMs decrease, the memory space is adequate and
optimized for the Cloud RAN VNFs.
3.5 Nokia AirFrame Cloud Infrastructure for Real-time

Applications (NCIR)
The Nokia AirFrame Cloud Infrastructure for Real-time Applications (NCIR) is designed
for the high data throughput performance requirements of the Cloud RAN applications.

Figure 6 High level NCIR architecture
For more details regarding the NCIR, see the NCIR Solution Description, section

Overview of NCIR.
3.6 Switches and routers

The routers and switches for the data center are installed in the Nokia AirFrame racks.
Edge router
The edge router provides the transport connections outside the edge DC. It aggregates
the data from the spine layer switches. 2N redundant edge routers are used at the edge
DC site.
The recommended product is Nokia SR7750 router.
Spine switch
The spine switch aggregates the transport traffic from the AirFrame racks within one data
center Pod. 2N redundant spine switches are used in the Pod.
The recommended product is Nokia AO/AR/AE-Z9100ON-A/D.
Leaf switch
The leaf switch aggregates the transport traffic from the installed nodes in an AirFrame
rack. 2N redundant leaf switches are used in the racks.
The recommended product is Nokia AO/AR/AE-Z9100ON-A/D or AO/AR-S4048T-A/D.
HW management switch
The leaf switch aggregates the transport traffic from the installed nodes in an AirFrame
rack. 2N redundant leaf switches are used in the racks.
The recommended product is Nokia AO/AR/AE-Z9100ON-A/D or AO/AR-S4048T-A/D.
RAP/BTS site switch

The radio access point (RAP) and/or BTS site switch aggregates the RAP/BTS data at
the remote site.
Currently the solution does not define a specific type for the switch. The switch is
selected based on the number of RAPs and BTSs at the site.
For more details, see AirFrame Data Center Solution, Operating Documentation in

Discovery Center. Select the relevant HW release.

Cloud RAN Solution Description CloudBand Application Manager (CBAM)
4 CloudBand Application Manager (CBAM)

The lifecycle of the Cloud RAN products is managed with the Nokia CloudBand
Application Manager (CBAM) as the virtual network function manager (VNFM). The role
of VNFM in ETSI MANO architecture is to support VNF lifecycle management
operations.
The CBAM is involved in the VNF creation and deletion, VNF instantiation, scaling and
other programmable custom workflows.
The CBAM can be integrated into the Nokia NetAct for network management functions
and the Nokia CloudBand Network Director (CBND) for network orchestration functions.
The CBAM offers the standard ETSI reference points for the VNF management, and thus
can be integrated to third party network orchestration functions as well.
For more information, see CloudBand Application Manager Operating

Documentation in Discovery Center.

Data Center layout Cloud RAN Solution Description
5 Data Center layout
5.1 DC Pods
An edge Data Center is divided into modular Pods for easy scaling. Each Pod can be
scaled from one to eight AirFrame racks, and new Pods can be created for increasing
the data center capacity.
5.2 Spine and super spine

The DC Pods are connected to a pair of edge routers through spine switches. A Pod of
one to three racks has two spine switches, and when the number of racks within the Pod
increases to four or beyond, four spine switches are installed into the Pod.
Multiple full Pods with four spine switches in each can be connected to the edge routers,
and when the DC grows bigger than this, a super-spine layer of two super-spine
switches are installed to aggregate the cabling from the spine switches to the edge
routers.
5.3 Reference configuration

This chapter describes the reference setup used for the end-to-end Cloud RAN Solution
verification.
The Cloud RAN Solution is built with spine-leaf architecture with Nokia products from the
DC HW to the edge router. The DC (underlay) networking uses L3 routing between the
leaf-spine-edge, and L2 networking between compute hosts and leaf switches (within a
single rack). Overlay networks are not used in the reference solution.
The same network configuration can scale from three nodes to a multi-rack DC site. The
reference network design supports multi-rack physical deployments, but with a single
NCIR stack per rack, within one Pod. In small deployments a full solution with spine layer
is not required, but it is advised to build the networking so that it is easily extensible if
needed afterwards – either due to new VNFs or capacity upgrades for the existing VNFs.
5.3.1 Edge DC and remote RAP/BTS sites

In case the RAP or BTS sites are not located in the immediate proximity of the data
center, the RAP/BTS site or a group of sites are connected to the DC with a router
aggregating the DU and BTS traffic.

Cloud RAN Solution Description Data Center layout
Figure 7 Edge DC with remote radio sites
This is the basic site configuration model from which the other variants are derived.
5.3.2 RAP/BTS site close to Edge DC

When the RAP or BTS sites are close to the DC site, for example in the same building or
campus, and the switches in the DU site, it can be practical to connect the DU site
switches directly to the spine layer in the Edge DC.
This configuration is optimal from the RAP/BTS site investment point of view, while the
site router can be left out from the site.
Figure 8 Edge DC and close radio site

Data Center layout Cloud RAN Solution Description
Typical applications for this site configuration are malls and airports, where the BTS and
RAP sites are in practice in the same building as the data center or nearby.
5.3.3 Minimum Edge DC configurations

In minimum configuration the edge DC contains only one Pod, with one or two racks.
Here the spine layer can be omitted, and the leaf switches are connected directly to the
edge router.
The same alternatives to connect the BTS and RAP sites can be used as in the previous
sections. The aggregation switches in the BTS/RAP site close to the DC can be
connected directly to the edge router of the DC instead of spine switches.
Figure 9 Edge DC in minimum configuration
Note that expanding this kind of configuration in commercial use to a larger DC is more
difficult compared to a DC with spine switches already in place.

Cloud RAN Solution Description Networking in the Data Center
6 Networking in the Data Center

The networking reference setup for the end-to-end Cloud RAN Solution accommodates
all radio VNFs in the scope at the same time, meaning that it applies no matter what type
of VNFs and how many instances of those are deployed. The solution covers the
AirFrame Rackmount and Open Rack variants. RM17 has 2 NICs for VNF usage, while
RM/OR18 and later releases has only one NIC (2 ports) for VNF usage per compute
host. In both cases one NIC is always reserved for infrastructure networks.
Traffic separation is done using separate networks/vNICs. The compute host connectivity
is based on accelerated vSwitch functionality (OVS-DPDK).
IP stacks and usage
Support for networking with IPv4, dual stack IPv4/IPv6 and/or pure IPv6 can be enabled
per product (support varies per product and per interface). For this reference solution
only IPv4 has been verified in this release.
IP allocation rules for each VNF for static vs dynamic IP allocation follow the VNF
specific instructions, but the required subnet/prefix amounts and sizes per shared
network must be large enough to accommodate all needed VNF instances. In a
multitenancy data center the external networks can be shared among the Cloud RAN
VNFs, so the actual number of networks does not grow with the number of VNF
instances. However, the number of IP addresses within the networks will increase.
6.1 Network fabrics

L2 domain in an AirFrame rack
Each AirFrame rack forms an individual L2 domain. There can be identical overlapping
VLANs in different racks, as VLANs are terminated at leaf switches and not visible above
the leaf.
It is recommended to assign unique VLAN ranges for particular uses over the whole Pod
(for example, dedicated VLAN ranges for provider external networks for each rack, like
1000-1100 for the first rack, 1101-1200 for the second, etc.). Thus, the range itself
already tells what the network is used for, and the actual ID tells which rack it is related
to. This eases maintenance and troubleshooting.
The L2 connections between the AirFrame server NICs and leaf switches are bundled
using the Link Aggregation Control Protocol (LACP) to support active-active bonding.
For leaf switch resiliency the leaf switch pairs in the AirFrame rack are configured to a
Multi Chassis Link Aggregation Group (MLAG).

Networking in the Data Center Cloud RAN Solution Description
Figure 10 L2 fabric in AirFrame rack
Figure L2 fabric in AirFrame rack illustrates the AirFrame OR hardware with two NICs

per server node. In AirFrame RM hardware two (4x10Gb) of the three NICs are available
for the applications. 1Gb BMC interfaces are connected to a separate hardware
management switch.
Note that separate storage nodes are not needed for rack configuration for Cloud RAN
products from storage capacity point of view, but the storage functions in the controller
nodes are sufficient.
For more information about networks usage for the infrastructure traffic, see Logical
networks section in the Networking Guide in NCIR Operating Documentation.
Leaf – Spine – Edge L3 fabric

Connections between leaf and spine switches and edge routers form an L3 routing
fabric. Border Gateway Protocol (BGP) is used for dynamic L3 routing, and Bidirectional
Forwarding Detection (BFD) for fast link failure detection in the fabric.

Figure 11 L3 fabric in Edge Data Center
In one rack site there is no need for the spine switches, and leaf uplinks are connected
directly to the edge router. The reference solution includes the spines for easy
extensibility to larger DC site solutions.
Connections and cabling

Within the OR rack, the servers are connected to leaf switches using 100 Gb (4x25 Gb)
breakout cables. In the RM rack 60 Gb (6x10 Gb) is used.
Leaf-spine interconnections are 100 Gb links. Spine-edge connections can be 100 Gb,
40 Gb, 25 Gb or 10 Gb links, depending on the customer requirements for the used
cables and configuration modes.
6.2 IP networks
IP usage for the reference configuration
Dual stack IPv4/IPv6 is configured for the underlay networks. The reference allocation
per Pod (max eight racks) is one /20 IPv4 network and one /96 IPv6 prefix.
The following lists show the Cloud RAN reference allocations. The operator can allocate
more addresses and networks as needed.
IPv4
x.x.0.0 /25 router ids
x.x.0.128 /25 router out of band
x.x.1.0 /24 host management (/28 subnet per one NCIR airframe cabinet)
x.x.2.0 /23 hw management (/26 subnet per one RM18/OR18 airframe cabinet)
x.x.4.0 /23 stack1 ProviderExterrnal subnets (8 x /26)
x.x.4.0 /26 stack1-ext0


x.x.6.0 /23 stack2 ProviderExternal subnets (8 x /26)
IPv6
# stack1 (first IPv6 network block with 117 mask stack, dual stack, 8x
subnets)
2a00:8a00:4000:3804:0:0:0:0/120 cran-pod1-stack1-ext0
# stack1 (second IPv6 network block with 117 mask stack, pure ipv6, 8x
subnets)
#cran-infra networks for one PoD
2a00:8a00:4000:3804:0:3:0:100/120 cran-infra-pod1-p2p (pool for /127
point-to-points)
2a00:8a00:4000:3804:0:3:0:0/120 cran-infra-pod1-routerids (pool for
/128 IPs)
2a00:8a00:4000:3804:0:3:0:1000/116 cran-infra-pod1-host-mgmts (/120 subnet
per one AirFrame cabinet)
2a00:8a00:4000:3804:0:3:0:2000/116 cran-infra-pod1-hw-mgmt (/120 subnet per
one AirFrame cabinet)
Routing
The routing in the L3 fabric is based on the Border Gateway Protocol (BGP).
The following routing principles are used in the reference solution:
• All network devices (edge routers, spine and leaf switches) have their own unique 4-
byte Autonomous System Numbers (ASNs). For easier manageability, it is
recommended to have distinctive AS number ranges for network topology layers
(edges, spines, leaves).
• Links between BGP peers in fabric are configured with /31 and IPv6 /127 point-to-
point addresses.
• IPv4 loopback address is used as BGP router ID.
• All switches have ECMP routing. Virtual Router Redundancy Protocol (VRRP) is
configured as active-active using peer routing.
BGP policy-based routing principles:
• Individual BGP neighbor peer groups are based on IPv4/IPv6 family and neighbor
role (leaf, spine or edge).
• Only IPv4/IPv6 default routes are advertised towards leaf layer.
• IPv4/IPv6 loopback and stack prefixes (including provider, host mgmt and HW mgmt
networks) are leaked out towards backhaul.

• Routes are not aggregated in leaf or spine switches.
• There are unique route maps and prefix lists for IPv4 and IPv6 family.
Racks' subnets are configured at the deployment, so that internal traffic among the racks
is also routed.
6.3 Dimensioning
In the AirFrame OR18 cabinet the compute nodes connect to the leaf switches with
4x25Gb links, which in 42 compute node configuration sums up to 4200Gb. The leaf
switches have 8x100GB uplink connections, which means 1:5,25 aggregation level for
the outgoing traffic from the AirFrame cabinet. This number covers both application traffic
and the internal DC management traffic.
In the AirFrame OR one of the two NICs in the compute nodes is used for the DC
management traffic. While the DC management traffic load is significantly lighter than the
application data traffic load, the effectual aggregation in the leaf layer is much smaller
than the theoretical 5,25 based on NIC capacities.
Much of the traffic within a rack is application internal traffic between the VNFCs (VMs) of
the Cloud RAN elements. While NCIR multi-rack clouds are not supported, this
application internal traffic remains within the cabinet, and does not reach the spine layer
switching. This leaves the aggregated traffic capacity for the real backhaul traffic of the
Cloud RAN services.
Although the switch redundancy in the spine layer takes care of the availability in case
one of the two switches fails, the capacity of the spine layer will suffer. Therefore, it is
recommended to install four spine switches for a data center Pod with more than four
AirFrame cabinets.
6.4 Availability
The router and switch devices are all duplicated in the reference solution for redundancy.
An outage in these devices leads to automatic rerouting. Note that losing a redundant
device still leads to a capacity drop in the networking, and all maintenance actions are to
be scheduled for low traffic hours.
The Bidirectional Forwarding Detection (BFD) is configured according to the size of the
topology, capacity of the network devices and availability requirements. In the solution
reference configuration, 100ms intervals with a multiplier value three are used. However,
the detection interval can be increased to up to 300 ms to increase the number of
sessions if needed.
6.5 Properties
MTU
While the products shall work with default maximum transmission unit (MTU) of 1500B,
performing fragmentation/reassembly when required, the MTUs in the Cloud RAN
Solution should be set as per VNF specific recommendations. The infrastructure
reference setup supports jumbo frames up to the edge router.

QoS
IP header Differentiated Services (DiffServ) is used to classify and mark the IP traffic
(DSCP). This can be set by the originating applications and overwritten by, for example,
virtual switches' compute hosts to harmonize QoS conventions in the network and not
rely/trust on the applications. Active traffic engineering is not required from the underlay.
Transport security
The infrastructure does not provide encryption for the data transfer; the E2E
communications are expected to be secured by applications when required.
In some networks separated networking layers for VNF traffic, VNF management traffic
and infrastructure management traffic may be required. In the Cloud RAN reference
solution, it is expected that the same networking infrastructure (devices, links) are used
for all purposes due to excess cost of providing physical separation. In general, physical
network/traffic separation is in cloud replaced by isolation in virtualized networking –
cloud underlay (not directly accessible by the VNFs) is considered as separation layer,
instead of using physical separation with interfaces and cabling.
In the NCIR the networks are separated logically and physically for performance and
security reasons. External networks belong to a different security zone from internal
ones. Also, provider networks used by VNFs are in a different zone from infrastructure
networks.
6.6 DC management networks

In AirFrame OR18, the 1Gb BMC interface of the compute hosts is connected to a
separate hardware management switch. Similarly, in RM17 there is separate connectivity
for HW management, towards dedicated AR-S3048-A Ethernet switch. The HW
management site network topology is similar for both form factors.
‘Out of Band’ management of switches and routers requires an additional device which
aggregates their management ports and connects them to either dedicated HW
management infra or to the same management spines used for the compute host
management.

Figure 12 HW management network

Management Cloud RAN Solution Description
7 Management
7.1 Fault and performance management

VNF application
The VNF application reports the application layer alarms and performance
measurements directly to NetAct the same way as from the classical bare-metal RAN
products.
NCIR
The alarms and measurements collected in NCIR are not VNF instance specific, but
related to all VNFs within the cloud.
7.2 VNF management

The lifecycle management operations of the Cloud RAN VNFs are executed in the
CloudBand Application Manager (CBAM).
A network orchestrator CloudBand Network Director (CBND) and advanced radio
network management functions in NetAct can be used for the management operations.
In Figure VNF management the CBAM is placed to the edge cloud, but a shared CBAM
instance in the central cloud may be used as well.
In general, from operability point of view it could be more efficient to have centralized
CBAM instance(s). Usually the networking (latency, bandwidth) requirements do not
mandate to co-locate CBAM with the managed VNFs. Typically, it’s the CBAM capacity
that drives the dimensioning.
Figure 13 VNF management

Cloud RAN Solution Description Management
In the solution context, only basic CBAM deployment (non-HA, IPv4, single OAM
networking connecting to VNFs) has been verified. CBAM was deployed in the same
stack as the VNFs. Note that with non-HA setup it is vital to arrange regular backups. For
details, see Administrator Guide in CloudBand Application Manager Operating
Documentation, in Discovery Center.
7.2.1 Application lifecycle management

The VNF lifecycle management (LCM) covers VNF create, instantiate, upgrade, heal,
scale, terminate and delete operations. These operations are managed with the CBAM.
The VNF healing is an automated operation between the CBAM and VNF. The healing
functions are VNF specific.
All VNF types in Cloud RAN support scaling in and out for some of their VNFC types.
These can be initiated manually with the CBAM, or automatically as load or configuration
based on-demand operations depending on the VNF and VNFC capabilities.
NetAct connects to CBAM for enabling centralized scaling. VNF creation, instantiation,
termination and deletion are manual operations in the CBAM UI.
7.3 Data center management

Each HW module in the DC equipment rack is connected to the HW management switch
in the rack. The HW management switch aggregates the HW management traffic and
can be connected to the Nokia AirFrame DC Manager (NADCM). The NADCM provides
HW operations automation and a HW management interface for NetAct for HW
monitoring functions, for example. In smaller edge deployments there may not be a need
for a separate HW management switch.
The Unified Cloud Infrastructure Manager (UCIM) will control the lifecycle management
of the infrastructure SW of the data centers in the network.
The NADCM server and HW management switches will reserve slots in the rack and
must be considered in the DC planning.

Management Cloud RAN Solution Description
Figure 14 Data Center management
7.4 Radio network management

The radio network management for the radio VNFs is based on NetAct (or NSP) as
EMS/NMS.
Figure 15 Radio Network management

Cloud RAN Solution Description Management
The operations and tools for managing the radio networks aspects of the Cloud RAN
elements are in principle identical to those of the bare-metal deployed RAN elements.
The main difference is in the HW management, where in Cloud RAN the HW is not
element specific and is therefore extracted as a separate set of functions from the
management of the virtual network element.
Typically, the NE deployment in cloud or in bare-metal is not visible in the radio network
(RNW) operability functions.
The OMS is used for the mediation functions of the AirScale RNC.
The AirScale RNC and AirScale BSC are connected to the same BTS types and
versions as in classical controller deployments.
The radio network management relation to ONAP is not covered in this description yet
but will be added to later issues.
7.5 CBAM placement for Cloud RAN

CBAM for edge DC VNF instances can be in a remote central cloud or distributed to the
edge clouds with the Cloud RAN instances.
One motivation for the CBAM distribution is the limitation on the number of VNFC
instances, or VMs, that one CBAM instance can practically manage. This limit can easily
be exceeded in an edge DC. Having several CBAM instances for the Cloud RAN VNF
management allows the distribution of the VNFM functions to the edge DC sites.
Figure 16 CBAM in Cloud RAN
Placing the CBAM for Cloud RAN VNF control in the central DC suits small Cloud RAN
networks and trialing. In distributed edge DC sites with several VNF instances (VNFI), a
more practical location for the CBAM may be in the edge DC clouds controlling the local
VNFs. In a small edge DC with only a few VNFIs, the CBAM in another edge cloud can
be shared as in Figure CBAM in Cloud RAN.
Consider also the setup for the network management – distributed CBAM deployments
enable access to the CBAM locally, while the access to services in the central cloud may
be restricted for security reasons.

Cloud BTS configurations Cloud RAN Solution Description
8 Cloud BTS configurations

With System Module DU
The current configuration for the AirScale Cloud BTS-5G contains central units (CU) as
Cloud BTS VNFIs in the edge cloud with a fronthaul connection to the distributed units
(DU). A generic term used in some instances for the DU is radio access point (RAP).
All-in-Cloud configuration
The All-in-Cloud configuration introduces a further functional split of the DU to a
virtualized function and physical function. The virtualized function is instantiated in a far
edge cloud, and is connected to the physical radio site, and to the CU in edge cloud.

Cloud RAN Solution Description Data center multi-tenancy
9 Data center multi-tenancy
9.1 DC multi-tenancy concept

The data center multi-tenancy enables deployment of different Cloud RAN element VNFs
in one cloud sharing the same DC HW and infrastructure. While in a typical network
setup, the AirScale RNC and AirScale BSC are deployed in one physical DC site, and
the AirScale Cloud BTS-5G in another, it is also possible to have all these Cloud RAN
elements to share a common DC HW and cloud.
However, note that the co-location of all the radio access technology VNFs in one
physical cloud is a theoretical setup for the reference configuration. This may not be
feasible for a practical deployment in a live network with the coverage redundancy
between radio access technologies.
In a DC multi-tenancy the operating costs of the DC and infrastructure maintenance are
shared between the Cloud RAN elements. In this setup it is economical to concentrate
the Cloud RAN functions to regional sites for maximizing the benefits.
Another benefit comes from the resource sharing. If the traffic increases in some parts of
the network, while the traffic in another segment goes down, the Cloud RAN services for
those areas can be scaled accordingly for maximizing the DC capacity usage. There is
no need to reserve maximum HW capacity for all the elements and service areas
separately.
By sharing the external VNF networks, the configuration of the DC for the VNF becomes
simpler.
The multi-tenant DC configuration may host different Cloud RAN VNF types, and multiple
VNF instances of each VNF type.
Figure 17 Multi-tenant DC connected to network services
The virtual network function components (VNFCs) of each VNF can be divided into and
used in all the compute nodes within the same Nokia AirFrame Data Center Solution
(NDCS) hardware. The number of possible tenants depends on the VNF size and type of
used hardware.

Data center multi-tenancy Cloud RAN Solution Description
The Cloud RAN reference solution does not use Availability Zones or host aggregates
and relies only on per-VNF anti-affinity rules in OpenStack to avoid placing redundant
units (VMs) to the same compute hosts.
DC multi-tenancy does not need a separate procedure for activation. When the feature is
available for the operator, it allows to use multi-tenancy with all its benefits.
9.2 Shared external networks

The reference setup uses shared external networks for VNFs to reduce network
configuration complexity and total amount of needed resources, such as IP addresses
and VLANs. This means that the external OAM, fronthaul and backhaul networks are
shared between all VNFs, while unique internal networks are created per each VNF
instance.
In the reference setup, CBAM is connected to the VNFs via an OAM network.
Table 7 External networks for Cloud RAN elements
Network name ASBSC ASRNC 5G cBTS
extnet-vlan-0 oam, omusig oam oam
extnet-vlan-1 aoip uplane1 (Iu-CS) -
extnet-vlan-2 Gp uplane2 (Iu-PS) backhaul_up0_net
extnet-vlan-3 - uplane3 (Iur) -
extnet-vlan-4 trxsig, pabis uplane4 (Iub) fronthaul_net,
fronthaul_up_0,
fronthaul_up_1
extnet-vlan-5 sigtran-1 cplane1 backhaul_cp_net

extnet-vlan-6 sigtran-2 cplane2 -
extnet-vlan-7 monitor monitor -
The logical network names do not include the data type carried in the network or product
specific indices, since they vary between the products, and could easily cause confusion
and misunderstanding.

Figure 18 External network configuration to edge DC for Cloud RAN elements
In addition to the external networks shown above, each Cloud RAN VNF uses a set of
VNF specific internal networks for internal data exchange between the VNFCs (VMs) of
the VNF instance. These networks become automatically created in the VNF creation.
NTP
The OAM network (extent-vlan-0) is used for the NTP, except in the ASBSC19 the
monitoring network (extent-vlan-7) is used for this purpose.
SCTP multi-homing
Two separate C-plane transport interfaces can be used for Stream Control Transmission
Protocol (SCTP) multi-homing configuration. Multi-homing can improve network
resilience at transport layer for the control plane.
9.3 IP plans
Typically a /26 subnet is reserved for each external network for the Cloud RAN VNFs.
Hovever, in large configurations the amount of IP addresses of a /26 subnet may be
exceeded in some external networks, and a second /26 subnet, or a larger /25 subnet
may be required.
In tables below, in the example A, /26 subnets are sufficient for all external VNF
networks, while in the example B, the extnet-vlan-7 for monitoring connections grows
beyond the /26 subnet address space, and a /25 network is required.
Table 8 Example A: Four small size VNFs in one rack
NVF configurations Amount External networks (IPs)
Amount: extnet-vlan-x
0 1 2 3 4 5 6 7
ASRNC RC1 1 4 12 8 8 8 8 8 25

Table 8 Example A: Four small size VNFs in one rack (Cont.)
NVF configurations Amount External networks (IPs)
RC2
RC3
ASBSC RD1 2 16 4 8 20 16 16 34
RD2
RD3
RD4
cBTS5G Non HA 1 1 14 9 2
Min HA
Max HA
TOTAL 21 16 30 8 37 26 24 59
Subnet /27 /27 /26 /28 /26 /26 /27 /26

size
needed
Table 9 Example B: Two medium size VNFs in one rack
NVF Amount External networks (IPs)
configurations
Amount: extnet-vlan-x
0 1 2 3 4 5 6 7
ASRNC RC1
RC2 1 4 24 16 16 16 16 16 45
RC3
ASBSC RD1
RD2 1 16 3 16 28 16 16 36
RD3
RD4
cBTS5G Non
HA
Min
HA
Max
HA
TOTAL 20 27 32 16 44 32 32 81
Subnet size /27 /27 /26 /27 /26 /26 /26 /25

needed
AirFrame OR18 rack is used in the examples above, although the subnet sizes do not
directly depend on the used rack type.

The OR19 with its increased vCPU capacity enables more and bigger VNF instances to
share the same cloud. While the number of VNFCIs increases correspondingly, also the
consumption of IP addresses in the external networks increases. Therefore, with the
OR19 the recommended subnet size (/26) may easily be exceeded. As in the example in
the table above, even in an OR18 rack with this specific configuration the subnet size
recommendation in the extnet-vlan-7 must be exceeded.
9.4 OpenStack configurations

In order to avoid any zoning needs, some OpenStack configurations must be common to
all VNFs – for example hugepage sizes (BIOS setting in compute nodes).
The tables below show various aspects what the VNFs require/use from the VIM. As a
summary, the VNFs use infra in quite a uniform manner. The main difference is the use
of hyperthreading (in guest VMs).
Table 10 OpenStack: VNF flavors
hw:cpu_polic hw:cpu_thread Hugepage AZs or host
y s_policy size aggregates
(hw:mem_p RM17 only: for VM
age_size) CPU models placement
supported
(hw:cpu_mod
el)
ASRNC dedicated prefer large hw:cpu_model Not needed

='Haswell'
(newer ones
can also be
used!)
ASBSC dedicated prefer 2048 Not needed
(ncir17a),
large
(ncir18)
5G cBTS dedicated isolate large Not needed
Table 11 OpenStack: other requirements
VNF tagged SR-IOV Anti-affinity Hyper-threading
VLAN trunk (server-groups) (host)
ASRNC no no 2 supported
ASBSC no no 2 supported
5G cBTS no no 4 supported
9.5 NCIR configurations

NCIR18 template file

The NCIR has one installation file (/opt/nokia/userconfig/user_config.yaml), and thus one
setup to cater for all its VNF tenants. Without separate zones, the environment has to be
able to accommodate the VNF with the highest demands. Mostly the content of the
configurations recommended for the products is similar with only a couple of differences.
NCIR18 template file / performance profiles section

The “performance profiles” section contents shown below are for ASRNC and ASBSC.
AirScale Cloud BTS-5G does not yet officially support NCIR18, but the file used in tests
for the reference solution described in this document has only 2 vCPUs for ovs_dpdk.
Here the ASRNC and ASBSC configuration is used, but this is not expected to cause
functional issues. Any consequences would be revealed in performance testing (or
density with regards to memory allocations).
OR18
dpdk_profile_compute:
default_hugepagesz: 1G
hugepagesz: 1G
hugepages: 160
platform_cpus:
numa0: 1
numa1: 0
ovs_dpdk_cpus:
numa0: 2
numa1: 2
RM17” compute
performance_compute_dpdk:
hugepagesz: 1G
hugepages: 112
platform_cpus:
numa0: 1
numa1: 0
ovs_dpdk_cpus:
numa0: 1
numa1: 1
RM17” controller+compute
performance_concompute_dpdk:
hugepagesz: 1G
hugepages: 80
platform_cpus:
numa0: 4
numa1: 4
ovs_dpdk_cpus:
numa0: 1
numa1: 1

Cloud RAN Solution Description Capacity and dimensioning
10 Capacity and dimensioning
10.1 Capacity of VNF services

The selecting of the Cloud RAN VNF configuration depends on the traffic profiles
expected in the network. These profiles vary depending on the geographical location of
the BTS or RAP sites, and the expected behavior with the mobile devices. For details,
see Cloud RAN product specific dimensioning guidelines.
Regardless of the initial configuration for the VNF, the VNF can scale depending on the
current traffic demands. Therefore, the maximum expected or allowed VNF size shall be
considered in the DC capacity dimensioning.
Capacity step selection
The Cloud BTS is instantiated with one fixed initial capacity, which is scaled out once the
traffic amount exceeds the capacity of the current VNF setup. In the Cloud BTS there is
no direct linkage between the number of cells or connected DUs to the number of
required scalable VNFCs.
Although the ASBSC and ASRNC provide scaling capabilities as well, they can be
instantiated with a specific initial capacity size already closer to the planned capacity
need.
The capacity step of an AirScale BSC is selected based on the number of TRXs and
PCU channels for GPRS/EDGE, as well as the planned user and control plane capacity,
throughput and external connectivity needs.
Table 12 AirScale BSC capacity steps
AirScale BSC19 TRX PCU Ch for GPRS/EDGE
RD1_BSC 1100 1100 4 864
RD2_BSC 3300 3300 24 576
RD3_BSC 5500 5500 16 384
RD4_BSC 8800 8800 54 016
The capacity step of an AirScale RNC is selected based on WBTSs and WCELs, the
capacity allocations for the CSPU VNFCIs, and planned user and control plane capacity,
throughput and external connectivity needs.
Table 13 AirScale RNC capacity steps
AirScale RNC20 WBTS WCEL
RC1 528 2640
RC2 1320 6600
RC3 2000 10000

Capacity and dimensioning Cloud RAN Solution Description
10.2 Dimensioning edge DC capacity

The edge DC for the Cloud RAN elements is planned based on the type, configuration
and number of the element instances affecting the computing and storage needs in the
DC.
The second important nominator for the planning is the size of switching required for the
VNF instances. Each interface in the VNF types has its own capacity requirements, and
due to traffic separation requirements, also the number of external interfaces for each
VNF type needs to be considered in the DC design.
The third aspect affecting the DC dimensioning is the planned user plane throughput and
control plane traffic.
The DC recovery actions and application upgrade procedures are based on available
spare AirFrame server capacity. The spare capacity is used to rehome the services from
a server with maintenance actions or a fatal failure as well as for rolling upgrade of the
infrastructure and application software.
The recommended spare capacity in an AirFrame rack is one spare server and
maximum 85% capacity usage allocation for the applications.
For more information, see the planning and dimensioning guides of the Cloud RAN
products.
The capacity numbers are element version specific.
Table 14 NFVI capacity allocations
AirScale BSC AirScale RNC 5G Cloud BTS CBAM
VCPUs Min 34, Max 680 Min 212, Max 804 Min 28, Max 372 8
Memory Min 176 GB, Max Min 316 GB, Max Min 78 GB, Max 32 GB
904 GB 1156 GB 916 GB
Storage Min 372 GB, Max Min 286 GB, Max Min 240 GB, Max 300 GB
747 GB 986 GB 2520 GB
(Non-HA
configuration)
In DC planning the maximum infrastructure resource utilization must not exceed 80-85%
of the maximum capacity. See product documentation for the detailed limitations.
CloudBand Application Manager
Table 15 CBAM capacity
CBAM capacity
50 Vims
1000 VMs
50 VNFIs
250 VMs/VNFI
16 parallel LCM operations

Cloud RAN Solution Description Capacity and dimensioning
The CBAM capacity limits the practical number of Cloud RAN VNF instances. Depending
on the configuration, several CBAM instances may be required to manage the VNF
instances at an edge cloud site.
To reserve enough capacity for VNF runtime LCM operations, such as scaling, it is not
advisable to connect too many VNFs to one CBAM.
For example, one large configuration of the AirScale Cloud BTS-5G alone may require
up to 128 VMs. This means maximum eight such 5G Cloud BTS instances for one
CBAM.
Note also that only one LCM operation for each VNF is allowed at a time.
In this example, the scaling capability introduces the limiting factor for the number of
VNF instances for one CBAM – regardless of the size of the AirScale Cloud BTS-5G
configuration.
When the CBAM is in the edge DC for the RAN VNFs, the processing needs of the
CBAM must be considered in the DC planning.
For more details, see Capacity Statement in CloudBand Application Manager

Operating Documentation in Discovery Center.
Switches and routers

The edge routers, spine and management switches are placed in the AirFrame racks
and occupy one-unit space in the rack. The racks with these routers and switches have
therefore less room for the control, computing and storage units for the radio services.

Cloud Ran Solution Soldescription

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cloud Ran Solution Soldescription

Uploaded by

Copyright:

Available Formats

Cloud RAN Solution, Solution

Cloud RAN Solution

f Important Notice on Product Safety

3.1 Products and versions in the solution

3.2 AirScale Radio Network Controllers

• AirScale BSC, Operating Documentation in Discovery Center.

3.3 AirScale 5G Cloud BTS

AirScale Cloud BTS-5G VNF configurations:

For more information, see AirScale Cloud BTS-5G,Operating Documentation in

3.4 Data Center HW

For more details, see AirFrame Data Center Solution, Operating Documentation in

3.4.1 AirFrame servers

3.5 Nokia AirFrame Cloud Infrastructure for Real-time

For more details regarding the NCIR, see the NCIR Solution Description, section

3.6 Switches and routers

RAP/BTS site switch

For more details, see AirFrame Data Center Solution, Operating Documentation in

4 CloudBand Application Manager (CBAM)

For more information, see CloudBand Application Manager Operating

5 Data Center layout

5.2 Spine and super spine

5.3 Reference configuration

5.3.1 Edge DC and remote RAP/BTS sites

5.3.2 RAP/BTS site close to Edge DC

5.3.3 Minimum Edge DC configurations

6 Networking in the Data Center

6.1 Network fabrics

Figure L2 fabric in AirFrame rack illustrates the AirFrame OR hardware with two NICs

Leaf – Spine – Edge L3 fabric

Connections and cabling

x.x.5.192 /26 stack1-ext7

6.6 DC management networks

7.1 Fault and performance management

7.2 VNF management

7.2.1 Application lifecycle management

7.3 Data center management

7.4 Radio network management

7.5 CBAM placement for Cloud RAN

8 Cloud BTS configurations

9 Data center multi-tenancy

9.1 DC multi-tenancy concept

9.2 Shared external networks

extnet-vlan-5 sigtran-1 cplane1 backhaul_cp_net

Subnet /27 /27 /26 /28 /26 /26 /27 /26

Subnet size /27 /27 /26 /27 /26 /26 /26 /25

9.4 OpenStack configurations

ASRNC dedicated prefer large hw:cpu_model Not needed

9.5 NCIR configurations

NCIR18 template file / performance profiles section

10 Capacity and dimensioning

10.1 Capacity of VNF services

10.2 Dimensioning edge DC capacity

For more details, see Capacity Statement in CloudBand Application Manager

Switches and routers

You might also like