Rehearse the network before you have to run it.
CPE Cluster stands up a synthetic subscriber base — routers, gateways and voice adapters that behave like devices, arranged market by market the way your footprint actually is — and points it at the platform you are about to depend on.
Volume is easy. Behaviour is the risk.
Anything can send a million requests at a URL. Nothing in production sends a million identical requests.
What actually goes wrong on launch day is a fleet being a fleet: devices informing on their own schedules, carrying their own configuration, retrying after a blip, answering when the platform reaches back to them, running a firmware campaign while everyone else carries on as normal. A load tool tells you a server survived a number. It cannot tell you what a real estate does to your provisioning logic, your database, or your support queue.
Real sessions
Full CWMP exchanges — Inform, GetParameterValues, SetParameterValues, GetParameterNames, GetRPCMethods — built from real device data models, not replayed packets.
Real timing
Devices call home on their own cycle, spread evenly across the inform interval, the way an estate does — not in a synchronised thundering herd.
Real state
Every device remembers what it was told, so the second session is not the first one again. Bootstrap and boot events fire once, on first contact, like they do in the field.
Real return path
When your platform reaches out to a device, a device answers on its connection-request URL and the exchange completes.
A frozen device teaches your platform nothing.
The cheap way to simulate a device is to answer every read with the same recorded value. Do that and everything downstream goes flat.
A collector polling the same device twice sees identical counters, every rate it derives comes out zero, and the dashboards your NOC will actually watch have nothing in them. The platform passes the test and disappoints on day one.
Counters that advance
Byte and packet counters move with wall-clock time and wrap at 2³² the way an unsignedInt does — so rates, deltas and trend lines come out non-zero and the warehouse behind the collector is exercised too.
Readings that drift
CPU, free memory, chassis temperature and the GPON optics — transceiver temperature, bias current, TX/RX power, supply voltage — wander inside plausible bands. These are the signals your alarms and thresholds are tuned against.
Diagnostics that complete
A WiFi neighbour scan is not one request. The platform asks, the device goes away, and returns in a new session carrying 8 DIAGNOSTICS COMPLETE. CPE Cluster runs that whole asynchronous exchange.
Diagnostic sub-trees are deliberately excluded from the drift: those report the result of the last test run, not lifetime traffic, and must stay where the dump put them. Behaviour is chosen per pool — a plain estate, a moving one, or one that answers diagnostics.
Model the footprint you actually have.
-
Market
One piece of your business as it really exists: a country, a region, an operating company, a brand you acquired and have not merged yet. It owns its own platform endpoint and its own service assumptions, and everything inside it follows.
-
Pool
A device mix you genuinely have — this vendor on that firmware, the voice-adapter estate, the router generation you are still retiring. Pools are where the numbers live: fleet size, data-model template, inform interval, target endpoint.
-
Run
Move a market to a new platform and every pool in it follows in one change. Grow one market for a rollout and leave the others exactly as they were. Two markets, their own platforms, their own device mixes, side by side.
That is what turns a load test into a rehearsal. You are not asking "can it take 100,000 sessions an hour"; you are asking "what happens to the northern region on the morning we cut it over" — and running exactly that.
TR-069 and USP, in the same fleet.
Most estates are mid-migration and will be for years.
CPE Cluster simulates TR-069 devices against your ACS and USP agents over MQTT against your controller — in the same market, in the same run. So the question you can finally answer is the one that actually keeps people up: not how each half performs alone, but what the mixed estate does to a platform that has to serve both while the migration runs.
TR-069 / CWMP
Full sessions against your ACS, including the ones your platform initiates.
TR-369 / USP over MQTT
Agents on your broker, holding their topics and their state like real ones.
Devices are only half the load.
A platform under real conditions is not only serving devices. Provisioning runs, bulk onboarding, reconciliation sweeps and campaign tooling all arrive through its northbound interface — and they arrive while the fleet is informing. That collision is where platforms fall over, and it is precisely what a device-only load test can never produce.
The same devices
A northbound actor works against the devices your pools are simulating — so the subscriber being provisioned and the device that answers are one device, not two test fixtures.
The same record
A provisioning call is traced exactly like a device session: what was sent, what came back, what it meant. One account of the run, with both halves in it.
Traffic that arrives the way your subscribers' will.
Where load comes from changes what it tests. A fleet can drive your platform directly, or through a relay that puts the traffic inside the network under test — so it crosses the same borders, firewalls and carriers that real subscriber traffic crosses, and the platform sees it arriving from where it will really arrive from. Connection requests come back the same way.
Results you can put in front of a change board.
Reproducible
Two runs of the same fleet describe the same fleet. A session that fails rolls its device back rather than committing half a change, so nothing drifts with a dropped connection or a slow night — which is what makes a before-and-after genuinely comparable.
Traced in full
Every session is kept: what was asked, what came back, in order, with the outcome attached — ok, failed, error or crash. Hand your vendor the exchange that proves it rather than an anecdote.
For the engineers who will live with it: fleets are declared in a manifest and driven from a command line, every run is reproducible, and nothing is configured by hand.
What it de-risks.
Platform migration
Move a market's fleet onto the new platform in rehearsal, at full size, before a single subscriber moves.
Capacity & sizing
Find where the platform bends under your real device mix, not under an averaged synthetic one.
Firmware campaigns
Rehearse a mass upgrade against the estate that will receive it, including everything that carries on around it.
Provisioning at scale
Put an onboarding wave through your northbound interface against a fleet that is already live, and find the ceiling before a launch does.
Vendor evaluation
Put two platforms through the identical fleet and compare answers, not sales decks.
Incident reproduction
Rebuild the conditions of a production incident on demand, and prove the fix under them.
Bring us the platform you are about to trust.
Tell us which platform you are validating, what your estate looks like market by market, and what decision is waiting on the answer. We will build the first market with you and run it.