Protocol version selection?

[danak6jq]

Has any thought been given to providing build-time (or, in a Utopian world, init-time) selection of LoRaWAN protocol version? (V1.0.3 vs 1.0.4/1.1 ?) Is this a case of simply "it's a lot of work" vs "it's a bad idea" ?

I appreciate there's another wrinkle there, more like a major fissure, with regional parameter selection, but let's not talk about that until exploring why or why not version selection is offered?

Thanks -
Dana

[janakj]

What would be the benefit of selecting, say, 1.0.3 instead of 1.0.4? Why would you want your devices to speak 1.0.3 if 1.0.4 is available and backward compatible? Protocol version negotiation is a hard problem in general, not only in LoRaWAN, but in other networked systems as well.

LoRaWAN has rudimentary 1.1/1.0 negotiation where the device indicates whether it supports LoRaWAN 1.1 in a Join request and the network server selects the the protocol version to be used during the session based on the device's indication and the device's profile in the network (manual configuration). This was probably meant to give the devices an easy upgrade path to LoRaWAN 1.1, with a fallback to 1.0 if that doesn't work. But this is only available in OTAA mode. The ABP mode has no negotiation and you need to configure the same protocol version on both sides.

Apart from 1.1/1.0 protocol selection, LoRaWAN has no mechanism (protocol fields) to indicate to the remote side which protocol version the device supports. So, even if the device supported 1.0.3 and 1.0.4 simultaneously, you would still need to manually configure matching values in the device and on the network server. But since minor protocol versions are meant to be backward compatible, this is probably not all that useful.

Supporting multiple protocol versions in the device requires multiple versions of the MAC. LoRaMac-node already does that for 1.1.1 and 1.0.4, which are supported simultaneously. That way, you always have the most recent 1.0 version and the most recent 1.1 LoRaWAN version.

Adding compile-time or init-time minor protocol version selection would be technically feasible, but the cost of doing so probably outweights the benefits. The developers would need to maintain an increasing number of MAC revisions and test (certify) them all. And without over-the-air protocol negotiation, you have one more knob on the device to get right, making a bad situation worse. You not only have to select the right protocol version in the network server, you also have to select it in the device now.