# Rethinking Modbus-UDP for Real-Time IIoT Systems
## 3 Protocol Specification
### Message Retransmission  
The Ethernet data-link layer (L2), unlike CAN's [11], does not have any built-in frame retransmission mechanism, except in the event of a collision. In particular, FCS errors detected by the receiving node do not trigger any automatic retransmission. Moreover, there is no retransmission upon a lack of acknowledgment since the Ethernet L2 does not have any built-in acknowledgment mechanism. For this reason, explicit L7 retransmission rules have been specified in Modbus-UDP. There is no need to do the same in Modbus-TCP because TCP already provides a well-proven automatic segment retransmission mechanism at L4.  
To avoid application-level transaction duplication or loss, retransmission rules must be complemented with replay rules on the Modbus slave side and discard rules on the master side. Replay rules determine whether and when the Modbus-UDP protocol layer must replay an application-layer message previously sent without involving the application layer again. Discard rules determine whether and when Modbus-UDP must simply discard an incoming message without notifying the application layer. Retransmission, replay, and discard rules depend on the traffic classes defined in Section 3.3.  
For unicast transactions, Modbus-UDP adopts a timeout-based retransmission mechanism complemented by a cap on the maximum number of retransmissions. In the current implementation, the master transmits requests up to \(r^{\text{(U)}}=4\) times (one initial transmission plus three retransmissions) spaced by \(t^{\text{(U)}}=3\,\text{ms}\). Therefore, in the worst case, the whole transmission sequence takes \((r^{\text{(U)}}-1)t^{\text{(U)}}=9\,\text{ms}\). Considering a typical application-layer timeout of \(10\,\text{ms}\), this still leaves the slave \(1\,\text{ms}\) to respond before the timeout expires, after it receives the very last retransmission.  
On the contrary, there is no retransmission for broadcast requests, in line with the lack of acknowledgment and retransmission of these requests in Modbus-RTU [2]. This is not deemed to be an issue because any broadcast-based protocol designed for Modbus-RTU or Modbus-CAN [7], including the one discussed in [13; 39], must already be prepared for the loss of a broadcast request and be able to recover appropriately.  
All retransmissions of a given message are performed using the same TID as in the first transmission of the message. This enables duplicate detection and discarding on both the master and slave ends, as described next.  
Each Modbus-UDP slave stores the TID of the last request directed to it and the corresponding response it sent. Upon receiving a new request with the same TID, the slave replays the same response without involving the application layer. The slave performs those replays by again sending the exact same response that it originally sent, including its TID, without further inspection. In this way, Modbus-UDP does not need to be aware of application-layer message content and semantics. Nodes never replay broadcast messages.  
A Modbus-UDP master discards a unicast response if it bears the same TID as a request for which a response has already been received and forwarded to the application layer. Broadcast messages, instead, are never discarded. To apply discard rules correctly, a master must store the last TID it generated, as well as the last TID it received from each slave.