Skip to main content

OmniCore IP Planning Standard

Overview​

This document outlines the standard IP planning approach for OmniCore deployments. The architecture requires four internal subnets to properly segment network functions for security, performance, and operational clarity.

IP Allocation Requirements​

Standard Allocation: Four /24 Subnets​

Each OmniCore deployment requires four distinct subnets for internal networking:

  1. Packet Core Network - First /24
  2. Signaling Network - Second /24
  3. IMS Internal Network - Third /24
  4. IMS Public Network - Fourth /24

Important: These are Recommendations, Not Requirements​

The subnet allocation described in this document is a recommended best practice for organizing OmniCore deployments. However, the architecture is completely flexible:

  • All hosts in one subnet: You can place all components in a single subnet if that suits your deployment needs
  • Each host type in its own subnet: You can create separate subnets for each component type (one for MMEs, one for HSS, etc.)
  • Custom groupings: You can organize hosts into any subnet structure that makes sense for your specific requirements
  • Mix internal and public IPs: Some hosts can use internal (RFC 1918) addresses while others use public IPs, all within the same deployment

The recommended four-subnet approach provides optimal security isolation, traffic management, and operational clarity, which is why we suggest it for production deployments. However, you should adapt the IP plan to fit your specific network topology, available address space, and operational requirements.

Network Segment Breakdown​

1. Packet Core Network (First /24)​

Purpose: User plane and core control plane elements

Components:

  • OmniMME (Mobility Management Entity)
  • OmniSGW (Serving Gateway)
  • OmniPGW-C (PDN Gateway Control Plane)
  • OmniUPF/PGW-U (User Plane Function / PDN Gateway User Plane)

Example: 10.179.1.0/24

mme:
  hosts:
    customer-mme01:
      ansible_host: 10.179.1.15
      gateway: 10.179.1.1
      host_vm_network: "v400-omni-packet-core"

2. Signaling Network (Second /24)​

Purpose: Diameter signaling, policy, charging, and management functions

Components:

  • OmniHSS (Home Subscriber Server)
  • OmniCharge OCS (Online Charging System)
  • OmniHSS PCRF (Policy and Charging Rules Function)
  • OmniDRA DRA (Diameter Routing Agent)
  • DNS Servers (internal/infrastructure DNS - distinct from the customer-facing DNS in the IMS Public segment; both are intentional)
  • TAP3/CDR Servers
  • Monitoring/OAM
  • SIP capture
  • License Server
  • RAN Monitor
  • Omnitouch Warning Link CBC (Cell Broadcast Center) - if deployed

Example: 10.179.2.0/24

hss:
  hosts:
    omni-site-hss01:
      ansible_host: 10.179.2.140
      gateway: 10.179.2.1
      host_vm_network: "v401-omni-signalling"

3. IMS Internal Network (Third /24)​

Purpose: IMS core signaling and services (internal SIP signaling)

Components:

  • OmniCSCF S-CSCF (Serving Call Session Control Function)
  • OmniCSCF I-CSCF (Interrogating Call Session Control Function)
  • OmniTAS (Telephony Application Server / Application Server)
  • OmniMessage (SMS Controller, SMPP, IMS)

Example: 10.179.3.0/24

scscf:
  hosts:
    omni-site-scscf01:
      ansible_host: 10.179.3.45
      gateway: 10.179.3.1
      host_vm_network: "v402-omni-ims-internal"

4. IMS Public Network (Fourth /24)​

Purpose: User-facing IMS services, customer-facing DNS, and SS7/legacy interconnect

Components:

  • OmniCSCF P-CSCF (Proxy Call Session Control Function)
  • XCAP Servers
  • Visual Voicemail Servers
  • Customer DNS
  • OmniSS7 STP (SS7 Signaling Transfer Point)
  • OmniSS7 HLR (Home Location Register) - for 2G/3G
  • OmniSS7 IP-SM-GW (MAP SMSc)
  • OmniSS7 CAMEL Gateway
  • MSC (Mobile Switching Centre)

Note: SS7/HLR and related legacy interconnect functions commonly sit in the public segment, since they peer with external 2G/3G networks over SIGTRAN/M3UA rather than internal IMS SIP.

Example: 10.179.4.0/24

pcscf:
  hosts:
    omni-site-pcscf01:
      ansible_host: 10.179.4.165
      gateway: 10.179.4.1
      host_vm_network: "v403-omni-ims-public"

Implementation Methods​

OmniCore supports two primary methods for implementing this network segmentation:

Use separate NICs or virtual bridges for each network segment. This provides the strongest isolation and is the recommended approach for production deployments. The convention is to name each bridge after its segment (v400-omni-packet-core, v401-omni-signalling, v402-omni-ims-internal, v403-omni-ims-public), though a single shared bridge (e.g. vmbr0) is also valid where segmentation is handled elsewhere.

Example:

