The 3G network is being switched off in eighteen months. What work does that create in the BSS and OSS?

A network programme whose hard parts are all commercial

Decommissioning radio equipment is scheduled, capital-planned work with a known shape. The part that overruns and generates regulatory attention is finding every subscriber and every device that will lose service, deciding what each of them is owed, and moving them before the date.

The reason that is hard is a mismatch nobody designed. Whether a subscriber keeps working after the shutdown is a property of the equipment in their hand or bolted to a wall, and almost nothing in the BSS is keyed on equipment. Subscriptions describe what was sold. Inventory describes what the operator owns. The device belongs to the customer, changes without telling anyone, and is the only thing that decides the outcome.

Capability lives in the device, so the IMEI becomes a business identifier

The identifier that travels with the handset is the IMEI, and the leading digits of it — the type allocation code — identify the model rather than the individual unit. That is the join key for the whole programme: collect the IMEIs observed for each subscription from usage records and signalling, resolve them to models through a device capability reference, and you have a per-subscriber statement of what technologies each customer's equipment supports.

Two capabilities have to be distinguished, because they fail differently. Data is the easier one: a device that supports a later radio technology keeps its data service, and a device that does not loses it entirely. Voice is where the awkwardness is, because a handset can support later-generation data while still relying on the older circuit-switched network for calls. Take the older network away and such a device needs packet voice over the newer network to make a call at all. Whether it falls back gracefully depends on what else is still switched on in that area, which is why 2G and 3G retirement decisions are usually sequenced rather than simultaneous, and why the answer for a given subscriber depends on coverage at their location as well as on their handset.

The observation window is the subtle judgement. Building the affected list from devices seen in the last month understates it, because a subscriber's second handset, a holiday phone or a device in a drawer will surface after the shutdown as a complaint. Widening the window to a year overstates it, because devices that have since been replaced are still in the data. There is no window that is simply correct, so pick one, state it, and accept a residual population handled reactively — with the contact centre briefed, because they will be the detection mechanism for whatever the analysis missed.

Packet voice is a provisioning campaign, not a marketing one

A capable handset is a necessary condition and not a sufficient one. Voice over the newer network requires the subscription to be provisioned for it in the subscriber register, an identity to exist in the IMS control layer, and the device to be carrying a configuration the operator considers supported. So a substantial fraction of the work is bulk changes to subscription data across millions of subscribers.

That is an unusual load for a provisioning stack, and the difference is worth naming. The order path is built for one order at a time with a human waiting, and its throughput, retry and fallout characteristics were tuned for that. A campaign pushing millions of subscription changes through the same path in a few weeks will find the rate limits of the network-facing interfaces, and its fallout — a small percentage of a very large number — becomes a queue larger than the operations team has ever seen. Plan the campaign as a throttled, resumable, per-subscriber-idempotent job with its own fallout handling, and reconcile the intended population against the completed one rather than trusting the job's own success count.

The machine-to-machine base is the cohort that cannot be phoned

This is where these programmes actually get stuck, and reaching for it unprompted marks a candidate who has thought past the consumer case.

Devices bought on long capital cycles are still running on whatever was current when they were installed: utility meters, intruder alarm panels, lift emergency telephones, vehicle telematics units, vending machines, agricultural sensors. Many support only the older technology, with no upgrade path short of physical replacement. Several characteristics compound the problem. They were sold in bulk to an enterprise, so the operator's record of where each SIM ended up may be a purchase order rather than an address. The device is often behind a third party's front door, because the operator's customer is the alarm company and the alarm company's customer holds the panel. Replacement requires a site visit by a qualified person, and there are more devices than there are qualified people in the window available. And some of them are safety-related, which converts a commercial deadline into a regulatory one.

The practical consequences reach into systems. You need per-SIM usage-based inference of what each device is and where it lives, because the sales record will not tell you. You need enterprise contract review, since exit and continuity terms were written before the shutdown was announced. And the shutdown date for the affected spectrum may have to be regionally staged around device replacement progress, which makes the network plan dependent on a BSS-side data quality exercise — an inversion of the usual direction that project managers consistently underestimate.

What changes in inventory, assurance and serviceability

On the OSS side the work is less dramatic but easy to get wrong.

Retire resources through their lifecycle rather than deleting them. Usage records, disputes, interconnect settlement and lawful requests will reference decommissioned elements and identifiers for years, so a cell or a network element that no longer exists must still resolve to a name, a location and a period of existence. An inventory that deletes retired equipment breaks every historical enquiry made about it afterwards.

Expect indicator definitions and reporting to need explicit handling. Anything aggregated across technologies changes composition as one of them shrinks to nothing, so a trend that spans the shutdown is comparing two different populations. Freeze the definitions, and annotate the series at the date, so a step change is not later mistaken for a network improvement or a regression.

Serviceability and coverage answers change per location as spectrum is refarmed, and they change in both directions: the retired technology's coverage disappears while the replacement's capacity in that area improves. Whatever answers "can this customer get this product at this address" reads that data, so it needs refreshing on the same schedule as the site work rather than annually.

The assumption to challenge

The instinct is that the network knows who is affected, because the network sees every device. It does not, and the gap is structural rather than a data quality problem you can fix with a better query.

The network sees devices that registered inside your observation window, under the configuration they happened to be using. It cannot see the handset switched off in a drawer that will be switched on next month, cannot distinguish a dual-capability device configured against the newer technology from one that lacks it, cannot tell you which of a business's forty SIMs are in devices that will be replaced anyway on their own refresh cycle, and cannot tell you anything about a subscriber who has not used the service recently but is still paying. Every one of those needs commercial data alongside the observations, which is why this is a BSS programme with a radio deadline rather than the other way round.