Audio Explanations: For a more comprehensive understanding of these theoretical concepts, supplementary audio guides are available on YouTube.

• Listen in English
• Listen in Hindi

1. Introduction to 5G Core Network Architecture

The 5G core network implements a Service-Based Architecture (SBA) that represents a paradigm shift from traditional monolithic architectures. Unlike its 4G predecessor, 5G adopts a modular, microservice-based design where network functions operate independently and can be scaled according to demand.

The core network architecture is strategically divided into two distinct planes:

1. Control Plane: Responsible for signaling, session management, and policy enforcement
2. User Plane: Handles actual data packet forwarding and routing

This architectural separation, known as Control and User Plane Separation (CUPS), enables flexible deployment strategies and optimized resource utilization. As illustrated in Figure 1, the Service-Based Architecture highlights the separation of the Control Plane—consisting of interconnected network functions such as the AMF, SMF, and PCF—and the User Plane, which routes the actual data traffic through the UPF.

2. Containerization and Orchestration

Containerization and orchestration technologies provide the foundational infrastructure for deploying and managing 5G core network functions in production environments. These technologies enable scalable, resilient, and efficient network function deployment.

2.1 Docker: Container Platform

Docker is a container platform used to build, package, distribute, and run applications in lightweight, isolated environments called containers.

A Docker container packages an application together with its required libraries, dependencies, runtime, and configuration. This helps ensure that the application runs consistently across different computers, servers, and cloud environments.

In 5G Core deployment, Docker is particularly useful because each Network Function (NF) can run in its own isolated container.

Core Docker Concepts

1. Container Images: Read-only templates containing application code, runtime, libraries, dependencies, and configuration files.
2. Containers: Running instances of Docker images that provide isolated environments for applications or network functions.
3. Docker Engine: The runtime responsible for creating, running, and managing containers on the host operating system.
4. Docker Registry: A repository used to store, manage, and distribute Docker images.

Benefits of Docker for 5G Core Deployment

1. Isolation: Each Network Function can run in its own container.
2. Portability: Containers provide consistent execution across different environments.
3. Resource Efficiency: Containers share the host OS kernel and generally require fewer resources than virtual machines.
4. Rapid Deployment: Network Functions can be started, stopped, and recreated quickly.
5. Version Control: Different versions of Network Function images can be maintained and deployed as required.

---

2.2 Kubernetes: Container Orchestration

Kubernetes (K8s) is an open-source platform for automating the deployment, scaling, management, and networking of containerized applications.

While Docker is mainly used to build and run individual containers, Kubernetes is used to orchestrate and manage containers across multiple machines in a cluster. This makes it suitable for large-scale and production-grade 5G Core deployments.

Core Kubernetes Concepts

1. Pods: The smallest deployable units in Kubernetes. A Pod contains one or more containers and provides the execution environment for a Network Function.
2. Services: Provide stable network endpoints and enable communication and load balancing between Pods.
3. Deployments: Define the desired state of an application and manage the creation, updating, and replacement of Pods.
4. ConfigMaps and Secrets: Used to manage configuration data and sensitive information such as passwords and credentials.
5. Namespaces: Provide logical separation of resources within a Kubernetes cluster.
6. Ingress Controllers: Manage external access to applications and services running inside the cluster.

Kubernetes Architecture Components

Control Plane

1. API Server: The central interface through which Kubernetes components and users communicate with the cluster.
2. Scheduler: Determines which Worker Node should run each Pod.
3. Controller Manager: Monitors and maintains the desired state of cluster resources.
4. etcd: Distributed key-value store that maintains Kubernetes cluster configuration and state.

Worker Nodes

1. Kubelet: Agent running on each Worker Node that manages Pods and communicates with the Control Plane.
2. Container Runtime: Software responsible for running containers.
3. Kube-proxy: Manages network rules and enables communication between Kubernetes Services and Pods.

Key Idea

Docker provides the technology for packaging and running applications in containers, while Kubernetes provides the orchestration required to deploy, scale, network, and manage those containers across a cluster.

For 5G Core, Docker is commonly useful for containerizing individual Network Functions, while Kubernetes is useful for managing those Network Functions at scale in a production environment.

2.3 Open-Source 5G Core Implementations: OAI and Open5GS

Beyond the underlying container and orchestration layer, open-source software stacks provide ready-to-deploy implementations of the 5G core network functions described in this document. Two of the most widely adopted projects for research, testbeds, and proof-of-concept deployments are OpenAirInterface (OAI) and Open5GS.

2.3.1 OpenAirInterface

OpenAirInterface is an open-source project maintained by the OpenAirInterface Software Alliance, providing a full software-based implementation of both the radio access network (RAN) and the 5G core network functions.

