🔧

Section 11.4

Mobile Core Integration (4G / 5G)

Mobile core as a single orchestration domain. 3GPP refresher (4G EPC: HSS/MME/S-PGW/PCRF; 5GC: AMF/SMF/UPF/UDM/PCF/NSSF/NRF). What the orchestrator actually configures (subscriber/profile, DNN/APN, QoS, slice templates, policy). Network slicing as the first-class XDO use case (3GPP 28-series, GSMA GST/NEST). MANO architecture (NFVO/VNFM/VIM) and Day-0/1/2 lifecycle. NFVI generations (OpenStack vs Kubernetes). Vendor stacks (Nokia OC, Ericsson SOA, Mavenir, ONAP). Anti-patterns: treating 5GC NFs as routers, SOM hard-coding infrastructure, slice = list of NF configs.

Mobile core is the OSS domain where the orchestration story is most often misconceived. Modern 5G core (5GC) network functions are cloud-native software, deployed on Kubernetes, and configured through 3GPP service-based interfaces. Treating them as routers — pushing per-NF YANG and CLI through a domain controller — produces an architecture that breaks the moment slice instantiation, lifecycle scaling, or NF replacement enters the picture.

This section covers the mobile core as a single orchestration domain spanning subscriber data, session management, policy, and the NFV/MANO stack that instantiates the NFs themselves. The goal is to make the integration explicit at three levels: the service intent the orchestrator receives (network slice, enterprise APN, subscriber profile), the 3GPP-aligned operations the orchestrator performs against the NFs, and the infrastructure lifecycle that MANO manages underneath.

3GPP Architecture Refresher: 4G EPC and 5GC

The mobile core has two distinct generations in concurrent production use. 4G EPC is monolithic, control- and user-plane often co-resident, integrated via Diameter and GTP. 5GC is a service-based architecture (SBA), strictly separated control and user planes, and integrated via HTTP/2 service-based interfaces (SBI). Most Tier-1s run both, with EPC carrying voice (VoLTE) and legacy LTE data while 5GC carries NSA and SA 5G traffic.

4G EPC and 5GC — the network functions an orchestrator configures

Function	Generation	Role	Typical orchestrator interaction
HSS (Home Subscriber Server)	4G EPC	Subscriber data store — IMSI, profiles, authentication keys	Diameter Sh / Cx; subscriber CRUD via OSS provisioning workflow
MME (Mobility Management Entity)	4G EPC	Control plane — attach, mobility, bearer setup	Configured via vendor EMS / SBI; rarely per-subscriber
S-GW / P-GW	4G EPC	User plane — anchor for sessions, packet forwarding	APN config via vendor EMS; policy via Gx
PCRF	4G EPC	Policy and charging — Gx/Gy rules	Policy push via Gx; profile updates via SOAP/REST per vendor
UDM / UDR (Unified Data Management / Repository)	5GC	Subscriber data and authentication for 5GC	Nudm / Nudr SBI; subscriber CRUD, slice profile association
AMF (Access and Mobility)	5GC	Registration, mobility, NAS termination	Configured via Namf; slice-aware
SMF (Session Management)	5GC	Session setup, IP allocation, UPF selection	Configured via Nsmf; DNN / S-NSSAI bindings
UPF (User Plane Function)	5GC	Data forwarding, QoS enforcement	Configured via Nupf-equivalent / vendor control; CUPS-aligned
NRF / NSSF / AUSF / PCF	5GC	Service discovery, slice selection, authentication, policy	Mostly NF-to-NF SBI; orchestrator configures via Nnssf, Nnrf for slice templates

Why SBI changes the integration story

In 4G EPC, every interface (Sh, Gx, Gy, S6a) is a different Diameter application with different semantics. In 5GC, every NF exposes a uniform HTTP/2 service-based interface, with consistent registration via NRF. This is what makes 5GC genuinely orchestratable — the orchestrator can speak one protocol family across all NFs, with consistent retry, idempotency, and service discovery. EPC integration was a per-NF adapter problem; 5GC is a service-design problem.

What the Orchestrator Actually Configures

The mobile core orchestrator does not configure devices — it configures subscribers, services, and slices. The three categories of work look different from any other OSS domain because the bottom layer is software, not boxes.

Orchestrator-driven configuration in mobile core

