OmniCall CSCF Capacity and Dimensioning Guide
Overview
This guide provides capacity planning and dimensioning information for OmniCall CSCF deployments. The capacity numbers presented here are guidelines based on source code analysis and production experience, not hard limits.
Horizontal Scaling Strategy
OmniCall CSCF achieves virtually unlimited scale through horizontal scaling - simply deploy additional instances as your subscriber base grows. There is no practical upper limit to total network capacity.
Key Scaling Principles:
✓ Add instances, not complexity: Need to support 1 million subscribers? Deploy 3-4 S-CSCF instances instead of one massive server
✓ Independent components: Each P-CSCF, I-CSCF, and S-CSCF instance operates independently
✓ Load distribution: I-CSCF automatically distributes users across S-CSCF instances; DNS or load balancers distribute traffic to P-CSCF and I-CSCF
✓ No session affinity required: Users can be distributed across different CSCF instances
✓ Geographic distribution: Deploy CSCF instances across multiple data centers for resilience and latency optimization
Example Scaling Path:
- 10K subscribers: 1 P-CSCF, 1 I-CSCF, 1 S-CSCF
- 50K subscribers: 2 P-CSCF, 2 I-CSCF, 2 S-CSCF
- 200K subscribers: 6 P-CSCF, 4 I-CSCF, 4 S-CSCF
- 1M subscribers: 30 P-CSCF, 10 I-CSCF, 10 S-CSCF
- 10M subscribers: 300 P-CSCF, 50 I-CSCF, 50 S-CSCF
Cost-Effective Scaling: Commodity hardware + horizontal scaling = lower CapEx than expensive "big iron" solutions.
About These Guidelines
The capacity numbers in this document are conservative estimates designed to:
- Provide headroom for traffic spikes (registration storms, mass calling events)
- Account for complex IFC processing and multiple Application Server integrations
- Ensure sub-second response times even under load
- Support high availability configurations with failover capacity
Your mileage may vary based on:
- Hardware specifications (CPU speed, RAM, network bandwidth)
- IFC complexity and number of Application Servers
- Registration expiry timers (shorter = more frequent re-registrations)
- Call holding times and busy hour traffic patterns
Recommendation: Use these guidelines as a starting point, then monitor production metrics to optimize instance counts and configuration for your specific deployment.
Table of Contents
- Executive Summary
- P-CSCF Capacity
- I-CSCF Capacity
- S-CSCF Capacity
- Deployment Sizing
- Performance Optimization
- Monitoring and Alerts
- Summary: Unlimited Scale Through Horizontal Scaling
Executive Summary
Key Capacity Constraints
| CSCF Type | Primary Constraint | Maximum per Instance | Typical Deployment |
|---|---|---|---|
| P-CSCF | IPsec Security Associations | ~50,000 UEs | 10,000-30,000 UEs |
| I-CSCF | CPU/Network (stateless) | Limited by throughput | 100,000+ req/sec |
| S-CSCF | User Registrations | ~500,000 IMPUs | 100,000-300,000 IMPUs |
| Dialogs | Active Call State | ~100,000 dialogs | 20,000-50,000 concurrent |
Technical Limits (Per Instance)
OmniCall CSCF has some technical boundaries per instance. These are not deployment limits - total capacity is unlimited through horizontal scaling:
| Limit | Value | What It Means | Solution |
|---|---|---|---|
| SPI Hash Tracking | 10,000 entries | Internal tracking structure for IPsec SPIs | This does NOT limit registrations to 10K. P-CSCF can handle 40K-50K registrations with proper configuration. Deploy more P-CSCF VMs for higher scale. |
| Contacts per IMPU | 100 | Maximum SIP contacts per public identity | Rarely hit in practice (typical: 1-5 contacts per user). Add S-CSCF VMs if needed. |
| Service Routes | 10 per contact | Maximum service route headers | Typical usage: 1-3. Not a constraint. |
| NOTIFY Body Size | 16 KB | Maximum notification message size | Split large subscriber lists across S-CSCF instances. |
Clarification on SPI Hash Limit:
- The 10,000 SPI hash limit is an internal tracking structure, not a hard registration limit
- P-CSCF instances regularly handle 40,000-50,000 concurrent registrations in production
- The SPI hash is used for fast lookups; actual IPsec SAs are managed separately by the kernel
- If you approach capacity limits, simply deploy additional P-CSCF VMs
Key Point: These are engineering limits for a single VM instance. For unlimited scale, deploy more VMs.
P-CSCF Capacity
The Proxy-CSCF is typically the most capacity-constrained component due to IPsec security association overhead.
Capacity Factors
1. IPsec Security Associations
Per-UE Memory Footprint:
Each IPsec SA consumes approximately:
- SPI tracking: ~200 bytes (hash table entry)
- Socket binding: ~1-2 KB (kernel resources)
- Contact state: ~500-1000 bytes (registration data)
- Total per UE: ~2-3 KB in shared memory
Per-Instance Capacity Guidelines:
- Aggressive: 40,000-50,000 UEs (approaches SPI hash limit)
- Recommended: 20,000-30,000 UEs (balanced performance and headroom)
- Conservative: 10,000-15,000 UEs (maximum HA headroom for failover)
Scaling Beyond Single Instance:
- 100K subscribers: Deploy 3-5 P-CSCF instances behind DNS load balancing
- 500K subscribers: Deploy 15-25 P-CSCF instances across multiple sites
- 1M+ subscribers: Deploy 30-50+ P-CSCF instances with geographic distribution
Note: These are guidelines, not limits. Production deployments have successfully run P-CSCF instances at 40K+ UEs with proper tuning.
2. Emergency Services
Emergency call handling uses in-memory storage for IMEI-to-callback mappings (24-hour TTL) to support emergency callbacks.
P-CSCF VM Requirements
Standard VM Specification: 8 vCPU, 8 GB RAM minimum
| Deployment Size | UEs per VM | VMs Needed for Example Deployments |
|---|---|---|
| Conservative | 10,000-15,000 | 10K subs = 1 VM, 50K subs = 4 VMs, 100K subs = 7 VMs |
| Recommended | 20,000-30,000 | 10K subs = 1 VM, 50K subs = 2 VMs, 100K subs = 4 VMs |
| Aggressive | 40,000-50,000 | 10K subs = 1 VM, 50K subs = 1 VM, 100K subs = 2 VMs |
VoWiFi with OmniePDG:
- OmniePDG terminates IPsec, P-CSCF handles only SIP
- Capacity increases to 80,000-100,000 UEs per P-CSCF VM
- 100K VoWiFi users = 1-2 P-CSCF VMs (vs. 4 VMs for VoLTE)
I-CSCF Capacity
The Interrogating-CSCF is stateless and primarily limited by CPU and network throughput rather than memory.
Capacity Factors
1. Stateless Design
- No session state: I-CSCF does not maintain user registrations or dialogs
- HSS queries: Each registration requires 1 Cx UAR/UAA exchange
- Throughput-based: Limited by REGISTER/INVITE processing rate
Typical Throughput:
- Registration Rate: 1,000-5,000 registrations/second (depending on HSS latency)
- Call Setup Rate: 5,000-10,000 INVITE/second
- Simultaneous Subscribers: Effectively unlimited (no state maintained)
2. S-CSCF Selection
I-CSCF maintains a pool of available S-CSCF instances (typically 2-10) for load balancing based on capabilities and current load.
I-CSCF VM Requirements
Standard VM Specification: 4 vCPU, 8 GB RAM minimum
| Deployment Size | Throughput per VM | VMs Needed for Example Deployments |
|---|---|---|
| Conservative | 1,000 reg/sec | 10K subs = 1 VM, 100K subs = 2 VMs, 500K subs = 4 VMs |
| Recommended | 2,000 reg/sec | 10K subs = 1 VM, 100K subs = 1 VM, 500K subs = 2 VMs |
| Aggressive | 5,000 reg/sec | 10K subs = 1 VM, 100K subs = 1 VM, 500K subs = 1 VM |
Scaling Strategy: Deploy multiple I-CSCF instances behind DNS round-robin or hardware load balancer. Each instance is independent and stateless.
S-CSCF Capacity
The Serving-CSCF maintains registration state and active dialogs, making it the core scalability component.
Capacity Factors
1. User Registrations
Memory Footprint per IMPU:
Each registered IMPU consumes approximately:
- Hash entry: ~1-2 KB (IMPU, contacts, expires)
- IFC (Initial Filter Criteria): ~5-20 KB (service profile from HSS)
- Authentication vectors: ~1-2 KB
- Total per IMPU: ~7-25 KB depending on service complexity
Per-Instance Capacity Guidelines:
- Aggressive: 400,000-500,000 IMPUs (with hash_size=14+, high-spec hardware)
- Recommended: 200,000-300,000 IMPUs (balanced load, typical IFC complexity)
- Conservative: 100,000-150,000 IMPUs (complex IFC, multiple AS, HA headroom)
Scaling for Large Deployments:
- 1M subscribers: Deploy 3-5 S-CSCF instances, I-CSCF distributes via HSS
- 5M subscribers: Deploy 15-25 S-CSCF instances across multiple data centers
- 10M+ subscribers: Deploy 30-50+ S-CSCF instances
Note: These are starting guidelines. Actual capacity depends on IFC complexity, AS integration, and hardware specifications. Some production deployments run 400K+ IMPUs per instance with optimized configurations.
2. Active Dialogs (Call Sessions)
Memory Footprint per Dialog:
Each active dialog consumes approximately:
- Dialog state: ~2-4 KB (Call-ID, From/To tags, route set)
- SDP information: ~1-2 KB (media parameters)
- Profiles/variables: ~1-2 KB
- Total per dialog: ~4-8 KB
Per-Instance Capacity Guidelines:
- Aggressive: 80,000-100,000 concurrent dialogs (with dlg_hash_size=15+)
- Recommended: 40,000-60,000 concurrent dialogs (typical deployment)
- Conservative: 20,000-30,000 concurrent dialogs (maximum HA headroom)
Scaling for High Call Volume:
- 100K concurrent calls: Deploy 2-3 S-CSCF instances
- 500K concurrent calls: Deploy 10-15 S-CSCF instances
- 1M+ concurrent calls: Deploy 20-30+ S-CSCF instances
Note: Dialog capacity is often higher than registration capacity since dialogs are short-lived (seconds to minutes) while registrations are long-lived (minutes to hours). Monitor actual busy-hour concurrent call rates to optimize.
3. Initial Filter Criteria (IFC) Processing
IFC Complexity Impact:
- Simple IFC (1-5 trigger points): Minimal overhead
- Complex IFC (10+ trigger points, multiple AS): 5-10 ms additional processing per call
- Memory: 5-20 KB per user depending on service profile complexity
S-CSCF VM Requirements
Standard VM Specification: 8 vCPU, 8 GB RAM minimum
| Deployment Size | IMPUs per VM | Concurrent Dialogs per VM | VMs Needed for Example Deployments |
|---|---|---|---|
| Conservative | 100,000-150,000 | 20,000-30,000 | 10K subs = 1 VM, 100K subs = 1 VM, 500K subs = 4 VMs |
| Recommended | 200,000-300,000 | 40,000-60,000 | 10K subs = 1 VM, 100K subs = 1 VM, 500K subs = 2 VMs |
| Aggressive | 400,000-500,000 | 80,000-100,000 | 10K subs = 1 VM, 100K subs = 1 VM, 500K subs = 1 VM |
Deployment Sizing
Small Deployment (< 10,000 Subscribers)
Scenario: MVNO, small enterprise, lab/test environment
| Component | VM Count | VMs Specification | Capacity per VM |
|---|---|---|---|
| P-CSCF | 1 | 8 vCPU, 8 GB RAM | 10,000-15,000 UEs |
| I-CSCF | 1 | 4 vCPU, 8 GB RAM | 1,000-2,000 reg/sec |
| S-CSCF | 1 | 8 vCPU, 8 GB RAM | 100,000-200,000 IMPUs |
| Total VMs | 3 | ||
| Total Capacity | Up to 15,000 subscribers |
Medium Deployment (10,000-100,000 Subscribers)
Scenario: Regional carrier, tier-2 operator, large enterprise
Conservative Sizing (100K subscribers):
| Component | VM Count | VMs Specification | Capacity per VM |
|---|---|---|---|
| P-CSCF | 4 | 8 vCPU, 8 GB RAM | 25,000 UEs each |
| I-CSCF | 2 | 4 vCPU, 8 GB RAM | 2,000 reg/sec each |
| S-CSCF | 2 | 8 vCPU, 8 GB RAM | 150,000 IMPUs each |
| Total VMs | 8 | ||
| Total Capacity | 100,000 subscribers |
Recommended Sizing (100K subscribers):
| Component | VM Count | VMs Specification | Capacity per VM |
|---|---|---|---|
| P-CSCF | 2 | 8 vCPU, 8 GB RAM | 50,000 UEs each |
| I-CSCF | 1 | 4 vCPU, 8 GB RAM | 5,000 reg/sec |
| S-CSCF | 1 | 8 vCPU, 8 GB RAM | 300,000 IMPUs |
| Total VMs | 4 | ||
| Total Capacity | 100,000 subscribers |
High Availability:
- Deploy I-CSCF behind DNS round-robin or load balancer
- I-CSCF distributes users across S-CSCF pool
- Geographic distribution recommended for resilience
Large Deployment (500,000 Subscribers)
Scenario: Tier-1 carrier, national operator
Conservative Sizing:
| Component | VM Count | VMs Specification | Capacity per VM |
|---|---|---|---|
| P-CSCF | 25 | 8 vCPU, 8 GB RAM | 20,000 UEs each |
| I-CSCF | 4 | 4 vCPU, 8 GB RAM | 2,000 reg/sec each |
| S-CSCF | 4 | 8 vCPU, 8 GB RAM | 150,000 IMPUs each |
| Total VMs | 33 | ||
| Total Capacity | 500,000 subscribers |
Recommended Sizing:
| Component | VM Count | VMs Specification | Capacity per VM |
|---|---|---|---|
| P-CSCF | 15 | 8 vCPU, 8 GB RAM | 33,000 UEs each |
| I-CSCF | 2 | 4 vCPU, 8 GB RAM | 5,000 reg/sec each |
| S-CSCF | 2 | 8 vCPU, 8 GB RAM | 250,000 IMPUs each |
| Total VMs | 19 | ||
| Total Capacity | 500,000 subscribers |
Aggressive Sizing:
| Component | VM Count | VMs Specification | Capacity per VM |
|---|---|---|---|
| P-CSCF | 10 | 8 vCPU, 8 GB RAM | 50,000 UEs each |
| I-CSCF | 1 | 4 vCPU, 8 GB RAM | 5,000 reg/sec |
| S-CSCF | 1 | 8 vCPU, 8 GB RAM | 500,000 IMPUs |
| Total VMs | 12 | ||
| Total Capacity | 500,000 subscribers |
High Availability:
- Active-active P-CSCF across data centers
- Geo-redundant I-CSCF with DNS or BGP anycast
- Multiple S-CSCF instances with I-CSCF load distribution
VoWiFi Deployment Considerations
With OmniePDG:
- P-CSCF capacity increases significantly (no IPsec overhead on P-CSCF)
- ePDG handles IPsec tunnel termination
- P-CSCF can support 100,000+ VoWiFi users (limited by CPU/network, not IPsec)
Architecture:
VoWiFi UE → (IPsec) → OmniePDG → (SIP) → P-CSCF → I-CSCF → S-CSCF
VoLTE UE → (IPsec) → P-CSCF → I-CSCF → S-CSCF
Recommendation: For large VoWiFi deployments (>50K users), deploy dedicated P-CSCF instances behind OmniePDG without IPsec module loaded for maximum throughput.
Performance Optimization
OmniCall CSCF is delivered pre-optimized for production use. Performance tuning is handled by OmniCall engineering during deployment.
Standard VM Configuration
All OmniCall CSCF VMs are configured with:
- OS: Linux kernel tuning for high network throughput
- Memory: Optimized shared memory allocation for hash tables and session state
- Network: TCP/IP stack tuning for SIP and Diameter traffic
Deployment-Specific Tuning
For custom tuning based on your specific deployment requirements, contact OmniCall support. Common tuning scenarios include:
- High call volume: Adjusting worker processes and dialog capacity
- Large subscriber base: Optimizing registration hash tables
- Complex IFC: Tuning notification processes for Application Server integration
- Geographic distribution: Optimizing failover and redundancy
Monitoring and Alerts
Key Performance Indicators (KPIs)
P-CSCF Metrics
| Metric | Description | Warning Threshold | Critical Threshold |
|---|---|---|---|
| IPsec SA Count | Active security associations | > 25,000 | > 40,000 |
| SPI Hash Utilization | Percentage of SPI range used | > 70% | > 90% |
| Registration Rate | REGISTER requests/sec | > 100/sec | > 500/sec |
| Contact Hash Load | Avg contacts per hash slot | > 20 | > 50 |
| Memory Usage | Shared memory consumption | > 70% | > 90% |
Prometheus Queries:
# IPsec SA count (from hash table monitoring)
ipsec_sa_count{cscf="pcscf01"}
# Registration rate
rate(sip_register_requests_total{cscf="pcscf01"}[5m])
S-CSCF Metrics
| Metric | Description | Warning Threshold | Critical Threshold |
|---|---|---|---|
| Registered IMPUs | Total registered users | > 300,000 | > 450,000 |
| Active Dialogs | Concurrent call sessions | > 40,000 | > 70,000 |
| IMPU Hash Load | Avg IMPUs per hash slot | > 50 | > 100 |
| Dialog Hash Load | Avg dialogs per hash slot | > 10 | > 20 |
| IFC Processing Time | Avg IFC evaluation time | > 10 ms | > 50 ms |
Prometheus Queries:
# Registered users
impu_registered_count{cscf="scscf01"}
# Active dialogs
dialog_active_count{cscf="scscf01"}
I-CSCF Metrics
| Metric | Description | Warning Threshold | Critical Threshold |
|---|---|---|---|
| Registration TPS | REGISTER transactions/sec | > 1,000/sec | > 2,000/sec |
| HSS Query Latency | Cx Diameter response time | > 50 ms | > 200 ms |
| HSS Failure Rate | Percentage of failed HSS queries | > 1% | > 5% |
Health Checks
System Health Monitoring:
OmniCall CSCF exports comprehensive health metrics via the control panel and Prometheus endpoints (http://<host>:9090/metrics). Monitor:
- IPsec SA counts (P-CSCF)
- Registration counts (P-CSCF, S-CSCF)
- Active dialog counts (S-CSCF)
- Memory utilization
- CPU utilization
For a complete list of all available metrics, see the Metrics Reference.
Alert Rules (Prometheus/Alertmanager)
groups:
- name: cscf_capacity
rules:
- alert: PCSCFIPsecSAHigh
expr: ipsec_sa_count > 40000
for: 5m
annotations:
summary: "P-CSCF {{ $labels.instance }} has high IPsec SA count"
- alert: SCSCFRegistrationHigh
expr: impu_registered_count > 450000
for: 10m
annotations:
summary: "S-CSCF {{ $labels.instance }} approaching registration capacity"
- alert: SCSCFDialogHigh
expr: dialog_active_count > 70000
for: 5m
annotations:
summary: "S-CSCF {{ $labels.instance }} has high active dialog count"
Appendix: Capacity Planning Methodology
This dimensioning guide is based on:
- Production Deployments: Analysis of real-world OmniCall CSCF deployments ranging from 5K to 500K+ subscribers
- Performance Testing: Load testing and benchmarking across various hardware configurations
- 3GPP Standards: Compliance with 3GPP specifications for IMS capacity and performance
- Engineering Analysis: Detailed technical review of CSCF architecture and resource utilization
Validation: All capacity numbers have been validated in production carrier networks.
Summary: Unlimited Scale Through Horizontal Scaling
Key Takeaways
-
No Hard Limits on Total Capacity: The per-instance limits documented in this guide are conservative guidelines, not absolute ceilings. Total network capacity is unlimited through horizontal scaling.
-
Simple Scaling Model:
Need more capacity? → Deploy more instances
Hit a per-instance limit? → Add another instance
Traffic growing? → Spin up more VMs -
Proven at Scale: OmniCall CSCF deployments range from:
- Small MVNOs: 5K-10K subscribers on 3-5 VMs
- Regional carriers: 50K-200K subscribers on 10-30 VMs
- Tier-1 operators: 1M+ subscribers on 100+ VMs
-
Cost-Effective Growth: Scale incrementally with commodity hardware rather than expensive forklift upgrades. Add capacity as revenue grows.
-
Guidelines, Not Rules: The capacity numbers in this document are:
- ✅ Conservative estimates with built-in headroom
- ✅ Based on source code analysis and production experience
- ✅ Useful starting points for planning
- ❌ NOT hard limits that cannot be exceeded
- ❌ NOT one-size-fits-all prescriptions
Real-World Scaling Example
Scenario: Growing from 10K to 1M subscribers over 3 years
| Year | Subscribers | P-CSCF | I-CSCF | S-CSCF | Action |
|---|---|---|---|---|---|
| Year 0 | 10,000 | 1 | 1 | 1 | Initial deployment (3 VMs) |
| Year 1 | 50,000 | 2 | 2 | 2 | 2x growth: Add 3 VMs |
| Year 1.5 | 100,000 | 4 | 3 | 3 | 2x growth: Add 4 VMs |
| Year 2 | 250,000 | 8 | 4 | 5 | 2.5x growth: Add 6 VMs |
| Year 3 | 500,000 | 15 | 6 | 8 | 2x growth: Add 13 VMs |
| Future | 1,000,000 | 30 | 10 | 10 | 2x growth: Add 24 VMs |
Total Investment: Incremental VM additions as revenue grows, not massive upfront CapEx.
When to Add Instances
Monitor these signals to know when to scale horizontally:
P-CSCF:
- IPsec SA count consistently >30K (>70% of recommended capacity)
- CPU utilization >70% during busy hour
- Registration response times >500ms
S-CSCF:
- IMPU count consistently >250K (>70% of recommended capacity)
- Dialog count approaching 50K concurrent
- CPU utilization >70% during busy hour
I-CSCF:
- Request rate consistently >2,000/sec per instance
- CPU utilization >80% during busy hour
- HSS query latency increasing
Action: Add 1-2 instances proactively before hitting limits. Horizontal scaling is cheap insurance against capacity issues.
Configuration Philosophy
Start Conservative, Tune as You Grow:
- Begin with recommended configurations from this guide
- Monitor production metrics (see Monitoring)
- Tune hash sizes and worker processes based on actual load
- Add instances before hitting 80% of observed capacity limits
- Test configurations in staging before production deployment
Remember: These guidelines provide a proven starting point, but every deployment is unique. Your actual capacity may be higher or lower depending on your specific environment, traffic patterns, and requirements.