## 3 Materials and Methods
### Session-Based Protocols--Modbus and DNP3  
In contrast to the GOOSE protocol, Modbus and DNP3 do not have low-latency requirements for their respective protocol transmissions. These protocols utilize a simple request/response model, with packets often scheduled through the internal logic of an IED or external signaling. The utilized network configuration for these protocols is the same as that of the 5G TCP test case described above. Instead of a GOOSE publisher, a test controller is implemented through the Scapy library [28]. In contrast to the previous tests against production IEDs, the 5G UE for these tests directly acts as an endpoint for these protocols. The UE utilizes the same Scapy library and responds to each Modbus and DNP3 request with a valid response.  
Modbus--The Modbus protocol was initially created for serial wire communication in a bus configuration. The protocol is frequently used to interact with Programmable Logic Controllers (PLCs) or for communication between a SCADA system and Remote Terminal Units (RTUs). It commonly utilizes RS-485 for signaling, and the messaging exchange follows a request/response model. The \"Client\" device is the requesting device for all communication, while a \"Server\" device generates a response packet to the corresponding request. The packet structure contains a 1-byte server address, function code, relevant data, and the CRC error-check field for a request or response. Although packets can be as small as 5 bytes, the protocol limits the size of a packet to 256 bytes [3].  
As Modbus transitioned to TCP communication, the error-check field was removed and a Modbus Application (MBAP) header was introduced. The header contains the server address and function code, but the packet adds a transaction identification field for devices to identify individual request packets and their responses. Containing the same number of 253 available data bytes, the largest Modbus packet in TCP communication is 260 bytes.  
DNP3--Similar to Modbus's request/response structure, DNP3 utilizes a \"Master\" for generating requests, with an \"Outstation\" creating the corresponding response. DNP3 is commonly used for communication between SCADA systems and a variety of components, including PLCs, RTUs, and IEDs. DNP3 allows for usage over a serial bus, such as RS-485, and TCP sessions over Ethernet, without changing the message structure. This is achieved through message fragmentation, as no DNP3 packet will ever exceed 292 bytes [4]. DNP3 utilizes link, transport, and application layer headers to determine message priority, including source and destination addresses, and for packet reassembly requirements. Given the ability to reassemble packets, more data can be read from a single request than is possible in Modbus.  
DNP3 also allows flexibility in data representation with defined object-oriented data types. Designed as a polling protocol, it enables scheduled reports to be requested at set intervals. However, the DNP3 protocol offers several levels of conformance [4], with higher levels allowing for the optional use of unsolicited messages from an \"Outstation\" to the \"Master\". For the purposes of this paper, we configure each DNP3 endpoint to refuse unsolicited requests.  
Latency Measurements--For latency measurements in each test case, a network tap was placed on the Core Network workstation and connected to the UE. On the UE device, Wireshark was utilized to capture packets on both the Core Network interface and the UE's 5G interface. This allowed for time-stamped measurements as the OT protocol packets arrived on the Core Network, during GTP packet forwarding to the gNB, and when OT protocol packets arrived at the UE.