# Rethinking Modbus-UDP for Real-Time IIoT Systems
## 3 Protocol Specification
### Frame Format, Addressing, and Frame Length Calculation  
Overall, the frame format proposed for Modbus-UDP in this work conforms with the standard Modbus application protocol specification [1] and the Modbus-TCP specification [8], except for a few key aspects:  
1. Modbus PDUs are encapsulated in, and transported by, UDP datagrams. Moreover, L2 frames are tagged with an IEEE 802.1Q VLAN tag. Section 3.6 provides more information on tag content and, more generally, how Modbus-UDP messages are prioritized at L2 and L3. 2. The TID is still backward-compatible but has additional semantics attached than in the original specification, so it serves not only as a way to pair requests and replies but also differentiates unicast and broadcast Modbus transactions. Section 3.3 defines the newly specified semantics. 3. Modbus-UDP datagrams are sent either to the directed broadcast IP address of the network interface chosen for Modbus-UDP communication or to a suitable multi-cast address. In the second case, the normal multicast subscription process must be followed to ensure that any interposed gateway forwards multicast messages appropriately. 4. The unit identifier is also used to identify directly connected slaves in addition to remote slaves connected on the other side of a gateway, as specified in Modbus-TCP. Figure 3 shows the proposed Modbus-UDP frame format and its encapsulation down to the physical layer (L1) packet of a 100 BaseTX Ethernet network. For each layer, the Service Data Unit (SDU), which contains the PDU of the layer immediately above, is shown in gray. The format of request and response messages pertaining to the RH and WM Modbus transactions, the ones chosen for the performance evaluation discussed in Section 4, has been depicted in Figure 1.  
The beginning of this section is focused on frame length calculation, while further information on the meaning of individual fields and the differences with respect to Modbus-TCP is provided in the rest. For each layer \(l\), the symbol \(L_{l}\) represents the length, in bytes, of its PDU, possibly parameterized as specified by the arguments that follow the symbol, while \(L_{\text{M}}\) is the length of a generic Modbus PDU. Moreover, \(L_{\text{M}}^{(\text{RRLS})}\), \(L_{\text{M}}^{(\text{RH,R})}\), \(L_{\text{M}}^{(\text{WM,S})}\), and \(L_{\text{M}}^{(\text{WM,R})}\) denote the specific lengths of Modbus request (S) and response (R) PDUs of RH and WM transactions, respectively. Starting from the physical layer (L1), the length of a packet that encapsulates a data link layer (L2) frame is given by \(L_{1}=7+1+L_{2}=L_{2}+8\), where 7 is the length of the preamble, 1 is the length of the Start Frame Delimiter (SFD), and \(L_{2}\) is the length of the encapsulated L2 PDU. The Inter-Packet Gap (IPG), depicted in light gray in the figure, is not to be included in transmission delay calculation because, on virtually all Ethernet controllers, incoming packets are made available to upper protocol layers as soon as their Frame Check Sequence (FCS) has been verified, without waiting for the IPG to end. For this reason, \(L_{1}\) does not include it. To ensure reliable collision detection, the L2 PDU must be at least 64 B long. If this is not the case, L2 adds trailing padding bytes to the L3 SDU as needed. Therefore, it is  
\[L_{2}=\max(12+4+2+L_{3}+4,64)=\max(L_{3}+22,64)=22+\max(L_{3},42)\enspace, \tag{1}\]  
which implies that the minimum \(L_{3}\) for which no padding is necessary is \(L_{3}^{\min}=42\). The amount of padding can be calculated as \(P_{2}=\max(42-L_{3},0)\). The constants in (1) represent, from left to right, the length of the L2 source and destination address (12 B), the length of the 802.1Q VLAN tag [38], which Modbus-UDP requires (4 B), the Ethertype (2 B), and, finally, the FCS (4 B). Moving on to L3 and L4, considered together in Figure 3, it is \(L_{3}=20+8+L_{7}=L_{7}+28\), where 20 and 8 are the lengths, in bytes, of the L3 (IP, without options) and L4 (UDP) headers.