# Packet Core - v400-omni-packet-core
mme:
  hosts:
    omni-site-mme01:
      ansible_host: 10.179.1.15
      gateway: 10.179.1.1
      host_vm_network: "v400-omni-packet-core"

# Signaling - v401-omni-signalling
hss:
  hosts:
    omni-site-hss01:
      ansible_host: 10.179.2.140
      gateway: 10.179.2.1
      host_vm_network: "v401-omni-signalling"

# IMS Internal - v402-omni-ims-internal
icscf:
  hosts:
    omni-site-icscf01:
      ansible_host: 10.179.3.55
      gateway: 10.179.3.1
      host_vm_network: "v402-omni-ims-internal"

# IMS Public - v403-omni-ims-public
pcscf:
  hosts:
    omni-site-pcscf01:
      ansible_host: 10.179.4.165
      gateway: 10.179.4.1
      host_vm_network: "v403-omni-ims-public"

Method 2: VLAN-Based Segmentation​

Use a single physical interface with VLAN tagging to separate networks. This is suitable for smaller deployments or when physical NICs are limited.

Example:

# All components share one bridge (ovsbr1); each segment uses a different VLAN tag.
# applicationserver (TAS) is an IMS Internal component -> VLAN 402 / 10.178.3.x
applicationserver:
  hosts:
    omni-site-sbc01:
      ansible_host: 10.178.3.213
      gateway: 10.178.3.1
      host_vm_network: "ovsbr1"
      vlanid: "402"

# dra and dns are Signaling components -> VLAN 401 / 10.178.2.x
dra:
  hosts:
    omni-site-dra01:
      ansible_host: 10.178.2.211
      gateway: 10.178.2.1
      host_vm_network: "ovsbr1"
      vlanid: "401"

dns:
  hosts:
    omni-site-dns01:
      ansible_host: 10.178.2.178
      gateway: 10.178.2.1
      host_vm_network: "ovsbr1"
      vlanid: "401"

Network Configuration:

  • Configure VLANs on the physical switch
  • Tag traffic appropriately at the hypervisor level
  • Route between VLANs at the gateway/firewall

Example VLAN Mapping:

VLAN 400: 10.x.1.0/24 (Packet Core)
VLAN 401: 10.x.2.0/24 (Signaling)
VLAN 402: 10.x.3.0/24 (IMS Internal)
VLAN 403: 10.x.4.0/24 (IMS Public)

Working with Public IP Addresses​

Overview​

Many OmniCore deployments require some components to have public IP addresses for external connectivity, such as:

  • DRA - For roaming diameter signaling with external carriers
  • Roaming SGW/PGW - For GTP traffic from roaming partners
  • ePDG - For WiFi calling (IPsec tunnels from UEs)
  • SMSC Gateway - For SMPP connections to external SMS aggregators
  • P-CSCF (in some deployments) - For direct UE SIP registration

How to Assign Public IPs​

Public IPs are handled exactly the same way as internal IPs in your host inventory files. Simply specify the public IP address in the ansible_host field along with the appropriate gateway and netmask.

Example: Roaming SGW/PGW with Public IPs

sgw:
  hosts:
    # Internal SGWs on private network
    customer-site-sgw01:
      ansible_host: 10.4.1.25
      gateway: 10.4.1.1
      host_vm_network: "v400-omni-packet-core"

    # Roaming SGWs with public IPs
    customer-site-roaming-sgw01:
      ansible_host: 203.0.113.10
      gateway: 203.0.113.9
      netmask: 255.255.255.248       # /29 subnet
      host_vm_network: "498-public-servers"
      in_pool: False
      cdrs_enabled: True

smf:  # PGWs
  hosts:
    # Roaming PGW with public IP
    customer-site-roaming-pgw01:
      ansible_host: 203.0.113.20
      gateway: 203.0.113.17
      netmask: 255.255.255.240       # /28 subnet
      host_vm_network: "497-public-services-LTE"
      in_pool: False
      ip_pools:
        - '100.64.24.0/22'

Example: DRA with Public IP

dra:
  hosts:
    customer-site-dra01:
      ansible_host: 198.51.100.50
      gateway: 198.51.100.49
      netmask: 255.255.255.240       # /28 subnet
      host_vm_network: "497-public-services-LTE"

Example: ePDG with Public IP

epdg:
  hosts:
    customer-site-epdg01:
      ansible_host: 198.51.100.51
      gateway: 198.51.100.49
      netmask: 255.255.255.240       # /28 subnet
      host_vm_network: "497-public-services-LTE"

Mixing Internal and Public IPs​

It's common to have a mix of internal and public IPs within the same component group. For example:

  • Internal SGWs for local sites using GTP
  • Public SGWs specifically for roaming traffic from external carriers
  • The same PGW-C can manage both internal and external SGWs

OmniCore's architecture handles this seamlessly - just configure each host with its appropriate IP addressing.

Last updated on