WaveCom Open AT plug-in for IBM MQTT

Before Sierra Wireless acquired WaveCom, there supposedly was a IBM MQTT client available as a plug-in for Open AT.
See fargotelecomasia.com/Product … ug-Ins.pdf.

Does anyone know where I can find this plug-in or else has Sierra Wireless completed an MQTT 3.0 client for Open AT? I can’t seem to find any information about MQTT clients for Open AT on the developer.sierrawireless.com site. There does seem to be cloud-based MQTT broker support which has been added to SW AirAdvantage cloud services, but alas no mention of clients. Perhaps someone may have implemented an Open AT client for the Paho MQTT C Client (see mqtt.org).

Cheers,
Gord

P.S. I’m looking to support MQTT in an Open AT application on a Sierra Wireless SL Series 8081 3G modem module (Maestro M100 3G oem version).

There’s no readily available MQTT port for Open AT as far as I know. Your best chance would probably be to port Paho.

MQTT is designed with a permanently on TCP connection in mind, and doesn’t work great otherwise. You can rarely afford such an always-on connection over GSM/3G, for bandwidth and battery consumption reasons. Could you tell more about your use case?

I don’t think so:

I seem to remember Andy Stanford-Clark saying he’d had it going over SMS…?

You can tweak it to run on whatever you want indeed, but is it still MQTT, if it’s not inter-operable with off-the-shelf MQTT-compliant software?

If we go back to “what problems MQTT solves?”, it’s a protocol that lets you choose what data subset is sent to which server, and where the data producer notifies the consumer about monitored value changes without need for an explicit poll from the monitoring app [1].

The central no-polling feature doesn’t work if the TCP connection isn’t kept open, and it can be especially tricky to hack around if there’s a NAT between the client and the server (as is frequently the case on wireless networks).

Security is left to TLS: that’s a one-off bandwidth and computation cost if you keep the connection open, so it’s OK; but if you need to reconnect, i.e. pay the TCP handshake overhead + TLS handshake overhead every time the device uploads data and polls for commands, you’ll typically spend most of your bandwidth budget on overheads. DTLS fares better, as it runs over UDP and there’s no such thing as a “UDP connection life-cycle”; but putting MQTT over DTLS would be a rather extensive hack, and the result wouldn’t be compatible with anything else.

The bottom line is, since MQTT doesn’t specify its data serialization protocol (although JSON seems the most frequent choice), if your subscription model is “push everything collected to the same unique server”, and you need to disconnect between uploads, you’re left with something that doesn’t perform better than HTTP.

OTOH, putting an MQTT broker on the device, to consolidate data sent locally by a swarm of IoT sensors, then send that back through a big-dumb-pipe to a server such as AirVantage’s, where it’s consolidated across sites, and accessible through HTTP/REST APIs for regular web developers, makes a lot of sense.

[1] Well I’m lying by omission: it also allows you to claim, albeit quite deceptively, that you use an “IoT protocol”, whatever that means out of press rooms.