~ How CSMA protocols and backoff and retry mechanisms help keep data traffic flowing on a multi-point wireless network ~
Wireless telemetry systems are a crucial tool for plant-wide monitoring and control applications, but site managers often have trouble identifying what type of system they need and how to manage network traffic. Here Ian McNeilage, engineering manager at wireless telemetry specialist Omniflex, explains the differences between simple master-slave and multi-point wireless systems and how to manage traffic and disruptions in multi-point networks.
There are two fundamental types of wireless networks. The first is a classic master-slave system, typically used when communicating with a top-end system like a SCADA system. The simplicity of these systems makes them easy to manage over a network as you get no signal clashes between devices.
Alternatively, you can get multi-point wireless systems that operate in a peer-to-peer manner and report by exception. Multi-point systems like this are common in applications where you have multiple devices communicating over a large area, instead of reporting to a central point like a SCADA. For example, a reservoir and pump system with several dispersed devices across a site that must communicate with each other.
In these systems, it is possible that multiple nodes will try to communicate with each other simultaneously and cause a signal collision that results in neither signal reaching their destination. The only way the node knows its signal didn’t reach its destination is if it doesn’t get the short acknowledgement message back from the other end.
Managing multi-point wireless traffic
To minimise clashes, these multi-point systems should use carrier sense multiple access (CSMA) protocols that allow all the nodes on the network to listen to the traffic and wait for a gap to send a signal. However, even with CSMA in operation, it is possible that multiple nodes may try to send a signal in the same gap in traffic and create a clash. In these cases, the system should then implement a backoff and retry mechanism.
Retry timings should be randomised as fixed timings are more likely to cause subsequent clashes. Furthermore, it best to set a retry limit of between three and five attempts as any more attempts than that are just needlessly blocking up the network while draining the nodes’ power supply.
Another way of minimising potential clashes is by ensuring there is not an excessive amount of nodes on a network. The more nodes you have, the more likely it is that signal clashes will occur. An effective wireless telemetry partner can advise on the optimal number of nodes for a given network, but as a general rule it is best not to exceed a dozen nodes to help keep traffic manageable.
For example, Omniflex delivers wireless telemetry systems for a wide range of industrial sectors, including utilities, mining, petrochemical, oil and gas and nuclear. It can provide either a simple master-slave system or a multi-point system depending on the given application and advise on network setup. Furthermore, its technology has been optimised to ensure reliable data traffic so any disruptions are minimised.
Omniflex’s wireless protocols contain an inbuilt digipeating feature, which solves the issue of having two devices wanting to communicate with one another when they cannot communicate directly because of lack of line of sight.
For example, node A wants to send a signal to node B where they both have network addresses but are either too far apart or out of line of sight. Here, we add a node C in a high point between them to relay the signal. Then, thanks to the digipeating address being ingrained in the message as part of the protocol, node C automatically knows to relay the signal it receives.
To find out more about Omniflex’s wireless telemetry offering, download its wireless sector overview for free here: www.omniflex.com/pub/downloads/omn264-omniflex-wireless-remote-monitoring-and-control-sector-overview-web.pdf.
