Choosing a DTU, industrial router or IoT gateway is a decision about where communication and data-processing work will take place. A serial instrument may need only a transport path to existing software. Another site may need local polling, engineering-unit conversion and outage records. Compare those duties first; the names on the enclosure do not define identical capabilities across manufacturers or firmware versions.
Which device already understands the field data?
If the receiving server already polls and interprets the instrument protocol, transparent transport may be sufficient. A DTU can carry serial data to the required endpoint when its serial timing and connection mode match the application. It does not make an undocumented instrument protocol self-describing.
If a PLC already supplies valid Ethernet data, the requirement may mainly be network routing. If no local or remote system owns the acquisition task, identify who will poll devices, apply scaling and report status. That gap is often the reason a project needs a gateway or RTU rather than a cellular transport device alone.
| Need | Route to assess | Question for the offer |
|---|---|---|
| Serial path | A DTU or an explicitly supported serial transport function. | Who initiates requests, and where are device replies interpreted? |
| IP access | An industrial router for the required local and wide-area network. | Which ports, routes and authorised access methods are included? |
| Data mapping | An IoT gateway with the required drivers and message functions. | Can the selected firmware read the actual device map and produce the required payload? |
| Direct I/O | An RTU or acquisition module with matching input circuits. | Are signal ranges, sensor power, isolation and channel counts suitable? |
DTU, industrial router or IoT gateway: compare actual configurations
The TR321 offered by METRAVON illustrates why device categories can overlap. It is a compact 4G router with one WAN and one LAN port, configurable as two LAN ports, and a listed RS232 interface. RS485/RS422 are options to specify, not interfaces to assume will be present in every delivered unit.

Its published serial transport and protocol options do not mean every routing configuration also performs application-level polling and cloud conversion. Ask the quotation to state the intended mode and firmware. For an existing transparent link, verify how serial boundaries, reconnects and multiple clients are handled before migrating the installation.
The TG451 lists more mixed interfaces: five Ethernet ports, RS232, RS485, two digital inputs and two relay outputs. It is a candidate when several equipment connections and gateway functions are needed together. Check the actual driver, tag and operating-mode requirements rather than using the larger port count as proof of compatibility.

For direct analogue acquisition, compare TG501 and its specified input configuration. A terminal block on a router is not evidence of analogue measurement capability. Similarly, a service serial port should not be counted as an available instrument channel.
Write the software responsibilities into the quotation
Name the system that owns device polling, conversions, timestamps, alarm evaluation and storage. Identify whether required drivers are standard, licensed or a separately assessed project function. A protocol name such as Modbus describes a family of communication functions, not a preconfigured map for every instrument.
For an MQTT destination, give the broker requirements, authentication arrangement and message schema. Do not assume that two products listing MQTT will produce the same topic structure or payload. Request a sample produced by the selected firmware and compare it with the application's accepted format.
Keep local machine control out of scope unless it has been explicitly designed and verified. Gateway scripting or relay outputs are not evidence of deterministic PLC behaviour or safety approval. Choose the controller and communications architecture according to their different responsibilities.
Test the unavailable-service cases before buying a fleet
Disconnect the intended uplink in a controlled trial and observe what happens to acquisition, sessions and records. Then restore it and check application recovery. A transport reconnect does not prove that missing history was retained or that the server has resumed accepting the device.
Where buffering is required, specify retention, record identity and full-buffer behaviour. Where remote maintenance is required, confirm the approved access method and who maintains credentials and firmware. Storage and maintenance functions must be verified for the actual order, not copied from another model in the series.
Also evaluate replacement. Can an approved configuration be restored onto a spare with the selected firmware? Are SIM, antenna, account and platform settings documented? A short bench demonstration should include recovery from a realistic interruption, not only a successful first connection.
Compare the complete project cost
Separate equipment price from driver configuration, platform integration, subscriptions, SIM service, antennas, cabinet hardware and maintenance. Reusing a known server-side driver may make transparent transport economical. Local conversion may be worth the extra configuration where it removes repeated custom work at many sites.
Do not select a mobile-network generation independently of the region and operator. Confirm the ordered module, supported bands and service availability at the installation. A technically capable gateway is still unsuitable if its cellular configuration cannot use the intended network.
Selection questions
Q1. Can a router replace a DTU?
It may, if the exact router variant provides the required serial interface and transport mode. Verify timing, connection ownership and recovery with the existing application. The presence of Ethernet routing alone does not satisfy a serial-link requirement.
Q2. Does a gateway remove the need for a server?
Not necessarily. Local acquisition or processing can reduce server duties, but reporting, user access and long-term storage still need an identified destination. Define which services run locally and which remain elsewhere before comparing quotations.
Q3. What should be provided for a model recommendation?
Supply the field-device list and interfaces, the system that currently interprets the data, the destination format and the required behaviour during an outage. Add site power, enclosure and operator details. These inputs distinguish a narrow transport task from a new integration project.
Summary
Select by responsibility: byte transport, IP routing, data mapping or direct signal acquisition. Ask METRAVON to review the proposed data path and identify the exact hardware, firmware and services needed, with options and exclusions stated in the offer.
