Learn Cellular Networks: A Tutorial for Beginners

How Cellular Networks Work

Cellular networks divide geographic areas into cells, each served by a radio site (an eNodeB in LTE or gNodeB in 5G). Mobile devices attach to the closest site that satisfies radio and load requirements, and the network hands sessions off between sites as the user moves. Multiple users share radio resources through scheduling and frequency reuse, which keeps spectral efficiency high in dense areas.

From an operational perspective, three activities dominate day-to-day work: (1) managing radio resources (scheduling, power, and handovers), (2) routing and policy in the core network (subscriber context, mobility, and session management), and (3) backhaul capacity and reliability between sites and the core. Understanding how these layers interact makes it easier to troubleshoot performance and coverage problems.

• Cells use scheduling and resource blocks to allocate airtime among users.
• Handovers preserve session continuity as devices move between cells.
• Control-plane signaling establishes authentication and bearer paths before data flows.

Key Components of Cellular Networks

Essential Network Elements and Architecture

At a high level, a mobile network consists of three logical layers:

• Radio Access Network (RAN): the radio sites (eNodeB for LTE, gNodeB for 5G) and their radios/antennas that connect UEs (user equipment) over the air.
• Core Network: control and user-plane functions that manage subscriber state, mobility, and interworking. In LTE this is the EPC (MME, S-GW, P-GW); in 5G it is the 5GC (AMF, SMF, UPF). These functions enforce policies, QoS, and interconnect to external networks.
• Backhaul & Transport: the wired or wireless links (fiber, microwave, Ethernet) that carry traffic between RAN sites and the core. Backhaul capacity, latency and jitter directly affect user-plane performance.

Operationally useful components and considerations:

• Site electronics: baseband units and remote radio heads. Modern deployments often separate these (split RAN) for flexibility.
• Core network functions: authentication/authorization, session and mobility management, and policy control. Virtualization (VNFs/CNFs) is widely used for scalability.
• Orchestration and monitoring: telemetry (SNMP, streaming telemetry) and OSS/BSS systems for alarms, KPIs and maintenance workflows.

When designing or troubleshooting, map the fault domain: is the problem in the RAN (coverage, RF interference), the transport (packet loss or capacity), or the core (session limits, misconfigured subscriber profiles)? That triage reduces mean time to repair.

Tools & Diagnostics (Wireshark, iperf3, adb, nmap)

Quick summary: this section lists the primary tools, their roles, and when to use each in a testing workflow (capture, measure, inspect, and validate).

This section collects the practical tools and commands you'll use to diagnose connectivity, throughput and configuration issues in cellular test environments. The guidance covers scope (what each tool is best for), compatibility notes, example commands to reproduce in a lab, and secure testing practices. Use these tools to: capture packet-level behavior (Wireshark/tshark), measure throughput and identify per-flow limits (iperf3), read device radio properties (adb), and validate host hardening (nmap). All commands and captures should be run in isolated test networks or on systems you control—never scan or capture on production or third-party networks without written permission. See the "What you'll need" and "Tools: usage details, examples and environment notes" sections for concrete commands and environment tips.

First Lab: Packet Capture + Throughput Analysis

This step-by-step beginner lab combines a packet capture (tshark/Wireshark) with a throughput test (iperf3) so you can reproduce a simple troubleshooting workflow on a controlled test network. Target environment: a laptop (Ubuntu 22.04 recommended), a test server (VM or cloud instance you control), and an Android device or client laptop acting as the UE.

Goal

Capture traffic between a test client and an iperf3 server, measure throughput, and identify any retransmits or RTT spikes in the capture.

Required software & versions (examples)

• Ubuntu 22.04 LTS (workstation)
• Wireshark 3.6+ / 4.x and tshark (same package)
• iperf3 3.1+ (3.9 or 3.10 commonly available)
• tcpdump (server-side captures)
• Android SDK Platform Tools 33+ (if using an Android test device)

Topology

Client (UE) <--over cellular/tethered USB--> Test laptop <--Internet/VPN--> Iperf3 server (VM).

Steps

1. Prepare the iperf3 server (on a VM you control):

   iperf3 -s  # Start server

2. On the test laptop, start a packet capture on the interface that carries the UE traffic (example: usb0 for a tethered device). Use a capture filter to limit size; capture both directions.

   tshark -i usb0 -f "host <server_ip>" -c 500 -w firstlab_capture.pcap

