前言

如果要說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調製的基礎上，根據自己的應用場景來玩就好了。