What communications media will Lucid operate over?

During the development of the Lucid protocol, one question we were often asked, was whether Lucid would work over a particular type of communications media, for example a serial line, mobile, ethernet or satellite. This article is an attempt to answer that question.

A quick review of Lucid communications

The Lucid protocol uses MQTT to allow Field Devices (FDs) to exchange messages with Supervisory Applications (SAs). MQTT is typically based on TCP/IP, so Lucid is expected to work over all TCP/IP based media types. This is in keeping with other IoT (Internet of Things) and IIoT (Industrial Internet of Things) devices, as the “Internet” term in their names is synonymous with the general internet, which is firmly TCP/IP based; so Lucid needs TCP/IP.

In the discussions below, we will be concentrating on the link between the FD and the MQTT broker and not the link between the SA and the MQTT broker. This is because it is on the remote FD side that we expect to see the various communications media in use. The SA to MQTT broker link is expected to be serviced by highly capable TCP/IP communications.

If you wish to use security with Lucid, then you will have to use TLS (Transport Layer Security) as described in Section 8 of the protocol specification (v3). This cryptographic protocol sits above TCP/IP and below MQTT, as shown in following diagram.

The diagram shows a simplified view of the communications stack for Lucid. The optional TLS layer will add extra messages to the creation of the link between the end device and the broker and will therefore increase the number of messages in the communications. Depending upon how much information the device is sending, this may be a very small percentage increase or a more significant percentage increase.

The size of messages and the bandwidth used to send messages is another consideration when determining if Lucid will work over some communications media. As one might expect, there is not a “one size fits all” answer to this question. Some very simple devices may send very little information and not engage in conversation, whilst other more capable devices may use much more data. In general, most media which supports TCP/IP would be expected to be able to handle the traffic coming from a normal Lucid device.

In Lucid version 3 an MQTT payload based on JSON is used, which can lead to larger messages. JSON was chosen, rather than encoding in binary, for readability reasons. The JSON encoding has been kept efficient to keep the sizes of the messages as small as practicable; the protocol also supports compression where this is required.

Lucid does not impose any strict latency requirements; however, if messages do take a long time to arrive then this will extend the time that the communications equipment is switched on, thereby increasing power use at the FD, and reducing battery life. In general, if a communications medium is capable of supporting TCP/IP then Lucid should work regardless of latency, assuming that latency does not give problems to the TCP/IP channel.

The broad conclusion from the above is that, if TCP/IP works over the communications channel, then it is highly likely that Lucid also will.

What media does Lucid work over?

The following is a list of communications media over which Lucid has been shown to work:

• Ethernet
• ADSL/DSL/Broadband
• Mobile – 2G, 3G, 4G and 5G
• LTE-M including Cat-M1
• NB-IoT including LTE Cat NB1

The following is a media type over which we fully expect Lucid to work but which has not yet been practically proven:

• Satellite – In 2018, the operation of WITS-DNP3 working over Satellite was demonstrated; this is heavier protocol than Lucid and so it is fully expected that Lucid will work over some forms of satellite links.

What media does Lucid NOT work over?

The following is a list of media over which Lucid is not expected to work, including the reasons why we think this is the case:

• Serial – Serial, such as RS232 or RS485 does not normally support TCP/IP and will therefore not support Lucid.
• SigFox – Sigfox has a very low expected bandwidth and does not permit TCP/IP; it will therefore not support Lucid.
• LoRa / LoRaWAN – Lora and LoRaWAN, although supporting a higher bandwidth than SigFox, it does not use TCP/IP either and so is not likely to support Lucid.

It is possible that there are current adapters, converters or new developments in these technologies which will eventually permit aspects of them to work. If that happens and operation of Lucid on those media can be demonstrated, then we will update this article to show the new status.

Looking to the future

A variant of MQTT, called MQTT-SN, is being investigated to see if this will permit Lucid to run over interfaces that are more serial in nature (for instance RS-232, RS-485) in a future version of the standard. It is fully expected that this will be the case, however it is not currently built into version 3 of the protocol.

The genesis of Lucid was from WITS-DNP3. The functions and semantics of the interface were lifted away from the binding to the DNP3 interface and repurposed for MQTT. The WITS technical group believe this same operation could be done again in the future to utilise other IoT like interfaces, for instance CoAP; however, this has not been done at present.

Summary

In this article we have examined the communications requirements of Lucid and then discussed which types of communications media Lucid can utilise. We have also highlighted a few media types where we do not expect Lucid to work.

If this article has piqued your interest in Lucid, you can read more on the Lucid website, or consider joining WITS so that you can attend face to face meetings and get involved with the community developing Lucid.

Mark Davison (Terzo Digital) and Dave Howarth (NWL)

May 2025

Terzo Digital and NWL have collaborated on a number of articles about Lucid in support of the protocol. You find find a list of those articles with a brief summary of their contents here.