1. OAI-CN5G: A cloud-native implementation of the 5G core, with each network function (AMF, SMF, UPF, AUSF, UDM, PCF, NRF, etc.) packaged as an independent Docker container, aligned with the Service-Based Architecture described in Section 1.
2. OAI-RAN: Software implementation of gNB and UE functionality, enabling end-to-end 5G testbeds using software-defined radios.
3. Standards Alignment: Closely tracks 3GPP Release specifications, making it a common reference platform for 5G research and standardization work.
4. Kubernetes Support: Official Helm charts allow OAI-CN5G network functions to be deployed and orchestrated on Kubernetes clusters, as described in Section 2.2.

2.3.2 Open5GS

Open5GS is an open-source project implementing both 4G EPC and 5G core network functions in C, designed for lightweight deployment and ease of integration.

1. Modular NF Implementation: Provides independent binaries/containers for AMF, SMF, UPF, AUSF, UDM, UDR, PCF, NRF, and NSSF, mirroring the modular design principles outlined in Section 1.
2. Deployment Flexibility: Can be run as native Linux processes, Docker containers, or via Helm charts on Kubernetes, supporting the same containerization workflow described in Section 2.1–2.2.
3. WebUI and Subscriber Management: Includes a MongoDB-backed WebUI for provisioning subscriber data, commonly used alongside UDM/UDR for testbed configuration.
4. Interoperability: Frequently paired with third-party RAN simulators (e.g., UERANSIM) or OAI-RAN for end-to-end testing, since it implements standard 3GPP N1–N4 interfaces.

2.3.3 OAI vs. Open5GS: Practical Comparison

1. Primary Use Case: OAI is favored for combined RAN+Core research and standards-compliant experimentation; Open5GS is favored for lightweight, quick-to-deploy core-only testbeds.
2. Language/Footprint: Open5GS (C) is generally lighter-weight; OAI-CN5G (C/C++) offers deeper RAN integration at the cost of higher setup complexity.
3. Community and Tooling: Both maintain active Kubernetes/Helm deployment support, making either suitable for the containerized architecture discussed in Section 2.

3. Network Function Roles and Responsibilities

The 5G core network comprises multiple specialized network functions that work in coordination to provide seamless mobile connectivity, session management, authentication, and policy enforcement. Each function has specific roles and responsibilities within the overall architecture.

3.1 Access and Mobility Management Function (AMF)

Role: Primary control plane gateway for user equipment (UE)

Key Responsibilities:

1. Registration Management: Handles UE registration and deregistration procedures
2. Connection Management: Manages signaling connections between UE and core network
3. Mobility Management: Tracks UE location and manages mobility events
4. Authentication Coordination: Works with AUSF to authenticate UE during initial access
5. Network Slice Selection: Selects appropriate network slice for UE based on subscription
6. SMF Selection: Chooses suitable SMF for PDU session establishment
7. Paging Management: Triggers paging when downlink data arrives for idle UEs

Key Interfaces:

1. N1: Communication with UE (NAS signaling)
2. N2: Communication with RAN (NGAP protocol)
3. N11: Communication with SMF for session management
4. N12: Communication with AUSF for authentication
5. N15: Communication with PCF for policy decisions

As depicted in Figure 2, the AMF acts as the central control point for access network connections. It communicates directly with the User Equipment (UE) via the N1 interface, the Radio Access Network (RAN) via the N2 interface, and coordinates with other core network functions—including the SMF, AUSF, and PCF—for comprehensive connection and mobility management.

3.2 Session Management Function (SMF)

Role: Orchestrates all PDU (Protocol Data Unit) session operations

Key Responsibilities:

1. Session Management:
   1. Establishment of new PDU sessions
   2. Modification of session parameters
   3. Termination of inactive sessions
2. IP Address Allocation: Assigns IP addresses to UE for data sessions
3. UPF Selection and Control: Selects appropriate UPF and configures packet forwarding rules
4. QoS Management: Applies Quality of Service policies to data flows
5. Charging Data Collection: Gathers usage information for billing purposes

Key Interfaces:

1. N4: Communication with UPF (PFCP protocol) for session configuration
2. N7: Communication with PCF for policy rules
3. N10: Communication with UDM for subscription data
4. N11: Communication with AMF for session signaling

Figure 3 outlines the SMF and its interconnections within the 5G core. It highlights the SMF's central role in managing user sessions by interacting with the AMF for control signaling, querying the UDM for subscription data, applying policy rules from the PCF, and instructing the UPF via the N4 interface to manage user plane data forwarding rules.

3.3 User Plane Function (UPF)

