Specifications

10.4. Router Mode

10.4.1. Channel access in Router mode

The protocol in the radio channel in the Router mode of RipEX uses several methods to prevent and

solve collisions. The first is Listen Before Transmit. Not a simple CSMA (Carrier Sensing Multiple Ac-

cess), but a sophisticated LBT with configurable threshold. Only a valid data packet with RSS above

threshold or a data packet destined for the RipEX itself is evaluated as a busy channel. RipEX's own

transmission is regarded a busy channel as well.

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 ar-

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

10.4.2. Solving collisions in Router mode

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 retrans-

mitting it when no ACK comes takes care of all possible reasons for packet non-delivery, collisions in-

cluded. 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 sophist-

icated approach again. RipEX uses its settings, packet parameters, sequence number of the retrans-

mission 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 probab-

ility 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, re-

transmitting 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

Channel access