A smart meter is a deceptively simple product on paper — measure consumption, report it — but the system design decisions underneath that single sentence determine whether a deployment is affordable at utility scale and whether the data it produces is actually useful. The two decisions that shape everything else are how frequently the meter reads and reports, and what communication path carries that data back to the utility. Both choices ripple into device cost, battery or mains-power requirements, backhaul infrastructure, and what analytics or grid operations become possible downstream.
Read frequency: the tradeoff nobody escapes
More frequent interval reads — 15-minute or even 5-minute granularity instead of monthly or daily totals — unlock real capability for grid operators: demand response, time-of-use billing, outage detection, load forecasting, and early identification of theft or equipment faults. But every step up in read frequency multiplies the data volume the device has to store locally between transmissions, the bandwidth needed to move it, and the backend storage and processing cost at fleet scale. A utility with millions of meters reporting at 15-minute intervals is generating an amount of data that's a different engineering problem than the same fleet reporting monthly totals — not just bigger, but different in terms of what ingestion and storage architecture is required. The right interval isn't the most granular one technically achievable; it's the coarsest interval that still supports the specific grid operations the utility actually intends to run.
Communication protocol: matching the network to the deployment
There's no single right answer for how a meter gets its data back to the utility — the choice depends on deployment density, geography, and what infrastructure the utility is willing to own versus rent.
- Mesh networks (RF mesh) — meters relay data hop-to-hop to a collector, which is well suited to dense residential and urban deployments where meters are close together. The utility typically owns and operates this network, which means more control but also more infrastructure to install, maintain, and eventually upgrade as radio standards evolve.
- Cellular (LTE-M, NB-IoT, or standard LTE) — each meter talks directly over a carrier network, which removes the need for utility-owned collector infrastructure entirely. This is attractive for sparse or rural deployments where mesh hop density doesn't work, but it comes with a recurring per-device data plan cost multiplied across the entire meter fleet, and dependency on carrier coverage and long-term network support in the deployment region.
- Power line communication (PLC) — data rides the existing electrical distribution wiring back to a substation or collector, which avoids needing a separate wireless network at all. It works well where the utility already has PLC-capable infrastructure, but signal quality is sensitive to the electrical characteristics of the specific grid segment, and it doesn't generalize as cleanly across different grid topologies as a wireless approach.
Many utility-scale rollouts end up combining approaches — mesh or PLC for dense areas, cellular for the long tail of remote endpoints — rather than forcing one protocol across an entire territory. The decision is really about matching network topology to communication topology, not finding a universally superior protocol.
Data granularity versus privacy and storage
Interval data at high granularity is genuinely more useful to grid operators, but it's also more revealing about what's happening inside a home or facility — appliance-level usage patterns can be inferred from sufficiently granular interval data, which is why some jurisdictions regulate how long granular data can be retained and who can access it beyond aggregate billing totals. That regulatory and privacy reality is a real constraint on system design, not an afterthought: it affects what gets stored at the edge versus the cloud, how long raw interval data is retained before being aggregated or discarded, and what access controls sit in front of it. Designing the data pipeline with that lifecycle in mind from the start — rather than defaulting to "store everything forever" because storage is cheap — avoids having to retrofit retention and access policy onto a system that wasn't built for it.
Practical takeaway
Smart meter system design is really three coupled decisions — read frequency, communication protocol, and data retention policy — that need to be made together rather than in sequence, because each one constrains the others' cost and feasibility at fleet scale. We help teams work through that architecture end to end, from the metering hardware itself through to the cloud ingestion pipeline; see our embedded hardware and cloud & device platform work for how we approach it.