Bridge mode is suitable for Point-to-Multipoint networks, where Master-Slave applications with polling-type communication protocol are used. The Bridge mode is suitable also for Point-to-Point networks (both half and full duplex).
Transparent radio channel protocol of the bridge does 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) are immediately transmitted to the radio channel.
ETH – The whole network of RipEX2 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).
One has to be very careful when RipEX in Bridge mode is connected to LAN, because all LAN traffic is then broadcasted to the Radio channel.
COM – All frames received from COM port are broadcast over the radio channel and transmitted to all COM ports on all radio modems within the network, the other COMs on the source RipEX excluding.
In the following, common acronyms from SCADA systems are used:
FEP – Front End Processor, designates the communication interface equipment in the centre
RTU – Remote Telemetry Unit, the terminal SCADA equipment at remote sites
The single digits in illustrations are “site names” and do not necessarily correspond with actual addresses of both the RipEX2‘s and SCADA equipment. Address configuration examples are given in the next chapter.
Polling cycle starts:
FEP’s RipEX2 broadcasts this packet on Radio
RipEX2 3 and RipEX2 1 send the received packet to their COM
RipEX2 2 sends repeated packet to its COM.
RipEX2 3 broadcasts the reply packet from RTU3 on Radio
FEP’s RipEX2 sends the packet (the reply from RTU3) to FEP through
RipEX2 2 sends repeated packet to its COM.
You can see an example of IP addresses of the SCADA equipment and RipEX2‘s ETH interfaces in the picture below.
In Bridge mode, the IP address of the ETH interface of RipEX2 is not relevant for user data communication. However it is strongly recommended to assign a unique IP address to each RipEX2s’ ETH interface, since it allows for easy local as well as remote service access. Moreover, leaving all RipEX2‘s with the same (= default) IP on the ETH interface may cause serious problems, when more RipEX2 units are connected to the same LAN, even if by accident (e.g. during maintenance).
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.
RipEX2 works as a standard IP router with multiple independent interfaces: Radio and Ethernets. Each interface has its own MAC address, IP address and mask.
IP packets are processed according to 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 an ETH or the IP of a radio interface.
The additional Virtual COM ports and Terminal server can act as other IP router ports. This enables Serial and TCP based RTUs to be combined in one network.
All traffic over the Radio channel is managed by the Base station. Radio channel access is granted by a deterministic algorithm resulting in collision free operation regardless of the network load. Uniform distribution of Radio channel capacity among all Remotes creates stable response times with minimum jitter in the network.
All communication on Radio channel is controlled by the Base station; all frames inside the radio network have to be routed through the Base station. Appropriate routing has to be set.
Base station can communicate with the Remote stations using individual modulation and FEC settings.
Any Remote can work as a Repeater for another Remote. Only one Repeater is possible between the Base station and Remote, however a number of Remotes can use the same Repeater.
There is no need to set any routes in Routing table(s) for Remote stations located behind Repeater. Forwarding of frames from the Base station over the Repeater in either direction is provided transparently by the Base driven protocol.
When Remote to Remote communication is required, respective routes via the Base station must be set in Routing tables in the Remotes.
Frame acknowledgement, retransmissions and CRC check, guarantee data delivery and integrity even under harsh interference conditions on the Radio channel.
A star topology with one repeater is used in the following example of a SCADA network using a polling and report by exception combination. The Repeater is also serving as a Remote radio. The packets’ acknowledgement on Radio channel is used in both directions in the example.
RipEX2 base station regularly checks the queue status of RipEX2 Remote stations for which it has no queueing information. The feedback enables the Base station to manage time allocations for all Remotes to transmit.
FEP sends a request packet to RTU1 via Base station; Base station transmits packet in shortest possible time. Remote station 1 receives the packet and hands it over to RTU1, simultaneously acknowledging packet receipt to the Base station.
RTU1 processes the request and sends the reply to Remote station 1. During the checking process the Base station detects a prepared packet in the queue of Remote station 1 and subsequently allots a Radio channel for transmission of the packet. Remote station 1 transmits the packet. If the Base station successfully receives the packet, it sends an acknowledgement and then the Remote station 1 clears the packet from the queue. A part of the relation includes a hand over of information about the number of packets waiting in the queue.
RTU2 is connected to Remote station 2 behind Repeater station 1, which manages all communication between the Base station and Remote station 2.
As already mentioned, RipEX2 works as a standard IP router with multiple
independent interfaces: Radio and Ethernets. Each interface has its own MAC address, IP
address and mask.
When Base driven protocol is used, Radio IP addresses for all RipEX2 units must share the same IP subnet.
The Base driven protocol routing table for each RipEX2 Remote station can be
simplified to a default gateway route rule directed to RipEX2 Base station Radio IP.
Only one record with respective IP address/mask combination for each remote station is
needed in the Base station routing table.
The repeaters are not considered in routing in Base driven protocol. Each Remote station uses its own Radio IP address as a gateway in the routing table of the Base station.
See chapter Advanced Configuration/ Settings/ Radio/ Base driven for more.
For those accustomed to using the Flexible Radio protocol:
When only serial protocols are used, there is no need to use Routing tables. Instead of using Routing tables records, Address translation in COM protocol settings is used. Serial protocol address to IP address translation rules apply where the Radio IP addresses are used. Radio IP addresses will only be used for maintenance in such circumstances.
RipEX2 enables combination of IP and serial protocols within a single application.
Five independent terminal servers are available in RipEX2. Terminal server is a virtual substitute for devices used as serial-to-TCP(UDP) converters. It encapsulates serial protocol to TCP(UDP) and vice versa eliminating the transfer of TCP overhead over the radio channel.
If the data structure of a packet is identical for IP and serial protocols, the terminal server can serve as a converter between TCP(UDP)/IP and serial protocols (RS232, RS485).
You can see an instructional video explaining the Terminal server functionality here: https://www.racom.eu/ripex-terminal
Generally, a Terminal server (also referred to as Serial server) enables connection of devices with a serial interface to a RipEX2 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 RipEX2. This type of connection between RipEX2 SCADA and application is beneficial in the following circumstances:
There is no hardware serial interface on the computer
Serial cable between RipEX2 and computer would be too long. E.g. the RipEX2 is installed very close to the antenna to reduce feed line loss.
LAN already exists between the computer and the point of installation
The TCP (UDP) session operates only locally between RipEX2 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 RipEX2. User data are extracted from the TCP messages and processed as if it came from a COM port. When the data reaches the destination RipEX2, it can be transferred to the RTU either via the serial interface or via TCP (UDP), using the Terminal server again. Please note, that RipEX2 Terminal server implementation also supports the dynamical IP port change in every incoming application datagram. In such a case the RipEX2 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 RipEX2 and the locally connected application up to 10 on each Terminal server.