LoRa信道争抢怎么办?传说中的冲突退避管用吗?

前言

如果要说LoRaWAN的缺点，我觉得最大的不足就是：作为一个MAC层协议，它在信道接入这块机制的处理太简单了。

LoRaWAN标准中，终端的信道接入方法是纯ALOHA机制，终端不进行信道检测，直接发送，这样随着终端数量增多或发送包数量增多时，多个终端的包在信道上发生碰撞的概率就大大增加。

IoT小能手在LoRa之前玩了挺长时间的ZigBee，放眼到WiFi，ZigBee等协议底层，他们都不约而同地采用了CSMA-CA技术。哦，这个“不约而同”用地并不好，本质上他们都是IEEE协会出的标准，工作组之间相互借鉴下成熟的东西，是挺正常的一回事。

你看这些协议都在关键部分就把信道接入给提出来了。

CSMA-CA

我们就来看看CSMA-CA是什么东西。

如下一段是摘抄自 IEEE802.15.4-2006 标准文档。

The IEEE 802.15.4 LR-WPAN uses two types of channel access mechanism, depending on the network configuration. Nonbeacon-enabled PANs use an unslotted CSMA-CA channel access mechanism, as described in 7.5.1. Each time a device wishes to transmit data frames or MAC commands, it waits for a random period. If the channel is found to be idle, following the random backoff, the device transmits its data. If the channel is found to be busy following the random backoff, the device waits for another random period before trying to access the channel again.

所以，CSMA-CA算法是怎么回事呢?

简单说就是分两步，第1步是对信道进行检测，检测信道忙闲，当信道空闲时进行发送；第2步是在信道忙时进行延时退避，延时到后再检测，如果检测还忙，则再进行退避，退避时间根据重试次数而指数倍增加。

这确实对提升数据单次传输的可靠性有一定的帮助，CLAA(中国LoRa应用联盟)的协议标准中也推荐了CSMA-CA算法。（利益声明：联盟秘书长和我是微信好友）

duty-cycle

难道Semtech、IBM、Actility这些通信专家就没想过这些问题吗?

在官方协议的地区参数文档中就做了声明，但是不明显。细心如本尊twowinter，也是在翻了第十二遍协议文档时，才发现了这段话。

为了满足ETSI 868的标准，LoRaWAN协议采用了其中的duty-cycle机制来处理，而放弃了 Listen Before Talk 机制。

duty-cycle的吐槽

说起duty-cycle机制，不知道在座的各位用过没有。反正我用着挺蛋疼的，每次都要费尽口舌给别人解释一番。场景是这样：

“小能手，为什么我现在发不了数据了?”
“因为你刚才的数据发了2秒钟，根据1%的duty-cycle限制，你接下来得等198秒后才能再发。”
“哇靠，what the f***!”

低功耗广域网领域目前还有一家躁动的公司Ingenu，它也深深地吐槽了LoRa的duty-cycle处理。(Ingenu取名源自英文足智多谋“ingenuity”，不少人读作“英格努”，我觉得还不够贴切，应该读作“英巨牛”。注意，twowinter我是认真的，不信可以去看英标。)

Ingenu的官网比较热血，如果你像我一样顶着产品经理的头衔，没事去找些无聊资料的话，就会在白皮书位置看到英巨牛对LoRaWAN和Sigfox的公开嘲讽，《LoRaWAN给你准备的九大惊喜》、《Sigfox给你准备的八大惊喜》。

在《LoRaWAN给你准备的九大惊喜》中，发现第一个惊喜就是对LoRaWAN duty-cycle的吐槽。

LoRaWAN的考量

行文至此，twowinter陷入了沉思，LoRa接下去的路究竟该怎么走。。。

想着想着，似乎化身成了LoRa技术委员会主席 Nicolas Sornin。画面切到2014年，为了制定协议标准而进行了多日唇枪舌战的那个夏夜。

“Listen Before Talk这种信道争抢方式，确实对数据可靠性有一定帮助，但各位刚才也提到了，这种随机延时会增加若干个接收窗口，增大功耗。我想这是一个取舍的问题，我们是什么技术，低功耗广域网技术，低功耗这三个字可是写在最前头啊。所以各位，数据可以丢，电池要保住！

还有一个尤为重要的地方，是我强烈支持采用duty-cycle的原因。在座的各位已经投入了非常多的财力物力到这里，可以说我们是一条船上的人。LBT的竞争性，不确定性让我感到不安，duty-cycle是让人放心的，即便有天网络瘫痪，duty-cycle可以让这个世界像没发生过。我们的LoRaWAN是奔着广域网的大目标去的，相比于ZigBee、WiFi这些小型网络，它的考量应该是更慎重一些。”

前面这个臆想画面纯属玩笑，但我想LoRaWAN很可能真的是从功耗和网络稳定性这两个角度去考虑，所以才采用duty-cycle信道接入方式。

后记

如果想要保证单次传输的可靠性和及时性，那还是可以考虑用下CSMA机制。毕竟LoRa技术的自由度很大，玩家在LoRa调制的基础上，根据自己的应用场景来玩就好了。