Your Rack Quit Being a GSM Rack Years Ago: The LTE Reality Audit Nobody Handed You

If you inherited a modem rack built in 2019, congratulations: you own a piece of telecom history. The hardware still boots, the fans still spin, and the runbook taped inside the door still says something about GSM registration. None of that matches what the radios are doing today.

The last nationwide 2G GSM networks in the US wound down in the early 2020s, and the 3G fallbacks went with them. AT&T finished its 3G sunset in early 2022; T-Mobile followed later that year. What replaced all of it is LTE with VoLTE on top, and a thin slice of 5G NSA that most modem farms quietly ignore. If your operational assumptions predate that shift, you are not running a GSM farm. You are running an LTE farm with GSM-era folklore.

This is the audit I wish someone had handed me. It is not about buying new hardware. It is about rebuilding the mental model so your monitoring, your SIM provisioning, and your on-call instincts stop lying to you.

First, Stop Trusting the Labels

Open a session to a handful of modems and ask them what they actually are. AT+CGMM, AT+CGMI, AT+COPS?, AT+CEREG?, AT+CGDCONT?. If the answer is EPS registration on an LTE band rather than a circuit-switched attach, the box in front of you is an LTE device no matter what the asset tag says.

The tell that trips people up: these modems enumerate over MBIM or QMI now, not as a serial PPP device. If your provisioning scripts still expect a /dev/ttyUSB chat sequence, you are driving a 2016 workflow against a 2022 radio. Check whether the modem is handing you a network interface with an IP already on it — that is the default bearer, and it is a different animal from the PDP context your old scripts used to bring up manually.

SIM Provisioning Is an IMS Problem Now

Under the old model, a SIM plus an HLR entry got you a registered subscriber and the rest was plumbing. Today the SIM has to be provisioned at the carrier or MVNO for the specific service you want, including VoLTE entitlement, and the IMS core has to accept the device profile you are presenting.

Three things bite people here. First, a data-only provisioning profile will attach happily, pass traffic, and never register for IMS — which means voice and SMS-over-IMS silently die while your dashboard stays green. Second, IMEI matters. Carriers match the TAC against approved device profiles, and a mismatched or generic IMEI can get you a polite "device not supported" that never surfaces as an error in your stack. Third, some MVNOs hand out a single APN and route IMS through it, while others want a dedicated ims APN. You need to know which kind of account you have before you debug anything else.

Query IMS registration explicitly. Depending on the modem, that is AT+CIREG, a vendor-specific command, or an MBIM service field. If you cannot get a clean answer on whether IMS is registered, that is your first infrastructure gap, not the last.

Voice Stopped Being a Circuit

Here is the part that breaks old assumptions hardest: there is no circuit domain to fall back to. When a call is placed on an LTE-only modem, it rides IMS as SIP signaling with the media as VoLTE. If IMS registration has lapsed, the call does not "fail over" — it fails, usually with a 503, sometimes with a long silence and a dead air hangup that looks like a network problem and is not.

SMS moved too. Depending on the carrier and device, it goes over IMS (SMSoIP) or over NAS signaling. What it does not do is arrive via the old circuit-switched AT+CMGS path you may still be testing against. If your smoke test is "send an SMS, get an SMS," make sure the test actually exercises the path production uses. A loopback test through your own gateway proves nothing about carrier delivery.

APNs and Bearers: Two Sessions, Not One

LTE gives you a default bearer the moment you attach, and that bearer is tied to one APN. Voice and IMS typically need a second PDN connection on the IMS APN. If your stack only configures one, you get data, no voice, and a very confusing afternoon.

Also check PDP type. Some US APNs are IPv6-only with NAT64, and a modem configured for IPv4-only will attach and then do nothing useful. AT+CGDCONT? will show you what is actually negotiated. Compare that against what your tooling assumes.

When a Band Drops, Nothing 'Fails'

This is the quiet one. In the GSM era, losing coverage meant losing registration, and your alert fired. On LTE, a modem can lose band 71 or band 13, drop to a narrower carrier, stay fully registered, and deliver a fraction of the throughput with rising latency. Everything reports healthy. Your SMS queue backs up anyway.

So stop monitoring aggregate signal. Track RSRP and SINR per band and per EARFCN, and alert on deterioration, not just absence. A modem pinned to a distant band with SINR under zero is worse than a modem that is honestly offline, because it costs you time before anyone notices.

The Signals That Actually Matter

Build your checks around these, in roughly this order:

• IMS registration state, polled on a schedule, alerted if it has been down longer than a few minutes.
• PDN session count, expected to be two on VoLTE-capable profiles.
• Per-band RSRP/SINR trends, not instantaneous values.
• Registration technology (AT+CEREG? stat plus the act field), so you catch a modem that quietly fell to a worse RAT.
• A synthetic MT SMS loop through a real external number, run hourly, with delivery confirmation.
• IMEI and firmware inventory, so a swapped modem does not silently change your device profile.

A Weekend Audit You Can Actually Finish

Pick ten modems, spread across carriers. For each one, record the model, firmware, IMEI TAC, active bands, APN list, PDP types, and IMS registration state. Then make one outbound voice call attempt and one inbound SMS test. Write it all into a single spreadsheet and diff it against your runbook.

The gaps you find will be boring and specific: a script that assumes one PDP context, a monitor keyed to signal strength alone, a SIM batch provisioned without VoLTE. Fix those, update the runbook taped inside the door, and your rack finally matches the network it has been living on for years.