5G Network Architecture in Sparx EA: Modeling Network Slicing, Core and RAN

The short version: 5G Standalone is not a radio upgrade — it is a complete redesign of the mobile network, built on a cloud-native, microservices-based 5G Core where each network function exposes an API and communicates over HTTP/2. Documenting it takes more than network diagrams. Sparx EA gives you a multi-layer model that holds the whole picture: network functions in the Application layer, physical infrastructure in the Technology layer, SysML for the protocol interfaces, network slices as a service hierarchy, and a TM Forum ODA governance layer above the network.

For a telecoms operator, that single source of truth is the difference between a stack of disconnected vendor diagrams and an architecture you can actually govern, trace and evolve as releases ship and enterprise slices come online. This guide walks the full stack — Core, RAN, transport and slicing — and shows where each piece lands in a Sparx EA repository.

5G architecture: the full stack

3GPP Standalone architecture (Release 15 and beyond)

The 3GPP Release 15 specification — published in 2018 — defined the first complete 5G Standalone architecture. Releases 16 and 17 extended it with network slicing enhancements, support for vertical industries (automotive, manufacturing, public safety) and positioning services. Release 18, the first 5G-Advanced release, adds AI and ML integration into the network management architecture.

The defining characteristic of the SA architecture — as distinct from the Non-Standalone (NSA) option that pairs a 4G LTE core with 5G radio — is the 5G Core (5GC): a cloud-native, microservices-based core network that breaks from the monolithic MME/SGW/PGW model of 4G. The 5GC is built on the Service-Based Architecture (SBA) principle, where each network function is a discrete service that exposes a set of APIs and talks to its peers through them rather than through point-to-point protocol interfaces. In practice this makes 5G as much a software architecture problem as a network engineering one.

5G Core network functions

The 5G Core is composed of discrete Network Functions (NFs), each with a defined scope and a Service-Based Interface (SBI) over which it communicates:

• AMF (Access and Mobility Management Function) — manages UE registration, connection management and mobility. The AMF is the UE's primary contact point into the core, handling authentication (with the AUSF), forwarding session requests to the SMF, and managing mobility events. It exposes the Namf interface.
• SMF (Session Management Function) — manages PDU sessions: establishment, modification and release. The SMF selects and controls the UPF, assigns IP addresses and enforces session policies received from the PCF. It exposes the Nsmf interface.
• UPF (User Plane Function) — the data plane: packet routing and forwarding, traffic steering, QoS enforcement and lawful interception. Unlike the control plane functions, the UPF can be distributed to the network edge for low-latency use cases, and it communicates with the SMF over the N4 interface (PFCP).
• NRF (Network Repository Function) — the service discovery function. Every NF registers its services with the NRF and discovers peers through it; it is effectively the service-mesh registry for the 5GC.
• PCF (Policy Control Function) — manages policy rules for sessions and service data flows, supplying QoS and charging policies to the SMF and access/mobility policies to the AMF, drawing subscriber data from the UDR.
• AUSF (Authentication Server Function) — handles UE authentication with the AMF and UDM, performing the 5G AKA and EAP-AKA’ procedures.
• UDM (Unified Data Management) — manages subscriber data (profiles, credentials, location). The UDM is the 5GC equivalent of the 4G HSS.
• NEF (Network Exposure Function) — the network's northbound API gateway, exposing 5GC capabilities (QoS on demand, slice selection, location, analytics) to enterprise applications and third-party developers through secure, standardized APIs.
• NWDAF (Network Data Analytics Function) — provides ML-based analytics to other NFs and, via the NEF, to external consumers, producing load-level information, performance predictions and mobility analytics.

Radio Access Network (RAN)

The 5G RAN introduces the gNodeB (gNB) as the base station — the access node that implements the 5G NR air interface. In the SA architecture the gNB talks directly to the AMF (via N2) and the UPF (via N3), with no 4G core dependency.

Open RAN (O-RAN) is the disaggregated, open-interface variant defined by the O-RAN Alliance. It splits the traditional gNB into three functional components:

• O-RU (Radio Unit) — the radio hardware, handling the physical-layer air interface.
• O-DU (Distributed Unit) — the lower-layer stack (Layer 1 lower PHY, Layer 2 MAC/RLC), typically deployed close to the O-RU.
• O-CU (Centralized Unit) — the upper-layer stack, split into O-CU-CP (control plane: RRC, PDCP-C) and O-CU-UP (user plane: PDCP-U), and deployable further away in a regional data center.

