Bridge mode is suitable for Point-to-Multipoint networks, where Master-Slave applications with polling-type communication protocol are used. RipEX in bridge mode is as easy to use as a simple transparent device, while providing communication reliability and spectrum efficiency by employing a sophisticated protocol in the radio channel.

In bridge mode, the radio channel protocol do not solve collisions. There is a CRC check of data integrity, however, i.e. once a message is delivered, it is 100% error free.

All the messages received from user interfaces (ETH&COM's) are immediately transmitted to the radio channel.

ETH - The whole network of RipEX radiomodems behaves as a standard ethernet network bridge. Each ETH interface automatically learns which devices (MAC addresses) are located in the local LAN and which devices are accessible over the radio channel. Consequently, only the ethernet frames addressed to remote devices are physically transmitted on the radio channel. This arrangement saves the precious RF spectrum from extra load which would be otherwise generated by local traffic in the LAN (the LAN to which the respective ETH interface is connected).

COM1,COM2 - All frames received from COM1(2) are broadcast over the radio channel and transmitted to all COM's (COM1 as well as COM2) on all radio modems within the network, the other COM on the source RipEX excluding.

There is a special parameter TX delay (Adv. Config., Device), which should be used when all substations (RTU's) reply to a broadcast query from the master station. In such case massive collisions would ensue because all substations (RTU's) would reply at nearly the same time. To prevent such collision, TX delay should be set individually in each slave RipEX. The length of responding frame, the length of radio protocol overhead, modulation rate have to be taken into account.

In the following, common acronyms from SCADA systems are used:

The single digits in illustrations are “site names” and do not necessarily correspond with actual addresses of both the RipEX's and SCADA equipment. Address configuration examples are given in the next chapter.

Step 1 Polling cycle starts: FEP sends a request packet for RTU3 through COM1 to the connected RipEX.

Step 2 FEP’s RipEX broadcasts this packet on Radio channel. RipEX3 and RipEX1 receive this packet. RipEX2 doesn’t receive this packet, because it is not within radio coverage of FEP’s RipEX.

Step 3 RipEX3 and RipEX1 send the received packet to their COM1 and COM2. Packet is addressed to RTU3, so only RTU3 responds. RipEX1 is set as a repeater, so it retransmits the packet on Radio channel. Packet is received by all RipEXes.

Step 4 RipEX2 sends repeated packet to its COM1 and COM2. RTU2 doesn’t react, because the packet is addressed to RTU3. RipEX3 and FEP’s RipEX do not send the repeated packet to their COM ports, because it has already been sent (RipEX3) or received (FEP’s RipEX) on their COM (anti-duplication mechanism). RTU3 sends the reply packet.

Step 5 RipEX3 broadcasts the reply packet from RTU3 on Radio channel. Packet is received by RipEX1 and FEP’s RipEX.

Step 6 FEP’s RipEX sends the packet (the reply from RTU3) to FEP through COM1. RipEX1 sends this packet to RTU1. RTU1 doesn’t react, because the packet is addressed to FEP. RipEX1 repeats the packet on Radio channel. All RipEXes receive the packet.

Step 7 RipEX2 sends repeated packet to its COM1 and COM2. RTU2 doesn’t react, because the packet is addressed to FEP. RipEX3 and FEP’s RipEXes do not send the repeated packet to their COM ports, because it has been handled already. FEP processes the reply from RTU3 and polling cycle continues…..

You can see an example of IP addresses of the SCADA equipment and RipEX's ETH interfaces in the picture below.

In Bridge mode, the IP address of the ETH interface of RipEX is not relevant for user data communication. However it is strongly recommended to assign a unique IP address to each RipEXs' ETH interface, since it allows for easy local as well as remote service access. Moreover, leaving all RipEX's with the same (= default) IP on the ETH interface may cause serious problems, when more RipEX's are connected to the same LAN, even if by accident (e.g. during maintenance).

Fig. 2.1: Bridge mode example

Repeater

Because using the bridge mode makes the network transparent, the use of repeaters has certain limitations. To keep matters simple we recommend using a single repeater. However, if certain rules are observed, using multiple repeaters in the same network is possible.

The total number of repeaters in the network is configured for every unit individually under Bridge mode parameters. This information is contained in every packet sent. All units that receive such packet will resume transmission only after sufficient time has been allowed for the packet to be repeated. The packets received from user ports remain buffered and are sent after the appropriate time passes. This prevents collisions between remote radio modems. There can be no repeater collisions if only one repeater is used.

Where two or more repeaters are used, collisions resulting from simultaneous reception of a repeated packet must be eliminated. Collisions happen because repeaters repeat packets immediately after reception, i.e. if two repeaters receive a packet from the centre, they both relay it at the same time. If there is a radiomodem which is within the range of both repeaters, it receives both repeated packets at the same time rendering them unreadable.

Examples:

1. Repeaters connected serially

A packet is transmitted and repeated in steps 1, 2, 3.

In improperly designed networks collisions happen if a remote radio modem lies in the range of two repeaters (see the image): the packet sent from the centre (1) is received by both repeaters. It is repeated by them both (2) causing a collision at the remote. In other words – there should not be more than one repeater where the centre and remotes' coverage areas overlap.

Solution 1. Adjust signal coverage so that RPT2 is out of range of the centre and RPT1 is out of the range of the remote radio modem. This can be achieved for example by reducing the output power or using a unidirectional antenna.

Solution 2. Use a single repeater. (Whenever network layout allows that.)

2. Parallel repeaters

Improperly designed network: - RipEX REM1 is within the range of two repeaters (RPT1 and RPT2). The repeaters receive a packet (1) from the centre (CEN) and repeat it at the same time (2) causing a collision at REM1.   Well-designed network: - A remote is only in the range of a single repeater (REM1-RPT1, REM2-RPT2). There is always only one repeater where the centre and remote coverage areas overlap.

Router mode is suitable for multipoint networks, where multi-master applications with any combination of polling and/or spontaneous data protocols can be used. The proprietary link-layer protocol on the radio channel is very sophisticated, it can transmit both unicast and broadcast frames, it has collision avoidance capability, it uses frame acknowledgement, retransmissions and CRC checks to guarantee data delivery and integrity even under harsh interference conditions on the radio channel.

RipEX works as a standard IP router with 2 independent interfaces: radio and ETH. Each interface has its own MAC address, IP address and mask.

IP packets are processed according the routing table rules. You can also set the router’s default gateway (applies to both interfaces) in the routing table.

The COM ports are treated as standard host devices, messages can be delivered to them as UDP datagrams to selected port numbers. The destination IP address of a COM port is either the IP of ETH or the IP of a radio interface. The source IP address of outgoing packets from COM ports is always the IP of the ETH interface.

In the following example, there are two independent SCADA devices connected to RipEX's two COM ports. One is designated RTU (Remote Telemetry Unit) and is assumed to be polled from the centre by the FEP (Front End Processor). The other is labelled PLC (Programmable Logic Controller) and is assumed to communicate spontaneously with arbitrary chosen peer PLCs.

Step 1 FEP sends a request packet for RTU1 through COM2 to its connected RipEX. Simultaneously PLC2 sends a packet for PLC1 to RipEX2 through COM1.

Step 2 FEP’s RipEX transmits an addressed packet for RTU1 on Radio channel. RipEX1 receives this packet, checks data integrity and transmits the acknowledgement. At the same time packet is sent to RTU1 through COM2. RipEX3 receives this packet too. It doesn’t react, because this packet is directed to RipEX1 only.

Step 3 RipEX2 waits till previous transaction on Radio channel is finished (anti-collision mechanism). Then RipEX2 transmits on Radio channel the addressed packet for PLC1. RipEX1 receives this packet, checks data integrity and transmits acknowledgement. At the same time packet is sent to PLC1 through COM1. Simultaneously the reply packet from RTU1 for FEP is received on COM2.

Step 4 RipEX1 transmitts the reply packet from RTU1 for FEP on Radio channel. All RipEXes receive this packet. This packet is addressed to FEP’s RipEX, so only FEP’s RipEX reacts. It checks data integrity and transmits the acknowledgement to RipEX1. At the same time the packet is sent to FEP through COM2.

Step 5 FEP receives the response from RTU1 and polling cycle continues…   However any PLC or RTU can spontaneously send a packet to any destination anytime.

As it was mentioned above, RipEX radiomodem works as a standard IP router with two independent interfaces: radio and ETH. Each interface has got its own MAC address, IP address and mask.

The IP router operating principles stipulate that every unit can serve as a repeater.. Everything what is needed is the proper configuration of routing tables.

Radio IP addresses of the RipEX’s required to communicate over the radio channel must share the same IP network. We recommend planning your IP network so that every RipEX is connected to a separate sub-network over the ethernet port. This helps to keep the routing tables clear and simple.

Note

Even if the IP addresses of all RipEXes in a radio channel share a single IP network, they may not be communicating directly as in a common IP network. Only the RipEXes that are within the radio range of each other can communicate directly. When communication with radio IP addresses is required, routing tables must include even the routes that are within the same network (over repeaters), which is different from common IP networks. The example configuration below does not show such routing rules for the sake of simplicity (they are not needed in most cases).

Fig. 2.2: Addressing

Formal consistency between the last byte of the radio IP address and the penultimate byte of the ethernet address is not necessary but simplifies orientation. The “Addressing” image shows a routing table next to every RipEX. The routing table defines the next gateway for each IP destination. In radio transmission, the radio IP of the next radio-connected RipEX serves as the gateway.

Example of a route from FEP (RipEX 50) to RTU 2:

In large and complex networks with numerous repeaters, individual routing tables may become long and difficult to comprehend. To keep the routing tables simple, the addressing scheme should follow the layout of the radio network.

More specifically, every group of IP addresses of devices (both RipEX's and SCADA), which is accessed via a repeater, should fall in a range which can be defined by a mask and no address defined by that mask exists in different part of the network.

A typical network consisting of a single centre and number of remotes has got a tree-like layout, which can be easily followed by the addressing scheme – see the example in the Figure Optimised addressing below.

Fig. 2.3: Optimised addressing

The default gateway is also a very powerful routing tool, however be very careful whenever the default route would go to the radio interface, i.e. to the radio channel. If a packet to non-existing IP destination came to the router, it would be transmitted over the radio channel. Such packets increase the load of the network at least, cause excessive collisions, may end-up looping etc. Consequently the default route should always lead to the ETH interface, unless you are perfectly certain that a packet to non-existing destination IP may never appear (remember you are dealing with complex software written and configured by humans).

Each SCADA protocol, such as Modbus, DNP3, IEC101, DF1, etc., has its own unique message format, and more importantly, its unique way of addressing remote units. The basic task for protocol utility is to check whether a received frame is in the correct protocol format and uncorrupted. Most of the SCADA protocols use some type of error detection codes (Checksum, CRC, LRC, BCC, etc.) for data integrity control, so RipEX calculates this code and check it with the received one.

RipEX radio network works in IP environment, so the basic task for the protocol interface utility is to convert SCADA serial packets to UDP datagrams. Address translation settings are used to define the destination IP address and UDP port. Then these UDP datagrams are sent to RipEX router, processed and typically forwarded as unicasts over the radio channel to their destination. If the gateway defined in the routing table belongs to the ethernet LAN, UDP datagrams are rather forwarded to the ethernet interface. After reaching the gateway (typically a RipEX router), the datagram is again forwarded according to the routing table.

Above that, RipEX is can to handle even broadcast packets from serial SCADA protocols. When broadcasts are enabled in the respective Protocol settings, the defined packets are treated as broadcast (e.g. they are not acknowledged on Radio channel). On the Repeater station, it is possible to set whether broadcast packets shall be repeated or not.

Note: UDP datagrams can be acknowledged on the radio channel (ACK parameter of router mode) but they are not acknowledged on the ethernet channel.

When a UDP datagram reaches its final IP destination, it should be in a RipEX router again (either its ETH or radio interface). It is processed further according its UDP port. Either it is delivered to COM1(2) port daemon, where the datagram is decapsulated and the data received on serial interface of the source unit is forwarded to COM1(2), or the UDP port is that of a Terminal server or any other special protocol daemon on Ethernet like Modbus TCP etc. Then the datagram is processed by that daemon accordingly to the respective settings.

RipEX uses a unique, sophisticated protocol on the radio channel. It guaranties data integrity even under heavy interference or weak signal conditions due to the 32 bit CRC used, minimises the likelihood of a collision and retransmits frames when collision happens, etc. These features allow for the most efficient SCADA application arrangements to be used, e.g. multi-master polling and/or spontaneous communication from remote units and/or parallel communication between remote units, etc.

Note: The anti-collision protocol feature is available only in the router mode. The bridge mode is suitable for simple Master-Slave arrangements with polling-type application protocol.

Generally, a terminal server (also referred to as serial server) enables connection of devices with a serial interface to a RipEX over the local area network (LAN). It is a virtual substitute for the devices used as serial-to-TCP(UDP) converters.

Examples of the use:

A SCADA application in the centre should be connected to the radio network via serial interface, however, for some reason that serial interface is not used. The operating system (e.g. Windows) can provide a virtual serial interface to such application and converts the serial data to TCP (UDP) datagrams, which are then received by the terminal server in RipEX. This type of connection between RipEX and application provides best results when:

Note: The TCP (UDP) session operates only locally between RipEX and the central computer, hence it does not increase the load on the radio channel.

In special cases, the terminal server can reduce network load from TCP applications . A TCP session can be terminated locally at the terminal server in RipEX, user data extracted from the TCP messages and processed as if it came from a COM port. When the data reaches the destination RipEX, it can be transferred to the RTU either via the serial interface or via TCP (UDP), using the terminal server again. Please note, that RipEX Terminal server implementation also supports the dynamical IP port change in every incoming application datagram. In such case the RipEX sends the reply to the port from which the last response has been received. This feature allows to extend the number of simultaneously opened TCP connections between the RipEX and the locally connected application up to 10 on each Terminal server.

There are ‘Neighbours’ and Statistic logs in RipEX. For both logs there is a history of 20 log files available, so the total history of saved values is 20 days (assuming the default value of 1440 min. is used as the Log save period).

Neighbours

The ‘Neighbours’ log provides information about neighbouring units (RipEX’s which can be accessed directly over the radio channel, i.e. without a repeater). Every RipEX on the network regularly broadcasts its status, the set of so called “Watched values”: the probability of packet loss when transmitting data over the radio channel, current supply voltage, internal temperature, measured RF output power, the Voltage Standing Wave Ratio on the antenna feed line and the total number of packets received from / transmitted to ETH, COM1, COM2 interfaces. In addition, the RipEX that records this data in its log also keeps track of how many times it listened to its neighbouring unit as well as of the RSS and DQ recorded. See Adv. Conf., Diagnostic for more.

Statistic

The ‘Statistic’ log provides information about the volume of data traffic on all interfaces: radio, ETH, COM1, COM2. It offers detailed information about the number of transmitted packets, their size and the throughput per second. Moreover, a detailed division into user and service packets is available for the radio channel. See chapter Adv. Conf., Diagnostic for more.

An independent database periodically stores the Watched values (see 'Neighbours' log above) from up to five neighbouring RipEX's and from the local one, there including most important values from the Statistic log. All these values can be displayed as graphs.

The graphs are available in summary and detailed versions. Detailed logging is triggered on when a threshold value has been reached for the specific item to enable a more detailed investigation into the units’ operation when an alarm event occurs. Each graph can display two different elements at once, including their set thresholds. Each of the values may originate from a different RipEX unit.

See chapter Adv. Conf., Graphs for more.

RipEX implements an SNMP client ver. 1. The values provided by RipEX are shown in the MIB table. RipEX also allows generating SNMP traps when thresholds have been reached for the monitored values: RSScom, DQcom, TXLost[%], Ucc, Temp, PWR, VSWR, ETH[Rx/Tx], COM1[Rx/Tx], COM2[Rx/Tx], HW Alarm Input.

See chapter RipEX App notes, SNMP for RACOM RipEX for more.

To diagnose the individual radio links RipEX is equipped with an enhanced Ping tool. In addition to the standard info such as the number of sent and received packets or the round trip time, it provides the overall load, the resulting throughput, BER, PER and specific data about the quality of the radio transmission, RSS and DQ for the weakest radio link on the route.

See chapter Adv. Conf., Ping for details.

TMonitoring is an advanced on-line diagnostic tool, which enables a detailed analysis of communication over any of the interfaces of a RipEX router. In addition to all the physical interfaces (RADIO, ETH, COM1, COM2), some internal interfaces between software modules (e.g. Terminal servers, Modus TCP server etc.) can be monitored when such advanced diagnostics is needed.

Monitoring output can be viewed on-line or saved to a file in the RipEX (e.g. a remote RipEX) and downloaded later.

Fig. 2.4: Monitoring

See chapter Adv. Conf., Monitoring for details.