From RS485 to the Cloud: How Many Protocols Work Together in One Industrial Data Collection Process?

"I only configured one Modbus address, so why isn't the device communicating?"

"The gateway responds to ping, and MQTT is connected, but the platform isn't receiving data. Which layer is the problem in?"

If you work on industrial device networking projects, these two questions will be familiar. Many engineers are familiar with terms like Modbus RTU, MQTT, and TCP/IP, but when problems occur on-site, they often can't tell whether the fault lies at the physical layer, link layer, network layer, or application layer. A serial port tool can read data, but a gateway can't; everything works fine on the local LAN, but fails over a 4G connection. The root cause is an insufficiently systematic understanding of the dependencies within the industrial communication protocol stack.

I. The Four Layers of Industrial Communication: Not Seven, but Four

Engineers working on industrial projects don't need to memorize the OSI seven-layer model. The most commonly used framework in practice is the TCP/IP four-layer model, which we can map directly to industrial scenarios:

Core concept: upper-layer protocols must be "encapsulated" into lower-layer protocols to be transmitted. This is the fundamental logic for understanding all communication faults.

II. The Encapsulation Relationship: How Upper-Layer Messages Are Packaged Layer by Layer

The most important concept is "encapsulation." Let's use a common industrial scenario to illustrate:

Scenario: A temperature controller that only supports Modbus RTU connects to an industrial gateway via RS485. The gateway then reports the data to a cloud platform using the MQTT protocol over a 4G network.

What encapsulation process does this data go through from the application to the physical medium?

Step 1: Application Layer – The MQTT Message is Born

The gateway's acquisition program reads a temperature value of 25.6°C from the temperature controller and decides to report it via MQTT. At this point, an MQTT PUBLISH message is generated, containing:

• Topic: factory/line1/temp001

• Payload: {"temp":25.6,"ts":1754193600}

• QoS level: 1 (at least once delivery)

This MQTT message is the application-layer data.

Step 2: Transport Layer – TCP Segment Encapsulation

MQTT is based on TCP. The operating system places the MQTT message into a TCP segment, adding a TCP header:

• Source port: a random high-numbered port (e.g., 49152)

• Destination port: 1883 (the default MQTT port)

• Sequence number, acknowledgment number, window size, and other control fields

At this point, the TCP segment performs the first encapsulation of the MQTT message. TCP is responsible for "end-to-end reliable transmission" —it doesn't care about the final route, only that data is delivered without loss or disordering from the gateway to the MQTT broker.

Step 3: Network Layer – IP Packet Routing

The TCP segment is then encapsulated into an IP packet. The IP header adds:

• Source IP: the gateway's 4G-assigned IP (e.g., 10.45.0.12, a carrier-private address)

• Destination IP: the cloud platform's public IP (e.g., 47.102.x.x)

• TTL (Time to Live): prevents infinite looping

The core responsibility of the IP layer is "addressing and routing." It determines the path this packet takes from the gateway, through base stations, the carrier core network, internet exchange points, and finally to the cloud server. If there is an issue here—like the gateway not getting an IP, incorrect routing table configuration, or NAT mapping failure—a TCP connection cannot be established, no matter how reliable TCP is.

Step 4: Link Layer – The Frame is Transmitted on the Medium

The IP packet must finally become a link-layer frame to be transmitted over the physical medium.

In a 4G scenario, this is handled by the 4G module:

• On the air interface, the data is encapsulated into LTE/NR radio frames.

• On the carrier core network side, it is converted to Ethernet frames for the internet.

If the gateway connects to the cloud via wired Ethernet, it is directly encapsulated into an Ethernet frame, which includes MAC addresses:

• Source MAC: the gateway's port MAC address

• Destination MAC: the next-hop router's (gateway) MAC address

The link layer handles "data transmission between adjacent nodes." If a cable is loose, RS485 A/B wires are reversed, or the 4G signal strength is below -110 dBm—the problem is at this layer.

Step 5: Physical Medium – The Bitstream's Final Form

The link-layer frame is finally converted into a bitstream and transmitted over a physical medium:

• Wired Ethernet: electrical signals (copper) or optical signals (fiber)

• 4G/5G: radio waves

• RS485: differential electrical signals

Encapsulation Process Summary

[MQTT Message]
    ↓ encapsulated into
[TCP Segment: port 1883]
    ↓ encapsulated into
