CMM Nokia Capacity

No further reproduction or networking is permitted. Distributed by Nokia.
Copyrighted material licensed to [email protected] on 20-01-2023.

Cloud Mobility Manager, Release
22, Operating Documentation, v. 1
Capacity
DN271043343
Issue 4-0
© 2021 Nokia. Nokia Condential Information
Use subject to agreed restrictions on disclosure and use.

Capacity
Nokia is committed to diversity and inclusion. We are continuously reviewing our customer
documentation and consulting with standards bodies to ensure that terminology is inclusive
and aligned with the industry. Our future customer documentation will be updated
accordingly.
This document includes Nokia proprietary and condential information, which may not be
distributed or disclosed to any third parties without the prior written consent of Nokia. This
document is intended for use by Nokia’s customers (“You”/”Your”) in connection with a
product purchased or licensed from any company within Nokia Group of Companies. Use this
document as agreed. You agree to notify Nokia of any errors you may nd in this document;
however, should you elect to use this document for any purpose(s) for which it is not
intended, You understand and warrant that any determinations You may make or actions
You may take will be based upon Your independent judgment and analysis of the content of
this document.
Nokia reserves the right to make changes to this document without notice. At all times, the
controlling version is the one available on Nokia’s site.
No part of this document may be modied.
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.
Copyright and trademark: Nokia is a registered trademark of Nokia Corporation. Other

product names mentioned in this document may be trademarks of their respective owners.
© 2021 Nokia.
2 © 2021 Nokia. Nokia confidential 4-0

Capacity
Table of Contents
Summary of changes .................................................................................................................... 6
1 About CMM capacity and configuration ..................................................................................... 9
2 Fixed system limits ..................................................................................................................... 10
3 Capacity overview for CMM deployments ............................................................................... 16
4 VM and pod resource requirements, scaling limits, and capacity ....................................... 24

4.1 Resource requirements and per-VM capacity for deployments with large VM flavors
............................................................................................................................................ 24
4.1.1 Per-VM instance count and redundancy on CMM-a8 ..................................... 26
4.1.2 Large configuration ephemeral and persistent storage volumes ................ 28
4.2 Resource requirements and per-VM capacity for deployments with small VM flavors
............................................................................................................................................ 29
4.2.1 Per-VM instance count and redundancy on the CMM-a2 .............................. 30
4.2.2 Per-VM instance count and redundancy on OpenStack with small VNF ...... 32
4.2.3 Per-VM instance count and redundancy with VMware with small VNF ......... 33
4.2.4 Small configuration ephemeral and persistent storage volumes ................. 33
4.3 Resource requirements, scaling limits, and capacity per pod .................................. 34
5 Per-VM and per-pod detailed capacity metrics, scaling limits, and load KPIs ................... 37
5.1 NECC detailed capacity metrics, scaling, and load KPIs ............................................. 37
5.2 ALMS pod .......................................................................................................................... 38
5.3 CTCS and alarm service pod .......................................................................................... 39
5.4 DBS detailed capacity metrics, scaling, and load KPIs ............................................... 39
5.5 CPPS detailed capacity metrics, scaling, and load KPIs ............................................. 40
5.6 EEMS pod .......................................................................................................................... 42
5.7 PAPS detailed capacity metrics, scaling, and load KPIs ............................................. 43
5.8 IPDS detailed capacity metrics, scaling, and load KPIs .............................................. 45
5.9 IPPS detailed capacity metrics, scaling, and load KPIs ............................................... 50
5.10 LIHS pod ......................................................................................................................... 52
6 Traffic model inputs required for dimensioning .................................................................... 53
7 Disk I/O performance metrics .................................................................................................. 55
4-0 © 2021 Nokia. Nokia confidential 3

Capacity
List of Tables
Table 1 AMF system limits .......................................................................................................... 10
Table 2 MME system limits ......................................................................................................... 11
Table 3 SGSN system limits ........................................................................................................ 14
Table 4 Maximum capacity values for CMM large VNF on OpenStack with SR-IOV/DPDK-OVS
and VMware/VMware VIO .............................................................................................. 16
Table 5 Maximum capacity values for CMM small VNF on OpenStack ................................. 19
Table 6 Maximum capacity values for CMM CNF on Kubernetes (CN-A/CN-B) ................... 19
Table 7 Maximum capacity values for CMM-a8 appliance ..................................................... 21
Table 8 Maximum capacity values for CMM-a2 appliance ..................................................... 22
Table 9 Per-VM resource requirements, instance scaling, and basic capacity parameters for
deployments with large VMs ......................................................................................... 24
Table 10 Per-VM instance count and redundancy for the CMM-a8 on HPE DL325 servers
(AMD CPU) ........................................................................................................................ 27
Table 11 Per-VM instance count and redundancy for the CMM-a8 on AirFrame RM18
servers (Intel CPU) .......................................................................................................... 28
Table 12 Large configuration ephemeral and persistent storage volumes ........................ 29
Table 13 Per-VM capacity for deployments with small VM flavors ....................................... 30
Table 14 Per-VM instance count and redundancy for CMM-a2 on HPE DL325 servers (AMD
CPU) .................................................................................................................................. 31
Table 15 Per-VM instance count and redundancy for CMM-a2 on AirFrame RM18 servers
........................................................................................................................................... 32
Table 16 Per-VM instance count and redundancy on OpenStack with small VNF .............. 32
Table 17 Per-VM instance count and redundancy with VMware ........................................... 33
Table 18 Small configuration ephemeral and persistent storage volumes ........................ 34
Table 19 Per-pod resource requirements, scaling limits, and capacity ............................... 34
Table 20 Pod persistent storage volumes ............................................................................... 36
Table 21 NECC KPIs ...................................................................................................................... 38
Table 22 ALMS pod KPIs .............................................................................................................. 39
Table 23 CTCS KPIs ...................................................................................................................... 39
Table 24 DBS KPIs ........................................................................................................................ 40
Table 25 CPPS KPIs ...................................................................................................................... 42
Table 26 EEMS KPIs ...................................................................................................................... 43
Table 27 PAPS KPIs ...................................................................................................................... 43
Table 28 Reference IPDS capacity and load KPIs per single active IPDS VM or pod
........................................................................................................................................... 45
Table 29 Performance impact of 5G SBI authentication/authorization .............................. 46
Table 30 Progression of capacity as configuration is grown for VNF deployments with
multiple IPDS ................................................................................................................... 48
Table 31 Progression of capacity as configuration is grown for CNF deployments with
multiple IPDS ................................................................................................................... 49

Capacity
Table 32 IPPS KPIs ........................................................................................................................ 51

Table 33 Traffic model factors for CMM dimensioning .......................................................... 53
Table 34 Average disk I/O performance metrics for VNF ...................................................... 55
Table 35 Average size block calculated: IOPS/kBps ................................................................ 56
Table 36 Peaks (total for VNF) .................................................................................................... 56
Table 37 Highest I/O values in a one-second period per VM ................................................ 57

Capacity
Summary of changes
A list of changes between document issues. Click the links to view the updated sections.
Changes between issues 3-0 (CMM21.8) and 4-0 (CMM22)
General changes
CMM support for Kafka removal (Feature f14203-02)
Large configuration ephemeral and persistent storage volumes: removed columns
/data-kafka and /data-influx
Small configuration ephemeral and persistent storage volumes: removed columns
/data-kafka and /data-influx
In the following sections, noted that AMF-MME-SGSN configuration is not supported in
small VM flavor deployments:
Resource requirements and per-VM capacity for deployments with small VM flavors
Per-VM instance count and redundancy on the CMM-a2
Per-VM instance count and redundancy on OpenStack with small VNF
Per-VM instance count and redundancy with VMware with small VNF
Small configuration ephemeral and persistent storage volumes
CMM support for AMMS/EMMS capacity to 50K message/second on CNF (Feature
f72030-03)
Resource requirements, scaling limits, and capacity per pod: for 5G-CPPS (AMMS) and
4G-CPPS (EMMS), changed the number of messages/s to 50 000
CPPS detailed capacity metrics, scaling, and load KPIs: for the CNF: 10 vCPU flavor,
changed the number of messages/s to 50 000
Resource requirements and per-VM capacity for deployments with large VM flavors:
vNICs: added Note 9 regarding simplex interfaces
NECC: added information for M-IPDS
DBS: added Large flavor, updated the vRAM values, added Note 10 regarding
recommended flavors
5G or 4G CPPS: added vNIC value for VMware
PAPS: updated vNIC value for VMware
Per-VM instance count and redundancy on CMM-a8:
Table Per-VM instance count and redundancy for the CMM-a8 on HPE DL325 servers
(AMD CPU):
NECC: added Note 4
5G CPPS (AMMS): updated Note 2, updated values for AMF only, MME/AMF, and

Capacity
AMF/MME/SGSN
4G CPPS (EMMS): updated Note 2, updated values for MME only, MME/AMF, and
MME/SGSN
PAPS: updated values for AMF/MME/SGSN and MME/SGSN
IPPS: updated Note 3, updated values for AMF/MME/SGSN and MME/SGSN
Table Per-VM instance count and redundancy for the CMM-a8 on AirFrame RM18
servers (Intel CPU):
Note 2: updated
Note 3: updated
Resource requirements and per-VM capacity for deployments with small VM flavors:
5G CPPS (AMMS): updated value for vRAM
4G CPPS (EMMS): updated value for vRAM
PAPS: updated value for vRAM
IPDS: updated values for vCPU and vRAM, added Note 1
Per-VM instance count and redundancy on the CMM-a2
Table Per-VM instance count and redundancy for CMM-a2 on HPE DL325 servers (AMD
CPU):
DBS: updated value for MME/AMF
5G CPPS (AMMS): updated value for MME/AMF
4G CPPS (EMMS): updated values for MME only and MME/AMF
Resource requirements, scaling limits, and capacity per pod:
Table Per-pod resource requirements, scaling limits, and capacity:
NECC: updated values for vDisk
ALMS: updated values for Shared vCPU and Shared vRAM
CTCS: updated values for Shared vCPU and Shared vRAM
IPDS: updated values for Exclusive vRAM and Shared vRAM
IPPS: updated value for Exclusive vRAM
NECC detailed capacity metrics, scaling, and load KPIs: updated the values for Threshold
per active VM for:
VNF: 16 vCPUs/48 GB RAM
VNF: 24 vCPUs /48 GB RAM
Changes between issues 2-0 (CMM21.5) and 3-0 (CMM21.8)
General changes
Fixed system limits, added an entry for Max AMFs in a set in the AMF system limits table
and Max MMEs in a pool in the MME system limits table.

