Direct Answer
5G Standalone (SA) architecture — the full 3GPP Release 15 and beyond implementation with a native 5G Core — is not just a radio access upgrade. It is a complete architectural redesign of the mobile network, introducing microservices-based network functions, Service-Based Architecture (SBA) with HTTP/2 API communication between core functions, and network slicing that allows a single physical infrastructure to present multiple logical network instances with different performance characteristics.
Documenting and governing this architecture requires more than network diagrams. Sparx EA provides the multi-layer modeling environment for the complete 5G architecture: network functions in the Application layer (AMF, SMF, UPF, NRF, PCF), physical infrastructure in the Technology layer (gNodeB, Open RAN components, fronthaul/midhaul/backhaul transport), protocol interfaces in SysML (network function APIs as blocks), and network slicing management as a capability hierarchy. TM Forum ODA MDG provides the governance layer above the network. EA GraphLink connects the architecture model to Power BI and Agentforce dashboards — giving transformation programme managers live visibility of 5G rollout progress and architecture coverage.
Key Takeaways
- 5G SA architecture is a Service-Based Architecture — network functions expose APIs (SBI — Service-Based Interfaces) and communicate via HTTP/2, making it a software architecture challenge as much as a network engineering challenge.
- Network slicing (eMBB, URLLC, mMTC) requires modeling both the logical slice topology and the management hierarchy (NSSF, NSMF, NSSMF) that creates, manages, and terminates slices.
- TM Forum ODA provides the component governance layer above the 5G network — EA provides the repository where the ODA architecture is maintained.
- SysML is the right modeling language for 5G network function API interfaces — network function APIs are modeled as SysML blocks with port-based interface specifications.
- EA GraphLink connects the 5G architecture repository to Power BI and Agentforce, enabling natural language queries on rollout status, coverage, and architecture completeness.
5G Architecture: The Full Stack
3GPP Standalone Architecture (Release 15 and Beyond)
The 3GPP (3rd Generation Partnership Project) Release 15 specification — published in 2018 — defined the first complete 5G Standalone architecture. Releases 16 and 17 extended it with enhanced capabilities: network slicing enhancement, 5G for vertical industries (automotive, manufacturing, public safety), and positioning services. Release 18 (the first 5G-Advanced release) adds AI/ML integration into the network management architecture.
The defining characteristic of the SA architecture — as distinct from the Non-Standalone (NSA) option that uses a 4G LTE core with 5G radio access — 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: each network function is a discrete service that exposes a set of APIs and communicates with other network functions through those APIs, rather than through point-to-point protocol interfaces.
5G Core Network Functions
The 5G Core is composed of a set of discrete Network Functions (NFs), each with a defined scope and a Service-Based Interface (SBI) over which it communicates with other NFs:
AMF (Access and Mobility Management Function) — manages UE (User Equipment) registration, connection management, and mobility. The AMF is the primary contact point for the UE (via the RAN) into the core network. It handles authentication (in conjunction with the AUSF), session management requests (forwarded to the SMF), and mobility events (handovers, location updates). The AMF exposes the Namf service-based interface.
SMF (Session Management Function) — manages PDU (Protocol Data Unit) sessions: session establishment, modification, and release. The SMF selects and controls the UPF for data plane functions, assigns IP addresses, and enforces session policies (QoS, charging rules received from the PCF). The SMF exposes the Nsmf interface.
UPF (User Plane Function) — the data plane function: packet routing and forwarding, traffic steering, QoS enforcement, and lawful interception. Unlike the control plane functions (AMF, SMF), which are deployed as cloud-native VMs or containers in a centralised data centre, the UPF can be distributed — deployed at the network edge (close to the RAN) for low-latency applications. The UPF communicates with the SMF via the N4 interface (PFCP — Packet Forwarding Control Protocol).
NRF (Network Repository Function) — the service discovery function for the 5GC. All network functions register their services with the NRF and discover peer NF services through it. The NRF is the service mesh registry for the 5GC’s microservices architecture.
PCF (Policy Control Function) — manages policy rules for sessions and service data flows. The PCF provides QoS policies and charging policies to the SMF (for session-level enforcement via the UPF) and access and mobility policies to the AMF. The PCF consumes subscriber data from the UDR (Unified Data Repository) via the Nudr interface.
AUSF (Authentication Server Function) — handles UE authentication in conjunction with the AMF and UDM. The AUSF performs the 5G AKA (Authentication and Key Agreement) and EAP-AKA’ authentication procedures.
UDM (Unified Data Management) — manages subscriber data (subscription profiles, authentication credentials, location information). The UDM is the 5GC equivalent of the 4G HSS (Home Subscriber Server).
NEF (Network Exposure Function) — exposes 5GC capabilities to external applications via secure, standardised APIs. This is the 5G network’s northbound API gateway — the function through which enterprise applications, hyperscalers, and third-party developers access network capabilities (QoS on demand, network slice selection, location services, network analytics).
NWDAF (Network Data Analytics Function) — provides AI/ML-based analytics to 5GC functions and to external consumers via the NEF. NWDAF analyses network data (from existing NFs via Nnwdaf interface subscriptions) and produces analytics outputs: load level information, network performance predictions, UE mobility pattern analytics.
Radio Access Network (RAN)
The 5G RAN introduces the gNodeB (gNB) as the base station — the access node that implements the 5G NR (New Radio) air interface. In the SA architecture, the gNB communicates directly with the AMF (via the N2 interface) and with the UPF (via the N3 interface), without a 4G core dependency.
Open RAN (O-RAN) is the disaggregated, open-interface variant of the 5G RAN architecture, defined by the O-RAN Alliance. O-RAN disaggregates the traditional gNB into three functional components:
- O-RU (O-RAN Radio Unit) — the radio hardware, handling the physical layer air interface.
- O-DU (O-RAN Distributed Unit) — the lower-layer stack, handling Layer 1 (lower PHY) and Layer 2 (MAC, RLC) processing, typically deployed close to the O-RU.
- O-CU (O-RAN Centralised Unit) — the upper-layer stack, split into O-CU-CP (Control Plane — handling RRC and PDCP-C) and O-CU-UP (User Plane — handling PDCP-U). The O-CU can be deployed further from the radio, in a regional data centre.
The interfaces between these components are standardised by O-RAN Alliance: the Open Fronthaul (between O-RU and O-DU), the F1 interface (between O-DU and O-CU), and the E1 interface (between O-CU-CP and O-CU-UP).
RIC (RAN Intelligent Controller) — the O-RAN management and intelligence layer: the Non-Real-Time RIC (Non-RT RIC, on a >1 second control loop, embedded in the SMO) and the Near-Real-Time RIC (Near-RT RIC, on a 10ms–1 second control loop). The RIC hosts xApps (for Near-RT RIC) and rApps (for Non-RT RIC) — software applications that implement radio resource management optimisation, energy efficiency, and interference coordination functions using AI/ML.
Transport: Fronthaul, Midhaul, Backhaul
The transport network connecting the disaggregated RAN components to each other and to the core network is segmented into three spans:
Fronthaul — connects O-RU to O-DU. This is the most timing-sensitive segment: the Open Fronthaul interface requires very low latency (typically <100 microseconds one-way) and precise synchronisation (IEEE 1588 PTP). Fronthaul is typically implemented with dedicated fibre or DWDM (Dense Wavelength Division Multiplexing) with strict timing characteristics.
Midhaul — connects O-DU to O-CU. Less timing-sensitive than fronthaul but still requiring synchronisation and relatively low latency (<10ms). Can use standard carrier Ethernet or IP/MPLS with appropriate QoS.
Backhaul — connects O-CU (and other RAN functions) to the 5G Core. The most flexible segment — requirements depend on the 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 is the capability that allows a single physical 5G infrastructure to present multiple logical network instances — slices — each optimised for a different use case or customer. 3GPP defines three standard slice types:
eMBB (Enhanced Mobile Broadband) — high throughput, moderate latency. Used for mobile broadband services, video streaming, fixed wireless access. This is the primary consumer mobile slice.
URLLC (Ultra-Reliable Low-Latency Communications) — very low latency (<1ms), 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 consumption. Used for IoT deployments: smart metering, asset tracking, environmental monitoring.
Enterprise customers can be assigned to dedicated or shared slices with defined Service Level Agreements (SLAs) mapped to the slice’s performance characteristics.
Modeling Network Slices in Sparx EA
In Sparx EA, network slices are modeled as Application Services — logical services provided by the 5G infrastructure to consumers (enterprises, IoT platforms, mobile broadband users). Each slice carries tagged values:
- SliceType: eMBB | URLLC | mMTC.
- S-NSSAI (Single Network Slice Selection Assistance Information): The slice identifier composed of SST (Slice/Service Type) and SD (Slice Differentiator).
- TargetLatency_ms: The committed latency SLA for this slice.
- TargetThroughput_Mbps: The peak throughput committed for this slice.
- TargetReliability: The reliability target (e.g., 99.9999% for URLLC).
- SliceCustomer: The enterprise or service that this slice is dedicated to (if dedicated) or blank (if shared).
- SliceStatus: Design | Provisioned | Active | Deprecated.
Slice Lifecycle Management Hierarchy (NSSF/NSMF/NSSMF)
The management hierarchy that creates, governs, and terminates network slices is a key architectural element of 5G:
NSSF (Network Slice Selection Function) — a 5GC network function that selects the appropriate network slice for each UE session, based on the UE’s requested S-NSSAI, subscription information (from UDM), and network slice availability.
NSMF (Network Slice Management Function) — the orchestration-layer function responsible for the lifecycle management of end-to-end network slices. The NSMF receives slice lifecycle requests from the service layer (OSS/BSS) and coordinates with the NSSMFs to instantiate, scale, and terminate the slice components.
NSSMF (Network Slice Subnet Management Function) — responsible for managing network slice subnet instances within a specific domain: the Core NSSMF (for the 5GC subnet), the Access NSSMF (for the RAN subnet), and the Transport NSSMF (for the transport subnet). Each NSSMF communicates with the NSMF through standardised management interfaces.
In Sparx EA, this management hierarchy is modeled as Application Components (NSSF, NSMF, NSSMFs) with Serving relationships showing the control flows between them. The slice lifecycle workflow (request → resource allocation → slice instantiation → monitoring → termination) is modeled as a BPMN process connecting the management hierarchy components.
TM Forum ODA Alignment
ODA as the Governance Layer Above the Network
TM Forum’s Open Digital Architecture (ODA) is the target architecture for telecoms BSS/OSS modernisation — but ODA also provides the governance layer above the 5G network. In the ODA component model, the 5G network itself sits within the Resource domain (specifically the Resource Management components that expose network capabilities to the Service and Product domains above). The network functions (AMF, SMF, UPF) are not ODA components — they are the internal implementation of the network that ODA Resource Management components abstract and expose.
For a telecoms operator, the ODA governance layer above the 5G network includes:
- Resource Inventory Management — the ODA component that maintains the inventory of 5G infrastructure elements (gNBs, O-RUs, O-DUs, O-CUs, core network functions).
- Resource Orchestration and Activation — the ODA component that handles the activation and configuration of 5G resources, including network slice provisioning.
- Network Slice Management — the ODA component that manages the end-to-end network slice lifecycle from the business perspective, interfacing with the NSMF at the network level.
- Service Quality and Performance Management — the ODA component that monitors 5G network 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 provides the component stereotypes and interface definitions.
Sparx EA Approach: Modeling 5G End to End
Application Layer: Network Functions
The 5G Core network functions (AMF, SMF, UPF, NRF, PCF, AUSF, UDM, NEF, NWDAF) are modeled as ArchiMate Application Components in the Application layer. Each NF carries tagged values:
- 3GPPFunction: The 3GPP standard function type (AMF | SMF | UPF | NRF | PCF | AUSF | UDM | NEF | NWDAF | other).
- DeploymentModel: Centralised | Distributed | Edge.
- VendorPlatform: The specific network function vendor (Ericsson, Nokia, Huawei, Mavenir, Parallel Wireless, etc.).
- Release: The 3GPP release version supported (Release 15 | 16 | 17 | 18).
- SBIVersion: The SBI API version implemented.
- CloudPlatform: The cloud infrastructure on which this NF is deployed (OpenStack, Kubernetes on bare metal, AWS, Azure, Google Cloud).
Application Interface elements represent each network function’s SBI — the standardised HTTP/2 API through which it exposes its services to peer NFs. Service relationships link NFs through their 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 nodes: gNB hardware, O-RU hardware, O-DU servers, O-CU servers, core network servers (physical or cloud VMs/containers).
- Communication Networks represent the transport segments: Open Fronthaul network, Midhaul IP network, Backhaul IP/MPLS network, SBI network (the internal network connecting 5GC functions).
- Network Path relationships connect nodes through their communication networks, annotated with latency, bandwidth, and synchronisation requirements.
Assignment relationships connect Application Components (network functions) to Technology Nodes (their hosting infrastructure) — modeling the deployment architecture.
SysML: Protocol Interface Modeling
The 5G network’s SBA interfaces — HTTP/2-based APIs between network functions — are detailed using SysML blocks with port-based interface specifications:
- Each network function is a SysML Block with Flow Ports representing its SBI APIs.
- Each SBI API endpoint is modeled as an Interface Block with operations (representing the 3GPP-specified service operations: create, retrieve, notify, update, delete).
- Connector elements between SysML blocks represent the protocol-level connections, carrying protocol type (HTTP/2), transport security (TLS 1.3), and message format (JSON) specifications.
For non-SBA interfaces (N2 between gNB and AMF using NG-AP over SCTP; N3 between gNB and UPF using GTP-U over UDP; N4 between SMF and UPF using PFCP), the SysML block approach models the protocol stack explicitly — enabling interface compliance tracking across different vendor implementations.
EA GraphLink: 5G Architecture Dashboards
EA GraphLink connects the Sparx EA 5G architecture repository to Power BI and Agentforce, providing live visibility of the 5G rollout and architecture:
5G Rollout Progress Dashboard: A geographic or functional view of gNB and O-RAN deployment status (Design | Provisioned | Active), with coverage statistics by region, frequency band, and slice type. Programme managers see actual deployment against planned rollout without manual status gathering from field teams.
Network Slice Portfolio: A table of all defined network slices — type, S-NSSAI, committed SLAs, customer assignment, and status. Operators and enterprise sales teams can query slice availability and SLA headroom.
ODA Component Coverage: A heat map of ODA components with implementation status — which ODA components are deployed, which are in progress, and which are not yet started. This view tracks BSS/OSS modernisation progress at the architecture level.
Open RAN Vendor Diversity: A breakdown of O-RU, O-DU, and O-CU vendors across the network — tracking multi-vendor Open RAN implementation against disaggregation targets.
Agentforce / Copilot Integration: Via EA GraphLink’s MCP Server, Agentforce or Microsoft Copilot can answer natural language queries against the 5G architecture: “Which gNBs are currently not yet 5G SA capable?” “What URLLC slices are currently active and what are their committed latencies?” “Which core network functions are running on Release 16 and not yet upgraded to Release 17?”
FAQ
Q1: What is the difference between 5G Non-Standalone (NSA) and Standalone (SA) architecture?
5G NSA (Non-Standalone) uses the existing 4G LTE Evolved Packet Core (EPC) as the control plane, with 5G NR (New Radio) added as a secondary access technology for additional throughput. NSA was the first 5G deployment option (3GPP Option 3) because it allowed operators to deploy 5G radio without replacing their core network. However, NSA cannot support network slicing, URLLC, or the full SBA architecture — it is a transitional step. 5G SA (Standalone) deploys the full 5G Core (5GC), enabling the complete 5G architecture including network slicing, URLLC latencies, and the SBA with NF API communication. In Sparx EA, NSA architecture is modeled as a transitional state — with the 4G EPC in the Application layer serving as the core, and 5G NR in the Technology layer as an additional radio access technology. The SA target architecture is modeled separately, and the migration roadmap (Implementation layer Work Packages) connects the two.
Q2: What is Open RAN and why does it matter architecturally?
Open RAN (O-RAN) is the disaggregation of the traditional monolithic base station (gNB or eNB) into three separately sourced components (O-RU, O-DU, O-CU) connected by standardised, open interfaces defined by the O-RAN Alliance. The architectural significance is that Open RAN enables multi-vendor RAN deployments — an operator can use an O-RU from one vendor, an O-DU from another, and an O-CU from a third, rather than being locked to a single integrated RAN vendor (Ericsson, Nokia, Huawei). This changes the competitive dynamics of the RAN market and creates new integration architecture challenges (interface compliance, timing synchronisation, management integration). Sparx EA models Open RAN by disaggregating the gNB into separate O-RU, O-DU, and O-CU Application Components, with the O-RAN Alliance interface specifications modeled as SysML Interface Blocks.
Q3: How does network slicing connect to the business architecture?
Network slices are the product delivery mechanism for 5G enterprise services. Each slice corresponds to a product or service offering (Industrial IoT with URLLC guarantees, high-throughput video for media production, massive IoT for smart cities). In Sparx EA, the Application layer network slice model connects upward to the Business layer: Business Services (the commercial product offerings) realise the network slices that deliver them, and the Products in the product catalogue reference the S-NSSAI and SLA commitments of the underlying slice. This multi-layer model — from Business through Application to Technology — is the architecture view that allows the product team to understand the network implications of a new enterprise product, and the network team to understand the business commitment behind each slice they are managing.
Q4: How does Sparx EA handle the configuration complexity of 5G Core network function parameters?
Sparx EA models the architecture of the 5G Core — the network functions, their interfaces, their deployment topology, and their relationships — not the operational configuration parameters of each function (which belong in network management systems like 3GPP-compliant EMS/NMS tools). The boundary between EA and network management is the interface boundary: Sparx EA documents which network functions exist, which interfaces they use, and what the architectural intent is; network management tools configure and operate the specific parameter values within each function. Tagged values in Sparx EA can reference network management configuration documents or records (e.g., ConfigurationRef pointing to the relevant NMS configuration artefact), maintaining the link without duplicating operational configuration data.
Q5: What is the NWDAF and how does it connect to AI architecture?
The NWDAF (Network Data Analytics Function) is the 3GPP-specified AI/ML analytics function for 5G networks. Defined in 3GPP Release 15 and significantly enhanced in Releases 16 and 17, NWDAF collects data from 5GC network functions (via standardised Nnwdaf subscriptions), applies ML models to that data, and produces analytics outputs consumed by other NFs (for automated network optimisation) or by external consumers (via the NEF). In Sparx EA, NWDAF is modeled as an Application Component with SBI connections to all NFs it subscribes to, Application Interfaces exposing its NnwdafAnalyticsInfo and NnwdafEventsSubscription services, and a connection to the AI/ML training platform (which may be an external cloud AI service or an on-premises AI infrastructure) via a data pipeline.
Q6: How does the TM Forum ODA MDG work in Sparx EA for 5G?
TM Forum publishes ODA Canvas specifications that define the component model, component API conformance requirements, and the integration architecture for ODA-compliant systems. The TM Forum ODA MDG for Sparx EA implements these specifications as stereotypes and tagged values: ODA Components (with domain classification, maturity level, and API conformance tagged values), ODA API elements (with TMF Open API reference, version, and implementation status), and ODA Integration Layer elements (representing the Canvas Integration Layer that connects components via event-driven APIs). For 5G, the ODA MDG governs the Resource and Service domain components that sit above the network — not the 3GPP network functions themselves. The combination of ODA MDG (for the OSS/BSS governance layer) and ArchiMate/SysML (for the 5G Core and RAN architecture) in a single Sparx EA repository gives operators their complete end-to-end architecture in one place.
Q7: Can Sparx EA model the 5G network for enterprise private network deployments?
Yes. Enterprise private 5G networks — dedicated 5G networks deployed within enterprise premises (factories, campuses, ports, hospitals) — have a distinct architecture from public mobile network deployments. In Sparx EA, a private 5G network is modeled as a subset of the full 5G architecture: the enterprise deploys its own gNB (or O-RAN components), a compact 5GC (often a containerised or edge-hosted core from vendors like Ericsson Private 5G, Nokia DAC, or Nokia MXIE), and connects to the internet or enterprise WAN through a controlled N6 breakout. The private network architecture is linked to the enterprise’s broader IT architecture in Sparx EA — specifically to the operational technology (OT) systems (SCADA, MES, robotics) that the private 5G network serves, modeling the use-case to network architecture traceability.
Q8: What engagement does Sparx Services recommend for 5G architecture documentation?
Connect is the recommended engagement for telecoms operators and enterprises deploying 5G — it delivers the 5G network architecture model (5GC functions, RAN topology, transport, network slices) in Sparx EA and connects it to Power BI via EA GraphLink for a live rollout and architecture dashboard. For operators that want to integrate 5G architecture governance into Agentforce or Microsoft Copilot — enabling natural language queries on the network architecture portfolio — the AI/BI connectivity components of Connect are extended to include MCP Server configuration for the chosen AI platform. Connect pricing starts from $50,000, with scope depending on the complexity of the network architecture and the number of BI/AI integration targets.
Work With Sparx Services
5G architecture spans Core, RAN, transport, management, and ODA governance layers — and it evolves continuously as new releases are deployed and enterprise slices are provisioned. Sparx Services’ Connect engagement builds your 5G architecture model in Sparx EA and connects it to Power BI and Agentforce via EA GraphLink — giving programme managers and enterprise customers live, queryable visibility of your network architecture.
Connect from $50,000. Contact us to discuss your 5G architecture documentation.