Object	Where it lives	Service intent	Underlying operation
Subscriber profile	HSS (4G) / UDM-UDR (5GC)	"Provision IMSI 234150999... with profile Enterprise-Voice-Plus"	Sh / Nudm CRUD; SUPI registration; key material; policy class binding
APN / DNN	PCRF + P-GW (4G) / SMF + UPF + PCF (5GC)	"Enable corp-internet APN for this enterprise group"	APN config push, IP pool assignment, QoS profile binding
QoS profile	PCRF (4G) / PCF (5GC)	"Apply 100 Mbps with 99.99% packet delivery for slice S1"	5QI mapping, ARP, AMBR, GBR profiles
Network slice instance	NSSF + slice-aware NFs (5GC)	"Instantiate slice S-NSSAI 01:CAFE01 for enterprise X"	Slice template realisation across AMF/SMF/UPF/UDM; transport slice request to IP/MPLS domain
Policy rule (PCC)	PCRF / PCF	"Throttle video to 5 Mbps after 50 GB"	Gx / Npcf rule push; charging key updates
NF instance scaling	MANO (NFVO + VNFM)	"Add UPF capacity in region EU-West"	NS lifecycle scale-out via NFVO; VNFM Helm chart update; new pods registered with NRF

Network Slicing: The First-Class XDO Use Case

Network slicing is the use case that justifies the existence of cross-domain orchestration in mobile networks. A slice is not a 5GC concept alone — it spans RAN, transport, and core, with consistent SLA across all three. The orchestrator that fulfils a slice cannot live inside any one of those domains; it must coordinate them. This is precisely the cross-domain orchestration layer described in 11.1, applied to its hardest production use case.

A logical mobile network identified by an S-NSSAI (Slice Service Type + Slice Differentiator), with its own SLA and policy.
Realised across the RAN slice (radio resources, scheduler weighting), the transport slice (IP/MPLS or SR with SLA-aligned class), and the core slice (slice-aware AMF/SMF/UPF/UDM).
Provisioned for use cases like enterprise verticals, IoT, fixed-wireless access, or low-latency industrial applications.

3GPP TS 28.530–28.541 define slice management and the management service architecture (CSMF, NSMF, NSSMF — the slice-management functions). GSMA GST (Generic network Slice Template) and NEST (Network Slice Type) standardise slice templates so enterprise customers can request slices in industry-portable terms (e.g. "URLLC industrial control" with defined latency/jitter/availability).

The orchestrator typically receives a NEST-aligned slice request from CSMF (customer-facing), decomposes it into NSMF (network slice management) and NSSMF (subnet slice management) operations across RAN/transport/core, and tracks the slice instance lifecycle as a first-class TMF service.

Cross-domain SLA composition — a 10 ms end-to-end latency slice requires latency budget allocation across RAN, transport, and core. No single domain controller can guarantee this; only the cross-domain orchestrator can.
Lifecycle independence — RAN, transport, and core scale on different cadences and may be operated by different teams or even different vendors. The orchestrator must allow each subnet slice to evolve without breaking the slice instance contract.
Slice isolation vs sharing — strict slice isolation requires dedicated NF instances; shared slicing reuses NFs with policy isolation. The catalog must encode this choice and the orchestrator must enforce it at fulfilment time.
Assurance feedback — slice SLA violations must feed back into the orchestrator (closed-loop), which may scale NFs, reroute transport, or reject new attaches. This is why slicing is rarely deployed without an integrated assurance product.

NFV and MANO: How the Mobile NFs Are Instantiated

5GC NFs (and remaining vEPC NFs) are virtualised — VMs in legacy estates, containers in modern ones. ETSI MANO is the standardised architecture for managing their lifecycle. While MANO can theoretically be applied to any virtualised workload, in practice the dominant production deployment of MANO in telcos is mobile core and IMS, with vCPE/SD-WAN being a smaller footprint. Hence MANO content sits naturally inside the mobile-core domain section.

NFVO + VNFM + VIM = ETSI MANO

Click any layer to explore its responsibilities, interfaces, and state ownership

The MANO architecture stack — NFVO orchestrates network services; VNFM manages individual VNF/CNF lifecycle; VIM controls the underlying NFVI (OpenStack or Kubernetes). Toggle between architecture and Day-0/1/2 lifecycle views.

MANO components and their responsibilities

Component	Responsibility	Key inputs	Day-0/1/2 focus
NFVO (NFV Orchestrator)	Network service lifecycle — instantiate, scale, terminate; on-boards NSDs and VNF packages	Network Service Descriptor (NSD), VNF Package, policy	Day-0 design / Day-1 instantiation; coordinates Day-2 across NFs
VNFM (VNF Manager)	Individual VNF/CNF lifecycle — instantiate, scale, heal, terminate one NF	VNF Descriptor (VNFD), Helm chart for CNFs	Day-1 (instantiate, configure) and Day-2 (scale, heal)
VIM (Virtualised Infrastructure Manager)	Allocates compute, storage, networking to VNFs/CNFs	NFVI capacity, placement constraints	Day-1 allocation; Day-2 reallocation under load
NFVI (Infrastructure)	Compute, storage, networking that hosts the NFs	Servers, storage, switching, hypervisor / Kubernetes	Underlying — not a Day-X actor, the substrate