Capacity
CMM support for VMware VIO NSX-T - Delivery (Feature f70020-02), added information for
VMware Integrated OpenStack (VIO) in the following topic:
Capacity overview for CMM deployments: Table Maximum capacity values for CMM
large VNF on OpenStack with SR-IOV/DPDK-OVS and VMware/VMware VIO
CMM support for KVM based appliance on HP HW (Feature f70009-31):
Capacity overview for CMM deployments, Table Maximum capacity values for CMM-a8
appliance: added information for the AMF/MME configuration on the CMM-a8
appliance on HPE DL325 servers
Per-VM instance count and redundancy on CMM-a8, added Table Per-VM instance
count and redundancy for the CMM-a8 on HPE DL325 servers
Per-VM instance count and redundancy on the CMM-a2, added Table Per-VM instance
count and redundancy for CMM-a2 on HPE DL325 servers
CMM support for MME/SGSN PCMD streaming (Feature f14615-11), updated the
following topics:
Resource requirements and per-VM capacity for deployments with large VM flavors:
Table Per-VM resource requirements, instance scaling, and basic capacity parameters for
deployments with large VMs, added a row for extra-large flavor for the NECC
NECC detailed capacity metrics, scaling, and load KPIs: Table NECC KPIs, added a rows
for VNF and CNF 24 vCPUs
CMM support for container SELinux and removal of SystemD - callP pods (Feature
f72002-34), in Resource requirements, scaling limits, and capacity per pod, Table: Per-pod
resource requirements, scaling limits, and capacity, updated the values for PAPS and IPPS.
CMM support for lawful intercept pod - delivery (Feature f72006-14), added information for
LIHS in the following topics:
Resource requirements, scaling limits, and capacity per pod, added an entry for LIHS in
the Per-pod resource requirements, scaling limits, and capacity table.
LIHS pod
Capacity overview for CMM deployments, removed incorrect column for AMF/MME/SGSN
from Table Maximum capacity values for CMM-a2 appliance
Changes between issues 1-2 (CMM21 M2) and 2-0 (CMM21.5)
General changes
Content throughout this guide has undergone major revision. New content has been added
and outdated information has been removed or updated. Existing content has been
simplified to tabular format.

Capacity
1. About CMM capacity and configuration

The CMM consists of modular services that are designed to optimize hardware and
support smooth capacity growth with minimal impact to adjacent network elements.
The architecture follows the multitier paradigm where operations, administration, and
maintenance, load balancing, transaction processing, and database constitute individual
tiers. The transaction processing and database layers can scale independently.
The key dimensioning parameters are the number of attached subscribers and their average
activity during busy hours, which is measured in transactions or messages per attached
subscriber.

Capacity
2. Fixed system limits

Tables in this section show fixed system limits.
The following tables list the fixed AMF, MME, and SGSN system limits in CMM21.8. These
limits are only related to internal static restrictions and are not dynamic, such as for CPU
utilization, nor dependent on traffic model.
Note:
In the following tables, a request and a response are counted as two messages total.
The following table lists the AMF system limits.
Table 1: AMF system limits
System parameter Maximum value
5G-AN gNB connectivity • CNF:

- 20 000 links per IPDS
- 80 000 links max/CMM
- 40 000 gNBs with M-TNLA factor of 2X
• VNF:
- 25 000 links per IPDS
- 50 000 links max/CMM
- 25 000 gNBs with M-TNLA factor of 2X
Tracking Areas (TAs) 10 000
TNLAs per gNB 16
NRFs 16
Each NRF can have up to 16 service instances
per service type.
NSSF 4
Each NSSF can have up to 16 service instances
per service type.
LMF 20
SCP/SEPP 32
Each SCP/SEPP can have one FQDN, which
resolves to up to two IPs per IP version type.
SCP/SEPP per HTTP proxy list 8
TCP/HTTP2 connections 10 000

Capacity
Trace targets per CMM 100
PDUs Per UE: 16

Total: not restricted
Slices (SNSSAI) SNSSAIs supported by AMF: 20

NSIs supported by AMF: 3
SNSSAIs per TA: 8
SNSSAI per UE:
• Subscribed/congured: 16
• Requested: 8
• Allowed:
- Single UE: 8
- Average: 3
Max AMFs in a set A CMM supports up to 48 NR10 links towards

the other CMMs in the set for intra set session
restoration.
If all CMMs in the set have:
• 1 IPDS pair, the set can have up to 49 CMMs.
Each CMM connects with one link to each other
CMM in the set.
• 2 IPDS pairs, the set can have up to 25 CMMs.
Each CMM connects with two links to each
other CMM in the set.
Each CMM connects with three links to each
Each CMM connects with four links to each
Note:
If the number of IPDS pairs is uneven, the

number of CMM connections is equal to the
number of IPDS pairs in the smallest CMM.
The following table lists the MME system limits.
Table 2: MME system limits
Tracking Areas (TAs) 20 000
MME TAIs with CMAS 10 000

Capacity
LTE eNB connectivity • OpenStack deployments with multiple IPDS,

up to one of the following limits:
- Up to 300 000 eNBs/MCEs (total MH and
SH SCTP S1 and M3 links).
- Up to 100 000 can be asymmetric MH
SCTP-based.
- 50 000 symmetric MH-SCTP, of which up
to 26 000 can be IPv6.
Note:
300 000 eNBs are achievable with three

spread IPDS pairs.
• OpenStack deployments with single IPDS: up

to 100 000 eNBs and MCEs (S1 and M3 links)
total.
• CMM-a2 MME: 20 000
Access point name (APN) Maximum: 16
Average: 10 per UE
PDN-GW (P-GW) IP address in HSS 16 per UE
Bearers per UE Maximum: 11 (any combination of default and

dedicated)
Average: 4
P-GW Up to 400 P-GW resource records in APN FQDN

query for PGW discovery.
Serving GW (S-GW) • Up to 254 NAPTR records per TAI-based DNS

query.
• Up to 1024 active S11 links to S-GWs.
S-GW, P-GW, and APN combinations 4096
Roaming restrictions Per UE: up to 320 forbidden TAIs and 320

forbidden LAIs.
Home PLMN and each equivalent PLMN: up to
20 forbidden TACs and 20 forbidden LACs.
IMSI range and roaming agreements • Up to 700 PLMN roaming agreements.

• Up to 100 PLMN roaming agreements with 2
IMSI ranges each.
• Up to 25 PLMN roaming agreements with 16
IMSI ranges each.
• Up to home PLMN with 16 IMSI ranges.
• Provisioning such that each IMSI range has 3
TAI-restricted lists of 10 TAs/LAs each.

Capacity
Paging • Up to 1200 eNBs for a single paging TAI

• Up to 2000 eNBs for a single page attempt
Intercept targets / CPPS 200 000
Actively intercepted 4G subscribers / CPPS 1000
MSC entities or IP addresses (SGs interface) 128

Up to 4 remote end points per MSC
MSC entities or IP addresses (Sv interface) 128
Cell broadcast entities or IP addresses (SBc 16

interface)
S10 links (total is a combined maximum with 512

the number of MME N26 links)
MBMS GWs (Sm interface) 100
Number of TAIs per eNB 256
ePCO packet size 1024 bytes
NAS message payload (non-Location-Service 3000 bytes

message)
NAS message payload for location services 7915 bytes
CMAS message length Up to 9000 cell IDs
LAIs per home/equivalent PLMN and up 3 other 10 000

PLMNs
PLMNs 4096
PLMN roaming agreements 9216

Capacity
Max MMEs in a pool A CMM supports up to 48 NR10 links towards

the other CMMs in the set for intra pool
session restoration.
If all CMMs in the pool have:
• 1 IPDS pair, the pool can have up to 49 CMMs.
Each CMM connects with one link to each other
CMM in the pool.
• 2 IPDS pairs, the pool can have up to 25
CMMs. Each CMM connects with two links to
each other CMM in the pool.
CMMs. Each CMM connects with three links to
CMMs. Each CMM connects with four links to
Note:
If the number of IPDS pairs is uneven, the

number of CMM connections is equal to the
number of IPDS pairs in the smallest CMM.
The following table lists the SGSN system limits.
Table 3: SGSN system limits
Capacity parameter Maximum value
Number of GGSNs/S-GWs S4 links: 256

Gn links: 2000
S-CDRs (open) No hard limit. CDRs can be created for all

active PDPs.
S-CDRs (closed) 176 000 000
RNCs/iHSPA NodeBs 8192
Iu/SCCP connections 4 000 000
NSEs 8186
NS-VCs (static) 32 744
NS-VCs (total static and dynamic) 65 535
NS-VCs (static) per NSE 80

Capacity
Capacity parameter Maximum value
NS-VCs (static) per NSE per PAPS 4
NSEs per RAI 500 (1 RAI can support up to 500 NSEs)
SS7 signaling links 11 743
SCTP associations 27 168
Number of stored authentication 7
RACs 256
LACs (3G) Not explicitly restricted as long as the total

number of 3G RAIs does not exceed the set
limit.
LACs (2G) 2000
RAIs 3000 for 2G + 3000 for 3G
Routing areas per RNC 64
RNC per RAI 256
RAI-NSE combinations 11 191
2G cells (total) 48 000
2G cells per PAPS 12 000
PLMN congurations 1500
Concurrent HLR resets 10
LIC connections 5
LIB connections/LIC 10
Stored LI targets per CMM 200 000
2G/3G intercepted subscribers /PAPS: (X2 5000

interface)
Intercepted data 1% of rated user plane capacity
MSC entities (Gs interface) 200

Capacity
3. Capacity overview for CMM deployments

