Trace the complete path of a data packet from a mobile device through the radio access network, 5G core, and across the global internet to its destination — every protocol, every hop, every function that participates in delivering the content you access.
Every time you open a browser or launch an app on your mobile device, a remarkable sequence of events unfolds in milliseconds. A request leaves your device, traverses radio waves to a base station, passes through a series of network functions in the operator's core network, exits onto the public internet, crosses potentially thousands of kilometres of optical fibre, reaches a server somewhere in the world, and returns with data — all before you perceive any delay. Understanding this journey — every protocol, every function, every physical and logical hop — provides genuine insight into how the internet works over mobile networks.
This article traces a single HTTPS web request from a 5G-connected smartphone to an origin web server, describing what happens at each stage with technical precision. The principles apply equally to any mobile internet session, whether over 5G, 4G LTE, or 3G, with differences in speed, latency, and specific protocol versions.
Complete internet connectivity path from mobile device to origin server across operator network and public internet
The journey begins in an application on the user's device — a browser, a streaming app, a social media client, or any application that communicates over the internet. When the application wants to retrieve content, it constructs an HTTP request (or HTTPS for encrypted connections, which is now the overwhelming norm). This request is handed to the device's operating system networking stack, which processes it through the TCP/IP layers.
Before any data can flow, the application must resolve the hostname of the destination server (e.g., "www.example.com") to an IP address via DNS. The device's DNS resolver sends a DNS query — typically to an operator-provided recursive resolver assigned during PDU session establishment. The DNS resolution completes in milliseconds, returning an IP address (or set of addresses, for large-scale services with multiple geographically distributed endpoints).
With the IP address known, the TCP stack initiates a three-way handshake (SYN → SYN-ACK → ACK) to establish a reliable connection to the server. For HTTPS, a TLS handshake follows the TCP handshake, negotiating encryption parameters and verifying the server's identity through its X.509 certificate. Modern browsers and applications use TLS 1.3, which requires only one round-trip for the handshake — the client sends its key share in the first message, and the server can begin sending encrypted data in its first response.
Once the IP packet is formed by the TCP/IP stack and handed to the modem, it enters the 5G radio protocol stack. The packet is processed top-down through the NR protocol layers: SDAP assigns the appropriate QoS Flow Identifier (QFI) based on the packet's destination and DSCP marking; PDCP compresses the IP/TCP headers using ROHC (Robust Header Compression) to save radio bandwidth, applies ciphering (AES or SNOW 3G) and integrity protection; RLC segments the compressed packet if necessary and provides error detection; and MAC multiplexes the data with any control information and requests radio resources from the scheduler.
The physical layer then modulates the data onto OFDM subcarriers, applies the beamforming precoding matrix calculated by the massive MIMO system to focus the signal energy toward the device's spatial location, and transmits the signal. The gNB base station receives the signal, decodes it through the PHY and L2 stack, and recovers the original IP packet — now encapsulated in a GTP-U tunnel for transport through the operator's backhaul network to the UPF.
The minimum one-way air interface latency in 5G NR is determined by the slot duration (0.5ms at 30kHz subcarrier spacing) plus processing times. In practice, one-way latency over the 5G air interface is 1–4ms for sub-6GHz deployments, compared to 4–10ms for LTE. For URLLC with 120kHz numerology, the slot duration is only 0.125ms, enabling sub-1ms over-the-air latency.
The GPRS Tunnelling Protocol — User Plane (GTP-U) is the tunnelling protocol used to carry subscriber data packets across the mobile operator's core network. GTP-U wraps each subscriber's IP packets inside GTP-U headers that identify the specific PDU session and QoS flow they belong to, allowing the network to maintain per-subscriber data separation and QoS enforcement as packets traverse shared infrastructure.
From the gNB, the GTP-U encapsulated packet travels over the operator's backhaul network — typically optical fibre — to the User Plane Function (UPF). The backhaul network may use IP/MPLS for traffic engineering, ensuring that GTP-U packets are forwarded with appropriate priority based on their QoS characteristics. At the UPF, the GTP-U tunnel is terminated: the UPF strips the GTP-U header, inspects the inner IP packet against its configured Packet Detection Rules (PDRs), and applies the appropriate Forwarding Action Rule (FAR) — which for internet-bound traffic means forwarding the packet out the N6 interface toward the public internet.
Before forwarding, the UPF also applies metering — recording the byte count for this subscriber's session and reporting it periodically to the Online Charging System (OCS) via the Nchf interface (5G) or Gy (4G). If the subscriber's data quota is exhausted, the OCS instructs the UPF to apply a throttling or blocking action rule instead. If a NAT function is required (because the subscriber has a private RFC 1918 IP address), the UPF or an adjacent NAT function translates the source address to a public IP before forwarding.
Once the packet exits the operator's UPF, it enters the public internet — a network of networks interconnected through commercial peering and transit agreements. IP routing on the internet uses the Border Gateway Protocol (BGP), the protocol that allows autonomous systems (AS) — the networks operated by ISPs, content providers, cloud platforms, and enterprises — to exchange reachability information and determine the best paths for forwarding packets between them.
The operator's border router has BGP routes learned from its upstream transit providers and any directly peered networks. It selects the best path to the destination IP address based on BGP attributes including AS path length, local preference, and community values set by routing policy. The packet may traverse multiple autonomous systems before reaching its destination — each AS router makes a hop-by-hop forwarding decision based on its routing table, built from BGP advertisements.
Internet Exchange Points (IXPs) play a critical role in reducing the number of hops and transit costs by providing a shared layer-2 fabric where multiple networks can peer directly without going through a transit provider. Major IXPs in the region, such as the MENA-IX in Dubai or the DE-CIX in Frankfurt (for European destinations), allow the operator's traffic to reach major content providers with fewer hops and lower latency than routing through a transit provider's backbone.
DNS resolution is a prerequisite for establishing any internet connection, and its performance has a direct impact on the user-perceived latency of every web page load and application startup. The DNS lookup that occurs at the beginning of a connection involves a recursive resolver (typically operated by the mobile network operator) querying a hierarchy of DNS servers to find the authoritative answer for the requested hostname.
The recursive resolver first checks its cache — if it has a recent non-expired record for the requested hostname, it returns the cached answer immediately without any further network queries. If not, it queries a DNS root server to find the TLD (Top Level Domain) nameserver, then queries the TLD nameserver to find the authoritative nameserver for the domain, then queries the authoritative nameserver for the final IP address. Each query involves a UDP or TCP packet exchange, and the total resolution time depends on the cache hit rate and the round-trip time to each nameserver in the hierarchy.
For large-scale services operated by major content providers, the authoritative DNS response returned to the resolver is not a single IP address but is carefully crafted to direct the requesting client to the geographically closest CDN edge node. The DNS response may include IP addresses of edge servers in the same country or region as the operator's resolver, ensuring that subsequent TCP connections and content delivery traverse the minimum possible geographic distance.
Content Delivery Networks (CDNs) are distributed systems of edge servers strategically positioned at internet exchange points and within ISP networks around the world. Major CDN operators — including Cloudflare, Akamai, Fastly, Amazon CloudFront, and Google Cloud CDN — operate thousands of edge nodes globally to cache and serve content as close to end users as possible, dramatically reducing the latency and bandwidth required to deliver web content and streaming media.
When a TCP connection is established from a mobile device to a CDN edge node, the TLS handshake is performed with that edge server rather than with the origin server — which might be located on a different continent. The TLS 1.3 handshake completes in a single round-trip to the edge node (potentially 10–30ms from the device to a regional edge node, compared to 100–200ms to a distant origin server), and the HTTPS request is processed by the edge.
If the requested content is cached at the edge (a cache hit), the CDN edge serves it directly without involving the origin server. For static content such as images, CSS, JavaScript, and video segments, cache hit rates of 80–95% are typical for well-configured CDN deployments. Only for dynamic content or cache misses does the edge need to fetch content from the origin — and it does so over a pre-established, persistent connection to the origin server, using HTTP/2 or HTTP/3 (QUIC) to efficiently multiplex multiple requests over a single connection.
HTTP/3, the latest version of the HTTP protocol, runs over QUIC (Quick UDP Internet Connections) rather than TCP. QUIC is a transport protocol built on UDP that provides multiplexed streams without head-of-line blocking, faster connection establishment (0-RTT or 1-RTT handshake), and built-in TLS 1.3 encryption. On mobile networks where packet loss is more common, QUIC's per-stream loss recovery prevents a single lost packet from blocking all concurrent streams — a significant advantage over TCP/HTTP2.
For dynamic content that cannot be cached — personalized pages, search results, real-time data, or authenticated user content — the request must reach the origin server. The origin may be a physical server in a data centre, a virtual machine in a cloud platform, or a containerised microservice in a Kubernetes cluster. The server processes the HTTP request, executes any application logic (database queries, authentication checks, business logic), and constructs an HTTP response.
The response travels back through the same path in reverse — from the origin through CDN infrastructure (which may cache the response for future requests), across the internet via BGP routing, through the operator's UPF, through GTP-U tunnels to the gNB, and finally over the 5G air interface back to the device. The device's TCP stack reassembles any fragmented packets, the TLS layer decrypts the response, and the HTTP layer passes the content to the application — which renders it for the user.
| Stage | Component | Typical Latency (one-way) | Notes |
|---|---|---|---|
| Air Interface | 5G NR (Sub-6GHz) | 1–4 ms | Slot duration + processing time |
| Backhaul | Fibre to UPF | 1–5 ms | Depends on backhaul distance |
| Core Network | UPF processing | <1 ms | Software forwarding in UPF |
| Operator → IXP | Peering interconnect | 1–10 ms | Regional IXP proximity |
| DNS | Recursive resolution | 5–50 ms | Cache miss; varies widely |
| IXP → CDN Edge | CDN edge node | 1–30 ms | Regional edge node location |
| CDN → Origin | Origin server | 20–200+ ms | Geographic distance to origin |
| Total (CDN hit) | Device to CDN edge | ~10–50 ms RTT | Common for cached content |
| Total (origin) | Device to origin server | ~50–300 ms RTT | Depends on origin location |
The vast majority of internet traffic over mobile networks today is encrypted using TLS (Transport Layer Security). HTTPS — HTTP over TLS — ensures that the content of web requests and responses cannot be read or modified by any intermediate network function, including the operator's own infrastructure. This encryption is applied end-to-end between the device and the TLS termination point (the CDN edge or origin server), meaning that even the UPF in the operator's core network sees only encrypted packets — it can see that the device is communicating with a specific IP address, but it cannot see the content of the communication.
This has important implications for mobile network management. DPI (Deep Packet Inspection) systems that rely on inspecting application-layer content are largely blind to HTTPS traffic. Instead, operators use encrypted traffic analysis techniques — examining packet sizes, timing patterns, and TLS metadata such as the Server Name Indication (SNI) field in the TLS ClientHello — to classify traffic for QoS and policy purposes without decrypting it. Encrypted Client Hello (ECH), an emerging TLS extension, further obscures even the SNI field by encrypting it using a public key published in the server's DNS records, providing additional privacy for users on mobile networks.
A unique challenge of mobile internet connectivity compared to fixed broadband is maintaining connection continuity as the device moves between cells. As described in the coverage section of this site, 5G handovers transfer the radio connection from one gNB to another — but from the perspective of the TCP connection, the endpoint IP addresses have not changed, and the connection continues uninterrupted. The UPF acts as the session anchor: even as the radio connection hands over to a different gNB, the data path from UPF to internet remains stable, and the gNB-to-UPF GTP-U tunnel is simply re-established to the new gNB. The TCP connection running on top of this infrastructure is completely unaware of the handover — it experiences no interruption, timeout, or packet loss (in an ideal handover scenario).
The journey of a single data packet from a 5G smartphone to a web server and back encompasses an extraordinary range of technologies and engineering disciplines: radio physics, signal processing, software-defined networking, internet routing, distributed systems, cryptography, and application protocol design. Each component — the 5G NR air interface, the GTP-U tunnelling infrastructure, the UPF's per-flow enforcement, the BGP routing fabric, the CDN edge network, and the TLS encryption layer — is the product of decades of standardisation and engineering refinement.
Understanding this chain of technology provides not just academic knowledge but practical insight into why mobile internet performance varies between locations, why different applications feel faster or slower on the same network, and why the network infrastructure investment that operators make directly translates into the quality of experience for every subscriber. The educational resources throughout this website explore each component of this chain in greater technical depth.