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.