The tables in this section provide capacity information for the CMM on OpenStack, DPDK-
OVS, VMware, and VMware VIO. The values in these tables assume that the CMM is
deployed with the VM and pods scaled out to the maximum setup.
Note:
Some functions share common resources, so not all maximum values can be
achieved at the same time, such as the maximum number of AMF, MME, and SGSN
subscribers or the maximum values for SGSN signaling and for SGSN throughput.
The maximum subscriber capacity is achievable only with a very low traffic model
(IoT).
Capacity metrics are for call models that do not use encryption; for example, TLS
for 5G SBI or GEA 1/2/3 for 2G data.
Capacity information in the following tables assumes the use of Intel vCPUs. Nokia
has not certified the capacity using AMD processors and a negative performance
impact is expected.
"Transaction" refers to 3GPP signaling procedures such as Attach, Detach, or PDP
activation.
In the following tables, a request and a response are counted as two messages
total.
The following table shows the maximum capacity information for a large VNF on OpenStack
with SR-IOV/DPDK-OVS and VMware.
Table 4: Maximum capacity values for CMM large VNF on OpenStack with SR-IOV/DPDK-OVS
and VMware/VMware VIO
Deployment CMM on OpenStack CMM OpenStack with CMM on

parameters with SR-IOV DPDK-OVS VMware/VMware VIO
Attached subscribers 20 000 000 10 000 000 10 000 000
Signaling messages/s • Single IPDS: 500 000 400 000 messages/s 500 000 messages/s
as MME-only • Multiple IPDS (4 IPDS
pairs): 1 600 000
Signaling messages/s • Single IPDS: 500 000 400 0000 messages/s 500 000 messages/s
as MME/SGSN • Multiple IPDS (4 IPDS
pairs): 1 600 000

Capacity

Signaling messages/s • Single IPDS (2 IPDS • Single IPDS (2 IPDS • Single IPDS (2 IPDS
as AMF-only pairs): 240 000 pairs): 240 000 pairs): 240 000
messages/s messages/s messages/s
• Multiple IPDS (2 IPDS • Multiple IPDS (2 IPDS • Multiple IPDS (2 IPDS
pairs): 410 000 pairs): 410 000 pairs): 410 000
messages/s1 messages/s1 messages/s1
Signaling messages/s 380 000, of which 380 000, of which 380 000, of which
for AMF/MME/SGSN there is a maximum there is a maximum there is a maximum
of 210 000 for 5G of 210 000 for 5G of 210 000 for 5G
gNBs • CNF: • CNF: • CNF:

- 20 000 links per - 20 000 links per - 20 000 links per
IPDS IPDS IPDS
- 80 000 links - 80 000 links - 80 000 links
max/CMM max/CMM max/CMM
- 40 000 gNBs with - 40 000 gNBs with - 40 000 gNBs with
M-TNLA factor of 2X M-TNLA factor of 2X M-TNLA factor of 2X
• VNF: • VNF: • VNF:
- 25 000 links per - 25 000 links per - 25 000 links per
IPDS IPDS IPDS
- 50 000 links - 50 000 links - 50 000 links
- 25 000 gNBs with - 25 000 gNBs with - 25 000 gNBs with
M-TNLA factor of 2X M-TNLA factor of 2X M-TNLA factor of 2X
eNodeB • Single IPDS pair: 100 Single IPDS pair: 100 Single IPDS pair: 100
000 000 000
• Multiple-IPDS pairs:
- MME only: 260
000 of which 50 000
MH SCTP
- MME/SGSN: 200
000 of which 50 000
MH SCTP
Attached AMF • Single IPDS: 2 000 2 000 000 2 000 000

subscribers @550 000
messages/BH • Multiple IPDS (AMF-
only setups): 2 700
000
Attached MME 10 400 000 2 600 000 3 300 000

subscribers @550
messages/BH
Attached IoT devices 20 000 000 10 000 000 10 000 000

@140 messages/BH

Capacity

MME bearer capacity Not restricted Not restricted Not restricted
Attached SGSN 8 000 000 8 000 000 8 000 000

subscribers
SGSN signaling 150 000 150 000 150 000

messages/s
3G-only subscribers 4 000 000 4 000 000 4 000 000

capacity @138
messages/27.3
transactions/BH
2G-only subscriber 4 000 000 4 000 000 4 000 000

capacity @38
messages/7.6
transactions/BH and 1
kbit/s THP
PDP context capacity 12 000 000 12 000 000 12 000 000
2G throughput (Gbps) 3.2 3.2 3.2
3G throughput (Gbps) 28 10 18
Note 1: Of the total messages/s for multiple IPDS, a number are reserved for specic functions.
The following table shows capacity information for a small VNF on OpenStack.

Capacity
Table 5: Maximum capacity values for CMM small VNF on OpenStack
Deployment Small MME 2x CPPS Small MME 3x or 4x Small MME/SGSN

parameters CPPS
Attached subscribers 2 500 000 2 500 000 2 500 000
Signaling messages/s 50 000 100 000 MME: 50 000

SGSN: 5 000
eNodeB 20 000 20 000 20 000
Attached MME 325 000 650 000 325 000

subscribers @550
messages/BH
Attached 4G-IoT 1 250 000 2 500 000 1 250 000

devices @140
messages/BH
MME bearer capacity Not restricted Not restricted Not restricted
Attached SGSN − − 250 000

subscribers
SGSN signaling − − 4500

messages/s
3G-only subscribers − − 110 000

capacity @138
messages/27.3
transactions/BH
2G-only subscriber − − 110 000

capacity @38
messages/7.6
transactions/BH and 1
kbit/s THP
PDP context capacity − − 750 000
2G throughput − − 190 Mbps
3G throughput − − 2.5 Gbps
The following table shows capacity information for CNF on Kubernetes (CN-A/CN-B).
Table 6: Maximum capacity values for CMM CNF on Kubernetes (CN-A/CN-B)

Capacity
Deployment AMF only MME only AMF/MME MME/AMF/SGSN

parameters
Attached 20 000 000 20 000 000 20 000 000 20 000 000

subscribers
Signaling 450 000 − 450 000 −

messages/s for
AMF
Signaling − 450 000 450 000 450 000

messages/s for
MME
Signaling − − − 20 000
messages/s for
SGSN
gNBs • 20 000 links per − • 20 000 links per • 20 000 links per
IPDS IPDS IPDS
• 80 000 links • 80 000 links • 80 000 links
• 40 000 gNBs • 40 000 gNBs • 40 000 gNBs
with M-TNLA with M-TNLA with M-TNLA
factor of 2X factor of 2X factor of 2X
eNodeB − 100 000 100 000 100 000
Attached AMF 3 000 000 − 3 000 000 3 000 000

subscribers
@550
messages/BH
Attached MME − 3 000 000 3 000 000 3 000 000

subscribers
@550
messages/BH
Attached IoT 20 000 000 20 000 000 20 000 000 20 000 000
devices @140
messages/BH
MME bearer Not restricted Not restricted Not restricted Not restricted
capacity
Attached SGSN − − − 8 000 000

subscribers
SGSN signaling − − − 120 000

messages/s

Capacity
Deployment AMF only MME only AMF/MME MME/AMF/SGSN

parameters
3G-only − − − 3 200 000

subscribers
capacity @138
messages/27.3
transactions/BH
2G-only − − − 3 200 000

subscriber
capacity @38
messages/7.6
transactions/BH
and 1 kbit/s THP
PDP context − − − 12 000 000

capacity
2G throughput − − − 2.8
(Gbps)
(Gbps)
The following table shows capacity information for the CMM-a8 appliance.
Table 7: Maximum capacity values for CMM-a8 appliance
Deployment CMM-a8 MME CMM-a8 AMF CMM-a8 CMM-a8 CMM-a8

parameters AMF/MME MME/SGSN AMF/MME/SG
SN
Attached 10 000 000 10 000 000 10 000 000 10 000 000 10 000 000
subscribers
Signaling 500 000 300 000 500 000 500 000 400 000
messages/s
gNBs − 25 000 25 000 − 25 000
eNodeB 100 000 − 100 000 100 000 100 000
Attached AMF − 2 000 000 2 000 000 − 1 600 000

subscribers
@550
messages/BH
Attached MME 3 300 000 − 3 300 000 3 300 000 2 600 000
subscribers
@550
messages/BH

Capacity
Deployment CMM-a8 MME CMM-a8 AMF CMM-a8 CMM-a8 CMM-a8

parameters AMF/MME MME/SGSN AMF/MME/SG
SN
Attached IoT 10 000 000 10 000 000 10 000 000 10 000 000 10 000 000
devices @140
messages/BH
MME bearer Not restricted − Not restricted Not restricted Not restricted
capacity
Attached SGSN − − − 3 500 000 4 500 000

subscribers
SGSN signaling − − − 105 000 135 000

messages/s
3G-only − − − 1 600 000 2 300 000

subscribers
capacity @138
messages/27.3
transactions/B
H
2G-only − − − 1 750 000 2 250 000

subscriber
capacity @38
messages/7.6
transactions/B
H and 1 kbit/s
THP
PDP context − − − 5 250 000 6 750 000

capacity
2G throughput − − − 2.1 2.7

(Gbps)
3G throughput − − − 4 8
(Gbps)
The following table shows capacity information for the CMM-a2 appliance.
Table 8: Maximum capacity values for CMM-a2 appliance
Deployment CMM-a2 MME CMM-a2 AMF CMM-a2 CMM-a2

parameters AMF/MME MME/SGSN
Attached 2 500 000 1 000 000 2 500 000 2 500 000

subscribers
Signaling 100 000 100 000 100 000 100 000

messages/s

Capacity
Deployment CMM-a2 MME CMM-a2 AMF CMM-a2 CMM-a2

parameters AMF/MME MME/SGSN
gNBs − 20 000 20 000 −
eNodeB 20 000 − 20 000 20 000
Attached AMF − 650 000 650 000 −

subscribers
@550
messages/BH
Attached MME 650 000 − 650 000 650 000

subscribers
@550
messages/BH
Attached IoT 10 000 000 10 000 000 10 000 000 10 000 000
devices @140
messages/BH
MME bearer Not restricted − Not restricted Not restricted

capacity
Attached SGSN − − − 500 000

