Architecture

Index AMI MQTT Architecture: Real-Time Meter Telemetry and Remote Management

June 3, 2026·7 min read

MQTT is the messaging protocol the Index AMI uses to publish meter readings and receive commands from the AMI Platforms. The Index AMI never communicates directly with the AMI Platforms: it always goes through an MQTT broker that decouples both ends. This guide explains the complete architecture: from how data leaves the meter to how it reaches the management platform, and how the AMI Platforms can remotely manage the device in real time.

Why MQTT in the Index AMI?

MQTT doesn't move data: it moves events. It's not a bulk-transfer channel or a download protocol — it's a messaging bus where every reading, alarm or state change is published as a discrete event the moment it happens. In an AMI context, MQTT is the mechanism that lets the Index AMI publish those events from the device to any MQTT subscriber, with no need for a fixed or public IP. The gateway opens an outbound connection to the broker over the 4G cellular network; that's why it works behind carrier NAT and never requires open ports or a static address. Any platform subscribed to the topic receives the event in real time.

MQTT as a messaging layer

MQTT does not replace TCP — it runs on top of it. The Index AMI publishes MQTT messages that travel over TCP through the 4G LTE cellular network. If the WireGuard VPN tunnel is active, that TCP runs inside the encrypted tunnel before reaching the internet. The result is an asynchronous, lightweight and reliable messaging layer over a mobile network.

Architecture roles

The Index AMI MQTT architecture has three actors:

  • Publisher — Index AMI: Publishes meter readings, events and device status on configured topics. Also subscribes to command topics to receive the instructions the AMI Platforms publish to the broker.
  • Broker — MQTT Broker: Receives and distributes messages between publishers and subscribers. Can be the Noatec broker included with the eSIM data plan, or a customer-owned broker (Mosquitto, HiveMQ, EMQX, etc.). Operates on port 1883 (TCP) or 8883 (TLS).
  • Subscriber / Publisher — AMI Platforms: Subscribe to telemetry topics to receive real-time readings. Also publish commands (read requests, restart, OTA update) to the Index AMI topics.

Telemetry flow: from meter to AMI Platforms

Each time the Index AMI reads the meter, it publishes the result to the broker. The AMI Platforms, subscribed to that topic, receive the data in real time without actively requesting it.

  1. The Index AMI queries the meter via RS485/RS232 at the configured interval.
  2. It obtains the reading (active energy, reactive, power, voltage, etc.) in DLMS/COSEM or Modbus format.
  3. It serializes the data and publishes it to the telemetry topic on the broker.
  4. The broker distributes the message to all subscribers (AMI Platforms, HES, MDMS, etc.).
  5. The AMI Platforms store, process or trigger alerts according to the configured business rules.

Remote management: commands from AMI Platforms to meter

Through the broker, MQTT allows the AMI Platforms to send instructions to the Index AMI without a field visit. The AMI Platforms never connect directly to the device: they publish commands to the broker, and the Index AMI — subscribed to its command topic — receives and executes them on the meter or on itself.

  1. The AMI Platforms publish a command to the Index AMI command topic (immediate read request, connect/disconnect, interval change, device restart, OTA firmware update).
  2. The MQTT broker delivers the message to the Index AMI.
  3. The Index AMI executes the instruction: queries the meter, activates the connect/disconnect relay, or updates its firmware.
  4. The Index AMI publishes the operation result to the response topic.
  5. The AMI Platforms confirm execution without sending anyone to the site.

MQTT topic structure

Topics organize the message flow. A typical convention with Index AMI:

  • Reading telemetry: Periodic meter readings (energy, power, voltage, current).
  • Events and alerts: Device events: Last Gasp, high and low temperature (per configuration) and cabinet switch (per configuration).
  • Device status: LTE signal (RSSI, RSRP), VPN status, firmware version, uptime.
  • Commands and responses: Commands from AMI Platforms and Index AMI responses.

MQTT channel security

The security level depends on the transport configuration:

  • MQTT over TLS (port 8883) — recommended: The TCP channel is encrypted with TLS. Requires CA, client certificates and private key loaded on the Index AMI. Protects data in transit even without VPN.
  • MQTT over TCP + WireGuard VPN: TCP travels inside the VPN tunnel encrypted with ChaCha20-Poly1305. End-to-end security — the broker is only accessible from within the tunnel. Recommended for critical infrastructure.

Integration with management platforms

The MQTT broker acts as a data bus between the Index AMI and any platform that supports the protocol:

  • HES (Head-End System) — receives real-time readings for storage and validation.
  • MDMS (Meter Data Management System) — processes, consolidates and distributes metering data.
  • SCADA / EMS — operational supervision and energy network control.
  • CIS (Customer Information System) — billing based on automated readings.
  • EAMS — meter event and alarm correlation.
  • BI and analytics platforms — topic consumption via MQTT for dashboards and predictive models.

Summary

  1. MQTT is the messaging layer; TCP is the transport; WireGuard VPN is the optional encryption layer.
  2. The Index AMI publishes readings and events; the AMI Platforms subscribe and act on them.
  3. AMI Platforms commands travel via MQTT through the broker to the Index AMI, which executes them on the meter without a field visit.
  4. The broker decouples the Index AMI from the platform — any MQTT-compatible system can integrate.
  5. MQTT over TLS (8883) or over WireGuard is recommended for critical infrastructure environments.