JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Mobility: Handoff, Mobile IP, and TCP on the Move

Walking out of one cell and into the next without dropping your call is a small miracle of coordination. This last guide in the rung shows how networks hand a moving device from base station to base station, why your IP address wants to stay still while you do not, and why TCP — built for stable wires — keeps misreading a moving wireless link.

The problem mobility creates

By now you have met the wireless link itself, the Wi-Fi MAC, the cellular architecture, and the leap from 3G to 5G. Each of those guides quietly assumed something that real life refuses to grant: that the device stays put. But the whole point of wireless is that you walk, drive, ride a train. The moment you move, two separate problems appear, and it is worth keeping them apart because they live at different layers and have completely different solutions.

The first problem is local and physical: as you move, the radio link to your current base station or access point gets weaker, and a different one nearby gets stronger. Something has to switch you over to the better one mid-conversation. That switch is called handoff (or handover), and it is a link-layer and access-network job. The second problem is global and logical: when you change which base station serves you, you may end up attached to a different part of the network entirely, yet the rest of the Internet still wants to reach you at the address it already knows. Keeping you reachable as you roam is mobility management, and the classic answer at the network layer is Mobile IP. Handoff is about staying connected to the air; mobility management is about staying findable on the Internet.

Handoff: passing you from cell to cell

Picture the cellular world you built in guide 3: a honeycomb of cells, each with a base station, all wired back to the operator's core. As you ride a train across cell boundaries, your phone is constantly measuring the signal strength of its current cell and of the neighbors it can hear. When a neighbor becomes clearly stronger for long enough — not just for a flicker, which would cause useless ping-ponging — the network decides it is time to move you. Crucially, in cellular the network is in charge of the decision, using your measurement reports plus its own knowledge of cell load, so it can steer you to a cell that has room, not just the loudest one.

  1. Your phone keeps measuring the strength of its serving cell and of neighbor cells it can hear, and reports those numbers to the network.
  2. The network decides a target cell is better (and has capacity) and tells that target to reserve resources for you in advance.
  3. The network signals your phone to retune to the target cell; for a brief instant the old and new paths overlap so almost nothing is lost.
  4. Your traffic is rerouted through the core to the new base station, the old cell releases your resources, and your call or download continues uninterrupted.

Wi-Fi handoff is humbler. In an access point mesh — say, a campus or an airport with one Wi-Fi SSID covering many APs — your laptop usually decides for itself when to roam, and classic 802.11 makes it disconnect from one AP and re-associate with the next. That gap, plus repeating the authentication handshake, can stall traffic long enough to drop a voice call, which is exactly why standards for faster roaming were added later. The honest summary: cellular handoff is network-controlled and engineered to be seamless because you are expected to move at highway speed; Wi-Fi roaming was bolted on afterward and is far more likely to hiccup.

Mobile IP: keeping one address while you wander

Now the network-layer half. Recall an honest point from early in the ladder: an IP address names a location in the network — an interface on a particular link — not a person or a permanent device. Addresses are handed out per network: when you join a new network you normally get a new address (often by DHCP). That is fine for a fresh download, but it is a disaster for an ongoing connection. Your friend, your game server, your video call all opened a session to your old address. Move, get a new address, and every one of those sessions is now talking to a place you no longer are. The packets fall on the floor.

Mobile IP solves this with a wonderfully simple idea: give the device two addresses and a mail-forwarding service. The first is your home address, permanent and stable, the one the world knows you by — think of it as your legal home street address. The second is a temporary care-of address you pick up wherever you currently are, like checking into a hotel. A piece of infrastructure on your home network, the home agent, acts as the post office that knows your forwarding instructions. Whenever you arrive somewhere new, you tell the home agent your current care-of address, and from then on it forwards anything sent to your home address onward to wherever you actually are.

  Correspondent                Home Agent                 Mobile node
  (your friend)             (the post office)          (you, roaming)
  ------------              -----------------          ---------------
  sends to HOME addr  --->   intercepts, then     --->  receives at
  198.51.100.7               wraps + forwards to         care-of addr
                             care-of 203.0.113.42        203.0.113.42

  reply  ----------------------------------------------> can go direct
  (often straight back to the friend's address)
The triangle of Mobile IP: traffic to your stable home address is intercepted by the home agent and tunneled to your current care-of address, while your replies can often head straight back. Your friend never has to know you moved.

The trick that makes this invisible is tunneling: the home agent does not rewrite your packets, it wraps each one inside a new IP packet addressed to your care-of address — an envelope inside an envelope, exactly the encapsulation idea from the foundations rung. Your device unwraps the outer envelope and finds a packet still addressed to its home address, so every connection believes it is still living at home. Honest caveats, though: this forwarding adds a detour (the 'triangle'), it needs that home-agent infrastructure, and classic Mobile IP is not widely used as a bare protocol on the public Internet today. In practice mobile carriers solve roaming inside their own core with their own anchor points and tunnels, and apps increasingly lean on higher-layer tricks instead. Mobile IP is best learned as the clean canonical model of the problem and its shape of solution.

Why TCP stumbles when you move

Even with handoff and mobility management working, there is a deeper mismatch, and it is the punchline of the whole rung. Classic TCP was designed for stable wires, and it carries one stubborn assumption you met in the congestion rung: a lost packet means the network is congested. On a wire that is almost always true — a packet is lost because a router's queue overflowed. So TCP's reflex on loss is to assume the network is full and cut its congestion window hard, roughly in half. That reflex is exactly right on a wire and exactly wrong on the air.

On a wireless link, packets are lost for reasons that have nothing to do with congestion: radio interference, fading, multipath, a momentary obstacle, a hidden terminal colliding on the air. The link has plenty of room — the bits just got corrupted. But TCP cannot tell wireless loss apart from congestion loss; it sees a missing acknowledgment and throttles itself anyway. So you get the worst outcome: the link was fine, nothing was congested, yet TCP needlessly halves its sending rate and crawls. That is the heart of poor TCP performance over wireless. Handoff makes it worse: a handoff gap looks to TCP like a burst of loss, so finishing a clean handoff can still trigger an unnecessary, self-inflicted slowdown.

How do networks fight back? Three honest families of fix. First, hide the loss below TCP: the wireless link layer retransmits corrupted frames locally and quickly — using strong Wi-Fi or cellular error correction and link-layer ARQ — so most radio losses are repaired before TCP ever notices a gap. Second, change the algorithm: a measurement-based design like TCP BBR does not equate loss with congestion at all, judging the path by its measured bandwidth and round-trip time instead, which suits a flaky wireless edge far better. Third, split the path: some systems terminate one TCP connection at the base station and run a wireless-tuned protocol over the last hop, so the wired half never sees the radio's losses. Each helps; none is free of trade-offs.

Putting the whole rung together

Step back and see the arc. You learned why the air is a hostile medium — attenuation, interference, multipath, a bit-error rate that wanders — and why a radio cannot detect a collision while it transmits, which forced Wi-Fi into collision avoidance with RTS/CTS instead of the collision detection that wired Ethernet enjoys. You met the access point and the choice of infrastructure versus ad-hoc, Bluetooth for the short range, and the cellular design of cells, base stations, and a core. You saw what 3G to 5G really changed. This final guide added the dimension that makes wireless truly hard: you do not hold still.