subscribers
SGSN signaling − − − 2800

messages/s
3G-only − − − 130 000

subscribers
capacity @138
messages/27.3
transactions/BH
2G-only − − − 130 000

subscriber
capacity @38
messages/7.6
transactions/BH
and 1 kbit/s THP
PDP context − − − 250 000

capacity
(Gbps)
(Gbps)

Capacity
4. VM and pod resource requirements, scaling limits, and

capacity
Tables in this section provide per-VM and per-pod resource requirements, scaling limits,
and capacity information for OpenStack, VMware, appliances, and containers.
Tables in this section show only the basic capacity parameters of each VM or pod. For
detailed VM capacity, refer to Per-VM and per-pod detailed capacity metrics, scaling limits,
and load KPIs.
Note:
impact is expected.
total.
4.1 Resource requirements and per-VM capacity for

deployments with large VM flavors
The table in this section shows resource requirements and per-VM capacity for
deployments with large VM flavors.
Table 9: Per-VM resource requirements, instance scaling, and basic capacity parameters for
deployments with large VMs
Instance Flavor Image Min to Redund vCPU vRAM vDisk (GB) vDisk vNICs9 Basic capacity
(qcow2) max ancy (GB) (IOPS) parameters per active
VMs VM
(VNF)
NECC Medium 2.2 GB 3 1+1+1 8 32 NECC-0, 1, 2:

1
1200 2−6 ≤ 200 000 messages/s
Large 16 48 Maximum VNF capacity
Extra- 24 48 Maximum VNF capacity

large
7
Required for M-IPDS
when PCMD streaming
is used
DBS Default 1 GB 2−32 or 2N or 8 VNF :

10
10 100 2 18 000 DBS R/W
2−16 N+
2
28 operations/s
2 500 000 UEs
Large CMM-
a8: 32

Capacity
Instance Flavor Image Min to Redund vCPU vRAM vDisk (GB) vDisk vNICs
9
Basic capacity
(qcow2) max ancy (GB) (IOPS) parameters per active
VMs VM
(VNF)
5G or 4G Medium 1 GB 2−36 N+ 10 28 10 100 2 50 000 messages/s

CPPS (VMware 350 000 MBB UEs
: 1)
Large 12 32 61 000 messages/s
500 000 MBB UEs
PAPS Default 1 GB 0 or N+ 10 24 10 100 2−12 • 2000 transactions/s

2−20
3
(VMware • 200 Mbps data
: 6) • 500 000 2G/3G
subscribers
IPDS4 SR-IOV 1 GB 2−8 2N 20 MME/ 10 100 2−24 Total 5G: 300 000
SGSN: Up to message messages/s
40 92 IPs5 s/s: 500
AMF: 52 000
8
QA: 62
VMware 2 10 Total
message
s/s: 500
000
DPDK- 2 24 Total
OVS message
s/s: 400
000
IPPS OpenSta 1 GB 0 or N+ 10 32 10 100 3−5 1.5 Gbps 30 000

ck DPDK- 2−8
3
PAPS-IPPS
OVS messages/s
VMware 10
6
3−5 3 Gbps 50 000
VMNet 3 PAPS-IPPS
messages/s
Default 10 2−10 4 Gbps 30 000

(SR-IOV) PAPS-IPPS
messages/s
DT 12 90 000
medium PAPS-IPPS
messages/s
DT large 14 120 000

PAPS-IPPS
messages/s
L3NS11 Default 300 MB 0 or 2 1+1 8 8 10 100 8−22 1 600 000 messages/s
Note 1: For NECC vDisk values, refer to the CMM LCM user guide for your deployment type.
Note 2: N+ is the only option when the setup is VNF and includes AMF.
Note 3: Multiple IPDS pairs are supported only on OpenStack deployments using SR-IOV as follows:
• MME-only: 4 IPDS pairs (with L3NS)
• MME/SGSN: 4 IPDS pairs (with L3NS)
• AMF-only: 2 IPDS pairs (no L3NS)
Note 4: Per IPDS messages/sec capacity is degraded if deployment falls into one or more of the following cases:
• TLS and/or OAuth is used.
• CMM is deployed with multiple IPDS (while overall per-CMM messaging capacity increases with M-IPDS, per pool messaging capacity
decreases).
• Deployment is AMF/MME and Quad Access.
Note 5: The vNIC limit applies only to VST mode while the IP limit applies only to VGT mode.
Note 6: IPPS with VMware VMXNet 3 allocates 10 physical cores in all VMware deployments due to "Latency sensitivity = High".
Note 7: Only applicable when traffic requirements are larger than 500 000 msg/s (such as when M-IPDS and L3NS are used) and when
CMM support for MME/SGSN PCMD streaming (Feature f14615-11) is enabled.
Note 8: Quad access does not support multiple IPDS.
Note 9: As VMware uses simplex interfaces, it has 24 vNICs (24 and 20 are available for project-specic requests).
Note 10: The 28 GB avor is generally recommended; however, the 24 GB and 20 GB avors are available for project-specic requests.
Note 11: L3NS is not available for AMF, Quad Access, or VMware deployments.

Capacity
4.1.1 Per-VM instance count and redundancy on CMM-a8

The following table shows the per-VM instance count and redundancy on the CMM-a8.
On AirFrame RM17 hardware, the CMM-8 supports the MME-only and MME/SGSN
configuration. For supported CMM-a hardware and deployment configuration
combinations, see Supported CMM-a hardware and deployment configuration in the
Cloud Mobility Manager Appliance Installation and Setup Guide.
Note:
For VMs deployed as all-active (CPPS, PAPS, IPPS), the counters below are referred to
as N+K, where K is the maximum number of VMs that may be lost in case of a host
failure. For DBS (deployed as 2N), 4+4 refers to 4 active and 4 standby VMs.

Capacity
Table 10: Per-VM instance count and redundancy for the CMM-a8 on HPE DL325 servers (AMD
CPU)
Instance AMF only MME only MME/AMF AMF/MME/SGS MME/SGSN

N
NECC
1
1+1+1 1+1+1 1+1+1 1+1+1 1+1+1
DBS
2
4+4 5+5 4+4 4+6 6+6
5G CPPS 11+3 0 6+1 6+1 0

(AMMS)3
4G CPPS 0 11+3 10+2 6+6 10+2

3
(EMMS)
PAPS 0 0 0 17+3 17+3
IPDS 1+1 1+1 1+1 1+1 1+1
IPPS4 0 0 0 3+1 3+1
L3NS − − − − −
Note 1: CMM-a8 exclusively uses the 16 vCPU variant of NECC.

Note 2: CMM-a8 uses the 32 GB RAM DBS avor in the 2N redundancy mode.
Note 3: CMM-a8 exclusively uses the 10 vCPU variant for AMMS and EMMS.
Note 4: CMM-a8 exclusively uses the 14 vCPU variant of IPPS.

Capacity
Table 11: Per-VM instance count and redundancy for the CMM-a8 on AirFrame RM18 servers
(Intel CPU)
Instance AMF only MME only AMF/MME/SGSN MME/SGSN
NECC 1+1+1 1+1+1 1+1+1 1+1+1
DBS1 5+5 5+5 6+6 6+6
5G CPPS (AMMS)2 9+3 0 6+1 0
4G CPPS (EMMS)2 0 11+3 8+2 9+3
PAPS 0 0 7+1 9+3
IPDS 1+1 1+1 1+1 1+1
IPPS3 0 0 2+1 1+1
L3NS − − − −
Note 1: CMM-a8 uses the 32 GB RAM DBS avor in the 2N redundancy mode.
Note 2: CMM-a8 exclusively uses the 10 vCPU variant for AMMS and EMMS.
Note 3: CMM-a8 exclusively uses the 12 vCPU variant of IPPS.
4.1.2 Large configuration ephemeral and persistent

storage volumes
The following table shows ephemeral and persistent storage volumes for CMMs with large
configurations.

Capacity
Table 12: Large configuration ephemeral and persistent storage volumes
Service ROOT /data /data /data /data /shar /data /data /data- /data-
- logs - pm - perf - ed - - redis charging sgsnmon
pcmd store1
2
NECC 15 15 15 20 100 10 50 20 50 100
DBS 10 0 0 0 0 0 0 0 0 0
CPPS 10 0 0 0 0 0 0 0 0 0
PAPS 10 0 0 0 0 0 0 0 0 0
IPDS 10 0 0 0 0 0 0 0 0 0
IPPS 10 0 0 0 0 0 0 0 0 0
L3NS 10 0 0 0 0 0 0 0 0 0
Note 1: Mount only to NECC0.

Note 2: If needed, the /data-sgsnmon logs must be stored manually before upgrade due to their
excessive sizes.
4.2 Resource requirements and per-VM capacity for

deployments with small VM flavors
The table in this section shows resource requirements and per-VM capacity for
deployments with small VM flavors. Note that AMF-MME-SGSN configuration is not
supported in small VM flavor deployments.

Capacity
Table 13: Per-VM capacity for deployments with small VM flavors
Instance Flavor Image vCPU vRAM vDisk vDisk vNICs Basic capacity
(qcow2) (GB) (GB) (IOPS) parameters per
active VM
NECC Default 2.2 GB 8 32 NECC-0: 800 2−6 Maximum VNF

225 capacity
NECC-1:
175
DBS Default 1 GB 8 20 10 100 2 18 000 DBS R/W

operations/s
1 250 000 UEs
5G-CPPS Default 1 GB 10 28 10 100 2 50 000 messages/s

(AMMS) 350 000 MBB UEs
4G-CPPS Default 1 GB 10 28 10 100 2 50 000 messages/s

(EMMS) 350 000 MBB UEs
PAPS Default 1 GB 4 24 10 100 2−12 • 600 000

transactions/s
• 80 Mbps data
• 300 000 2G/3G
subscribers
IPDS Default 1 GB 10 32 10 100 2−24 100 000 messages/s

(MME,
MME/S
GSN)
40
(AMF,
1
AMF)
IPPS Default 1 GB 8 18 10 100 2−5 2.5 15 000

Gbps PAPS-IPPS
messages
/s
Note 1: Small AMF and AMF/MME are only for PoC/Trials.
4.2.1 Per-VM instance count and redundancy on the CMM-

