02 · The problem
Responders lose connection when they need it most
Why responders need a connection
First responders increasingly rely on online tools in the field. Many teams use ATAK, which puts team positions and incident data on a shared map on their phones and has traditionally depended on cellular service. Search and rescue teams plan and navigate with mapping tools such as CalTopo, and voice calls over the internet let teams talk wherever there is data coverage.
In a desert search and rescue operation or during a sandstorm, however, coverage is patchy, and a responder's phone constantly switches between different cell towers and satellite. The tools are only as good as the connection underneath them.
Why switching networks breaks things
Each network switch gives the phone a new IP address. Ordinary app connections are tied to that address, so every switch forces apps to start again with a new TCP handshake. As a result, maps stall, pages fail to load and voice calls drop out.
What a single switch looks like to an app:
- The phone joins a new network and gets a new IP address.
- Every open TCP connection was tied to the old address, so it is now dead, though the app often only notices after a timeout.
- The app opens a new connection: a TCP handshake, then a TLS handshake, before any data can flow.
- Whatever was in flight, a page, a map tile, a message, is lost or has to be sent again.
Each gap may seem short, but switches happen again and again as a team moves, and every one interrupts every app on the phone at the same time.
The cost of reconnecting
of dead time after every switch on a geostationary satellite link, before any data can flow again.
A new secure connection needs a TCP handshake and then a TLS handshake, and each takes at least one full round trip. On a geostationary satellite link a single round trip takes around 600 milliseconds, so the cost of reconnecting grows with the latency of the link.
| Link | Round trip | Two handshakes |
|---|---|---|
| Wi-Fi | 8 ms | 16 ms |
| 5G | 24 ms | 48 ms |
| Low-orbit satellite | 40 ms | 80 ms |
| Geostationary satellite | 600 ms | 1.2 s |
Round trips of the links we emulate. Noticing that the old link is gone comes on top.
With QUIC connection migration, no new handshake is needed at all.
03 · Existing solutions
What already exists, and where it falls short
QUIC connection migration
QUIC is a modern transport protocol that identifies a connection by an ID rather than an IP address, so in principle it can move to a new network without reconnecting. It is already built into some web browsers, where it speeds up page loads by combining the transport and encryption handshakes into one.
+ Strength: Designed to survive network changes, with fast, encrypted handshakes.
− Limitation: Migration is rarely used in practice, and most apps and voice traffic still run over TCP, which cannot migrate at all.
Mosh, the mobile shell
Mosh is a remote terminal tool that keeps a session alive while the client changes IP address, even when switching between Wi-Fi, cellular data and wired Ethernet. It also predicts how each keystroke will change the screen, hiding latency from the user.
+ Strength: Proven roaming between networks, plus prediction that hides delay.
− Limitation: Works only for terminal sessions, so it cannot help a responder loading a map, opening a website or making a call.
Multipath TCP
Multipath TCP lets a single connection use several network paths at once, such as Wi-Fi and cellular. If one path fails, traffic carries on over the others. Apple uses it on iPhones for services such as Siri, so that requests survive a weak Wi-Fi signal.
+ Strength: Keeps a connection alive when one link drops, and can combine the capacity of several links.
− Limitation: Both the device and the server must support it, which most websites do not, and it does nothing to reduce the data sent over slow links.
Side by side
| Survives an IP change | Helps web and app traffic | Needs every website to change | Sends less data on slow links | |
|---|---|---|---|---|
| QUIC migration | Yes, when both ends support it | Only apps built on QUIC | Yes | No |
| Mosh | Yes | No, terminal sessions only | Needs Mosh on the remote machine | Only for terminal screens |
| Multipath TCP | Yes, if another path is up | Where both ends support it | Yes | No |
| Shajarah | Yes | Apps that use the phone's proxy setting | No, only our own server | Yes: compression and prefetching |
04 · Our idea
A dual proxy between the phone and the cloud
Shajarah places two proxies between the user's apps and the internet: a client proxy on the user's device and a server proxy in the cloud. All traffic between them travels through one QUIC tunnel that stays open when the device changes network, while the server proxy does the heavy work on the device's behalf. Unlike the existing solutions, it both survives network switches and reduces the data that has to cross a slow link.
Survives IP switches
The client proxy takes the traffic of every app that uses the phone's proxy setting and carries it inside a single QUIC tunnel. When the phone switches networks, the tunnel moves with it instead of breaking.
Sends less data
The server proxy fetches web pages on the phone's behalf and compresses them before sending, so far less data crosses the slow link. This saves bandwidth on every connection, not just satellite ones, lowering data costs and leaving more capacity for time-critical traffic such as voice calls.
Loads before you click
The server uses Jev, a lightweight AI model accessed through an API, to predict which links the responder will open next. It sends those pages to the phone in advance, so they load instantly, even during a brief loss of signal.
Why two proxies?
Neither the apps nor the websites have to change. Apps talk to the client proxy as they would to any proxy, and websites see an ordinary visitor: the server proxy. Only the part in between, which we control on both ends, needs to cope with the network changing.
Keeping the unreliable link short
The handshakes with websites and any lost packets on the way to them are handled by the server, over its fast and stable connection. Only the phone's own link, the one that keeps changing, is left to the QUIC tunnel.
05 · Model
How Shajarah fits together
A request, step by step
- An app asks the client proxy for a page.
- If a fresh copy is in the phone's cache, it is served at once. If an older copy is there, the proxy asks the server whether it changed (ETag), and only the answer crosses the link when it hasn't.
- Otherwise the request goes through the tunnel; the server fetches the page, compresses it and sends it back.
- In the background, the server asks Jev which links come next and pushes the likely pages to the cache.
When the network changes
- The client proxy checks the tunnel five times a second.
- If the current link stops answering for a second, it moves the tunnel to another network that works.
- The same QUIC connection carries on from the new IP address: no new handshake, and requests in flight complete.
- If the link comes back after a long silence, QUIC's retry timer is reset at once, so traffic flows again within a second.
When the signal fades
- The phone watches the signal strength and fits a trend to the last five seconds.
- If the signal will become unusable within eight seconds and there is no other network, it warns the server.
- The server prefetches much more, two clicks deep for long outages, so there is something to read offline.
- It stops sending just before the expected drop, since data sent into a dead link only jams the connection when it comes back.
06 · Prototype
How our prototype works
Why two computers? We have not yet committed to paying for server hosting, so computer 2 stands in for the cloud server. In the real system, the client proxy runs on the iPhone itself and connects directly to a remote server.
Running the demo
Computer 2 runs the server proxy and creates a certificate, which we copy to computer 1 so the two machines can trust each other. Computer 1 runs the client proxy and accepts connections from other devices on the Wi-Fi network. On the iPhone, we set a manual proxy in the Wi-Fi settings that points at computer 1, then browse normally in Safari. The full steps are in the README on GitHub.
Two kinds of traffic
Secure HTTPS sites pass through the tunnel still encrypted, so neither proxy can read their contents. Plain HTTP sites go through the full proxy, where the server compresses pages and the phone side caches them. Both kinds of traffic share the same QUIC tunnel between the two computers.
Showing a network switch
The iPhone's proxy setting only works on Wi-Fi, so the switch happens on computer 1: it keeps Wi-Fi for the iPhone and moves the tunnel between Ethernet and mobile data while Safari keeps loading. On computer 2, the server log records every site opened, and Wireshark shows one QUIC connection carrying all of the traffic. The switch itself is what our emulated tests measure; see the results.
What the live demo showed
secure connections to 44 different sites in half an hour of browsing on the iPhone, all carried by one QUIC tunnel
connections opened by a single Google search in under four seconds, every one inside the same tunnel
to load a 922 KB Wikipedia page over HTTPS through both proxies
The Instagram app worked through the tunnel unchanged: it picks up the iPhone's proxy setting by itself. Every connection that failed was to an ad, tracking or telemetry server, which the network we tested on appears to block.
07 · Testing process
How we tested Shajarah
To test the system fairly and repeatably, we built a simulated network on a single Linux PC. Network namespaces create four separate machines: a phone, a router, a cloud server and a website. tc netem, a free, open-source Linux tool, gives each link realistic delay, jitter, packet loss and bandwidth. We ran two scenarios: a 5G outage, where the signal fades and the link stays dead for about 45 seconds before returning, and a walk where Wi-Fi fades out and the phone moves over to 5G.
The signal fades from 30 s, the link is dead from 38 s to 84 s, and 5G returns. Wi-Fi and satellite are unavailable throughout, so there is nowhere to switch to.
Instead of inventing browsing behaviour, we used Wikipedia's public click records, which count how often real readers followed each link from one article to another. Each run is one simulated reader following real clicks from August 2026. We ran 20 runs for each of four setups, from plain TCP up to the full system, and compare median results so that one unusually fast or slow run cannot skew the outcome.
Jev is used as-is through its API, so it needs no training data. We scored it on 1,002 Wikipedia pages against 109.1 million real clicks from July 2026 and compared it with three baselines: a random pick among the same 40 links Jev sees, the order of links on the page, and the most-clicked link from June. Keeping the three months separate means no predictor is scored on clicks it learned from.
What we measured
- Page load time: The time from requesting a page to receiving all of it.
- Recovery time: How long after the network comes back the first new packet gets through the tunnel.
- Data transferred: The bytes sent over the phone's link, before and after compression.
- Hit rate: The share of real clicks that went to a predictor's top one or top three links.
- Wasted prefetch: Data spent on prefetched pages that were never opened.
Link settings (one-way)
| Link | Delay | Jitter | Loss | Bandwidth |
|---|---|---|---|---|
| Wi-Fi | 4 ms | 2 ms | 0.1% | 100 Mbit/s |
| 5G | 12 ms | 4 ms | 0.2% | 150 Mbit/s |
| LTE | 25 ms | 8 ms | 0.5% | 30 Mbit/s |
| Low-orbit satellite | 20 ms | 6 ms | 0.5% | 100 Mbit/s |
| Geostationary satellite | 300 ms | 10 ms | 0.3% | 20 Mbit/s |
Applied at both ends of each link, so a round trip is about twice the delay. The grey rows are ready in the testbed but not yet used in a test.
The four setups
| Setup | Tunnel | Compression | Prefetching | Runs | Pages opened |
|---|---|---|---|---|---|
| TCP+TLS | TCP+TLS, reconnects after a drop | Yes | No | 20 | 78 |
| QUIC | QUIC, keeps the connection | Yes | No | 20 | 90 |
| QUIC + fixed prefetch | QUIC | Yes | Jev, ignoring outage warnings | 20 | 92 |
| Shajarah | QUIC | Yes | Jev, more before an outage | 20 | 95 |
Three months of click data, kept apart
| Month | Used for |
|---|---|
| June 2026 | The most-clicked-link baseline only |
| July 2026 | The answer key: scoring Jev and the baselines (109.1 million clicks on 1,002 pages) |
| August 2026 | The browsing sessions the simulated readers follow |
08 · Test results
What the tests showed
QUIC recovery after a 5G outage, against 13.1 s for our TCP+TLS baseline (median of 20 runs)
median page size reduction with deflate, across 2,147 Wikipedia pages
Jev top-3 hit rate, over three times a random pick among the same links (5.1%)
Recovery time, median
After the 5G outage, 20 runs each
Show as a table
| Median | Middle half of runs | |
|---|---|---|
| TCP+TLS | 13.1 s | 13.0–13.2 s |
| QUIC | 0.96 s | 0.92–1.03 s |
Page load time, median
Away from any drop
Show as a table
| TCP+TLS | QUIC | |
|---|---|---|
| Wi-Fi | 224 ms (10 pages) | 216 ms (10 pages) |
| 5G | 265 ms (54 pages) | 229 ms (61 pages) |
Recovery
When 5G returned after an outage of about 45 seconds, QUIC was carrying traffic again within a second, while our TCP+TLS baseline took 13 seconds to reconnect. This includes our own change to QUIC, which resets its retry timer as soon as the server is heard again; without it, QUIC also took tens of seconds. Away from any drop, page loads took about the same time on both.
Prediction
Jev's top-3 hit rate of 16.1% beats both data-free baselines, a random pick (5.1%) and the order of links on the page (9.4%), without needing any click data. A most-clicked ranking scores higher (38.1%), but it relies on the website's own click logs, which a proxy does not have.
Data savings
Across the 20 outage runs, plain QUIC sent 4.7 MB where the uncompressed pages would have taken 25.2 MB, 5.4 times less. Over the whole Wikipedia snapshot used in testing, 847 MB of pages compresses down to 133 MB, a 6.4-fold saving on every link, not just slow ones.
Waiting for pages during the outage
Total time each reader spent waiting for pages over the two-minute run, 20 readers per setup. Pages opened from the phone during the outage are the ones Shajarah had prefetched or saved.
| Setup | Mean wait | Median wait | Outage clicks opened from the phone | Prefetched per run |
|---|---|---|---|---|
| TCP+TLS | 31.7 s | 28.5 s | 3 of 20 | – |
| QUIC | 21.6 s | 17.0 s | 3 of 22 | – |
| QUIC + fixed prefetch | 20.1 s | 12.6 s | 5 of 23 | 0.24 MB |
| Shajarah | 14.0 s | 3.4 s | 14 of 26 | 2.9 MB |
Against plain QUIC, Shajarah was faster for 8 of the 20 readers and slower for none; the others clicked a page that had not been predicted and waited for the network like everyone else.
Prediction in detail
| Predictor | Top 1 | Top 3 | Needs |
|---|---|---|---|
| Jev | 6.2% | 16.1% | Nothing but the page |
| Random pick among the same 40 links | 1.7% | 5.1% | Nothing |
| Order of links on the page | 2.7% | 9.4% | Nothing |
| Most-clicked link last month | 19.2% | 38.1% | The website's click logs |
Share of each page's real July clicks that went to the predictor's top links, averaged over 1,002 pages. Jev sees the page's first 40 content links, which hold 66% of the clicks; the most-clicked baseline ranks every link.
Data in detail
| Uncompressed | Sent | Saving | |
|---|---|---|---|
| Wikipedia snapshot, 2,147 pages | 847 MB | 133 MB | 6.4× |
| QUIC, 20 outage runs | 25.2 MB | 4.7 MB | 5.4× |
| Shajarah, 20 outage runs, with prefetching | 384 MB | 62.1 MB | 6.2× |
Per page, the saving ranges from 2.7× to 19×; the middle half of pages shrink between 5.1× and 6.2×.
The cost of prefetching
Shajarah sent 2.9 MB of prefetched pages per run, and 99.2% of it was never opened: most predictions miss, so a prefetch pays off only when an outage makes one hit worth the data. That is why prefetching is heavy only when a dropout is predicted.
What went wrong along the way
- Pushing into a dead link. Early runs kept prefetching into the outage. The unacknowledged data then held up QUIC's recovery, and some readers waited longer than with plain QUIC. The server now stops just before the predicted drop and never has more than 256 KB of prefetched data unacknowledged.
- A retry timer that kept growing. After 45 seconds of silence, QUIC waited about 30 seconds before trying again. Both ends now reset that timer as soon as they hear from each other.
- Pages that never matched. Prefetched pages were missed because the same address was written in two ways. Addresses are now normalised on both ends.
09 · Improvements
What we can improve
- QUIC tunnelOne connection that survives IP address changes.
- HTTPS pass-throughSecure sites cross the tunnel still encrypted.
- Satellite and cellular at onceSend over both links and use whichever is faster.
- Predictive early switchingMove networks before the signal fails.
- Proxy authenticationOnly approved devices can use the client proxy.
- Jev link predictionRanks the links a user is likely to open next.
- Page cacheServes repeated requests without refetching them.
- Conditional requests (ETag)Checks if a page changed without redownloading it.
- Local Jev via LayaKeeps browsing data on servers we control.
- Battery-aware prefetchingPrefetches less when the battery is running low.
- Deflate compressionPages cross the tunnel about 5.7 times smaller.
- Brotli compressionA stronger algorithm that shrinks pages further.
- Text-first loadingSends the text of a page before its images.
- Strip unneeded HTML and CSSRemoves code that carries no useful information.
- Resize images and videoShrinks images and lowers video quality on slow links.
- Emulation testbedRecreates Wi-Fi and 5G links, outages and handovers.
- Self-hosted serverEmergency services control their own infrastructure.
- Responder priority (eMLPP)Serves responders first, as GSM does for rescue calls.
- Resilient Opus voice callsError correction turns packet loss into brief distortion.
- Store-and-forward messagesMessages sent in a blackout arrive on reconnection.
10 · Real-world use
From prototype to the field
Phase 1 · Done
Lab prototype
The emulated testbed and iPhone demo presented here.
Phase 2
Field recordings
Use an antenna to record real signal drops in the field, then replay them in our simulated network.
Phase 3
Cloud server
Set up an AWS server to host the server proxy, so the tunnel runs over the real internet.
Phase 4
Easy-to-use app
Build a user-friendly laptop or Android app that sets up the client proxy for the user.
Who can use it
Shajarah was built around first responders, such as search and rescue teams and ambulance crews working in remote areas, but the same problem affects everyday users. Commuters on trains and buses, drivers passing between cell towers and travellers on patchy connections all lose pages and calls when their phone changes network, so Shajarah can keep ordinary browsing smooth too. For emergency teams, each device would be registered with a priority level, so the server knows whom to serve first when bandwidth is scarce.
Risks and safeguards
Because the server proxy handles users' traffic, it must be trusted, so it runs on infrastructure we control, starting with AWS, and Jev would eventually run locally. Secure sites already pass through encrypted, so the server cannot read them. The client proxy will also need authentication so that only approved devices can use it, and if the server is unreachable, the client will fall back to a direct connection, so users are never worse off than without Shajarah.
Guidelines for quality of service and experience
- Tie sessions to the user, not the network. A connection should carry on unchanged when the device moves to a new network.
- Keep the unreliable link short. Handshakes and resends should only travel between the device and a nearby, stable server.
- Fetch what matters while the signal is good. Download maps, instructions and contacts before coverage drops.
- Give live traffic priority. Voice calls and urgent messages should always go ahead of large downloads.
- Match content to the connection. On slow links, send smaller images and leave out parts of a page that add nothing.
- Judge quality by what users feel. Measure stall time, recovery time and call quality, not just download speed.