Cellular Network Architecture Explained: From RAN to 5G Core

Cellular network architecture is the system that carries a phone call, app request, or sensor message from a mobile device to another device or service. It combines radio equipment, transport links, core-network software, and operational systems. Knowing how these parts fit together helps developers, IoT teams, and network engineers make better decisions about coverage, latency, security, and deployment. This guide follows the path from a device to the wider internet, then compares network generations and explains what 5G-Advanced and 6G mean in practice.

What Is Cellular Network Architecture?

A cellular network divides a service area into cells so nearby devices can share radio resources. A base station serves each cell and connects devices to the operator’s network. As a device moves, the network can transfer its connection between cells; this is called a handover.

The complete architecture includes more than towers and antennas. It has four broad parts:

• User equipment (UE): A phone, modem, vehicle, or sensor with a cellular radio and a SIM or eSIM.
• Radio access network (RAN): Base stations and radio functions that connect devices over the air.
• Transport: Fiber, microwave, or other links carrying traffic between radio sites and the core.
• Core network: Functions that authenticate devices, manage mobility and sessions, apply policy, and route user traffic.

For how a downloadable operator profile is delivered and managed, see our eSIM remote provisioning architecture guide.

Operations, billing, voice, and application services sit alongside these layers. Cellular architecture is therefore an end-to-end system, not a single radio standard.

Why Cellular Networks Are Layered

Radio conditions change with distance, buildings, interference, and the number of active users. At the same time, a mobile network must authenticate subscribers, preserve sessions while they move, route data, support emergency and voice services, and enforce operator policy. Separating radio access from transport and core functions lets each part evolve without replacing the whole system.

The layers also expose real trade-offs. Low-frequency spectrum generally reaches farther and penetrates buildings better; higher-frequency bands can provide more capacity but usually need denser sites. More bandwidth alone does not guarantee a fast application: congestion, radio conditions, transport capacity, core routing, and the remote service all contribute to end-to-end performance.

How Cellular Network Architecture Works

At a high level, a data session follows this path:

Device and SIM/eSIM → radio link → base station and RAN → transport → mobile core → internet or private service

Control signaling follows a related path to authenticate the device, register it on the network, and establish a data session. The user plane carries the actual packets. Keeping these roles distinct helps explain both 4G and 5G.

Radio access and transport

The base station schedules radio resources and exchanges signals with devices. In LTE it is called an eNodeB; in 5G New Radio (NR), a gNodeB. A 5G gNodeB may be divided into a Central Unit (CU) and one or more Distributed Units (DUs), which communicate over standardized interfaces. Implementations vary: functions may be located together at a site or split across edge and regional facilities.

Transport connects RAN sites to core functions. Operators engineer these links for capacity, availability, timing, and latency. Terms such as fronthaul and midhaul describe particular transport segments in split-RAN designs; they are not required as separate physical networks in every deployment. For broader transport planning, see our SD-WAN implementation guide.

Core functions and session flow

The 4G Evolved Packet Core (EPC) and 5G Core (5GC) both handle subscriber access, mobility, policy, and data routing, but they use different architectures. In a simplified 5G service-based architecture:

• The AMF handles access and mobility signaling.
• The SMF manages PDU sessions and selects or controls user-plane resources.
• The UPF forwards user data between the RAN and a data network.
• Other functions provide subscriber data, authentication, policy, and discovery services.

Network functions communicate through defined interfaces. The 5G Core’s service-based architecture (SBA) makes network-function services available to authorized consumers; it does not mean every operator must deploy each function as a separate microservice or container. Production deployment choices depend on the vendor, operator, performance, and resilience requirements.

In a typical 5G standalone data session, the device registers through the NG-RAN and 5GC, then a PDU session is established. Control-plane functions coordinate the session while user packets travel through a selected UPF. A UPF near the user can support local breakout or edge applications, but low latency still depends on the radio, transport, routing, and application path.

Standalone, non-standalone, and mobility

5G non-standalone (NSA) commonly adds 5G NR capacity while retaining LTE and the EPC as an anchor. 5G standalone (SA) uses a 5G Core with 5G NR, enabling the full 5GS architecture. Availability and features vary by operator, coverage, device, and subscription; a status-bar 5G icon does not tell you which core is in use.

When a device changes cells, the RAN and core coordinate mobility so active services can continue. Interworking between LTE and 5G can preserve service during coverage changes, although interruptions and performance depend on the deployment and application. At the transport layer, MPTCP can use or fail over between network paths without managing radio handovers itself.

For the normative architecture, see the 3GPP overview of the 5G system.

Components and Architecture Variants