The O-RAN Alliance standardizes the interfaces between them: the Open Fronthaul (O-RU to O-DU), the F1 interface (O-DU to O-CU) and the E1 interface (O-CU-CP to O-CU-UP). The RIC (RAN Intelligent Controller) sits above the RAN as its management and intelligence layer — a Non-Real-Time RIC on a control loop greater than one second and a Near-Real-Time RIC on a 10ms–1s loop — hosting xApps and rApps that implement radio resource management, energy efficiency and interference coordination using ML.

Transport: fronthaul, midhaul, backhaul

The transport network connecting the disaggregated RAN components to each other and to the core is segmented into three spans, each with different timing demands:

• Fronthaul (O-RU to O-DU) — the most timing-sensitive segment. The Open Fronthaul interface requires very low latency (typically under 100 microseconds one-way) and precise IEEE 1588 PTP synchronization, usually carried on dedicated fiber or DWDM.
• Midhaul (O-DU to O-CU) — less sensitive than fronthaul but still needing synchronization and relatively low latency (under 10ms). Standard carrier Ethernet or IP/MPLS with appropriate QoS works here.
• Backhaul (O-CU and other RAN functions to the 5G Core) — the most flexible segment, with requirements driven by traffic load and the latency sensitivity of the use case. Standard IP/MPLS or SD-WAN is typically adequate.

Network slicing architecture in Sparx EA

Network slicing concepts

Network slicing lets a single physical 5G infrastructure present multiple logical network instances — slices — each optimized for a different use case or customer. 3GPP defines three standard slice types:

• eMBB (Enhanced Mobile Broadband) — high throughput, moderate latency. The primary consumer mobile slice, used for mobile broadband, video streaming and fixed wireless access.
• URLLC (Ultra-Reliable Low-Latency Communications) — very low latency (under 1ms) and very high reliability (99.9999%). Used for industrial automation, autonomous vehicles, remote surgery and other mission-critical applications.
• mMTC (Massive Machine-Type Communications) — very high device density, low throughput, low power. Used for IoT: smart metering, asset tracking, environmental monitoring.

Enterprise customers can be assigned to dedicated or shared slices with Service Level Agreements (SLAs) mapped to the slice's performance characteristics.

Modeling network slices

In Sparx EA, network slices are modeled as Application Services — logical services the 5G infrastructure provides to consumers (enterprises, IoT platforms, mobile broadband users). Each slice carries tagged values that turn it into governed, queryable data rather than a label on a diagram:

• SliceType: eMBB | URLLC | mMTC.
• S-NSSAI: the slice identifier composed of SST (Slice/Service Type) and SD (Slice Differentiator).
• TargetLatency_ms: the committed latency SLA for the slice.
• TargetThroughput_Mbps: the peak throughput committed.
• TargetReliability: the reliability target (for example, 99.9999% for URLLC).
• SliceCustomer: the enterprise or service the slice is dedicated to, or blank if shared.
• SliceStatus: Design | Provisioned | Active | Deprecated.

Slice lifecycle management (NSSF / NSMF / NSSMF)

The hierarchy that creates, governs and terminates slices is itself a key architectural element:

• NSSF (Network Slice Selection Function) — a 5GC function that selects the right slice for each UE session, based on the requested S-NSSAI, subscription information from the UDM and slice availability.
• NSMF (Network Slice Management Function) — the orchestration-layer function responsible for end-to-end slice lifecycle management. It receives lifecycle requests from the service layer (OSS/BSS) and coordinates with the NSSMFs to instantiate, scale and terminate slice components.
• NSSMF (Network Slice Subnet Management Function) — manages slice subnet instances within a domain: Core, Access (RAN) and Transport NSSMFs, each communicating with the NSMF through standardized management interfaces.

In Sparx EA this hierarchy is modeled as Application Components with Serving relationships showing the control flows between them. The slice lifecycle workflow — request, resource allocation, instantiation, monitoring, termination — is captured as a BPMN process connecting those components.

TM Forum ODA: the governance layer above the network

TM Forum's Open Digital Architecture (ODA) is the target architecture for telecoms BSS/OSS modernization, and it also provides the governance layer above the 5G network. In the ODA component model the network itself sits within the Resource domain — specifically the Resource Management components that expose network capabilities to the Service and Product domains above. The 3GPP network functions (AMF, SMF, UPF) are not ODA components; they are the internal implementation that ODA Resource Management components abstract and expose.

For an operator, the ODA governance layer above the 5G network includes:

• Resource Inventory Management — maintains the inventory of 5G infrastructure (gNBs, O-RUs, O-DUs, O-CUs, core functions).
• Resource Orchestration and Activation — handles activation and configuration of 5G resources, including slice provisioning.
• Network Slice Management — manages the end-to-end slice lifecycle from the business perspective, interfacing with the NSMF at the network level.
• Service Quality and Performance Management — monitors 5G performance and triggers remediation.