3. Run a parallel-stream iperf3 test from the client toward the server (on the client device or test laptop):

   iperf3 -c <server_ip> -P 4 -t 30

4. Stop the capture after iperf3 completes and open the capture in Wireshark for analysis.

Key Wireshark display filters and checks:

• Filter by flow: ip.addr == <client_ip> && ip.addr == <server_ip>
• Check for retransmits and out-of-order packets: tcp.analysis.retransmission || tcp.analysis.out_of_order
• Review RTT: enable the TCP stream graph (Statistics > TCP Stream Graphs > Round Trip Time) to observe RTT spikes.
• If GTP-U is present on your capture point, filter UDP port 2152: udp.port == 2152 and use the GTP dissector to inspect inner IP/TCP details.

Troubleshooting actions

• If you see frequent TCP retransmits with normal radio metrics, inspect MTU/fragmentation on the transport path and consider MSS clamping on the gateway.
• If throughput is asymmetric (good downlink, poor uplink), run iperf3 in both directions and correlate with interface queue statistics on the UPF or backhaul equipment.
• If you observe high jitter or bursts, check for queueing on the backhaul and verify QoS marking by re-running iperf3 with DSCP set: iperf3 -c <server_ip> -P 4 -S 0xb8.

Security and operational best practices for the lab

• Run all tests in an isolated VLAN or test SSID. Never run scans or captures on networks you do not own.
• Keep capture files private and delete them when no longer needed; captures may contain subscriber or device identifiers.
• Document baseline KPIs (latency, jitter, packet loss, throughput) before making configuration changes.

This simple lab demonstrates the core workflow you'll repeat: create a controlled load, capture packet-level traces, and use protocol analysis to correlate observed user symptoms with network events.

What you'll need (software & hardware)

Below is a minimal, practical checklist of hardware and software required to run the labs and reproduce the examples safely. These items focus on reproducibility and security: using controlled endpoints and versions that provide current dissectors and tooling behavior.

Before running the commands and captures in this guide, assemble a minimal lab with the following items to ensure reproducible results and safety:

• Laptop or workstation (Linux preferred for packet capture and network tooling; Ubuntu 20.04 LTS or 22.04 LTS are commonly used in labs).
• Test server (VM or cloud instance you control) to run iperf3 server and collect packet captures.
• Android test device with USB debugging enabled (for adb). Ensure the device is dedicated to testing and not attached to production SIMs unless you have permission.
• USB cables and optionally a USB Ethernet adapter for tethered capture.
• Software:
  • Wireshark 3.6+ / 4.x and tshark from the same package
  • iperf3 3.1+ (3.9–3.10 commonly available in package managers)
  • Android SDK Platform Tools 33+ (adb)
  • nmap 7.80+
  • tcpdump (useful for server-side captures)
• Network isolation: a VLAN or isolated test SSID so that captures and scans do not impact production users. If remote, use a secure VPN and authenticated access to the test server.
• Permissions: written authorization to run tests on any networks you don't own; follow your organizations change-control and testing policies.

Security reminder: keep all collected captures and scan outputs private. They can contain sensitive headers, subscriber identifiers, and configuration information.

Download and installation references

Official project pages (root domains):

• Wireshark — packet capture and protocol analysis
• iperf3 — bandwidth measurement tool (project root)
• Android developer site — Platform Tools (ADB)
• Nmap — network scanner

Example installation commands for Ubuntu 22.04 (package names current at time of writing):

sudo apt update
sudo apt install -y wireshark tshark iperf3 nmap tcpdump android-sdk-platform-tools-common

Security/install notes:

• During Wireshark install you may be asked whether non-root users should capture packets; add operators to the "wireshark" group rather than running Wireshark as root.
• If package versions in your distribution are older than recommended, use the project site to obtain newer binaries or build from source following official guidance.

Security Best Practices

Quick summary: protect captures and test assets, isolate test infrastructure, and enforce strict access controls and auditability for any management plane access.

This consolidated section groups actionable security controls and examples that are referenced throughout the labs. It focuses on protecting test artifacts, controlling access to test infrastructure, and securing management planes when you run diagnostics or maintain RAN/core equipment.