Other deployment choices cut across generations. Private cellular networks serve a defined campus or organization. Open RAN aims to make RAN interfaces and components more open and interoperable; it is not itself a new cellular generation or a guarantee of plug-and-play integration. Our Open RAN architecture and RIC explainer covers its components, interfaces, control loops, and integration trade-offs. Virtualized and cloud-based RAN/core functions can improve deployment flexibility, but require careful engineering of timing, capacity, security, and failure recovery. The O-RAN Alliance overview describes its goals and ecosystem.

3GPP’s Release 18 summary and Release 19 summary describe the two releases associated with 5G-Advanced. By contrast, 6G is still in research and standardization planning. The ITU’s framework and objectives for future mobile networks set a vision for the next generation; they are not a finished 6G technical specification or a promise that proposed capabilities are commercially available.

Real-World Use Cases

• Consumer mobile broadband: LTE and 5G provide connectivity for browsing, video, and cloud services. Actual experience depends on signal quality, cell load, device capability, and backhaul.
• Industrial and campus networks: Private LTE or 5G can provide managed coverage and device mobility across a facility. A design still needs spectrum authorization, security controls, site planning, and a fallback plan.
• IoT and metering: LTE-M and NB-IoT support low-power devices in some regions and bands. Device battery life and coverage depend on radio configuration, operator support, and reporting frequency.
• Edge applications: A nearby application or UPF can shorten some data paths for industrial control, video, or analytics. It does not remove radio scheduling delay or guarantee deterministic latency.
• Connected transport: Cellular systems can provide wide-area communication for fleet operations and vehicle services, complemented by other technologies when coverage or latency needs require it.
• Satellite and high-altitude coverage: A non-terrestrial network can extend a cellular service area or connect remote gateways, with different payload, latency, and mobility constraints. See our NTN architecture explainer for how these systems fit together.

The appropriate architecture follows the application’s requirements, not the generation label alone. Applications that need dependable operation should also account for coverage gaps, handover behavior, congestion, and loss of connectivity.

Practical Considerations and a Small Test

Before selecting a cellular service or designing a device, confirm:

1. Coverage and bands: Check the operator’s bands, the device’s supported bands, indoor coverage, roaming, and local legacy-network retirements.
2. Core and service requirements: Determine whether LTE, NSA, or SA is available and whether private APNs, static addressing, or local breakout are required.
3. Performance targets: Specify application-level latency, jitter, throughput, packet loss, and availability rather than relying on advertised peak rates.
4. Security and operations: Protect SIM/eSIM provisioning, authenticate application traffic, restrict management access, monitor failures, and plan software updates.
5. Fallback and recovery: Define behavior when radio coverage disappears, a session changes cells, or the remote service is unreachable.

For a controlled lab, iperf3 can measure throughput between a device using cellular data and a server you administer. It measures the end-to-end path, not radio capacity alone:

# On a server you control:
iperf3 -s

# On the test device, while connected through the cellular network:
iperf3 -c SERVER_IP -t 10

Use an authorized endpoint and keep the test duration and parallel streams appropriate for your plan and lab. Compare results at different locations and times, and pair throughput with latency and packet-loss measurements. A home lab setup guide can help plan a small test environment; container networking basics explains network paths when services run in containers.

For mobile robots or edge applications, review the ROS 2 beginner’s guide alongside the cellular design. Operators can also use PowerShell automation to standardize routine checks, provided access and change controls are in place.

Common Misconceptions

• “5G always means standalone.” Many 5G services use NSA architecture; SA availability is operator- and location-specific.
• “A 5G icon guarantees low latency or high speed.” It indicates a network connection, not a particular core, signal quality, service path, or application experience.
• “Network slicing creates a physically separate network.” A slice is a logically differentiated service across shared infrastructure, with behavior determined by the operator’s implementation and service agreement.
• “Cloud-native means the core is automatically resilient.” Resilience depends on redundancy, capacity, failure domains, operations, and tested recovery procedures.
• “6G capabilities are already standardized.” The ITU framework sets goals for future development. Research goals should not be presented as final specifications or available commercial features.
• “Open RAN removes integration work.” Open interfaces can support multi-vendor choices, but interoperability, performance, lifecycle, and security still need validation.

Related Articles

• How 5G technology affects development for application and industry implications.
• 6G network technology explained for the distinction between current research and future network goals.
• SD-WAN implementation guide for transport and wide-area network design.
• Container networking basics for service connectivity in virtualized environments.
• Building a home lab for practical network testing.
• ROS 2 beginner’s guide for robotics and edge use cases.
• PowerShell automation for Windows for repeatable operations tasks.