Configure Radio filters in all your networks utilizing Babel protocol via the Radio channel. Why?Neither Babel nor other dynamic routing protocols can take RSS/MSE values into account. In most of the networks, some links have very good RSS and MSE values running high QAM modulations. Links with (very) bad RSS/MSE values should not be used for routing user traffic in case there are links with higher quality. Without the Radio filter, short Babel management/overhead data may be able to successfully go through such links, but important user traffic might be corrupted resulting in unreliable SCADA operation.

Babel itself has a known mechanism of Hello packets and increasing link metrics based on Hello packets success rate of going through particular links. We enhanced this behaviour (proprietary) so that some of the Hello packets are discarded if received with RSS or MSE values below set thresholds.

Default thresholds are:

If the RSS/MSE values of received Hello packet is worse than the “Hard” limit, it is always discarded. In case the RSS/MSE values are better than “Soft” thresholds, they are always accepted.

If the values are between thresholds, Hello packets are discarded randomly with probability increasing linearly between Soft and Hard limits. The probability of a Hello packet being received by the filter is calculated as the product of the probabilities based on RSS and MSE. If at least one of the variables exceeds the Hard limit, the packet is always discarded. The limit setting is either global or individual for each Hello packet source address (radio IP address). The individual setting is only used if there is a translation of the link address to a radio IP address (ARP request/reply for the given IP had to be sent/received so that you don’t see 0.0.0.0 Radio IP within the Statistics menu, but a correct IP for a given Link address). Discarding a Hello packet will cause the Babel protocol metric to be increased and the link to be disadvantaged.

Keep in mind each modulation has its own sensitivity levels. If you combine multiple modulations within the network, individual link thresholds are recommended.

Sensitivity levels (RSS) can be read from the Specification.

MSE recommendations can be read within the application note on RACOM website.

Let’s see one example. In the whole network, we run the QAM modulation π/4-DQPSK, within the 25 kHz channel. The sensitivity level (for BER 10^-6) is -111 dBm. Recommended MSE is -14 dB.

Default thresholds could be:

Received Hello packets’ RSS/MSE values and its operation:

Let’s imagine we have one unit and it has at least two neighbors (10.10.10.2 and 10.10.10.3 are the neighbors’ Radio IP addresses). For the neighbor ‘2’ the modulation is set to 64QAM, for the neighbor ‘3’ the modulation is ‘256QAM’. We set two individual thresholds, e.g.:

Further optimization can be discussed with our technical support team via support@racom.eu.

Within the example topology we utilize 25kHz channel and 16DEQAM modulation. We do not set any Individual thresholds, in case you need them, check the information above. Default thresholds in all four units will be set to

Fig. 2.1: Default Radio filter thresholds for 16DEQAM

Save this change in all 4 units.

Check the Babel Status after a while. Based on your conditions, you may see similar output.

Fig. 2.2: RipEX_D Babel routing

Within our example output, signals to 10.10.10.2 and 10.10.10.3 are better than configured thresholds, but signals to 10.10.10.1 are between the soft and hard thresholds, i.e. we only got 10 out of 16 Hello packets correctly and the direct metric is now 256. It is still the lowest metric so the direct radio link is used.

Based on Statistics, MSE values are better than the soft threshold, but signals to 10.10.10.1 are in average -83 dBm which is close to soft threshold, but worse. The minimum measured signal is even -89 dBm. This is the reason why some of the Hello packets are discarded and the metric is higher.

Fig. 2.3: RipEX_D Radio signal statistics

Discarding is based on probability so once you check the Status again, it can be different, e.g.:

Fig. 2.4: RipEX_D Babel routing, #2

Important

Individual thresholds can be taken into account only if the IP address is known and correct Link address and IP address translation has been done. Check your Statistics. For each remote you only see 0.0.0.0 as the IP address, the default thresholds are used. Once there is any communication with a particular IP address, ARP data are exchanged and the IP address is known afterwards. In case there is regular traffic with all the neighbors (SCADA, …), the IP addresses are always known, but there might be multiple other sites within the radio coverage (visible in Statistics), but with no user traffic resulting in only Link addresses within Statistics and IPs being 0.0.0.0.

Fig. 2.5: Unknown IP addresses for Link addresses

Relay filters can be used for

In case the unit is not supposed to propagate any obtained routes further, so it serves as the end-station (terminal, not repeater), you can reject all rules to be propagated/relayed.

Just go to the SETTINGS > Routing > Babel > Relay filter menu and change the policy to “Reject”.

Fig. 2.6: RipEX_D filter policy set to “Reject”

Until this change, e.g. the RipEX_A could have similar Babel routes.

Fig. 2.7: RipEX_A Babel routes

We can see RipEX_D (10.10.10.4) is also used as a gateway for 192.168.3.0/24 (RipEX_C). If we set that Reject policy in RipEX_D, no rule will not be propagated from RipEX_D to other units except its own configured subnets.

Fig. 2.8: RipEX_A Babel routes after setting RipEX_D to reject relay policy

You can also increase metric for the routes being propagated, e.g. to disadvantage particular repeater. Let’s set RipEX_C (10.10.10.3) to increase metrics obtained from this repeater by 100.

Fig. 2.9: RipEX_C Relay filter to increase metric by 100

We can see similar output in neighbouring units, e.g. from RipEX_D.

Fig. 2.10: RipEX_D Babel routes with higher metrics via 10.10.10.3

Routes to 192.168.1.0/24 and 192.168.2.0/24 via 10.10.10.3 have the highest metric. Direct route to its own subnet 192.168.3.0/24 is not disadvantaged this way, as required/configured. If you need to increase the metric of this direct path as well, do it via Static rules tab of Babel menu and increase the “Metric” parameter for the given Destination IP/mask.

Last, but not least, is to limit just some of the propagated routes, not all, via the “Reject” Relay filter policy. Go to the RipEX_D again and change the Policy to “Accept”, but let’s reject propagating 192.168.2.0/24 and 192.168.3.0/24 networks. I.e. the unit will only propagate 192.168.1.0/24 (and of course its own subnet, but this not controlled by the Relay filter).

Fig. 2.11: RipEX_D Relay filter – rejecting 192.168.2.0/23 subnets with /24 mask

We know we should receive 192.168.2.0/24 and 192.168.3.0/24, i.e. /24 mask in both cases. We can limit the Mask from/to parameters to suit our scenario. We could also have two individual rules or do it via a single rule using /23 mask.

The default policy is “accept” so the 192.168.1.0/24 network will be propagated.

Fig. 2.12: RipEX_C Babel routes without 10.10.10.4 for 192.168.[2-3].0/24 networks

RipEX_C does not use 10.10.10.4 as a gateway to reach 192.168.2.0/24 and 192.168.3.0/24 networks. Obviously, it uses the gateway to reach 192.168.1.0/24 and 192.168.4.0/24.

	Note
	If you configure Babel routing for the fist time in your network, it is suggested to reboot each device after final configuration changes so the dynamic protocol is fully restarted in all units with correct and current configuration.

Sure, you can combine all the options in every unit within the whole network to suit your requirements.

Further optimization can be discussed with our technical support team via support@racom.eu.