a2
The following table shows the per-VM instance count and redundancy on the CMM-a2.

Capacity
On AirFrame RM17 hardware, the CMM-2 only supports the MME-only configuration.
For supported CMM-a hardware and deployment configuration combinations, see
Supported CMM-a hardware and deployment configuration in the Cloud Mobility
Manager Appliance Installation and Setup Guide.
Note:
AMF-MME-SGSN configuration is not supported on the CMM-a2.
Table 14: Per-VM instance count and redundancy for CMM-a2 on HPE DL325 servers (AMD
CPU)
Instance AMF only MME only MME/SGSN MME/AMF
NECC 1+1 1+1 1+1 1+1
DBS 2+2 2+2 1+1 2+2
5G CPPS (AMMS) 2+6 0 0 2+2
4G CPPS (EMMS) 0 4+4 2+2 2+2
PAPS 0 0 2+2 0
IPDS 1+1 1+1 1+1 1+1
IPPS 0 0 1+1 0

Capacity
Table 15: Per-VM instance count and redundancy for CMM-a2 on AirFrame RM18 servers
Instance AMF only MME only MME/SGSN MME/AMF
NECC 1+1 1+1 1+1 1+1
DBS 1+1 1+1 1+1 2+2
5G CPPS (AMMS) 2+2 0 0 2+2
4G CPPS (EMMS) 0 2+2 1+1 2+2
PAPS 0 0 1+1 0
IPDS 1+1 1+1 1+1 1+1
IPPS 0 0 1+1 0
4.2.2 Per-VM instance count and redundancy on

OpenStack with small VNF
The following table shows the per-VM instance count and redundancy on OpenStack with
small VNF. Note that AMF-MME-SGSN configuration is not supported in small VM flavor
deployments.
Table 16: Per-VM instance count and redundancy on OpenStack with small VNF
Instance MME only MME/SGSN AMF (proof of

concept for CMM21.5
and later)
NECC 1+1 1+1 1+1
DBS 1+1 1+1 1+1
5G CPPS (AMMS) 0 0 1+1
4G CPPS (EMMS) 1+1, 2+1, or 3+1 1+1 0
PAPS 0 2+2 0
IPDS 1+1 1+1 1+1
IPPS 0 1+1 0

Capacity
4.2.3 Per-VM instance count and redundancy with VMware

with small VNF
The following table shows the per-VM instance count and redundancy with VMware with
small VNF. Note that AMF-MME-SGSN configuration is not supported in small VM flavor
deployments.
Table 17: Per-VM instance count and redundancy with VMware
Instance AMF (proof of concept for CMM21.5 and later)
NECC 1+1
DBS 1+1
5G CPPS (AMMS) 1+1
4G CPPS (EMMS) 0
PAPS 0
IPDS 1+1
IPPS 0
4.2.4 Small configuration ephemeral and persistent

storage volumes
The following table shows ephemeral and persistent storage volumes for CMMs with
small configurations. Note that AMF-MME-SGSN configuration is not supported in small
VM flavor deployments.

Capacity
Table 18: Small configuration ephemeral and persistent storage volumes
Service ROOT /data- /data- /data- /data- /share /data- /data- /data- /data-
logs pm perf pcmd d store1 redis charging sgsnmo
2
n
NECC 15 15 15 15 50 10 50 5 25 20
DBS 10 0 0 0 0 0 0 0 0 0
CPPS 10 0 0 0 0 0 0 0 0 0
PAPS 10 0 0 0 0 0 0 0 0 0
IPDS 10 0 0 0 0 0 0 0 0 0
IPPS 10 0 0 0 0 0 0 0 0 0
Note 1: Mount only to NECC-0.

Note 2: If needed, the /data-sgsnmon logs must be stored manually before upgrade due to their
excessive sizes.
4.3 Resource requirements, scaling limits, and capacity

per pod
The table in this section shows per-pod resource requirements, scaling limits, and
capacity information.
Table 19: Per-pod resource requirements, scaling limits, and capacity

Instance Flavor Min Redundancy Exclusive Shared Exclusive Shared vDisk vDisk vNICs Basic capacity
to vCPU vCPU vRAM vRAM (GB) (IOPS) parameters
max (GB) (GB)
pods
NECC Medium 3 1+1+1 8 0 32 − NECC-0, 1200 2−6 ≤ 200 000

1, 2:
1
messages/s
Large 12 0 48 − Maximum CNF

capacity
ALMS Default 1 Simplex 0.2 3.7 0.5 5.75 0 0 2 Maximum CMM

capacity
Large 7.25 Must be used if

SGSN user plane
trace is planned
to be used
CTCS Default 1 Simplex 2 1.47 1 3.75 0 0 2 Maximum CMM

capacity for
signaling trace
Large 6 5.25 Must be used if

SGSN user plane
trace is planned
to be used

Capacity
Instance Flavor Min Redundancy Exclusive Shared Exclusive Shared vDisk vDisk vNICs Basic capacity
to vCPU vCPU vRAM vRAM (GB) (IOPS) parameters
max (GB) (GB)
pods
DBS Default 2−16 N+ 8 0.7 24 1.25 0 0 2 16 000 DBS R/W

operations/s
5G-CPPS Default 1−36 N+ 10 0.7 28 1.25 0 0 2 50 000

(AMMS) messages/s
350 000 MBB
UEs
4G-CPPS Default 1−36 N+ 10 0.7 28 1.25 0 0 2 50 000

(EMMS) messages/s
350 000 MBB
UEs
EEMS Default 2−6 N+ 2 0.7 2.5 1.25 0 0 2 2000 subscribe

requests/s or
overall 4000
event exposure-
related
messages/s per
direction
PAPS Default 0 or N+ 10 0.7 24 1.25 0 0 6 • 1600

2−20 transactions/s
• 155 Mb data
• 500 000 2G/3G
subscribers
IPDS Default 2−6 2N 10 0.7 40 1.25 0 0 12 150 000

or 8 (<8 messages/s
rcmd)
IPPS Default 0 or N+ 8 0.7 32 1.25 0 0 5 1.0 15 000

2−8 Gbps PAPS-
IPPS
LIHS Default 2 1+1 0.4 1.8 0.96 3.75 0 0 2 less than 1000 LI
surveillance
targets
1.0 3.75 up to 10 000 LI

surveillance
targets
4.5 3.75 up to 150 000 LI

surveillance
targets
Large 0.96 5.25 less than 1000 LI

surveillance
targets2
1.0 5.25 up to 10 000 LI

surveillance
targets2
4.5 5.25 up to 150 000 LI

surveillance
targets 2
Note 1: For NECC vDisk values, refer to the CMM LCM user guide for your deployment type.
Note 2: Large LIHS avor must be used if SGSN user plane trace is planned to be used.
The following table shows the persistent storage volumes for pods.

Capacity
Table 20: Pod persistent storage volumes
Service /data /data /data /data /shared /data /data /data /data /data- /mariaDB
- logs - pm - perf - - - - - charging
pcmd store1 kafka redis inux 2
NECC 15 15 20 100 10 50 20 20 20 25 1G
DBS 0 0 0 0 0 0 0 0 0 0 0
CPPS 0 0 0 0 0 0 0 0 0 0 0
PAPS 0 0 0 0 0 0 0 0 0 0 0
IPDS 0 0 0 0 0 0 0 0 0 0 0
IPPS 0 0 0 0 0 0 0 0 0 0 0
Note 1: Mount only to NECC0.

Note 2: The /data-charging volume is required even for deployments that are not QA.

Capacity
5. Per-VM and per-pod detailed capacity metrics, scaling

limits, and load KPIs
Tables in this section provide information about NECC, ALMS, CTCS, DBS, CPPS, EEMS,
PAPS, IPDS, and IPPS capacity metrics and load KPIs.
When multiple flavors of a VM or of pods are available, a single flavor must be selected for all
VMs or pods. Mixing different flavors in the same deployment is not supported.
Note:
impact is expected.
total.
5.1 NECC detailed capacity metrics, scaling, and load KPIs

The NECC handles OAM, business logic, Open API and centralized functions.
This service does not scale. The flavor should be selected to serve the maximum capacity.
Note:
The memory and CPU fluctuate frequently and spike every 10 minutes, every 15
minutes, and every hour; this is considered normal.

Capacity
Table 21: NECC KPIs
KPI Flavor Threshold per active VM NetAct formula Relevant PM

counter
Signaling VNF: 8 vCPUs /32 ≤ 200 000 messages/s cmm_293a MPH (VS.TotalMsgsRcv
messages/s GB RAM messaging dFromMPH +
transactions rate VS.TotalMsgsSent
VNF: 16 vCPUs/48 Maximum VNF capacity (single ToMPH) /
GB RAM IPDS or when PCMD streaming is (period_duration
not used) × 60)1
VNF: 24 vCPUs Maximum VNF capacity (multiple

/48 GB RAM IPDS when PCMD streaming is
used)
CNF: 8 vCPUs/32 ≤ 200 000 messages/s cmm_371a Total (VS.TotalMsgsRcv

GB RAM Messages dPerInterface +
Received per Sec VS.TotalMsgsSent
CNF: 12 vCPUs/48 Maximum CNF capacity in IPDS for CNF + PerInterface) /
GB RAM cmm_372a Total (period × 60)
Messages Send
CNF: 24 vCPUs/48 Maximum CNF capacity per Sec in IPDS
GB RAM for CNF
CPUs % All 75% 85% 90% cmm_287a VS.aveCpuUsage,

Average NECC VS.peakCpuUsage
CPU load, (to check for
cmm_447a Peak spikes)
NECC CPU load
Memory % All 93% 95% 99% cmm_451a VS.MemUsedSize/

Average NECC size of NECC RAM
Memory usage avor, in MB; for
example, 48 000
for the 16 vCPU
Note 1: TotalMsgsRcvdFrom/toMPH counters are reported in 5 min, 15 min, 30 min, or 60 min intervals according
with the period conguration in CMM. These counters must be converted to rate per second.
5.2 ALMS pod