Protecting packet captures and logs

Capture files often contain identifiers and metadata that must be safeguarded. Recommended controls:

• Store captures on encrypted volumes (LUKS on Linux) or encrypt individual files with GPG (GnuPG >= 2.2 recommended).
• Restrict file permissions to the operator account that performed the capture (chmod 600).
• When sharing captures for triage, redact or extract only the flows needed and escrow full captures using secure channels.

# encrypt a capture with a symmetric cipher (GnuPG)
gpg --symmetric --cipher-algo AES256 firstlab_capture.pcap

# set strict permissions
chmod 600 firstlab_capture.pcap.gpg

Access control for test servers and RAN management

Limit administrative access using strong SSH settings, dedicated keys, and role-based accounts. Do not reuse production admin credentials in test labs.

Host test-server
  HostName 203.0.113.10
  User labadmin
  IdentityFile ~/.ssh/id_rsa_lab
  StrictHostKeyChecking yes
  UserKnownHostsFile ~/.ssh/known_hosts_lab

• Disable password authentication and root login in OpenSSH (OpenSSH >= 7.6 recommended where available):

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
AllowUsers labadmin

Network isolation and scanning policy

Always run scans and traffic generation in segregated environments. Use VLANs, private subnets, or dedicated SIMs (for cellular test UEs) to avoid impacting customers and to keep test traffic contained. Keep an explicit list of IP ranges, device IDs and SIMs associated with tests and record authorization.

Logging, auditing and key lifecycle

• Enable audit logging for configuration and software changes and centralize logs in a secure SIEM or log collector with restricted access.
• Rotate SSH keys and API credentials on a regular schedule and revoke keys after a test cycle completes.
• Use short-lived credentials for cloud test VMs (e.g., cloud provider temporary tokens) where possible.

Example: secure file transfer and cleanup

Use SFTP with key-based authentication or SCP over an authenticated channel for moving artifacts. Remove temporary artifacts after post-mortem.

# copy encrypted capture to secure analysis host
scp firstlab_capture.pcap.gpg analyst@analysis-host:/secure/analysis/

# on analysis host: decrypt for local, ephemeral analysis
gpg --decrypt firstlab_capture.pcap.gpg > /tmp/firstlab_capture.pcap
# set permissions
chmod 600 /tmp/firstlab_capture.pcap
# remove after analysis
shred -u /tmp/firstlab_capture.pcap

Operational controls for RAN and CNFs

• Use role-based access (RBAC) for orchestrators and CNF control planes. Limit who can apply policy or change scheduler parameters.
• Stage firmware and software upgrades in a lab environment; perform canary deployments with automated rollback on KPI degradation.
• Monitor management-plane access and alert on unusual activity such as atypical command sequences or new administrative keys.

These controls reduce the risk of exposing subscriber data, prevent accidental production impact, and make lab activities auditable and repeatable. Where the guide repeats security reminders, consult this section for the detailed controls and examples to implement in your environment.

Tools: usage details, examples and environment notes

Quick summary: this section gives concise, tool-focused guidance for capture, measurement, device inspection, and host validation—follow the examples verbatim in isolated labs.

This section covers practical usage tips and example commands for the primary tools used in the labs. For exact recommended versions and platform notes, refer to the "What you'll need" section above.

Wireshark (packet analysis)

Wireshark and tshark are the go-to tools for packet captures. For LTE/5G analysis you may need the appropriate capture point (for cellular control-plane you often need operator-side capture; for user-plane GTP-U traffic you can capture on the gateway or on an N6/N3 interface).

Common capture tips:

• Use capture filters to reduce noise. For GTP-U traffic (user-plane) use: udp port 2152.
• If capturing on a tethered device over USB or on a Wi-Fi uplink, ensure you capture both directions to see full TCP flows.
• Keep capture files manageable—ring buffers and packet limits prevent disk exhaustion: tshark -i any -c 100 -w capture.pcap.

Example: capture 100 packets with tshark and write to a file (command-line):

tshark -i any -c 100 -w capture.pcap

Open capture.pcap in Wireshark to inspect protocol stacks, retransmissions, and RTT. Troubleshooting tips: look for TCP retransmits, duplicate ACKs, and out-of-order segments when investigating poor throughput; inspect ICMP or ARP errors when connectivity is intermittent.

