вв

cache data, ensuring that if communications fail temporarily, data is not lost. Electricity meters typically store at least 13 months of half-hourly consumption data in a cyclic log, as well as daily aggregated values and various event logs. For instance, the SMETS2 specification defines a Daily Read Log (often storing ~14 days of daily register snapshots) and a Profile Data Log for at least 3 months of half-hourly data. When these logs are full, the oldest entries roll over. Gas meters, also storing consumption logs, similarly keep many months of data (the 13-month retention applies to both electricity and gas data). Additionally, meters maintain event logs for power loss/restoration, tampers, etc., and can queue up alerts. This onboard caching means that even if a meter cannot communicate for an extended period (due to network issues or outages), the data can often be retrieved later from the meter’s memory once connectivity is restored. In summary, smart meters

configured), or the WAN link (comms hub ↔ DCC) can fail due to poor signal or network outages, or the meter itself might not execute a command properly. Below we outline typical failure scenarios and what logs/telemetry they produce, contrasting them with normal (healthy) communication logs. Normal Successful Communication: In a healthy scenario, a scheduled reading or on-demand request reaches the meter and the meter responds with data. For example, consider a daily read request (Service Request 4.6.1 – Retrieve Import Daily Read Log). The DCC sends the command at the scheduled time, and the meter’s response is received promptly. The system logs would show a Response message for the meter, with a timestamp, containing the requested data. At the DCC level, this might appear as a record in the Oracle database with fields like 6 7 8 9 10 1112 1314 11 1516 • 2 MSG_TYP="RetrieveImportDailyReadLogRsp" (response), sender = meter ID, receiver =

erval data (48 intervals per day) – the meter records these locally every 30 minutes and they can be retrieved by DCC on a scheduled or on-demand basis (e.g. a daily collection of half-hourly profile data). Gas meter readings are typically reported less frequently (often daily) via the electricity meter, and can lag slightly behind the electricity data due to the gas meter’s sleep schedule. Besides consumption, smart meters and the DCC network support ~150 distinct message types including configuration commands, tariff updates, and asynchronous alerts. Data Formats: Communications use standardized data formats defined by the Smart Metering Equipment Technical Specifications (SMETS) and Great Britain Companion Specification (GBCS). On the HAN (meter ↔ comms hub), Zigbee SEP 1.2 clusters carry metering data (e.g. Metering cluster 0x0702 for consumption) and event information. Over the WAN, the DCC wraps messages in its XML-based

On the HAN (meter ↔ comms hub), Zigbee SEP 1.2 clusters carry metering data (e.g. Metering cluster 0x0702 for consumption) and event information. Over the WAN, the DCC wraps messages in its XML-based DCC User Interface Specification (DUIS) format. For example, a supplier’s service request is an XML payload containing header metadata and the command (which may target the electricity or gas meter); the meter’s response is returned as a DUIS XML message, potentially containing an embedded GBCS payload (which is often a binary or Base64-encoded blob of the meter’s data). All communications are secured via encryption and authentication per the SMETS security trust chain. Onboard Memory and Caching: Importantly, smart meters have onboard non-volatile memory to cache data, ensuring that if communications fail temporarily, data is not lost. Electricity meters typically store at least 13 months of half-hourly consumption data in a cyclic log, as well as daily

uest (SRV) data and alert codes from raw blobs, predictive telemetry patterns (alert sequences, schedule mismatches, “inventory drift”), methods to flag inconsistencies between internal systems (e.g. MeterFlow) and DCC data, root causes beyond the meter itself (infrastructure/software issues), communication protocols and packet loss, and propose an explainable diagnostic framework. Example decoded logs for healthy vs failing meters are provided. The goal is an explainable and auditable approach to classify smart meter health and detect non-communication issues early. Smart Meter Communication Overview Smart meter communication network: energy companies (“Users”) send Service Requests to the DCC’s Data Service Provider (DSP) system, which relays commands over the Wide Area Network (WAN) to the premises. The local Communications Hub (Comms Hub) forwards messages via the Home Area Network (HAN) to the smart meter.

