Content
At 23:50 on the last night of the month, a billing engineer at a regional utility watches the overnight read counter climb: 61 percent, 68 percent, 74 percent. Every meter that fails to answer becomes an estimated bill, a call-center ticket, and revenue that arrives late. The gap between a 92 percent and a 99 percent read rate is almost never the meter itself. It is the communication design: how a smart meter communicates with the utility head-end system (HES), over which media, under which protocols, and with what fallback behavior when a link degrades.
Four terms carry the whole discussion: the local area network (LAN), the data concentrator unit (DCU), the wide area network (WAN), and the advanced metering infrastructure (AMI) they form together.
In one line: the meter speaks a local language, a concentrator or a cellular network carries it across the wide area, and the head-end turns packets into bills.
The head-end system is the utility-side control center for the entire meter fleet. Every scheduled read, remote command, tariff update, and firmware package passes through it, and every billing file it produces is only as good as the communication design beneath it.
Core definition
A head-end system (HES) is the software platform on the utility side that manages two-way communication with every deployed meter: it schedules reads, collects billing and event data, distributes commands and firmware, and hands verified results to billing and analytics platforms.
In daily operation it runs four jobs:
Suppliers that build both layers, such as Futurise Technologies Co., Ltd. with its internationally certified meter portfolio and its own HES platform, use that dual position to keep protocol mapping consistent at both ends of the wire, exactly where mixed-vendor projects lose weeks.
Meter data almost never travels in one hop. Standard designs split the journey into a local last mile, an optional aggregator, and a wide-area backhaul, each with its own failure modes and cost structure.
Hop one is the neighborhood link, where the smart meter uses its local area network: power line communication (PLC) over the low-voltage cable, or a sub-GHz radio frequency (RF) link, often meshed. Hop two is aggregation, where a data concentrator unit (DCU) at the distribution transformer collects that local traffic and forwards it. Hop three is the wide area, where cellular options such as GPRS, narrowband IoT (NB-IoT), and LTE Cat M, or Ethernet and fiber, carry the payload to the HES over TCP/IP with DLMS/COSEM messages inside.
Direct-to-HES
Concentrator-based
A common planning heuristic: above roughly 40 meters per distribution transformer, concentrator-based designs usually win on ten-year cost; below that, direct cellular avoids DCU hardware that would sit underused.
Each last-mile technology dominates a different deployment density, and the wrong match shows up immediately as missed reads.
| Technology | Carrying medium | Typical reach | Best fit | Watch-outs |
| PLC (narrowband) | The low-voltage power cable itself | Hundreds of metres per transformer | Dense urban grids | Grid noise and transformer coupling; needs a nearby DCU |
| RF mesh (sub-GHz) | Radio; meters relay for each other | A few hundred metres per hop | Suburban and dispersed housing | Spectrum rules vary by country; mesh planning takes iterations |
| Cellular (NB-IoT, GPRS) | Operator mobile network | Full operator coverage | Rural or scattered projects | SIM cost per meter; indoor signal pockets |
Typical first-attempt daily read success
Indicative field ranges reported across AMI programmes; results depend on grid noise, topology, and retry design, not on the technology name alone.
No bar is destiny: a tuned PLC network behind a clean transformer can outperform a careless cellular deployment with basement dead zones, so hold every bidder to a measured pilot against a contractual read-success target.
Two protocol families do most of the work: DLMS/COSEM structures the data conversation, and STS secures prepaid credit. Certify both on both sides of the link and interoperability stops being a gamble.
DLMS/COSEM, short for the Distribution Line Message Specification and its Companion Specification for Energy Metering, models every meter as addressable objects: a clock, energy registers, load-profile buffers, a disconnect control. Each object carries an OBIS (Object Identification System) code, so when the head-end requests object 1.8.0 it receives exactly the active-energy import total in a standard format.
STS, the Standard Transfer Specification managed by the STS Association, governs prepaid: the vending system issues a 20-digit token, the meter validates it locally against its stored key, and the HES reconciles the credit files afterward. Futurise joined the STS Association in 2013 and holds DLMS User Association (DLMS UA) certification, so its meters exchange standard objects without proprietary glue code.
A meter and a head-end from different vendors exchange bytes happily only if both implement the same DLMS/COSEM conformance class and OBIS map. Budget a formal interoperability factory test before signing any supply contract; it is the cheapest risk reduction in an AMI project.
Billing totals are the smallest part of the traffic. A modern head-end conversation moves schedules, profiles, alarms, and commands in both directions, and the meter is expected to keep recording even while the link is down.
15 min
Load-profile capture interval
2-4
Scheduled reads per day in most AMI programmes
99%
First-attempt read target written into contracts
12-24 mo
Billing data a meter retains if the link fails
Downstream, the HES pushes tariff tables, remote connect and disconnect commands, maximum-demand thresholds, and signed firmware images. Upstream, meters return register reads, load profiles, power-out and tamper events, and voltage quality records. When the WAN drops, store-and-forward buffering in the DCU and the meter fills the gap and drains once the link returns. A missed read should delay a bill, never lose it.
Security is layered, not switched on in one place: the meter locks its local port, the application layer authenticates and encrypts, and keys are managed centrally.
Ask every bidder three questions: which DLMS security suites the meters support, whether the HES ships with a key management center, and how firmware images are signed. Vague answers here are the earliest reliable signal of a weak offer.
Communication failures are cheapest to catch in a pilot and most expensive to catch after 100,000 installations. Four stages keep the risk where it belongs.
Bottom line: communication design is revenue design. Specify the hops, demand certified interoperability on both ends, and write the read-success target into the contract.
Yes. In a direct-to-HES architecture each meter carries its own wide-area modem, usually cellular, and speaks to the head-end with no local aggregation. The trade-off is recurring SIM cost per meter against one-time DCU hardware cost, so direct designs favor dispersed customers and concentrator designs favor dense housing.
Most international projects run DLMS/COSEM over TCP/IP, whether across cellular, Ethernet, or fiber backhaul, or across PLC and RF segments below a DCU; prepaid meters add STS for token validation. Regional regulators may add local requirements, so both ends should hold the certifications your market recognizes.
Most programmes schedule two to four reads per day plus on-demand reads for disputes or disconnects; monthly billing files compile from the daily data, and load profiles stay on a 15-minute interval.
The meter and any upstream DCU apply store-and-forward buffering: data accumulates locally and uploads once the link recovers. The head-end raises an exception for every meter that misses its schedule, so field teams can intervene before estimated bills pile up.
Share:
English
Français
