The jitter and the network
In 1827 Robert Brown watched pollen grains judder in water for no visible reason. The cause, established by Einstein in 1905, is molecular bombardment: billions of collisions, none decisive, none cancelling out exactly. Einstein's result was precise — mean squared displacement grows linearly with time, so typical distance from a starting point grows as the square root of elapsed time. There is no restoring force pulling the grain home. Given enough time, it wanders arbitrarily far.
A telecommunications network is bombarded the same way, except the collisions are cell handovers, firmware pushes, a football final, a new app that changes how forty million phones behave overnight. No single event moves the network. Their sum does. A capacity plan is a snapshot of a particle's position, and the network keeps moving after the snapshot is taken.
What arrives
Four streams matter, and they arrive at different rates and with different half-lives of relevance.
Traffic telemetry is the fastest: per-cell throughput, latency, packet loss, handover success rate, typically polled every fifteen minutes to an hour across tens of thousands of cells in a mid-sized national network. Fault alarms arrive asynchronously and urgently — a fibre cut, a power failure at a site, a cooling fault — and are meant to be acted on within minutes. Spectrum filings move on a bureaucratic clock: licence variations, coordination notices, interference complaints filed with the regulator, updated weekly or monthly, but capable of reallocating a band overnight if a regulator acts. Churn signals — porting requests, tariff downgrades, complaint volume — move on a customer clock measured in days and weeks, and they are the slowest of the four to show cause, because a subscriber's dissatisfaction usually precedes their departure by months.
None of these streams is dramatic on its own. A cell's throughput dips two per cent this week. A filing shifts five megahertz of guard band six months out. A cohort of prepaid users starts topping up less. Each is a small, independent perturbation. None forecasts the others. That is exactly the Brownian signature: no bias, no coordination, no single cause, and no ceiling on where the aggregate ends up.
What is held
A network planning system, in the frozen-corpus mode, holds a traffic model built from a defined observation window — commonly a busy-hour profile taken over several weeks the previous quarter — plus a spectrum inventory as filed at build time and a churn baseline from the last customer survey cycle. This bundle is then treated as ground truth for the planning horizon, often twelve to twenty-four months, because re-deriving it is expensive: it requires coordinated data pulls, validation against billing systems, and sign-off.
That bundle is a single realisation of a moving system, taken once. From the moment it is frozen, the actual traffic mix, the actual interference environment, and the actual subscriber base begin to separate from it, driven by nothing more dramatic than ordinary use. The planner did not do anything wrong. The corpus was a fair sample of a distribution that has since drifted, and drift needs no villain.
What triggers revision — and what usually doesn't
In the frozen mode, revision is triggered by the planning calendar, not by the network. A new capacity model is commissioned annually, or when a visible failure forces the question. Between those points, no mechanism exists to notice that the underlying traffic composition has shifted.
This is the characteristic failure. A capacity plan for a metro cluster is built on a traffic mix in which video streaming accounts for, say, forty per cent of downlink bytes and messaging apps a negligible share. Nine months later a messaging platform ships a feature that auto-plays short video within chat threads. Uplink and downlink profiles both change: shorter sessions, more of them, higher signalling load per byte transferred, different time-of-day peaking because the behaviour rides on notification patterns rather than deliberate viewing. None of this appears as an alarm. Fault monitoring shows nothing wrong; cells are within spec. What has moved is the shape of demand against a capacity plan built for a different shape. The plan is discovered stale only when congestion appears at hours the old busy-hour profile did not predict, usually reported first as customer complaints rather than telemetry breaches, because the metric being watched — peak utilisation against the old busy hour — is no longer measuring the new peak.
The person who inherits this is the network planner, and the discovery typically arrives as a congestion report from a region the model rated comfortably under-provisioned, six to nine months after the release that caused it, well past the point where blame is traceable to a cause. The planner did not miss an event. There was no event to miss — only accumulation.
What continuous intake would look at instead
A Large World Model narrows this gap without closing it: it senses a scene while the scene is present, so a live drive-test or a temporary spectrum survey tracks perturbation accurately for the duration of that episode, then goes stale again the moment the survey team leaves. Useful for a fault investigation or a site audit. Useless as a standing defence against drift, because the walk resumes as soon as observation stops.
The alternative is to treat every one of the four streams as a standing observation rather than a periodic one: traffic telemetry, fault alarms, spectrum filings and churn signals all held as live, revisable beliefs, each tagged with source and timestamp, each allowed to update the capacity model incrementally rather than at the next scheduled rebuild. Under this arrangement the mix shift caused by the video-in-chat feature would show up as a gradual reweighting of the traffic model within the first two or three weeks of the app's rollout, visible as a drift signal on the affected cells' profile before it crosses any capacity threshold. The planner is not shown a crisis. They are shown a rate of change.
| frozen corpus | bounded scene | continuous streams | |
|---|---|---|---|
| traffic telemetry | busy-hour snapshot, fixed at build | live during survey window only | polled continuously, drift tracked |
| fault alarms | not modelled, reactive only | captured during audit only | integrated as standing revision trigger |
| spectrum filings | inventory as filed at build time | re-checked per project | watched continuously, provenance kept |
| churn signals | quarterly survey baseline | not applicable | tracked as leading indicator, timestamped |
What it costs, and where the objections bite
Two objections carry real weight in this domain.
The first is economic. Displacement under a Brownian process grows only as the square root of time, so halving the observation interval buys a factor of roughly 1.4 in accuracy, not a factor of two. Running continuous ingestion, storage, and reconciliation across four heterogeneous streams — telemetry at fifteen-minute resolution, alarms in real time, filings weekly, churn daily — is materially more expensive than a quarterly rebuild, and most operators cannot justify streaming every one of these at full fidelity.
"You are proposing a standing operational cost to shave a square root off an error term. The capacity model is refreshed twice a year because that is the point on the curve where cost and benefit meet. Streaming everything is a solution in search of a budget."
The answer is not that the scaling is wrong — it is right — but that consequences here are convex, not linear. A traffic model stale by one quarter is a rounding error most weeks and a blocked-call event during a single unanticipated peak. The cost of staleness is not smooth, so a fixed refresh interval is a bet that no threshold gets crossed between refreshes. Selective continuity — streaming the fast-moving telemetry and alarms continuously, while leaving spectrum filings and churn on a slower but still standing watch — is the defensible middle position, and it still requires continuous measurement to know which streams are which.
The second objection concerns the streams themselves. Continuous ingestion does not cure drift; it can relocate it. A telemetry probe recalibrates after a firmware update and every downstream cell suddenly reports ten per cent lower latency, not because the network improved but because the meter changed. A vendor changes an alarm schema without notice and severity codes silently remap. An operator's own churn dashboard ingests a billing feed that is itself three days behind. An always-on system integrating these streams without discipline produces a belief state that random-walks on its own account, and is harder to audit than the frozen corpus it replaced, because the frozen corpus at least carried an honest date.
"You have swapped a stale but legible snapshot for a live but unaccountable churn. I cannot tell you why the capacity model changed its mind about that cell last Tuesday."
This is answered only by discipline, not by architecture. Every ingested value needs a source and a timestamp attached, so that a shift in the traffic model can be traced to the probe recalibration that caused it and reversed if the recalibration was itself an error. Calibration drift is a Brownian process in its own right and has to be watched the same way the traffic is watched — which is the argument's own recursion, not a flaw in it. A Large Universe Model, as argued, is not continuous intake alone; it is continuous intake plus provenance plus revisability held together, and in a network operations context that combination is the only version of "always on" worth building. Streaming without it is not an improvement on the quarterly rebuild. It is the same drift, arriving faster and less legibly.