[IP Packet: src 10.45.0.12 → dst 47.102.x.x]
    ↓ encapsulated into
[Ethernet Frame / 4G Radio Frame]
    ↓ converted into
[Electrical/Optical/Electromagnetic Signals] → Transmission over physical medium

The golden rule for troubleshooting: check from the bottom layer up. Once the physical layer is clear, check the link layer; once the link layer is clear, check the network layer (can you ping?); once the network layer is clear, check the transport layer (are ports open?); once the transport layer is clear, check the application layer (is the protocol format correct?).

III. Pre-Services: The "Preparation Work" That Must Be Done Before Communication Begins

Before communication starts, some parsing or configuration work must be completed. In industrial networks, three pre-services are critical:

3.1 DNS: Domain Name Resolution Isn't Just for Browsing

Many engineers think DNS is only for web browsing. In fact, when an industrial gateway connects to a cloud platform using a domain name (e.g., mqtt.factory-cloud.com), the first step is DNS resolution to convert the domain name to an IP address.

Common On-Site Issues:

• Gateway 4G dial-up succeeds, but the DNS server configuration is wrong (e.g., using an internal DNS that can't resolve public domain names).

• The platform domain changes, but the gateway still has the old IP cached.

• Some closed industrial networks block outbound DNS queries, causing domain-based connections to fail.

Engineering Suggestion: For critical projects, configure domain name + IP dual-insurance on the gateway, or enable local Hosts mapping to avoid DNS as a single point of failure.

3.2 ARP: The "Address Inquiry" for LAN Communication

When a gateway and a PLC/SCADA server are on the same LAN, the gateway knows the target IP but not its MAC address. It needs to send an ARP request (Address Resolution Protocol):

"Device with IP 192.168.1.100, what is your MAC address?"

After the target device replies with an ARP response, the gateway can encapsulate the correct Ethernet frame.

Common On-Site Issues:

• Some industrial PCs/HMIs respond slowly or not at all to ARP.

• The gateway and target are on different subnets, but the subnet mask is misconfigured, causing ARP broadcast flooding.

• IP address conflicts (two devices using the same IP), causing the ARP table to refresh constantly and communication to be intermittent.

3.3 DHCP: The "Double-Edged Sword" of Auto-IP Assignment

When an industrial gateway connects to a client's internal network, it often uses DHCP to get an IP automatically. This simplifies configuration but introduces uncertainty:

• The IP changes after the DHCP lease expires, making the gateway IP configured in the SCADA system invalid.

• The DHCP server assigns an IP range that conflicts with field PLCs.

• Some older PLCs don't support DHCP and require a static IP.

Engineering Suggestion: For critical gateway devices, prefer static IP or DHCP reserved addresses (IP-MAC binding) to avoid data acquisition interruptions due to IP changes.

IV. Ancillary Control: They Don't Carry Data, But Communication Can't Happen Without Them

These protocols don't carry business data, but they provide essential support like parsing, error reporting, path building, and routing.

4.1 ICMP: The Network Layer's "Diagnostic Tool"

The most common application of ICMP (Internet Control Message Protocol) is ping.

In industrial settings, ping is the primary tool for checking network layer connectivity:

• ping 8.8.8.8 → Tests if the gateway can access the public internet.

• ping [Cloud Platform IP] → Tests network layer connectivity to the platform.

• ping -t continuous monitoring → Checks for packet loss or latency jitter.

Note: ICMP only tests network layer connectivity. A successful ping does not guarantee the application layer is working. The target device's TCP port 1883 might be blocked by a firewall, but ICMP might still be allowed, leading to the classic "ping works but MQTT can't connect" scenario.

4.2 Routing Protocols: The "Path Selection Logic" in Industrial Settings

In large factory or multi-site projects, industrial networks often involve multiple subnets. Routing protocols (static routes, OSPF, etc.) determine the forwarding path for IP packets.

Common Industrial Routing Scenarios:

• A gateway connecting to both a workshop intranet (192.168.1.x) and a 4G external network needs policy routing: traffic to PLCs goes through the intranet, while traffic to the cloud goes through 4G.

• In VPN scenarios, the gateway establishes an IPsec tunnel to headquarters, requiring static routes to direct traffic to the tunnel interface.

Routing errors are among the hardest to diagnose in industrial settings, as symptoms are often "some things work, others don't" – connectivity to certain IPs works, but not to others – essentially because the routing table doesn't cover the target subnets.

4.3 NAT: The "Mandatory Path" for Internal Devices to Reach the Cloud

The IP address an industrial gateway gets via 4G/5G dial-up is often a carrier-private address (like 10.x.x.x or 172.x.x.x), which is a private IP and cannot be directly accessed from the public internet.

When the gateway actively connects to a cloud platform as a client, it uses SNAT (Source Network Address Translation) – the gateway's private IP is translated to a public IP by the carrier's router, allowing internet access.

Common On-Site Issues:

• Some projects require the cloud platform to access the gateway in reverse (e.g., for remote PLC program downloads), but the gateway lacks a public IP. This requires VPN tunneling or NAT traversal solutions.

• Carrier NAT is layered too deeply (double NAT), causing VPN handshake failures.

V. Conditional Dependencies: Protocol Choices Vary Completely by Scenario

Different versions, protocols, or scenarios present different choices. This is particularly critical in industrial communication.

5.1 TCP vs UDP: The Reliability vs. Timeliness Trade-off

Selection Recommendations:

• Device status monitoring, critical process parameter reporting → MQTT over TCP (reliability first)

• High-frequency vibration sensor data, real-time surveillance video → UDP or QUIC (low latency first)

• Remote areas with poor network quality → Consider MQTT QoS 1/2 over TCP, or application-layer custom retransmission.

5.2 Modbus RTU vs Modbus TCP: Not a Replacement, but Different Encapsulation

Many engineers mistakenly think Modbus TCP is an "upgrade" to Modbus RTU. In fact:

• The application layer is identical: function codes, register addresses, and data formats are the same.

• The difference is only in the transport and link layers: RTU uses RS485 serial + CRC; TCP uses Ethernet + MBAP header + TCP checksum.

This means: the core job of a protocol conversion gateway is to take the RTU frame, remove the CRC, add the MBAP header, and place it in a TCP segment – and vice versa. Understanding this clarifies why some "protocol conversion" issues are actually TCP connection problems, not Modbus issues.

5.3 HTTP/1.1 vs HTTP/2 vs HTTP/3: Evolution in Industrial Edge Computing

With the rise of industrial edge computing and web-based SCADA, HTTP is entering industrial scenarios:

• HTTP/1.1: TCP-based, serial requests, low efficiency, but good compatibility.

• HTTP/2: TCP-based, supports multiplexing, allowing multiple requests in parallel over one TCP connection.

• HTTP/3: Based on QUIC (running over UDP), with better connection migration, more stable in poor network conditions.

Industrial Implication: For projects involving web SCADA, RESTful API calls, or OTA firmware downloads, prioritizing solutions that support HTTP/3 can improve transmission stability in weak network environments.

VI. Control and Routing Protocols

Correcting a common misconception: not all network protocols run on top of TCP or UDP. This is equally true in industrial networking.

6.1 Protocols Running Directly on IP

• OSPF: IP Protocol Number 89, used for route discovery within industrial networks, doesn't rely on TCP/UDP.

• ICMP: IP Protocol Number 1, used for network diagnostics and control.

• ICMPv6: IPv6 Next Header 58, used for IPv6 neighbor discovery and error control.

6.2 Protocols Running Directly on the Data Link Layer

• ARP: Encapsulated directly in Ethernet frames (EtherType 0x0806), bypassing the IP layer.

• STP: Layer 2 BPDUs, used for loop avoidance in industrial switches.

• IS-IS: Runs directly on Layer 2, used for route discovery and maintenance.

Engineering Insight: When you're configuring OSPF or troubleshooting STP loops on industrial switches, don't think in terms of "TCP ports" – these protocols don't use them.

VII. Practical Breakdown

Let's connect all the concepts above by walking through a complete industrial data acquisition communication flow.

Scenario Setup:

• Field device: Modbus RTU temperature controller with RS485 interface (Station Address 1).

• Gateway: Industrial gateway, RS485 for downlink, 4G for uplink.

• Platform: MQTT Broker (domain: iot.platform.com, IP: 47.102.x.x).

• Goal: Collect temperature once per second and report it via MQTT.

Phase 1: Gateway Startup and Network Preparation

1. 4G Module Dial-up: Gateway powers on; the 4G module sends an attach request to the carrier's base station and establishes a PDN connection.

2. DHCP IP Assignment: Carrier core network assigns an IP (e.g., 10.45.0.12) and DNS server addresses.

3. DNS Resolution: Gateway resolves iot.platform.com → 47.102.x.x.

4. TCP Three-Way Handshake: Gateway (random port 49152) → Platform (port 1883), establishing a TCP connection.

5. MQTT CONNECT: Gateway sends an MQTT CONNECT packet (with ClientID, username, password); the platform returns a CONNACK.

At this point, the "communication highway" from the gateway to the platform is open.

Phase 2: Field Device Data Acquisition

6. Modbus Polling: Gateway sends a Modbus RTU request frame over the RS485 bus:

   • Station Address: 0x01

   • Function Code: 0x03 (Read Holding Registers)

   • Starting Address: 0x0000

   • Register Count: 0x0001

7. Device Response: The temperature controller returns a data frame containing the raw temperature value (e.g., 0x0100, which is 25.6°C).

8. CRC Check: Gateway verifies the CRC16 to confirm data integrity.

Phase 3: Data Encapsulation and Reporting

9. Application Layer: Gateway packages temperature into an MQTT PUBLISH message:

   • Topic: factory/line1/temp001

   • Payload: {"temp":25.6,"ts":1754193600}

   • QoS: 1

10. Transport Layer: MQTT message is encapsulated in a TCP segment, destination port 1883.

11. Network Layer: TCP segment is encapsulated in an IP packet, source 10.45.0.12, destination 47.102.x.x.

12. Link Layer: IP packet is encapsulated in a 4G radio frame, transmitted via base station → core network → internet → cloud platform.

13. Platform Processing: Cloud receives the MQTT message, parses the payload, and stores it in a time-series database.

Phase 4: Connection Maintenance

14. MQTT KeepAlive: Gateway sends a PINGREQ every 60 seconds; platform replies with PINGRESP to maintain the TCP long connection.

15. TCP Retransmission: If a PUBLISH message is lost, the TCP layer automatically retransmits; if QoS=1, the MQTT layer also performs a publish acknowledgment.

A failure at any step in this process will cause data interruption. For example:

• Step 2 fails → Gateway didn't get an IP; check SIM card and APN.

• Step 4 fails → Platform port is closed or blocked by a firewall; check security group rules.

• Step 7 fails → RS485 bus interference or device unresponsive; check wiring and baud rate.

• Step 12 fails → Weak 4G signal or carrier network failure; check signal strength.

VIII. Protocol Dependency Chain Troubleshooting

6 Common Misconceptions (Industrial Edition):

1. Being able to ping does not mean the application port is working. ICMP only confirms network connectivity, not port or service status.

2. DNS resolving correctly does not mean the server is reachable. Intermediate network paths, routing, and firewalls can still block the connection.

3. A successful TCP handshake does not mean TLS will succeed. The encrypted handshake can still fail due to certificates, protocols, or cipher suites.

4. TLS succeeding does not mean the HTTP/MQTT service is working. Application logic, permissions, and Topic rights can all cause issues.

5. ARP working only confirms the current hop is resolved. Subsequent routing, name resolution, ports, and applications can still fail.

6. DHCP failing does not mean a statically addressed host cannot communicate. If static configuration is correct, communication can still be normal.

Core Principle: Validate layer by layer, from the bottom up. Don't skip layers. When ping fails, don't start adjusting MQTT QoS. When RS485 doesn't work, don't suspect the cloud firewall.

Industrial IoT projects are growing more complex, with more protocol types, but the underlying logic remains unchanged – layering, encapsulation, and dependencies.

• The link layer solves "how adjacent nodes communicate."

• The network layer solves "how to find a path across subnets."

• The transport layer solves "how to ensure end-to-end reliability."

• The application layer solves "how to represent business data."

Add to this the pre-services like DNS, ARP, DHCP, ancillary controls like ICMP, routing protocols, NAT, and conditional choices like TCP vs UDP, RTU vs TCP conversion, HTTP version evolution – a seemingly simple "device-to-cloud" connection relies on a sophisticated network of cooperating protocols.

As engineers, we don't need to be protocol experts, but we must understand the boundaries and dependencies of each layer. When a fault occurs, being able to quickly identify "which layer is the problem" is more valuable than memorizing any product's specifications.

The essence of industrial communication is not just "connecting," but "connecting continuously and reliably under complex physical and network conditions." Understanding protocol stack dependencies is the foundation for building this stability. We hope this article helps you get a better night's sleep during your next on-site troubleshooting session.