Alarm management service (ALMS) runs as a separate process on the NECC VM of a VNF
CMM and as a pod on a CNF CMM.
ALMS has two flavors: default and large. The large ALMS must be used if the SGSN user
plane trace is planned to be used (as CTCS and ALMS share the common Redis database and
CTCS requires the larger Redis database flavor); otherwise, the default flavor can be used.

Capacity
Table 22: ALMS pod KPIs
KPI Flavor Threshold per NetAct formula Relevant PM

active pod counter
SGSN user plane Default Not supported − −

tracing
Large Required
5.3 CTCS and alarm service pod

Call trace collection service (CTCS) runs as a separate service on the NECC VM of a VNF
CMM and as a pod on a CNF CMM.
CTCS has two flavours: default and large. The large CTCS must be used if SGSN user plane
trace is planned to be used; otherwise, the default flavor can be used.
Table 23: CTCS KPIs

active VM or pod counter
Trace targets All Signaling for up − −

without user to 100 trace
plane targets
SGSN user plane Default Not supported

tracing
Large 15 000
messages/s
5.4 DBS detailed capacity metrics, scaling, and load KPIs

DBS stores all subscriber mobility and session management context data for 2G, 3G, 4G,
and 5G.
DBS can be deployed as active-active or active-standby. In the case of active-active

deployment, traffic must be extrapolated to calculate host failures. Otherwise, in active-
standby, capacity is not affected by host failures.
Subscribers are more than attached SAUs, because DBS also stores detached subscribers
until they are purged.

Capacity
The DBS can scale out or scale in without service interruption. However, the DBS cluster
configuration used for VNF deployment is selected based on the size that can meet the UE
storage and transaction requirements. In duplex configuration, the DBS scales horizontally
in increments of 2; in simplex configuration, the DBS scales in increments of 1.
Up to 16 active DBSs (that is, up to 32 DBSs) can be in use when deployed as 2N, or 16 DBSs
when deployed as N+.
Note:
Measurements should be gathered from the active DBS.

Memory extrapolates with the number of subscribers.
CPU limits are generally not reached even during the maximum-rated capacity. The
engineered messages/s limit is normally reached first.
Table 24: DBS KPIs

KPI Flavor Threshold per active VM NetAct formula Relevant PM counter
Read/write VNF: 8 vCPU 18 000 cmm_295a 4G signaling ((VS.

operations transactions rate + (2 × Ave4GCtrlMsgRate+VS.CtrlMsg5
cmmsg_2463a 3G GNbrMean) / 8) +
transactions) + (2 × [[(VS.TotalMsgsRcvdFromMPH +
cmmsg_2462a 2G VS.TotalMsgsSentToMPH) /
CNF: 8 vCPU 16 000 transactions) + (period × 60)] − (VS.
PROC_PROCESS_AMF_SUM / Ave4GCtrlMsgRate +
(period_time × 60) VS.CtrlMsg5GNbrMean)] / 6
(approx.) (IPDS)
Subscribers VNF: 28 GB RAM 2 500 000 cmm_462b CMM peak VS.MaxNbrOfRegisteredUE +

attached users + VS.MaxNbrOfDeRegisteredUE
RM_DEREG_UES_MAX + (CPPS) + VS.PeakAttachIuUsers
CNF: 24 GB RAM 2 500 000 MAX_DEREGISTERED_UE + VS.PeakAttachGbUsers +
VS.MaxNbrOfAttachConnected
NbIotUe +
20 GB RAM 1 250 000 VS.RegisteredSubNbrMax +
VS.DeregisteredSubMax
CPUs % CNF/VNF 85% 90% 95% cmm_285a Average DBS CPU VS.aveCpuUsage (for normal
load / cmm_445a Peak DBS operation)
CPU load VS.peakCpuUsage /
VS.avePerCoreCpuUsage (for
abnormal cases/spikes)
RAM % CNF/VNF 93% 95% 99% cmm_449a Average DBS VS.memUsage,

Memory usage, cmm_453a VS.maxNEmemUsage
Peak DBS Memory usage
5.5 CPPS detailed capacity metrics, scaling, and load KPIs

CPPS handles 4G or 5G mobility and session management transactions.
CPPS is deployed as active-active and traffic must be extrapolated for host failures. Each

Capacity
CPPS either operates as EMMS (MME) or AMMS (AMF). CPPS scales out to 36 CPPS and can
scale in and scale out without service interruption. The horizontal increment or decrement
step is 1 x CPPS.
Note:
Memory is mainly preallocated and does not extrapolate with traffic.

4G NB-IOT SAUs do not count toward the cache limit (cache age out).
4G messages in CPPS are a bit less than 4G messages counted in IPDS, because
IPDS fans out messages when required, such as for paging or CMAS.
CPU limits are generally not reached even during maximum-rated capacity. The
Ave4GCtrlMsgRate is available in both IPDS and CPPS reports. The value in the
CPPS reports is more accurate because it does not include paging fan outs and
CMAS.
If the IPDS report is used, it needs the entry in the active (most busy).

Capacity
Table 25: CPPS KPIs

counter
4G/5G VNF: 10 vCPU 50 000 (steady)/150 000 (SafetyNet) cmm_292a Peak 4G VS.Ave4GCtrlMsgRat
messages/s control messages e+
rate + VS.CtrlMsg5GNbrMea
CTRL_MSG_5G_MEAN n
VNF: 12 vCPU 61 000 (steady)/183 000 (SafetyNet) AVE_4G_CTRL_MSG_R VS.Peak4GCtrlMsgRa
ATE + te (spikes) +
CTRL_MSG_5G_MAX VS.CtrlMsg5GNbrMax
CNF: 10 vCPU 50 000 (steady)/150 000 (SafetyNet) cmm_371a Total (VS.TotalMsgsRcvdPe

Messages Received rInterface +
per Sec in IPDS for VS.TotalMsgsSentPer
CNF + cmm_372a Interface) / (period ×
Total Messages Send 60)
per Sec in IPDS for
CNF
Subscribers VNF/CNF: 10 vCPU 350 000 cmm_65 Average VS.MaxNbrOfRegiste

EPS EMM- redUE (4G) −
REGISTERED + VS.AveNbrOfAttachN
cmm_305a 5G bIotUe
Average RM-
REGISTERED users,
VNF: 12 vCPU 500 000
cmm_99a Peak EPS
EMM-REGISTERED
users, MME +
rm_reg_ues_max
DDNs VNF/CNF: 10 vCPU 1400 DDN_RCVD, VS.DdnRcvd [CPPS]

DDN_THROTTLED_D (for average)
ROP VS.DDNThrottledDro
VNF: 12 vCPU 1936 pped [IPDS] (for
spikes)
CPUs % All 85% 90% 95% cmm_284a Average VS.aveCpuUsage (for

CPPS CPU load, normal operation)
cmm_444a Peak VS.peakCpuUsage /
CPPS CPU load VS.avePerCoreCpuU
sage (for abnormal
cases/spikes)
RAM % All 93% 95% 99% cmm_452a Peak VS.memUsage,

CPPS Memory usage, VS.maxNEmemUsag
cmm_448a Average e
CPPS Memory usage
5.6 EEMS pod

Event exposure management service (EEMS) runs as a separate process on a VNF CMM
and as a separate pod on a CNF CMM.
On a CNF, there are at least two EEMS pods, which can scale out up to six instances, all
active.

Capacity
Table 26: EEMS KPIs

active VM or pod counter
Event exposure Default 2000 subscribe − −

signaling requests/s or
overall 4000
event exposure-
related
messages/s per
direction
5.7 PAPS detailed capacity metrics, scaling, and load KPIs

PAPS handles 2G and 3G mobility and session management and 2G data.
The PAPS can scale in and scale out. Scale out (maximum 20) is supported without service
interruption. Scale in is supported without service interruption for 3G subscribers, but 2G
subscribers served by the PAPS that were removed must reattach. PAPS is deployed as
active-active and traffic must be extrapolated for host failures. This service can scale up to
20 PAPS for the 10 vCPU variant. The horizontal increment or decrement step is 1 x PAPS.
The rule that defines the number of required VMs is shown in the following table.
Note:

CPU limits may be approached when serving the maximum-rated capacity,
depending on the call model.
The maximum signaling and throughput limits cannot be achieved at the same
time. The basic value for monitoring should be the average vCPU.
Table 27: PAPS KPIs
2G VNF: 10 vCPU 2000 cmmsg_2462a 2G More than 30

transactions/s transactions
1
counters
CNF: 10 vCPU 1350
VNF: 4 vCPU 600

Capacity
3G VNF: 10 vCPU 2250 cmmsg_2463a 3G More than 30

transactions/s transactions1 counters
CNF: 10 vCPU 1500
VNF: 4 vCPU 600
2G data VNF: 10 vCPU 195 Mbps cmmsg_2458b 8×

unciphered Unciphered user (VS.Gea0DataInKbytes
CNF: 10 vCPU 130 Mbps plane packets SentUl +
throughput VS.Gea0DataInKbytes
SentDl) / (period_time
VNF: 4 vCPU 90 Mbps × 60 × 1024)
2G data VNF: 10 vCPU 141 Mbps (GEA3) cmmsg_2457b 8×

ciphered Ciphered user plane (VS.Gea1DataInKbytes
packets throughput SentUl +
VS.Gea1DataInKbytes
SentDl +
CNF: 10 vCPU 95 Mbps (GEA3) VS.Gea2DataInKbytes
SentUl +
VS.Gea2DataInKbytes
SentDl +
VS.Gea3DataInKbytes
VNF: 4 vCPU 70 Mbps (GEA3) SentUl +
VS.Gea3DataInKbytes
SentDl) / (period_time
× 60 × 1024)
Intercepted All 1% of user plane traffic − −

data
Total All 500 000 cmmsg_2449a 3G VS.PeakAttachGbUser

subscribers peak attached users s+
+ cmmsg_2450a 2G VS.PeakAttachIuUsers
peak attached users
2G subscribers All 250 000 cmmsg_2450a 2G VS.PeakAttachGbUser

peak attached users s
PDPs All 750 000 cmmsg_703a VS.PeakGbPdpCont +