Day-2 dominates the cost

Day-0 (design) is a one-off. Day-1 (instantiate) is event-driven. Day-2 (operate) runs forever — scaling under load, healing failed pods, applying patches, rolling upgrades. Most MANO products were originally optimised for Day-1 and grew Day-2 capabilities awkwardly. Selecting MANO for Day-1 demos and discovering Day-2 limits later is a recurrent transformation pattern.

NFVI Generations: OpenStack and Kubernetes

The infrastructure beneath MANO has gone through two generations. Most operators run a hybrid estate — legacy VNFs on Gen-1 OpenStack, cloud-native NFs on Gen-2 Kubernetes — and will continue to for years.

SOM

Service Order Management

Orchestrates CFS → RFS — delegates to MANO, does not touch NFVI directly

MANO / NFVO

NFV Orchestrator + VNF Manager

Manages VNF/CNF lifecycle — instantiate, scale, heal, terminate

VIM

Virtualised Infrastructure Manager

Gen 1: OpenStack (VMs) — Gen 2: Kubernetes (Containers/Pods)

OpenStackKubernetes

NFVI

Network Functions Virtualisation Infrastructure

Physical compute, storage & networking in operator data centres and edge sites

Compute (x86 COTS)Storage (SSD / Ceph)Networking (OVS / SR-IOV / DPDK)

⚠

NFVI hosts network functions only (packet core, IMS, vCPE, SD-WAN). BSS/OSS applications run on separate IT infrastructure. Physical network devices (routers, switches) are managed by ROM/NSO, not NFVI.

NFVI stack — SOM → MANO → VIM → NFVI layers, with VNFs hosted on VMs (Gen-1) or CNFs hosted on containers/Kubernetes (Gen-2).

NFVI generations

Aspect	Gen 1 — OpenStack	Gen 2 — Kubernetes
Unit of deployment	Virtual Machine (VNF)	Container / Pod (CNF)
Startup time	Minutes	Seconds
Resource efficiency	Full OS per VM — heavy	Shared kernel — lightweight
Scaling	Manual or Heat templates	Native auto-scaling (HPA/VPA)
Typical workload	Legacy VNFs (vEPC, vIMS)	Cloud-native 5GC NFs (AMF, SMF, UPF)
VNFM coupling	Per-vendor VNFM, often heavy	Helm-based, increasingly standard

MANO ≠ NFVI builder

MANO manages VNF/CNF lifecycle on top of existing NFVI — it does not provision bare-metal, install OpenStack, or set up Kubernetes clusters. Infrastructure is a separate concern, typically owned by tooling like MAAS, Terraform, OpenStack-Ansible, or a managed K8s platform. Conflating "set up the cluster" with "deploy the NF onto the cluster" causes scope creep in MANO implementations and is a top reason MANO programmes overrun.

Vendor Stacks for Mobile-Core Orchestration

Mobile-core orchestration is the domain where vendor stacks are most mature, partly because telco operators co-developed slicing and 5GC orchestration with their core vendors, and partly because the regulatory and reliability bar is highest here. The dominant stacks differ in how much of the slice / NF / NFVI lifecycle they cover natively versus integrate with separate products.

Nokia Orchestration Center

Catalog + COM + SOM + cross-domain orchestration including 5G slicing — same product covers the full layering from 11.1

Native 5G slicing, SD-WAN, IP/transport orchestration in one product
Anchor reference: stc 5G slicing and monetisation
Often paired with Nokia Assurance Center for closed-loop slice SLA
Where Nokia is the core vendor, the vendor coupling is deep but consistent

Ericsson Service Orchestration & Assurance

Cross-domain orchestration with assurance — paired with Ericsson Order Care upstream

Multi-domain workflow across mobile core, RAN, transport, cloud
Closed-loop assurance integrated with the orchestration product
Ericsson MANO and EOM (Ericsson Orchestrator Manager) handle the NF lifecycle below
Strong fit when Ericsson RAN and core are the dominant network vendors

Mavenir cloud-native suite

Cloud-native 5GC vendor with own orchestration; common in greenfield and Open RAN deployments

Tighter NF + orchestrator coupling — designed together
Strong fit for greenfield 5G SA deployments and altnet operators
Less prescriptive about cross-domain coordination beyond core

ONAP-based stacks

Open-source orchestration used by several Tier-1s for 5G slicing pilots and production

SO + SDN-C + APPC + PolicyEngine + DCAE — multi-product framework
Production maturity uneven; most Tier-1 deployments use heavily customised ONAP forks
Strong where multi-vendor cross-domain orchestration with operator code-control is required

Worked Mini-Example: Enterprise 5G Slice Activation