Ping (connectivity check)

Use ping to verify reachability and baseline RTT.

ping -c 4 google.com

Check packet loss and rtt min/avg/max. High variance in RTT or packet loss often points to radio or backhaul issues rather than application-layer problems.

ADB: checking device properties (prerequisites and alternatives)

ADB requires Android SDK Platform Tools (recommend Platform Tools 33+). Enable Developer Options > USB debugging on the device. If ADB is unavailable, use the device UI (About > Network & SIM) or carrier diagnostic apps.

Command (reads device properties and filters for radio/band metadata):

adb shell getprop | grep 'band'

Example expected output (values vary by device and modem):

[ro.vendor.sw.bands]: [LTE:B1,B3,B7]
[ril.currentBand]: [1800]
[ro.radio.nw.band]: [n78]

Note: property names and availability differ by vendor and Android build; search for alternative keys if none match.

iperf3 (bandwidth test)

iperf3 measures throughput between two endpoints. Ensure firewall rules allow the chosen port (default 5201) and that you run tests during controlled windows to avoid disruption.

Start the server on the test server:

iperf3 -s  # Start server

Run the client on the test client machine (replace <server_ip>):

iperf3 -c <server_ip>  # Client command to test bandwidth

Typical troubleshooting steps: run multiple parallel streams (-P) to check for single-stream limits, and test both directions to identify asymmetric throughput issues. To exercise QoS paths or mark traffic for testing, set the DSCP/TOS value from the client with -S (example uses EF/Expedited Forwarding):

iperf3 -c <server_ip> -P 4 -S 0xb8

nmap (port scanning) — purpose and security considerations

nmap helps discover open ports and services for validating host hardening. Only scan hosts and networks you own or have explicit permission to test.

nmap -p 1-65535 localhost

Security note: avoid wide scans of carrier or customer networks. Use nmap results to harden services (close unused ports, apply access controls) and keep results private.

Security and testing best practices

• Run diagnostics inside an isolated lab or VLAN; never expose test endpoints to public networks.
• Use VPNs or secure tunnels when remote testing is required; authenticate and authorize access to testing tools.
• Record baseline KPIs (latency, jitter, packet loss, throughput) before making configuration changes so you can measure impact.

Troubleshooting Checklist

This concise checklist consolidates common steps and investigative order for faster triage. Use it as a runbook for lab tests or as a starting point for production troubleshooting (with appropriate approvals).

1. Confirm scope: Identify affected users, apps, and cell/site IDs. Determine if issue is persistent or intermittent.
2. Baseline checks: Ping relevant gateways and the test server; note packet loss and RTT variance.
3. Capture traces: Start captures at client and server sides. For cellular user-plane captures consider capturing on GTP-U ports (udp 2152) or at the gateway interface.
4. Measure throughput: Run iperf3 in both directions; test single stream and parallel streams with -P.
5. Inspect radio metrics: On device (via adb) or from RAN counters, check RSRP/RSRQ/SINR and scheduling reports. Low RSRP/SINR implies RAN coverage/antenna issues.
6. Check transport: Look for packet drops, interface errors, or queueing on backhaul links; correlate time-series metrics with user complaints.
7. Validate core: Check session limits, policy rules, and authentication logs (MME/AMF/SMF) for attach or bearer failures.
8. Mitigate & confirm: Apply a targeted change (increase power, adjust QoS, re-route backhaul) in a canary segment; measure KPIs and revert if no improvement.
9. Document: Record root cause, actions, and rollback steps. Add monitoring alarms for early detection of recurrence.

Common Pitfalls

• Capturing only one direction of traffic—always capture both sides when possible to see full TCP flows.
• Running iperf3 with default single stream and concluding network is slow—test parallel streams to reveal per-flow limits.
• Assuming application issues are network-related without reviewing server logs and application metrics.
• Exposing test devices or management interfaces to public networks—use isolation and strong authentication.

Real-World Applications of Cellular Networks

Examples from deployments

Mobile networks support consumer broadband, enterprise connectivity, and machine-type communications. In one smart-city deployment I contributed to, cellular-linked sensors supplied real-time traffic counts to a central system; adjusting signal timing based on aggregated data reduced delays at targeted intersections. Operational improvements like these come from combining reliable telemetry, predictable backhaul, and appropriate QoS policies in the core.