Average amount of VS.PeakIuPdpCont
PDP contexts
cmmsg_704a Peak
amount of PDP
contexts
CPUs % All 75% 78% 81% cmm_297a Average VS.aveCpuUsage /

PAPS CPU load, 469a VS.peakCpuUsage /
Peak PAPS CPU load VS.avePerCoreCpuUs
age (for abnormal)
Memory % All 93% 95% 99% cmm_473a Peak VS.MemUsedSize /

PAPS Memory usage, size of PAPS RAM
cmm_471a Average avor (in MB; for
PAPS Memory usage example, 20 000)
Note 1: Transactions should be divided by (period_time × 60).

Capacity
5.8 IPDS detailed capacity metrics, scaling, and load KPIs

IPDS handles all the signaling traffic except for 2G RAN (Gb). Because it operates in
active/standby mode, there is no need to extrapolate traffic for pod, VM, or host failure
scenarios.
The IPDS scales horizontally in active-standby pairs. To scale in or scale out an IPDS pair on
VNF, the CMM must be out-of-service and redeployed. To scale in or scale out an IPDS pair
on CNF, redeployment is not required but is a manual procedure.
Capacity metrics, scaling, and load KPIs of single IPDS VM or pod

The capacity of a single IPDS pair is shown in the following table.
Table 28: Reference IPDS capacity and load KPIs per single active IPDS VM or pod

counter
Total 20 vCPUs 500 000 (steady) / 550 000 cmm_293a MPH (VS.TotalMsgsRcvdF
5G/4G/3G (SafetyNet) messaging romMPH +
messages/s1 transactions rate VS.TotalMsgsSentT
DPDK-OVS: 20 400 000 (steady) / 440 000 oMPH) /
vCPUs (SafetyNet) (period_duration ×
60)
VNF: 10 vCPUs 100 000 (steady) / 110 000
(SafetyNet)
CNF: 10 vCPUs 150 000 (steady) / 165 000 cmm_371a Total (VS.TotalMsgsRcvdP
(SafetyNet) Messages Received erInterface +
per Sec in IPDS for VS.TotalMsgsSentP
CNF + cmm_372a erInterface) /
Total Messages (period × 60)
Send per Sec in
IPDS for CNF
5G 20 vCPUs 300 000 messages/s − −

messages/s2
VNF: 10 vCPUs 100 000 (steady) / 110 000 − −
(SafetyNet)
CNF: 10 vCPUs 150 000 (steady) / 165 000 − −

(SafetyNet)
M3UA 20 vCPUs 300 000 messages/s − −

messages/s
10 vCPUs 100 000 messages/s − −

Capacity

counter
5G/4G/3G/2G 20 vCPUs 20 000 000 cmm_462b CMM VS.MaxNbrOfRegist

SAUs3 peak attached eredUE +
users VS.PeakAttachGbUs
ers +
10 vCPUs 2 500 000 VS.PeakAttachIuUse
rs +
VS.RegisteredSubN
CNF: 10 vCPUs 20 000 000 brMax +
VS.MaxNbrOfAttach
ConnectedNbIotUe
CPUs% All 85% 90% 95% cmm_286a average VS.aveCpuUsage

IPDS CPU load, (for normal
cmm_446a Peak operation)
IPDS CPU VS.peakCpuUsage /
VS.avePerCoreCpu
Usage (for
abnormal
cases/spikes)
Memory% − − − − cmm_454a Peak VS.memUsage,

IPDS Memory VS.maxNEmemUsa
usage and ge
cmm_450a Average
IPDS Memory
usage
Note 1: There is 18% performance impact when combining MME and AMF functionality in the same IPDS.
Note 2: Values are without OAuth/TLS.
Note 3: The limit is the same system-wide, regardless of the number of IPDS pairs that are deployed.
Performance impact of 5G SBI authentication/authorization on IPDS

The performance impact of 5G SBI authentication/authorization is shown in the following
table.
Table 29: Performance impact of 5G SBI authentication/authorization
Functionality Performance degradation %
Self-signed TLS 7
CA-signed TLS 18
OAuth2.0 10
Performance impact of combining 4G and 5G traffic in IPDS

When IPDS is used as AMF along with MME, there is an additional 18% degradation in the
IPDS.

Capacity
Progression of capacity for VNF deployments with multiple IPDS

The maximum number of subscribers is the same, regardless of the number of IPDS pairs
that are deployed.
The following table shows the changes to capacity as a CMM with VNF deployment increases
the number of IPDS pairs.
Note:
The values in the following table refer to SBI traffic without OAuth or TLS. The
performance impact of 5G SBI authentication/authorization must be taken into
account.

Capacity
Table 30: Progression of capacity as configuration is grown for VNF deployments with multiple
IPDS
Deployment Capacity 1 IPDS pair 2 IPDS pairs 3 IPDS pairs 4 IPDS pairs
metric
AMF only 5G messages/s 240 000 410 000 − −
AMF/MME Total 400 000 −

messages/s
5G messages/s 240 000
MME only 4G messages/s 500 000 600 000 1 100 000 1 600 000
MME/SGSN Total 500 000 800 000 1 300 000 1 600 000
messages/s
4G messages/s 500 000 800 000 1 100 000 1 600 000
M3UA 300 000 300 000 300 000 300 000

messages/s
AMF/MME/SGS Total 400 000 −

N messages/s
M3UA 300 000

messages/s
For multiple IPDS MME or MME/SGSN with L3NS (OpenStack) deployments, capacity is as
follows:
Lead IPDS pair: 500 000 messages/s of non-S1/M3/S11/S11U signaling traffic
Spread IPDS pair:
500 000 messages/s S1/M3/S11/S11U
with S11-only spread IPDS: 400 000 of S11 traffic
with S11/S1 spread IPDS: 500 000 messages/s, of which up to 330 000 can be S11
maximum 100 000 eNBs
Up to 300 000 eNBs/MCEs (S1/M3 links) total, up to 50 000 of which can be MH SCTP-
based:
26 000 of which can be MH SCTP-based IPV6
50 000 of which can be MH SCTP-based IPv4 + IPV6

Capacity
Progression of capacity for CNF deployments with multiple IPDS

In CNF deployments, each IPDS can support 150 000 messages/s; however, in multiple IPDS
deployments, each IPDS serves specific interfaces. As such, Nokia recommends maintaining
a buffer of about 25% to handle imbalanced traffic.
The maximum number of subscribers is the same, regardless of the number of IPDS pairs
that are deployed.
The following table shows the changes to capacity as a CMM with CNF deployment increases
the number of IPDS pairs.
Note:
The values in the following table refer to SBI traffic without OAuth or TLS. The
performance impact of 5G SBI authentication/authorization must be taken into
account.
Table 31: Progression of capacity as configuration is grown for CNF deployments with multiple
IPDS
Deployment Capacity 1 IPDS pair 2 IPDS pairs 3 IPDS pairs 4 IPDS pairs
metric
AMF only 5G messages/s 150 000 225 000 337 000 450 000
AMF/MME Total 123 000 184 000 275 000 370 000
messages/s
AMF/MME/SGS Total 123 000 184 000 275 000 370 000
N messages/s
Consider the following when determining capacity:

Measurements should be gathered from the active IPDS except for the
VS.TotalMsgsRcvdFromMPH + VS.TotalMsgsSentToMPH. Because M3UA messages can be
sent and received via standby IPDS, the VS.TotalMsgsRcvdFromMPH +
VS.TotalMsgsSentToMPH measurements can be aggregated including the standby IPDS.
Because memory is mainly preallocated and does not extrapolate with traffic, it is not
considered a KPI.
In case of deployment with M-IPDS, the eNodeB count must be divided by the number of
per-spread IPDS pairs because the lead IPDS does not support S1 traffic. Some counters
need unit conversion; for example, VS.TotalMsgsRcvdFromMPH reports for a 15 minute

Capacity
period and must be converted to a rate per second.

CPU limits are generally not reached even during maximum-rated capacity. The
CPU3 in the 20 vCPU IPDS flavor is always reported as 100%. This is normal, because this
is the thread where the DPDK-related KNI thread is pinned.
5.9 IPPS detailed capacity metrics, scaling, and load KPIs

IPPS handles 3G user plane data.
IPPS operates in all-active mode and traffic must be extrapolated for host failures. Only the
non-direct tunnel 3G traffic should be calculated as throughput, although this traffic does
count as PDPs. The IPPS scales horizontally in increments of 1, up to a maximum of 8. Scale
out is supported without service interruption. Graceful scale in is supported, which means
that the IPPS is gradually offloaded during the draining period. During this period, only
already-established PDPs/bearers are served.
Note:

Direct tunnel PDPs are also counted in the total PDPs.
CPU limits are generally not reached even during the maximum-rated capacity. The
On VMware deployments, each vCPU allocates one physical core.

Capacity
Table 32: IPPS KPIs
3G user plane OpenStack: 4000 Mbps cmmsg_2452a 3G VS.GtpuKbytesDownL

10/12/14 vCPUs GTPU Throughput inkPriClsX +
VS.GtpuKbytesUpLink
PriClsX (X=[1..4]) +
VMware: 10 vCPUs 3000 Mbps VS.GtpuKbytesDownL
inkPriClsStr +
VS.GtpuKbytesUpLink
OpenStack: 8 vCPUs 2500 Mbps PriClsStr +
VS.GtpuKbytesDownL
inkPriClsConv +
CNF: 10 vCPUs 640 Mbps VS.GtpuKbytesUpLink
PriClsConv
3G packets/s OpenStack: 1000 Kpps cmmsg_2453a 3G VS.GtpuPktsDownLink

10/12/14 vCPUs GTPU packets rate PriClsX +
VS.GtpuPktsUpLinkPri
ClsX (X=[1..4]) +
VMware: 10 vCPUs 750 Kpps VS.GtpuPktsDownLink
PriClsStr +
VS.GtpuPktsUpLinkPri
OpenStack: 8 vCPUs 625 Kpps ClsStr +
VS.GtpuPktsDownLink
PriClsConv +
CNF: 10 vCPUs 160 Kpps VS.GtpuPktsUpLinkPri
ClsConv
PDPs 10/12/14 vCPUs 4 000 000 cmmsg_706a Peak VS.PeakIuPdpCont

