Nire Bryce

from my experience the public-facing IP generally stays because there's enough internal routing between the handset and the internet. so for a static web page, at least, I think you could get by with a dynamic DNS provider like the venerable dyndns, and a caching/CDN layer, and still be pretty available -- cloudflare would probably give you enough caching for free, if you can swallow your distaste for them. as the site gets more dynamic, you'll suffer more outages because less is cacheable, but even up to a simple webapp you can probably theoretically do it. just offhand, I think the first pinch point might be efficiently utilizing a cell phone processor using process-per-worker web frameworks?

at least in lte or 5g, and probably older 3gpp protocols, there's a central ~router that hands out ip addresses for mobiles to use, and the control plane asks it to tunnel your traffic toward your serving base station. the inner ip header is what your mobile sees, and the outer header has the addresses of the base station and the "core network" piece that handles the tunneling (lte calls it a gateway, 5g calls it a user plane function). the land internet sees you coming from a fixed location, wherever the gw or upf connects to.

to support mobility, the serving base station asks your phone to report signal measurements of neighboring base stations, and when it's appropriate, the serving base station asks the neighbor to set up a handover, and the handover process also results in signaling to move the tunnel to the new base station. there's also some "user-plane" (data path) stuff so data that got to the old base station (or was sent shortly after the handover) finds its way to you before new data.

there are many sequence diagrams for lte signaling in 3gpp ts 23.401 clauses 5.3 and 5.5, and some overview in 36.300. i haven't soaked my brain quite enough in the 5g equivalents to have a reference handy, but if you actually want i can dig some up.