Carrier-grade deployments emphasize redundancy and monitoring: diverse backhaul links, active/passive core redundancy, and automated alarms for KPIs such as RRC connection failures, attach success rate, and handover success rate.

• Apply QoS and policy to differentiate latency-sensitive traffic (VoIP, control loops) from bulk data.
• Use telemetry and alarms to detect degrading RAN or transport performance before user impact.
• Test changes in canary segments before broad rollouts to limit risk.

Detailed Case Studies

These short case studies present concrete scenarios, tools used, key configuration choices and troubleshooting steps drawn from field experience. They demonstrate practical trade-offs and reproducible mitigation steps.

Case Study A — Private 5G for a Manufacturing Campus

Problem: An automated manufacturing line experienced intermittent packet loss and jitter affecting an edge control application that requires low latency.

Environment & tools used: private 5G RAN with an edge UPF/MEC server colocated in the factory, iperf3 (3.9) for synthetic load, Wireshark/tshark (3.6+) for captures, and device telemetry (modem counters exposed via vendor API).

Key findings and actions:

• Observation: iperf3 tests with single-stream throughput were fine, but parallel-streams (iperf3 -P 8) caused increased packet reordering and higher jitter on the control VLAN.
• Root cause: bursty UDP/TCP flows from a bulk-data backup scheduled during production windows overloaded a single backhaul link and exposed queueing in the UPF path.
• Mitigation: implemented QoS at the UPF and RAN scheduler to prioritize the control-plane flows. Marked control traffic with EF DSCP and verified treatment end-to-end using iperf3 -c <server> -S 0xb8 -P 4 for synthetic validation. Also scheduled bulk backups to an off-peak window.
• Verification: post-change iperf3 and packet captures showed reduced jitter and no packet reordering. Added an alert for per-interface queue length on the UPF to detect recurrence.

Security notes: management access to the MEC/UPF cluster used SSH keys, role-based accounts, and an audit trail. Firmware updates were staged in a lab and rolled via a CI/CD pipeline with automated rollback on failure.

Case Study B — Rural Broadband Optimization

Problem: A rural operator reporting poor indoor coverage and frequent re-attaches in low-density areas after a capacity upgrade.

Environment & tools used: macrosite with mid-band and low-band carriers, microwave backhaul, radio counters, and field A/B tests using Android phones (adb) and laptop captures.

Key findings and actions:

• Observation: client devices reported marginal RSRP (around -105 to -110 dBm) indoors and RSRQ below expected thresholds. Backhaul latency spikes correlated with customer complaints during peak hours.
• Root cause: the upgrade added mid-band carriers for capacity but reduced low-band resource allocation for coverage; additionally the microwave backhaul was oversubscribed during peaks.
• Mitigation: rebalanced carrier aggregation to restore more low-band PRBs for coverage-sensitive cells, added a parallel microwave path for backhaul redundancy, and applied POLQA-based voice tests to validate parity. Field device metrics were read via ADB and validated using in-field iperf3 tests while capturing traffic on a tethered interface:

# capture tethered interface traffic to file
tcpdump -i usb0 -w rural_site_capture.pcap

Post-change, indoor RSRP improved into the -90 to -100 dBm range for most sites, handover stability improved, and complaints decreased. Added periodic monitoring for RSRP/RSRQ rolling averages and set alarms for sustained backhaul latency over 50 ms.

Case Study C — GTP-U Fragmentation and Throughput Loss

Problem: A site showed poor TCP throughput for large-object downloads despite apparently good RSRP and SINR.

Tools: Wireshark/tshark, tcpdump, server-side application logs, and iperf3.

Diagnosis steps & fix:

• Captured GTP-U on the gateway and observed excessive fragmentation and per-packet overheads on the backhaul MTU.
• Fix: adjusted the GRE/GTP MTU settings to avoid fragmentation (in collaboration with backhaul engineers) and enabled TCP MSS clamping at the gateway to ensure endpoints used a safe MSS. Verified improvement with iperf3 tests and TCP flow analysis in Wireshark.
• Recommended check: when you see high retransmits with good radio metrics, verify MTU/fragmentation on transport paths and inspect GTP-U encapsulation overheads.

Evolution of Cellular Technology