amount of Gb PDP (provided per PAPS)
VNF/CNF: 8 vCPUs 750 000 contexts
IPPS-PAPS 14 vCPUs 120 000 cmmsg_2463a 3G Via data-perog

messages transactions × 2.5 × analysis
12 vCPUs 90 000 (1-DT%) +
cmmsg_2463a 3G
OpenStack: 10 30 000 transactions × 2.5 ×
vCPUs (DT%)
VMware: 10 vCPUs 45 000
8 vCPUs 15 000
Intercepted All 1% of user plane traffic − −

data
Average CPUs All 75% 78% 81% cmm_296a Average VS.aveCpuUsage,

% IPPS CPU load VS.peakCpuUsage /
VS.avePerCoreCpuUs
age (for abnormal)
Memory % All 93% 95% 99% cmm_472a Peak VS.memUsage,

IPPS Memory usage VS.maxNEmemUsage

Capacity
5.10 LIHS pod

The Lawful Interception Handling service (LIHS) runs as a separate process on the IPDS
VM of a VNF CMM and as a pod on a CNF CMM.
LIHS has two flavors: default and large. The large LIHS must be used if the SGSN user plane
trace is planned to be used, as CTCS and LIHS share the common Redis database and CTCS
requires the larger Redis database flavor; otherwise, the default flavor can be used.

Capacity
6. Traffic model inputs required for dimensioning

Required and recommended traffic model values that are required for CMM dimensioning
are provided in the table in this section.
Note:
In the following tables, a request and a response are counted as two messages total.
Table 33: Traffic model factors for CMM dimensioning
Dimensioning factor Typical value (range) Relevant NetAct formulas and PM

counters
Required input1
5G SA SAUs − VS.RegisteredSubNbrMax
4G MBB SAUs − VS.MaxNbrOfRegisteredUE (4G)
4G IOT SAUs − VS.MaxNbrOfAttachNbIotUe
3G SAUs − VS.PeakAttachIuUsers
2G SAUs − VS.PeakAttachGbUsers
Strongly recommended input2
5G SA # Msg/UE/BH (eMBB) 750 (550−1500) VS.Ave5GCtrlMsgRate (not possible to

deduce per type)
5G SA # Msg/UE/BH (MBB 400 (350−700)
Idle mode connected)
5G SA # Msg/UE/BH (MIoT) 55 (30−250)
4G # Msg/UE/BH (MBB) 750 (550−1000) VS.Ave4GCtrlMsgRate (not possible to

deduce per type)
4G # Msg/UE/BH (3X-MBB) 850 (650−1100)
4G # Msg/UE/BH (NB-IOT) 100 (30−150)
3G # transactions/UE/BH 27 (25−50) cmmsg_2462a 2G transactions
3G # transactions/UE/BH 7.6 (5−15) cmmsg_2463a 3G transactions
3G # Data/UE 10 Kbps (5−30) cmmsg_2452a 3G GTPU Throughput
3G Direct Tunnel % 90% (85−97%) VS.DirectTunPdpContPeak/VS.PeakIuPdpC

ont
3G # Data/UE 1 kbps (0.5−4) cmmsg_2452a 3G GTPU Throughput

Capacity
Dimensioning factor Typical value (range) Relevant NetAct formulas and PM

counters
3
Recommended input
5G SA # Msg/Proc 10 (8−12) −
4G # Msg/Proc (MBB/NB- 8 (7−10) −

IOT)
4G # Msg/Proc (3X-MBB) 10 (8−12) −
3G # Msg/Proc 7 (6−8) −
Average is closer to 8
when direct tunnel is
90%+
2G # Msg/Proc 5 (5−7) −
2G Ciphering 80% (70−100%) cmmsg_2457b Ciphered user plane

packets throughput vs. cmmsg_2458b
Unciphered user plane pkt throughput
Avg. 3G Data Pkt Size 500 bytes (400−650) cmmsg_2454a 3G average packet size
Avg. 2G Data Pkt Size 500 bytes (400−650) cmmsg_2456a 2G average packet size
Percentage of 5G traffic 1% (0−5%) −

that is event exposure
service-related
Unnecessary input4
Number of bearers/UE Typically 1−2 Never is the limit
4G data traffic − −
CPU clockspeed 2000 to 2600 MHz Same engineered capacity no matter the
vCPU clockspeed (very minor differences
in reported CPU load)
Note 1: No default values are available for these dimensioning factors. Values must be given for each
deployment.
Note 2: Values or KPIs for each deployment are strongly recommended, although defaults may be
used if necessary.
Note 3: Values for each deployment are recommended; otherwise, defaults may be used.
Note 4: Values for these factors do not impact dimensioning.

Capacity
7. Disk I/O performance metrics

The disk input/output (I/O) performance metrics were measured in CMM21.5 application
running on top of CBIS 20 and AirFrame hardware with large configuration, and are
applicable to CMM21.8. The numbers provide guidance and visibility to the disk I/O
requirements for the CMM application.
CMM21.5 has been tested with standard AirFrame hardware. The values change when the
software changes.
Note:
The following tables show average values. Actual values depend on the traffic mix and
the configuration.
Table 34: Average disk I/O performance metrics for VNF
Average for VNF Value
Disk writes IOPS 600
Disk writes throughput 11 MBytes/s
Disk reads IOPS 10
Disk reads throughput 1.16 MBytes/s
IOPS(1s) write+read 11 MB/s + 1.6 MB/s = 12.6 MB/s (6.3 MB/s

without 100% headroom)

Capacity
Table 35: Average size block calculated: IOPS/kBps
Services IOPS Bandwidth kB/s Average

read/write
Average read Average write Average read Average write block size
NECC 2 12 820 3540 310
DBS 0 6 0 60 10
CPPS 0 6 0 60 10
PAPS 0 6 0 70 10
IPDS 0 6 1 60 10
IPPS 0 6 0 60 10
Table 36: Peaks (total for VNF)
Peaks (total for VNF) Value
Disk writes IOPS 15 000
Disk writes throughput 700 MBytes/s
Disk reads IOPS 3000
Disk reads throughput 160 MBytes/s
IOPS(1s) write+read 700 MB/s + 160 MB/s = 860 MB/s (430 MB/s without
100% headroom)
Note:
The peak IOPS and throughput are dependent on the maximum storage performance
that the infrastructure can provide. For example, increasing the infrastructure storage
performance can result in higher peaks, but shorter duration.

Capacity
Table 37: Highest I/O values in a one-second period per VM
Services IOPS Bandwidth kB/s Average

read/write
Peak read Peak write Peak read Peak write size block (K)
NECC 300 1200 50 000 37 500 300
DBS 5 70 50 900 10
CPPS 1 50 5 600 10
PAPS 0 60 0 800 10
IPDS 90 65 2700 800 20

CMM Nokia Capacity

Uploaded by

Copyright:

Available Formats

CMM Nokia Capacity

Uploaded by

Document Information

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

CMM Nokia Capacity

Uploaded by

Copyright:

Available Formats

No further reproduction or networking is permitted. Distributed by Nokia.

Copyrighted material licensed to [email protected] on 20-01-2023.

© 2021 Nokia. Nokia Condential Information

Use subject to agreed restrictions on disclosure and use.

No part of this document may be modied.

Copyright and trademark: Nokia is a registered trademark of Nokia Corporation. Other

2 © 2021 Nokia. Nokia confidential 4-0

Summary of changes .................................................................................................................... 6

1 About CMM capacity and configuration ..................................................................................... 9

2 Fixed system limits ..................................................................................................................... 10

3 Capacity overview for CMM deployments ............................................................................... 16

4 VM and pod resource requirements, scaling limits, and capacity ....................................... 24

6 Traffic model inputs required for dimensioning .................................................................... 53

7 Disk I/O performance metrics .................................................................................................. 55

4-0 © 2021 Nokia. Nokia confidential 3

4 © 2021 Nokia. Nokia confidential 4-0

Table 32 IPPS KPIs ........................................................................................................................ 51

4-0 © 2021 Nokia. Nokia confidential 5

Changes between issues 3-0 (CMM21.8) and 4-0 (CMM22)

6 © 2021 Nokia. Nokia confidential 4-0

Changes between issues 2-0 (CMM21.5) and 3-0 (CMM21.8)

4-0 © 2021 Nokia. Nokia confidential 7

Changes between issues 1-2 (CMM21 M2) and 2-0 (CMM21.5)

8 © 2021 Nokia. Nokia confidential 4-0

1. About CMM capacity and configuration

4-0 © 2021 Nokia. Nokia confidential 9

2. Fixed system limits

The following table lists the AMF system limits.

Table 1: AMF system limits

System parameter Maximum value

5G-AN gNB connectivity • CNF:

Tracking Areas (TAs) 10 000

TNLAs per gNB 16

SCP/SEPP per HTTP proxy list 8

TCP/HTTP2 connections 10 000

10 © 2021 Nokia. Nokia confidential 4-0

System parameter Maximum value

Trace targets per CMM 100

PDUs Per UE: 16

Slices (SNSSAI) SNSSAIs supported by AMF: 20

Max AMFs in a set A CMM supports up to 48 NR10 links towards

If the number of IPDS pairs is uneven, the

The following table lists the MME system limits.

Table 2: MME system limits

System parameter Maximum value

Tracking Areas (TAs) 20 000

MME TAIs with CMAS 10 000

4-0 © 2021 Nokia. Nokia confidential 11

System parameter Maximum value

LTE eNB connectivity • OpenStack deployments with multiple IPDS,

300 000 eNBs are achievable with three

• OpenStack deployments with single IPDS: up

PDN-GW (P-GW) IP address in HSS 16 per UE

Bearers per UE Maximum: 11 (any combination of default and

P-GW Up to 400 P-GW resource records in APN FQDN

Serving GW (S-GW) • Up to 254 NAPTR records per TAI-based DNS

S-GW, P-GW, and APN combinations 4096

Roaming restrictions Per UE: up to 320 forbidden TAIs and 320

IMSI range and roaming agreements • Up to 700 PLMN roaming agreements.

12 © 2021 Nokia. Nokia confidential 4-0