A simplified flow showing the orchestrator coordinating MANO, 5GC SBI, and the cross-domain transport request. The full cross-domain example, including the transport-slice handoff to IP/MPLS and the assurance feedback loop, lives in 11.6.

5G slice activation: order → MANO → 5GC → transport

COM/SOM receives enterprise slice order

COM → SOM

Enterprise customer orders "URLLC industrial slice" — translated by COM/SOM into a NEST-aligned slice template request with latency/jitter/availability targets and an associated S-NSSAI.

XDO decomposes into RAN / transport / core sub-orders

XDO

Cross-domain orchestrator decomposes the slice into a RAN slice configuration request, a transport slice request (handed to IP/MPLS domain), and a core slice realisation across AMF/SMF/UPF/UDM with the right NSSF and PCF policy.

MANO scales NF capacity if required

NFVO → VNFM → VIM

XDO requests dedicated UPF capacity for the slice. NFVO + VNFM scale out a UPF instance via Helm; new pods register with NRF and become discoverable to the slice-aware SMFs.

Slice-aware NFs configured via 3GPP SBI

XDO → 5GC NFs

XDO calls Nnssf for slice selection policy, Namf for AMF slice config, Nsmf for SMF policy, Nudm for slice-bound subscriber profile, Npcf for slice-specific policy. All idempotent SBI operations.

Slice instance registered + assurance armed

XDO → Inventory + Assurance

XDO publishes the slice instance to inventory and arms slice-level KPIs in the assurance product. Closed-loop policies set: scale UPF if PRB utilisation > 80%, alarm if latency budget exceeded.

Common Pitfalls in Mobile-Core Orchestration

Treating 5GC NFs as routers

Pushing per-NF YANG / CLI through a generic domain controller, instead of speaking 3GPP SBI, ignores the service-based architecture entirely. The result is brittle vendor-specific config that does not survive 5GC NF replacement, slice template changes, or NF scaling.

SOM hard-coding infrastructure detail

SOM payloads that contain Kubernetes namespace names, Helm chart versions, container image references, or VIM identifiers leak infrastructure into the service catalog. These belong in the VNFD/NSD, not in SOM. Hard-coding them destroys the abstraction boundary and forces SOM rework on every NFVI change.

Service state confused with infrastructure state

A VNF/CNF can be "running" (MANO sees it healthy) while the service is "not yet active" (SOM has not completed the cross-domain saga) — and vice versa. Conflating these leads to false-positive activations, incorrect billing triggers, or stuck orders. The two states are independent.

Mobile-core orchestration anti-patterns

Anti-pattern	What it looks like	What breaks first
Slice = "configure these NFs"	Slice template is a list of per-NF configurations rather than an SLA contract	Slice cannot be replanned, scaled, or moved across NF instances; vendor swap forces template rewrite
Direct EMS push for 5GC	Bypass SBI and configure 5GC NFs through the vendor EMS UI / API	Slice-aware operations break; multi-vendor 5GC becomes impossible; standardisation benefits lost
Subscriber provisioning bypassing UDM	OSS pushes subscriber data directly to per-NF stores	UDM-as-source-of-truth principle violated; first 5GC NF that revalidates against UDM rejects the session
Cross-domain slice in one orchestrator with no transport awareness	Mobile-core orchestrator believes it owns the slice end-to-end; transport is "someone else's problem"	Transport-slice SLA violation goes undetected; latency budget consumed before reaching core; assurance loop incomplete
Day-2 ignored at MANO selection	Product chosen on Day-1 demo; Day-2 scaling/healing capability not tested	Six months in, scale-out events require manual intervention; auto-healing fails on pod-level events; ops team rebuilds Day-2 logic outside MANO

Section 11.4 Key Takeaways

Mobile core is software, not boxes. 5GC NFs are configured via 3GPP service-based interfaces (Nudm, Namf, Nsmf, Nnssf, Npcf), not via NETCONF or CLI.
The orchestrator configures subscribers, services, slices, and NF capacity — it does not configure devices. The line between service intent and infrastructure must be held.
Network slicing is the first-class XDO use case. It composes RAN, transport, and core; no single domain controller owns it. NEST/GST templates and 3GPP 28-series management functions (CSMF/NSMF/NSSMF) define the contract.
MANO (NFVO + VNFM + VIM) manages NF lifecycle on NFVI. NFVI is OpenStack or Kubernetes — most operators run a hybrid, and will for years. Day-2 operations dominate the operational cost.
Vendor stacks differ in scope: Nokia Orchestration Center spans COM through cross-domain; Ericsson splits Order Care from SOA; Mavenir tightly couples NF and orchestrator; ONAP-based stacks give code control at the cost of integration work.
The defining anti-patterns are treating 5GC NFs as routers, SOM hard-coding infrastructure detail, conflating service state with infrastructure state, and selecting MANO on Day-1 demos without Day-2 validation.