Role: Handles all user data packet processing and forwarding

Key Responsibilities:

1. Packet Operations:
   1. Routing between RAN and external networks
   2. Forwarding based on SMF rules
   3. Deep packet inspection for policy enforcement
2. QoS Enforcement: Applies traffic shaping and prioritization rules
3. Packet Buffering: Buffers downlink packets for UEs in idle mode
4. Traffic Measurement: Collects traffic statistics for reporting
5. Lawful Interception: Supports legal data interception when required

Key Interfaces:

1. N3: Communication with RAN (GTP-U protocol) for user data
2. N4: Communication with SMF (PFCP protocol) for configuration
3. N6: Communication with Data Network (Internet/Enterprise networks)
4. N9: Communication with other UPFs for distributed deployments

Visualized in Figure 4, the UPF serves as the essential bridge for data traffic. The figure illustrates how the UPF receives user data from the RAN via the N3 interface and routes it to the external Data Network (DN) via the N6 interface, all while operating under the control of the SMF through the N4 interface.

3.4 Authentication Server Function (AUSF)

Role: Performs authentication services for UE network access

Key Responsibilities:

1. UE Authentication: Validates UE credentials during registration
2. Authentication Method Support: Supports 5G-AKA and EAP-AKA protocols
3. Security Key Generation: Creates encryption and integrity protection keys
4. Authentication Vector Management: Retrieves and processes authentication data from UDM
5. Re-authentication: Triggers periodic authentication when security context expires

Key Interfaces:

1. N12: Communication with AMF for authentication requests
2. N13: Communication with UDM for authentication credentials

As demonstrated in Figure 5, the AUSF plays a critical role in network security by mediating between the AMF and the UDM. This process ensures secure authentication of the User Equipment (UE), guaranteeing that only authorized users can access network services.

3.5 Unified Data Management (UDM)

Role: Central repository for subscriber data and credentials

Key Responsibilities:

1. Subscription Management:
   1. Stores and provides subscriber profile information
   2. Maintains authentication keys and vectors
2. UE Registration: Tracks UE registration status across the network
3. Access Authorization: Validates UE access rights and restrictions
4. Subscription Data Provisioning: Delivers subscription data to requesting network functions

Key Interfaces:

1. N8: Communication with AMF for registration and subscription data
2. N10: Communication with SMF for session-related subscription data
3. N13: Communication with AUSF for authentication credentials
4. N35: Communication with UDR for data storage

Figure 6 illustrates the UDM acting as the centralized database for subscriber information. Various control plane functions—such as the AMF, SMF, and AUSF—are shown querying the UDM to retrieve the essential subscription, authentication, and policy data required for their respective operations.

3.6 Policy Control Function (PCF)

Role: Provides unified policy framework for network behavior

Key Responsibilities:

1. Policy Management:
   1. Defines and enforces network policies
   2. Determines QoS parameters for sessions
   3. Applies charging policies for billing
2. Policy Provisioning:
   1. Session-specific rules to SMF
   2. Access and mobility policies to AMF
   3. Network slice policies

Key Interfaces:

1. N5: Communication with Application Functions for app-specific policies
2. N7: Communication with SMF for session policies
3. N15: Communication with AMF for access and mobility policies
4. N36: Communication with UDM for policy-related subscription data

As shown in Figure 7, the PCF orchestrates network rules and quality of service parameters. The diagram highlights how the PCF provides critical policy decisions to the AMF for access and mobility control, and to the SMF for session management and traffic policing.

3.7 Network Repository Function (NRF)

Role: Service discovery and registration for network functions

Key Responsibilities:

1. Network Function Registry: Maintains registry of available network functions
2. Service Discovery: Enables network functions to discover each other
3. Profile Management: Stores capability and status information
4. Selection Support: Helps select appropriate instances based on criteria
5. Authorization: Validates access tokens for service-based communication

Figure 8 demonstrates the NRF acting as a central service discovery directory for the 5G core. It outlines the process where various network functions register their profiles with the NRF and subsequently query it to discover and securely communicate with other required services within the Service-Based Architecture.

4 Network Function Interconnections

All network functions collaborate through standardized interfaces to provide seamless mobile connectivity. The control plane functions (AMF, SMF, AUSF, UDM, PCF, NRF) manage signaling and policies, while the user plane function (UPF) handles actual data traffic. This modular architecture enables flexible deployment, independent scaling, and efficient resource utilization.

A holistic view of these interconnections is provided in Figure 9, which summarizes all the previously discussed network functions and their standardized interfaces. This complete interconnection map visually reinforces the distinct separation between the interconnected control plane services and the user plane data path.