ter cannot communicate for an extended period (due to network issues or outages), the data can often be retrieved later from the meter’s memory once connectivity is restored. In summary, smart meters communicate at configurable intervals (e.g. daily or half-hourly) using standardized encrypted messages over HAN/WAN, and they buffer substantial history locally to bridge communication gaps. Communication Failure Scenarios and Indicators Despite robust design, communication failures do occur. Understanding how and when these failures happen is key to detecting non-communicating meters. Failures can happen at different stages: the HAN link (meter ↔ comms hub) can fail (especially for gas meters out-of-range or if the HAN is misconfigured), or the WAN link (comms hub ↔ DCC) can fail due to poor signal or network outages, or the meter itself might not execute a command properly. Below we outline typical failure scenarios and

er (DSP) system, which relays commands over the Wide Area Network (WAN) to the premises. The local Communications Hub (Comms Hub) forwards messages via the Home Area Network (HAN) to the smart meter. Smart meters in Great Britain communicate via a hierarchical network managed by the DCC. In the home, an integrated Communications Hub creates a Home Area Network (HAN) (using Zigbee SEP 1.2 radio) that links the electricity meter, gas meter, and other devices (e.g. In-Home Displays). The electricity smart meter (ESME) typically acts as a hub on the HAN for the gas meter (GSME), since the gas meter is battery-powered and only “wakes up” periodically (around every 30 minutes) to send its readings via the electricity meter. The Communications Hub connects to the DCC’s Wide Area Network (WAN) (using cellular or long-range radio) to forward messages between the meters and DCC’s central Data Service Provider (DSP) system. In essence, energy suppliers and network operators

Area Network (WAN) (using cellular or long-range radio) to forward messages between the meters and DCC’s central Data Service Provider (DSP) system. In essence, energy suppliers and network operators send Service Requests (commands) through the DCC, and meters respond with the requested data or alerts via this chain of communication. 12 3 4 5 1 Communication Frequency & Data Payloads: The frequency of data transmission depends on configured schedules and user consent. By default, most SMETS2 smart meters send at least a daily read (often at a randomized time of day to avoid network peaks), delivering the previous day’s consumption. If the consumer opts in to more granular readings, meters can provide half-hourly interval data (48 intervals per day) – the meter records these locally every 30 minutes and they can be retrieved by DCC on a scheduled or on-demand basis (e.g. a daily collection of half-hourly profile

Smart Meter Non-Communication Detection – Technical Investigation Introduction Smart meters are critical IoT devices in modern energy infrastructure, continuously measuring consumption and periodically transmitting this data to stakeholders via the Data Communications Company (DCC) network. Ensuring these meters communicate reliably is essential for accurate billing, network management, and customer service. This report investigates non-communication detection in smart meters using historical DCC data (stored as Oracle BLOBs) and alert telemetry from a proof-of- concept (PoC) system. We explore how smart meters communicate (frequency, formats, methods, onboard storage), scenarios and indicators of communication failure, decoding of DCC service request (SRV) data and alert codes from raw blobs, predictive telemetry patterns (alert sequences, schedule mismatches, “inventory drift”), methods to flag inconsistencies between internal systems (e.g.

the DCC level, this might appear as a record in the Oracle database with fields like 6 7 8 9 10 1112 1314 11 1516 • 2 MSG_TYP="RetrieveImportDailyReadLogRsp" (response), sender = meter ID, receiver = DCC, and a status indicating success. The raw BLOB would contain the response payload (to be decoded, as discussed later). No error codes or alerts are generated in this case – the DCC would mark the request as completed successfully. A snippet of a decoded successful response might look like the example in the later section (e.g. a JSON with timestamp and consumption values). Meter Not Responding (On-Demand Request): A common failure case is when the DCC attempts to contact the meter for an on-demand read or a scheduled read and receives no response. This could be due to the meter being offline (power loss in case of electricity meter, or HAN link down in case of gas meter) or WAN issues preventing the request from reaching it. The