Network Tuning

RIIM comes already configured with settings that will work for most use-cases. However, RIIM also provides tools and settings for tuning network performance. Network tuning is complicated, and care must be taken to ensure stability. No setting exists that’s suitable for all topologies or traffic patterns, and applying the wrong one could lead to degraded performance or the network stop working altogether. Radiocrafts support may also help you with your specific use-case.

All the settings are accessible in the RIIMConfig struct defined in UAPI_Node.h

TSCH parameters

Warning

Network.setTSCHParameters is deprecated. Use Node.SetCurrentConfiguration instead.

The SDK provides preset TSCH parameters that can be used direcly using Network.setTSCHParameters. The presets are defined in the header file UAPI_Network.h in the SDK, and each preset consists of 4 numbers as shown here:

#define TSCH_LOW_POWER                      0,29,43,67
#define TSCH_LOW_POWER_150kbps              0,59,83,137
#define TSCH_BALANCED                       0,17,31,23
#define TSCH_LOW_LATENCY                    0,9 ,31,23
#define TSCH_HIGH_THROUGHPUT_SENSOR_DATA    1,17,31,23

Warning

For a network to function properly, all nodes must have the same settings.

Note

All numbers should normally be prime numbers and never be the same number as any other. This is to avoid the problem of having frequent collsions between unicast, shared and EB-slots as only one message can be sent in any one timeslot.

Active or Passive Mode

The first number specifies if the network is to operate in active or passive mode, and can be 0 or 1. Networks in passive mode only listens in a subset of TSCH slots, while in active mode they listen in all slots. This means that a network in active mode supports higher throughput and lower latency, but may use several times the amount of power that a passive network does.

Warning

This parameter can only be set in RIIM_SETUP before starting the network. Once set it can’t be changed.

Unicast Slotframe Length

The second number specifies the length of the unicast slotframe. The lesser the value, the more often any given node is able to send a unicast message. This can lower latency and increase throughput, but can also lead to more packet collisions, more overlap between unicast, shared and EB-timeslots. This can in turn lead to congestion and higher packet loss. Also, lower numbers increases the node’s power usage.

Shared Slotframe Length

The third number specifies the lengt of the shared slotframe. The lesser the value, the more often the node are able to send multicast/broadcast messages. Lesser values can help with multicasts and joining times in sparse networks, but can also lead to timeslot collisions and congestion if tuned too aggressively. Also, lower numbers increases the node’s power usage.

Enhanced Beacon (EB) Slotframe Length

The fouth number specifies the length of the EB slotframe. The lower the number, the more often a node is able to send enhanced beacons. This can help with joining and updating settings through the network, but also increases power usage and the probability of timeslot collisions.

Control Packets and Join Times

DIO Interval

DIOIntervalMin and DIOIntervalMax defines the minimum and maximum DIO interval respectively. The time unit is in milliseconds. DIOs (DODAG Information Objects) are used to exchange information between nodes, for instance during joining. The lower the interval, the faster information will be excanged, but may cause congestion in dense networks and when many nodes wants to join at the same time.

Note

DIO Interval is increased by doubling the last value. Therefore DIOIntervalMax should be some doubling of DIOIntervalMin. For example: DIOIntervalMin can be 100, while DIOIntervalMax can be 1600 (4 doublings of DIOIntervalMin).

DAO Delay

DAODelay sets the delay from a node is associated with a parent until a DAO is sent to the Border Router. DAOs (Destination Advertisement Objects) are sent from a node to the Border Router to notify about its new intended parent. In response, the Border Router sends a DAO-ACK as a response to the node with the response to the request. Lower delays will enable faster joining, but may cause network congestion if many nodes are joining simultaneously.

Multicast

MPL Control Messages

MPL control messages are used to synchronize and help multicast messages to be received by all nodes. When MPL control messages are sent is controlled by trickle timers. Trickle timers are described in detail here: https://www.rfc-editor.org/rfc/rfc6206 . In RIIM, the user can set the IMin, IMax and K parameters.

MPL Data Messages

MPL data messages are used to transfer the actual data between nodes when using multicast. In multicast all nodes tries to forward the packet two times. This number is not configurable in ICI. This forwarding of multicast packet is called proactive.

The time before forwarding is given by IMin and IMax, with some randomization added.

IMin is number on milliseconds before retransmitting first time.(default = 12500 in TSCH and 650 ms in single channel) IMax is number of times IMin is doubled. (default =1)

In dense network with many nodes all nodes will try to forward and this can cause congestion. In MPL each node can be muted if it hear other neighbor forward the same message. The value “K” controls this. Default = 1, which gives a careful/slow forwarding with low probability of congenstion. K up to 4 has been verified to work. This give quicker flooding of the network.

MPL Control Messages

In addition to the flooding the MPL also have a mechanism for nodes to compare latest multicast packet number and if one node is one packet number ahead of the other, this packet is forwarded. This is a called a reactive forwarding. This process is slower than the proactive forwarding. But it adds reliability in case of rare multicasting.