Sparx EA is where the ODA component architecture — including the Resource domain components that govern the 5G network — is documented and maintained. The TM Forum ODA MDG Technology supplies the component stereotypes and interface definitions that keep that governance consistent.

The Sparx EA approach: modeling 5G end to end

Application layer: network functions

The 5G Core functions (AMF, SMF, UPF, NRF, PCF, AUSF, UDM, NEF, NWDAF) are modeled as ArchiMate Application Components. Each NF carries tagged values:

• 3GPPFunction: the standard function type (AMF | SMF | UPF | NRF | PCF | AUSF | UDM | NEF | NWDAF | other).
• DeploymentModel: Centralized | Distributed | Edge.
• VendorPlatform: the network function vendor (Ericsson, Nokia, Mavenir, and so on).
• Release: the 3GPP release supported (15 | 16 | 17 | 18).
• SBIVersion: the SBI API version implemented.
• CloudPlatform: the infrastructure the NF runs on (Kubernetes on bare metal, OpenStack, AWS, Azure, Google Cloud).

Application Interface elements represent each function's SBI — the standardized HTTP/2 API through which it exposes its services to peers. Service relationships link the NFs through those SBIs: the AMF calls the AUSF via Nausf, the SMF calls the UDM via Nudm, and so on.

Technology layer: physical infrastructure

The physical 5G infrastructure is modeled in the ArchiMate Technology layer:

• Technology Nodes represent physical or virtual compute: gNB hardware, O-RU hardware, O-DU and O-CU servers, core network servers (physical or cloud VMs/containers).
• Communication Networks represent the transport segments: Open Fronthaul, Midhaul IP, Backhaul IP/MPLS and the SBI network connecting the 5GC functions internally.
• Network Path relationships connect nodes through their communication networks, annotated with latency, bandwidth and synchronization requirements.

Assignment relationships connect Application Components (network functions) to Technology Nodes (their hosting infrastructure), capturing the deployment architecture.

SysML: protocol interface modeling

The SBA interfaces — the HTTP/2 APIs between network functions — are detailed with SysML blocks and port-based interface specifications:

• Each network function is a SysML Block with Flow Ports representing its SBI APIs.
• Each SBI endpoint is an Interface Block with operations for the 3GPP-specified service operations (create, retrieve, notify, update, delete).
• Connectors between blocks carry the protocol-level details: protocol type (HTTP/2), transport security (TLS 1.3) and message format (JSON).

For the non-SBA interfaces — N2 between gNB and AMF (NG-AP over SCTP), N3 between gNB and UPF (GTP-U over UDP), N4 between SMF and UPF (PFCP) — the same SysML approach models the protocol stack explicitly, which makes interface compliance traceable across different vendor implementations.

From model to live visibility

Once the 5G architecture lives in Sparx EA as typed elements with governed tagged values, it stops being documentation and becomes data. The repository can drive the views a rollout actually needs: a deployment progress view of gNB and O-RAN status (Design, Provisioned, Active) with coverage by region, band and slice type; a network slice portfolio listing every slice with its S-NSSAI, committed SLAs, customer assignment and status; an ODA component coverage view of which governance components are deployed, in progress or not yet started; and an Open RAN vendor diversity breakdown that tracks multi-vendor disaggregation against targets.

Because every one of those views reads from the same governed model, program managers see actual deployment against plan without chasing field teams for status, and enterprise sales teams can answer slice-availability questions straight from the architecture. The model earns its keep precisely because it is queryable rather than static.

FAQ

Where Sparx Services fits

5G architecture spans Core, RAN, transport, management and ODA governance — and it keeps evolving as new releases ship and enterprise slices are provisioned. Sparx Services helps telecoms operators and enterprises build the 5G architecture model in Sparx EA: the 5GC functions, RAN topology, transport and network slices, governed with the right MDG so the model stays consistent as it grows. From there it becomes the single, queryable source of truth that program managers and enterprise customers can rely on for rollout and architecture visibility. If your starting point is messier than that, Paralysis to a Plan is the scored baseline that gets you to a fundable first step. For the broader picture of where modeling like this is heading, see AI Augmented Architecture.

Keep reading

You might also be interested in

Insight

Enterprise Architecture in Telecoms: Using TM Forum ODA and Sparx EA

How ODA frames BSS/OSS modernization, and where it lands in a Sparx EA repository.

Read → Insight

Cloud-Native BSS/OSS Architecture: TM Forum ODA and Sparx EA in Practice

Taking the ODA component model from canvas to a working cloud-native architecture.

Read → Discipline

IT Architecture

Modeling infrastructure, networks and platforms with rigor in Sparx EA.

Explore → For leaders

Paralysis to a Plan

Turn a sprawling architecture estate into a scored, fundable starting point.

See how →

← All insights