Method of accessing the radio channel may significantly affect the overall reliability of packet transmission. Even in a simple polling-type application, which never generates more than a single packet at a time, collisions may occur when repeaters are used. The goal of channel access is either to eliminate collisions completely, or to reduce their probability while ensuring that systematic repeated collisions never happen. RipEX provides different channel access methods in different modes and optimum configuration can be found for every communication scheme and network layout.
What is so special about collisions that they deserve that much attention? Well, they are a special case of interference (“friendly fire”, a military reporter would say), which may very seriously harm network performance.
A collision happens, when two (or more) transmissions in the network overlap in time. Radio modem A transmits a packet for B, C transmits for D. In well designed network the respective signal levels (i.e. A received at B, C received at D) do ensure error-less reception. For the period of time when these two transmissions overlap, signal from C at receiver input B and signal A at D act as interference signals, reducing the SNR (Signal to Noise Ratio). If B and D are in the same area, the difference in signal strength is small and so is the resulting SNR at both receivers. Consequently the BER (Bit Error Rate) at both receivers jumps to unacceptable level and none of the packets is successfully received. That is the basic principle of a collision.
There are two very harming features of collisions:
The first is a systematic repeated collision. No application generates a totally random traffic pattern. So it may happen (and it does happen), that a certain sequence of packets in a certain network layout generates a collision and it generates this collision repeatedly, in fact always. The result is that certain specific packets are never delivered, regardless of number of retries set at the application level. Imagine a SCADA system never capable of performing one specific task, while all communication tests report that links are in perfect shape. It would be very tempting to blame the SCADA, while the true problem is a systematic collision, i.e. wrong network design. Ways to avoid such collisions are described further in this document.
The second dangerous feature of collisions is just a direct consequence of probability laws. The most effective communication scheme for many applications is the report-by-exception mode, which can vastly reduce the amount of mainly useless traffic generated by polling-type systems. Report-by-exception means though, that collisions can never be ruled out completely, hence a collision-solving system must be an integral part of the protocol in the radio channel (RipEX in router mode provides such protocol of course). Solving a collision means retransmission, typically a delayed retransmission. Consequently the probability of another packet being generated by the application in the meantime increases by the delay, and it increases at both parties involved in the collision. That results in an increased probability of next collision to happen…and so on. This principle makes report-by-exception networks very sensitive to bursty loads. Whenever the load increases over certain limit (we may say “normal” network capacity), number of collisions grows exponentially, reducing the instant network capacity well below normal situation. Series of lost packets and very long delivery times are the result from the application point of view. While the network for report-by-exception application has to be designed to provide maximum capacity possible, it is recommended to take measures to avoid burst load generation at the application level. Limiting the possible load generated by a single device can help to avoid the whole network collapse just because one remote unit goes suddenly “crazy” (e.g. generates hundreds of “exceptions” per second).
In Bridge mode, a packet is transmitted to the radio channel immediately, without any checking whether the radio channel is occupied or not. If other radio was transmitting simultaneously, a collision would occur and both packets would be lost. Consequently Bridge mode can be used only for applications which never generate more than a single message at a time, e.g. master-slave polling applications. Still appropriate measures have to be taken to avoid collisions in special situations.
Repeaters can be used in the Bridge mode in order to extend the radio coverage. Considering the repeated packets, it is necessary to schedule the access to the radio channel to avoid systematic collisions. In a polling-type network, there is a request packet from centre to remote, to which the remote responds immediately. When a remote receives the request directly from the centre, its immediate response would collide with the repeated request, so it would be never received by the centre – a perfect example of a systematic collision.
Packet header contains information about the number of Repeaters on the route, i.e. how many times the packet can be possibly repeated. This number is decremented when passing through each Repeater. The remote radio modem which receives the packet must delay its own transmission for a period. This delay is calculated from the number of the remaining repetitions, the packet length and the modulation rate in the radio channel. Repeaters always transmit immediately, without any delay.
There are 4 radios in the network operated in the Bridge mode. Everyone can receive each other except Radio 4, which is not able to receive Radio 1 and vice versa. Therefore, in the Radio 3 the Repeater function is turned on, and it mediates the connection between 1 and 4.
First, packet A is broadcast from Radio 1.
Radio 2 receives Packet A and sends it to its COM. In the instant when it starts the reception of Packet A, Radio 2 calculates (from information in the received packet header and from number of repeaters in its own setting) the time delay which is needed for the delivery of Packet A through the repeater (repeaters). When the response from the connected device arrives via COM (Packet B), the Radio 2 postpones its transmission for the delay.
In the meantime, Radio 3 (Repeater) receives Packet A and repeats it to the radio channel immediately. Radio 4 receives the Packet A and then Packet B and sends them both to the COM. Packet B is also received by Radio 3 and immediately repeated. Whenever a radio receives a copy± of the same packet during the calculated delay, it discards it as a repeated packet. Note that the picture does not show all the packets at all the radios.
Repeater is configured in the Settings / Device / Operating Mode menu, for Radio 3 (left) and Radio 1, 2, 4 (right):
The delay period based on number of repeaters solves the collision between a repeated packet and a possible response. When more than one repeater is used in a Bridge-mode network, collisions between repeated packets from different repeaters may occur. These cannot be solved by simple delays, rather a sophisticated anti-collision protocol is required. The RipEX Router mode is recommended to be used in more complex networks with multiple repeaters. Nevertheless if certain conditions on signal coverage (sometimes non-coverage) among repeaters, centre and remotes are met, the Bridge mode for a polling-type application can be used. See the chapter Bridge mode in RipEX Manual.
There is also the Tx delay setting in the menu. It shall be used in Bridge mode if multiple RTUs connected to slave stations reply to a broadcast query from the centre. It is necessary to spread out their replies to the radio channel in terms of time, otherwise a massive collision occurs. It can be achieved by setting the TX delay parameter to an adequate sequence of TX delays (e.g. 0, 100, 200 ms as in the example below) in individual remote RipEXes. The slave RipEXes will enter the radio channel successively and no collisions will occur.
Note: The TX delay applies to every packet that is sent out to the radio channel.
The Centre broadcasts request and the RTUs 1, 2 and 3 generate the response and send it out to their respective RipEX.
Radios 1, 2 and 3 have the TX delay parameter set to 0, 100 and 200 ms, respectively. Therefore, Radio 1 starts transmitting just after reception of the frame from COM port. Upon 100 ms later, when Radio 1 has completed transmission, Radio2 starts transmitting. Finally, 200 ms after the reception of the packet from RTU, Radio 3 starts its transmission. All three responses are thus sequentially sent to the Centre and no collision happens.
The TX delay parameter coresponds to multiples of maximum packet length expected and shall be set in miliseconds. The packet transmission time through radio channel can be calculated as follows:
t = (n + 12). 8/(b . fec)
|– time needed for the packet transmission|
|– number of bytes transmitted (consider the longest possible reply from RTU)|
|– Modulation rate|
|– Forward Error Correction|
This calculation gives approximate results ( ± 3ms). When more accurate calculation is necessary, please check the calculation tool on Racom web pages http://www.racom.eu/eng/products/radio-modem-ripex.html#calculation
TX delay is configured in the Settings / Device / Operating Mode menu, for Radio 1 (left) and Radio 2 (right):
The COM port in Bridge mode can be switched into the Stream mode. In any other mode, a packet/frame coming to RipEX over any interface has to be received completely before any further processing. In Stream mode the incoming bytes are transmitted to radio channel with minimum possible delay, byte by byte. Consequently nor checks neither processing of the data can be done. All the bytes are simply broadcast to the radio channel and every radio modem which can receive them forwards them immediately to its COM port(s).
Obviously there can not be any repeaters in the Stream mode and no measures against possible collisions can be taken. The responsibility for collision-free communication remains solely with the application. Consequently only simple master-slave polling-type applications, which never respond to broadcasts, can use the Stream mode. This mode should be used solely in applications which would not work when the normal store-and-forward regime is used because of the inevitable delays involved.
The Stream mode is configured in the Settings / Device / Operating Mode menu:
The protocol in the radio channel in the Router mode of RipEX uses sophisticated method to prevent and solve collisions. When a data packet with RSS above the configurable threshold or a data packet destined for the RipEX itself are received it leads to the „busy channel“ state, as well as the RipEx’s own transmission.
When RipEX evaluates the channel as free, it calculates the Access period – time for which it has to continue monitoring the channel before starting a transmission. Only when the channel stays free for the Access period or more, RipEX starts transmitting whenever a packet destined to radio channel arrives. If channel gets busy, the arriving packets have to wait in a queue and whole process starts from the beginning.
The Access period calculation follows quite complex algorithm, which takes into account RipEX settings, properties of the last packet sent or received and there is – very important – random element. The result is an optimum performance of RipEX’s in a report-by-exception network.
When report-by-exception application or multiple-master polling-type one loads the network, collisions can not be avoided completely despite the sophisticated channel access method used. Then a collision-solving algorithm becomes equally important.
The standard protocol feature of sending an Acknowledgement (ACK) to every data packet and retransmitting it when no ACK comes takes care of all possible reasons for packet non-delivery, collisions included. However retransmitting a packet increases the network load and so increases the collision probability. Moreover, it is possible to create a systematic collision by e.g. a regular retransmissions after the initial random collision. Thus the calculation of the retransmission time-out requires a sophisticated approach again. RipEX uses its settings, packet parameters, sequence number of the retransmission and the necessary random element to calculate the time-out.
Retransmission feature is enabled by selecting “On” in the ACK listbox. By deciding on number of Retries you define the very important compromise between the longest possible delivery time and the probability of a packet being lost. Note that this setting does not normally affect the typical (most probable) delivery time in the network, since a typical packet is delivered without retransmissions.
Most applications require their data to be delivered completely and error-free, hence there are message retransmissions at the application level. Note that the RF protocol (i.e. RipEX’s) retransmissions are always more effective than the application ones, since the radio modem can use more information from the channel when calculating the retransmission time-out. Moreover, when repeaters are involved, retransmitting over a single hop is always faster (and has a greater chance to succeed) than retransmitting over the whole path. Consequently a reasonable approach is to set application time-out to maximum value possible and use an adequate number of Retries in RipEX’s in the network. Though the application engineers may find it difficult to understand, such setting will make the application run faster.
There are few exceptions and hitches though. There are applications which rather send a fresh data instead of simply retransmitting the original message. In such case, depending on the frequency of fresh data from the application, the Retries should be set to 1 or ACK switched off completely. Sometimes the application is hard-wired and the retransmission time-out cannot be changed – then it is better to minimize or switch off RipEX’s retransmissions again. The trickiest case is when the application centre generates messages to non-existent or switched-off remotes (for any reason). When a remote site is without power (including the RipEX) and the centre continues sending requests to that remote, the last repeater will keep retransmitting these requests for full number of Retries set. More importantly, a long retransmission time-out at the application level is not desirable any more, since it keeps the centre from continuing the polling cycle. Nevertheless in any case it is beneficial to keep the number of application retransmissions at the lowest setting available, i.e. zero if possible, and leave the RipEX network to use the time available for the possible retransmitting.
To calculate the typical and maximum possible delivery time for different settings, please use the calculator on Racom web pages, http://www.racom.eu/eng/products/ripex.html#calculation
The parameters discussed above are configured in the Router operating mode menu. Kindly see the Help pages for further information.