From 1G to 5G

Each generation introduced practical changes: 1G was analog voice, 2G added digital voice and basic data, 3G expanded mobile internet, 4G delivered IP-based mobile broadband, and 5G introduced higher throughput and capabilities such as URLLC and network slicing. Migration projects typically involve both RAN and core changes; operators often run multi-RAT networks (2G/3G/4G/5G) during transitions to preserve coverage and legacy services.

• 1G: Analog voice.
• 2G: Digital voice and SMS.
• 3G: Mobile internet and multimedia.
• 4G: IP-based mobile broadband (LTE).
• 5G: Enhanced mobile broadband, low latency, and massive IoT support.

Modulation basics: QPSK and 16-QAM (detailed)

Modulation maps bits onto symbols that change signal phase and/or amplitude. Two commonly used schemes are:

• QPSK: encodes 2 bits per symbol using four phase points. It is robust at low SNR and therefore often used for control channels or robust modulation and coding schemes.
• 16-QAM: encodes 4 bits per symbol by using 16 distinct amplitude/phase combinations. It provides higher spectral efficiency but requires better SNR.

Simple ASCII constellation sketches (I = in-phase, Q = quadrature):

QPSK constellation (4 points):
   Q
   ^    o       o
   |\
   |\
   o       o    ---> I

16-QAM simplified layout (4x4 grid, 16 points):
   Q
   ^   o  o  o  o
   |   o  o  o  o
   |   o  o  o  o
   |   o  o  o  o  ---> I

Adaptive modulation in LTE/5G selects the highest-order modulation that the current channel conditions will support while meeting target BLER (Block Error Rate). In practice this is controlled by the scheduler and link adaptation algorithms on the RAN side.

Why this matters: understanding modulation versus SNR directly informs cell planning and scheduling decisions—when you see low SNR in field metrics you can expect schedulers to fall back to more robust modulation, reducing throughput but increasing reliability. This is an operational trade-off technicians and planners must manage during coverage or capacity changes.

Understanding Frequency and Coverage

Frequency Bands and Their Impact

Lower-frequency bands propagate further and penetrate structures better, making them suitable for rural coverage and deep-building penetration. Mid bands are a balance of capacity and coverage. High bands, including mmWave, provide very high capacity but are limited in range and require dense site deployments.

• Lower bands: larger coverage footprints and better indoor penetration.
• Mid bands: good compromise for urban and suburban deployments.
• High bands (mmWave): high capacity, short range—useful for hotspots.

Why this matters: selecting bands is a direct operational decision—operators trade coverage for capacity. For engineers, band selection impacts antenna planning, expected RSRP/RSRQ baselines, and where to target small-cell densification or carrier aggregation to meet SLAs.

For details on checking your device's frequency band via ADB, refer to the Tools & Diagnostics section.

Future Trends in Cellular Networks

Emerging Technologies and Innovations

Key directions include continued 5G densification, integration of edge computing to reduce latency for real-time workloads, and network automation driven by AI for capacity planning and anomaly detection. Network slicing enables operators to create virtual networks tuned to specific SLAs, improving resource utilization across diverse use cases.

Challenges and Considerations

Upgrading networks introduces operational complexity and security implications. Examples: opening management interfaces for remote maintenance must be combined with strong authentication, least-privilege access, and monitoring. Use staging environments and change control processes for software updates and configuration changes to reduce the risk of service disruption.

• Plan capacity and spectrum strategy carefully; regulatory coordination is required for spectrum allocation.
• Harden management planes and control access to orchestration systems; enable logging and alerting for suspicious activity.
• Schedule maintenance windows and validate rollback plans for large-scale upgrades.

Glossary of Cellular Terms

• 5G: Fifth-generation mobile networks, providing higher throughput, lower latency and features such as network slicing.
• IoT: Internet of Things; networked devices that exchange data and can be managed remotely.
• Latency: Delay between sending and receiving data; important for real-time applications.
• Bandwidth: Maximum data transfer rate of a network or connection.
• Modulation: Method of encoding bits onto a carrier; examples include QPSK and 16-QAM.
• Frequency Reuse: Reusing frequency resources across non-adjacent cells to increase capacity.
• Network Slicing: Creating multiple virtual networks on shared infrastructure to provide isolated performance profiles.