RipEX2 in detail

Print version

5. RipEX2 in detail

5.1. Bridge mode

5.1.1. Detailed Description

Bridge mode enables transparent data transfer over the RipEX2 network. It 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 links (both half and full duplex).

One of the advantages of the Bridge mode (together with Radio Transparent protocol) is its transparency. For example: both IPv4 and IPv6 type of traffic passes through; Frames defined by IEEE802.1Q-2018 are supported (e.g. VLAN, QinQ).

Bridge mode operation depends on the following system settings:

  • Radio channel: Transparent protocol selected

  • Ethernet ports: The Ethernet ports, intended to be used in Bridge mode, are grouped together in the Network interface (default name “bridge”), which is bridged with the Radio interface (parameter “Bridged with radio” enabled)

  • COM ports: “Transparent protocol” selected

Radio channel

Transparent radio channel protocol does not solve collisions. There is a CRC check of data integrity to assure once a message is delivered, it is error free.

Ethernet ports

The whole radio network build from RipEX2 radio modems behaves as a standard Ethernet bridge. An Ethernet bridge (“Network interface” in RipEX2) 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 over the radio channel. This arrangement saves the precious RF spectrum from extra load which would be otherwise generated by local traffic.

By default all Ethernet ports are bridged together with the Radio interface. It is possible to remove some Ethernet ports from this Network interface (having the Radio interface attached) to prevent unwanted traffic to enter the radio channel.

At least one Eth interface has to be bridged with the Radio

It is possible to form another Network interface(s). Any needed Ethernet traffic can be routed in between individual Network interfaces.

It is a good practice to detach one (or more) Ethernet port(s) from the main Network interface (described above) for other purpose than transparent data transfer. One typical example is: dedicated port for the unit management. It is very useful to use such a separated port for unit management, because there is no danger of transferring unwanted traffic (e.g. system updates or similar traffic) from the client PC over the radio channel. You can create another Network interface (e.g. called LAN-mgmt). Attach the previously detached ETH port and configure an IP address to be able to access the unit management.

COM port

The COM port needs to be Enabled and a Protocol needs to be selected to transfer any data. “Transparent” type of COM protocol is dedicated for Bridge mode purposes. This protocol transfers data between the COM port and the RipEX2 network transparently. Any other Protocol can be selected when needed.

When the “Transparent” protocol is selected, all frames received from the COM port are broadcasted over the radio channel and transmitted to all COM ports on all radio modems within the network. If the remote COM port is also configured for “Transparent” protocol, the received data are transparently transmitted over the COM port.

Terminal Servers

Behavior of Terminal Servers is similar to COM port. “Transparent” protocol needs to be selected when transparent data transfer to whole network (broadcasts) is needed. The other protocol types can be used for “Router mode” type of addressed communication.

5.1.2. Functionality example

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

  • FEP – Front End Processor, designates the communication interface equipment in the center

  • 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 Section 5.1.3, “Configuration examples”.

Step 1

Polling cycle starts:

FEP sends a request packet for RTU C through COM to the connected RipEX2.

Step 2

RipEX2 FEP broadcasts this packet on Radio channel.
RipEX2 C and RipEX2 A receive this packet.
RipEX2 B does not receive this packet, because it is not within radio coverage of RipEX2 FEP .

Step 3

RipEX2 C and RipEX2 A send the received packet to their COM ports.
Packet is addressed to RTU C, so only RTU C responds.
RipEX2 A is set as a repeater, so it retransmits the packet on Radio channel. Packet is received by all RipEX2 units.

Step 4

RipEX2 B sends repeated packet to its COM.
RTU B does not react, because the packet is addressed to RTU C.
RipEX2 C and RipEX2 FEP do not send the repeated packet to their COM ports, because it has already been sent (RipEX2 C) or received (RipEX2 FEP) on their COM (anti-duplication mechanism).
RTU C sends the reply packet.

Step 5

RipEX2 C broadcasts the reply packet from RTU C on Radio channel.
Packet is received by RipEX2 A and RipEX2 FEP.

Step 6

RipEX2 FEP sends the packet (the reply from RTU C) to FEP through COM.
RipEX2 A sends this packet to RTU A. RTU A does not react, because the packet is addressed to FEP.
RipEX2 A repeats the packet on Radio channel.
All RipEX2 units receive the packet.

Step 7

RipEX2 B sends repeated packet to its COM.
RTU B does not react, because the packet is addressed to FEP.
RipEX2 C and RipEX2 FEP units do not send the repeated packet to their COM ports, because it has been handled already.
FEP processes the reply from RTU C and polling cycle continues…

5.1.3. Configuration examples

You can see an example of IP addresses of the SCADA equipment and RipEX2 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 RipEX2 Network interface, since it allows for easy local as well as remote service access. Moreover, leaving all RipEX2 units 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).

Bridge mode example

Fig. 5.1: Bridge mode example


Because using the bridge mode makes the radio 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 Settings/Interfaces/Radio/Radio protocol 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 center, they both relay it at the same time. If there is a radio modem which is within the range of both repeaters, it receives both repeated packets at the same time rendering them unreadable.

5.2. Router mode

5.2.1. Detailed Description

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.

5.2.2. Router – Base driven, Detail description

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.

5.2.3. Router – Base driven, Functionality example

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.

Router - Base driven, Functionality example

Fig. 5.2: Router – Base driven, Functionality example

Step 1
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.

Step 2
FEP sends a request packet to RTU A via Base station; Base station transmits packet in shortest possible time. Remote station 1 receives the packet and hands it over to RTU A, simultaneously acknowledging packet receipt to the Base station.

Step 3
RTU A 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.

Step 4
RTU B is connected to Remote station 2 behind Repeater station 1, which manages all communication between the Base station and Remote station 2.

5.2.4. Router – Base driven, Configuration example

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.

Router - Base driven, Addressing

Fig. 5.3: Router – Base driven, Addressing


For those accustomed to using the Flexible Radio protocol:
Settings for radios connected over a Repeater differ considerably in Base driven 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.

Router - Base driven, Addressing - Serial

Fig. 5.4: Router – Base driven, Addressing – Serial

5.3. Combination of IP and serial communication

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:

5.3.1. Detailed Description

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 center 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.