It is important to ensure clarity about the bandwidth capabilities of the Trio Q Series data radio. There are significant challenges with trying to connect a high speed (hard-wired) LAN to a narrowband radio system. The Q radios are capable of at BEST 80 kbps over-the-air, compared to at least 10 Mbps for a hard-wired system. (often as much as 1 Gbps) On average, this 80 kbps will actually be less due to several factors, for example:
- The radio system's own internal protocol overhead
- Some radio links may have lower receive signal levels (or higher interference/noise levels) so have to talk more slowly eg 16 kbps now and then or maybe even once in awhile 8 kbps.
- A system may include some repeaters. Store & Forward type repeaters will significantly increase the latency (delay) on any message sent through them. (typically double)

When sending a single polling message (eg Modbus) through a Q Series radio system including NO repeaters, the typical delay might be around 100 milliseconds, not counting any necessary response time by the destination RTU or PLC. Through one repeater, it will go up to around 200 ms. Through 2 in-series repeaters, the delay will again rise to around 300 ms. If there are collisions due to overly-high traffic loading, or interference/noise events, there will be significant delays caused by radio layer Retries. As a result, any SCADA Host system must be ready to wait as much as 2-3 seconds for a response, though it would typically get a response in the time frame discussed above. (based on number of in-series repeaters)

When a Q Series radio system is configured for the (default) Transparent Bridge mode, each radio will transmit all data that it hears on its LAN ports. If there's a repeater in the system, it likewise will repeat everything. The only exception: in each radio you can enable various Ethernet traffic filters via the Filtering Firewall configuration page. There are Predefined Filters that can filter some general Ethernet traffic types as well as specific commonly used protocols. (HTTP, Telnet, SNMP, SSH, etc...)

For Ethernet Filter Type, there are 4 options:

• Allow All (no Ethernet filtering)
• Allow ARP + Unicast + Multicast (Multicast delivers a messages to a group of destination addresses simultaneously. Not a broadcast message to everyone)
• Allow ARP + Unicast (ARP is primarily used by networks to identify which physical devices own which IP address)
• Allow Unicast (only used when a MAC address table is statically assigned)

Furthermore, additional User Defined Filters can be created to allow specific IP addresses, MAC addresses or Ethernet ports.

If the radios are configured for IP Routing mode, typically to allow multiple repeaters in one system, ARP messages will, by default, be blocked from going over the air as the radio system is now considered to be a Wide Area Network (WAN). ARP only exists on a LAN. That's one good thing. Each radio and any devices locally connected must be configured to be on a unique LAN in this mode. Then IP Routing rules are created in each radio to forward messages to an appropriate destination LAN. If there is no Routing rule in a radio for a message directed to a specific LAN, it will drop that packet. So IP Routing rules can help block some traffic not meant to go over the radio system. But such rules cannot stop or slow down traffic for which rules exist.

The biggest single problem that can exist is when the SCADA Host computer is configured to poll many sites very rapidly for a very large amount of data. This works fine on a 100 Mbps hard-wired network but will drag a 32 kbps radio link to its knees. No sort of filter can block this from happening, as all the traffic is desired traffic, there's just way too much of it. The only way to make such a system work is to ensure that only ONE message goes out at any time, then the SCADA Host waits for the reply, then after a brief delay it sends the next message. Note that the "brief delay" mentioned is perhaps 100 milliseconds between polls, to give the radio system time to perform its own internal "housekeeping" functions without creating great odds of collisions or timeouts. If there were some way to tell the Host to poll rapidly when on the high speed system, and to slow down and add those 100 ms pauses between polls, when on the backup system, it would work far better.

Released for: Schneider Electric Macedonia