Lorawan協(xié)議說明書

1、第1章介紹本文檔描述了 LoRaWAN網(wǎng)絡(luò)協(xié)議，是針對電池供電的終端設(shè)備（不管移動(dòng)還是固定 位置）進(jìn)行優(yōu)化的一套網(wǎng)絡(luò)協(xié)議。LoRaWAN網(wǎng)絡(luò)通常采用星型拓?fù)浣Y(jié)構(gòu)，由拓?fù)渲械?網(wǎng)關(guān)來轉(zhuǎn)發(fā)終端與后臺(tái)網(wǎng)絡(luò)服 務(wù)器間的消息。網(wǎng)關(guān)通過標(biāo)準(zhǔn)IP連接來接入網(wǎng)絡(luò)服務(wù)器，而終端則通過單跳的LoRa 或者FSK來和一個(gè)或多個(gè) 網(wǎng)關(guān)通訊。雖然主要傳輸方式是 終端上行傳輸給網(wǎng)絡(luò)服務(wù) 器，但所有的傳輸通常都是雙向的。終端和網(wǎng)關(guān)間的通訊被分散到不同的信道頻點(diǎn)和數(shù)據(jù)速率上。數(shù)據(jù)速率的選擇需要 權(quán)衡距離和消息時(shí)長兩個(gè)因素，使用不同數(shù)據(jù)速率的設(shè)備互不影響。LoRa的數(shù)據(jù)速率范圍可以從0.3kbps到50kbps。為了最大程度地

2、延長終端的電池壽命和擴(kuò)大網(wǎng)絡(luò) 容量，LoRa網(wǎng)絡(luò)使用速率自適應(yīng)（ADR）機(jī)制來獨(dú)立管理每個(gè)終端的速率和 RF輸出。雖然每個(gè)設(shè)備可以在任意信道，任意時(shí)間，發(fā)送任意數(shù)據(jù)，但需要注意遵守如下規(guī) 定：終端的每次傳輸都使用偽隨機(jī)方式來改變信道。頻率的多變使得系統(tǒng)具有更 強(qiáng)的抗干擾能力。終端要遵守相應(yīng)頻段和本地區(qū)的無線電規(guī)定中的發(fā)射占空比要求。終端要遵守相應(yīng)頻段和本地區(qū)的無線電規(guī)定中的發(fā)射時(shí)長要求。twowinter注：發(fā)射占空比，意思是發(fā)射時(shí)長占總時(shí)長的比例。按照無線電規(guī)定，每 個(gè)設(shè)備不能瘋狂發(fā)射霸占信道，總得給別人一點(diǎn)機(jī)會(huì)。這份文檔主要講述協(xié)議細(xì)節(jié)，一些基于各地區(qū)規(guī)定的操作參數(shù)，例如發(fā)射占空比和 發(fā)射

3、時(shí)長等，在另一份文檔LoRaWAN地區(qū)參數(shù)中做具體描述。將這份文檔分開， 是為了加入新地區(qū)參數(shù)時(shí)不影響基礎(chǔ)的協(xié)議規(guī)范。1.1 LoRaWANClasses所有的LoRaWAN設(shè)備都必須至少實(shí)現(xiàn)本文檔描述的 ClassA功能。另外也可以實(shí)現(xiàn) 本文檔中描述的ClassB和ClassC及后續(xù)將定義的可選功能。不管怎么樣，設(shè)備都 必須兼谷ClassAo1.2 文檔約定MAC命令的格式寫作？LinkCheckReq?（粗余體），位和位域的格式寫作？FRMPayload ?（粗體），常量的格式寫作 RECEIVE_DELAY1，變量的格式寫作 N。在本文檔中， 所有多字節(jié)字段的字節(jié)序均采用小端模式 EUI

4、是8字節(jié)字段，采用小端模式傳輸 默認(rèn)所有RFU保留位都設(shè)為0第2章LoRaWANClasses類型介紹LoRa是由Semtech面向長距離、低功耗、低速率應(yīng)用而開發(fā)的無線調(diào)制技術(shù)。本文檔中，將ClassA基礎(chǔ)上實(shí)現(xiàn)了更多功能的設(shè)備稱為更高class終端”。2.1 LoRaWANClassesApplicationLoRa MACClassAClass BClassC(baseline)(beacon)(Continuous)LoRa ModulationLoRa網(wǎng)絡(luò)包含基礎(chǔ)LoRaWAN （稱之為ClassA）和可選功能（ClassB, ClassC）:ApplicationMACMAC op

5、tionsEUEUUSAS868433915430ModulationRegional ISM band圖 1.LoRaWANClasses雙向傳車ft終端（ClassA）: ?ClassA的終端在每次上行后都會(huì)緊跟兩個(gè)短暫的下 行接收窗口，以此實(shí)現(xiàn)雙向傳輸。傳輸時(shí)隙是由終端在有傳輸需要時(shí)安排， 附加一定的隨機(jī)延時(shí)（即ALOHA協(xié)議）。這種ClassA操作是最省電的，要求 應(yīng)用在終端上行傳輸后的很短時(shí)間內(nèi)進(jìn)行服務(wù)器的下行傳輸。服務(wù)器在其他 任何時(shí)間進(jìn)行的下行傳輸都得等終端的下一次上行。劃定接收時(shí)隙的雙向傳輸終端（ClassB）: ?ClassB的終端會(huì)有更多的接收時(shí)隙。 除了 ClassA的隨

6、機(jī)接收窗口，ClassB設(shè)備還會(huì)在指定時(shí)間打開別的接收窗口。 為了讓終端可以在指定時(shí)間打開接收窗口，終端需要從網(wǎng)關(guān)接收時(shí)間同步的 信標(biāo)Beacon。這使得服務(wù)器可以知道終端正在監(jiān)聽。最大化接收時(shí)隙的雙向傳輸終端（ClassC）: ?ClassC的終端基本是一直打開著 接收窗口，只在發(fā)送時(shí)短暫關(guān)閉。ClassC的終端會(huì)比ClassA和ClassB?更加耗電，但同時(shí)從服務(wù)器下發(fā)給終端的時(shí)延也是最短的。2.2 文檔范圍這份LoRaWAN協(xié)議還描述了與 ClassA不同的其他Class的額外功能。更高 Class 的終端必須滿足ClassA定義的所有功能。注意：物理層幀格式，MAC幀格式，以及協(xié)議中更

7、高 class和ClassA相同的內(nèi)容都 寫在了 ClassA部分，避免內(nèi)容重復(fù)。第3章PHY幀格式LoRa有上行消息和下行消息。3.1 上行消息上行消息是由終端發(fā)出，經(jīng)過一個(gè)或多個(gè)網(wǎng)關(guān)轉(zhuǎn)發(fā)給網(wǎng)絡(luò)服務(wù)器。上行消息使用LoRa射頻幀的嚴(yán)格模式，消息中含有 PHDR和PHDR_CRC。載荷有CRC校驗(yàn)來保證完整性。PHDR, PHDR_CRC及載荷CRC域都通過射頻收發(fā)器加入。上行PHY:PreamblePHDRPHDR_CRCPHYPayloadCRC圖2.上行PHY幀格式3.2 下行消息下行消息是由網(wǎng)絡(luò)服務(wù)器發(fā)出，經(jīng)過單個(gè)網(wǎng)關(guān)轉(zhuǎn)發(fā)給單個(gè)終端。下行消息使用射頻幀的嚴(yán)格模式，消息中包含PHDR和P

8、HDR_CRC。下行PHY:PreamblePHDRPHDR_CRCPHYPayload圖3.下行PHY幀格式3.3 接收窗口每個(gè)上行傳輸后終端都要開兩個(gè)短的接收窗口。接收窗口開始時(shí)間的規(guī)定，是以傳 輸結(jié)束時(shí)間為參考甘ansmit-RXi | RX2圖4.終端接收時(shí)隙的時(shí)序圖3.3.1 第一接收窗口的信道，數(shù)據(jù)速率和啟動(dòng)。第一接收窗口 RX1使用的頻率和上行頻率有關(guān)，使用的速率和上行速率有關(guān)。RX1是在上行調(diào)制結(jié)束后的 RECEIVE_DELAY1秒打開。上行和RX1時(shí)隙下行速率的關(guān) 系是按區(qū)域規(guī)定，詳細(xì)描述在LoRaWAN地區(qū)參數(shù)文件中。默認(rèn)第一窗口的速率是 和最后一次上行的速率相同。3.3

9、.2 第二接收窗口的信道，數(shù)據(jù)速率和啟動(dòng)。第二接收窗口 RX2使用一個(gè)固定可配置的頻率和數(shù)據(jù)速率，在上行調(diào)制結(jié)束后的 RECEIVE_DELAY2秒打開。頻率和數(shù)據(jù)速率可以通過 MAC命令（見第5章）。默認(rèn) 的頻率和速率是按區(qū)域規(guī)定，詳細(xì)描述在 LoRaWAN地區(qū)參數(shù)文件中。3.3.3 接收窗口的持續(xù)時(shí)間接收窗口的長度至少要讓終端射頻收發(fā)器有足夠的時(shí)間來檢測到下行的前導(dǎo)碼。3.3.4 接收方在接收窗口期間的處理如果在任何一個(gè)接收窗口中檢測到前導(dǎo)碼，射頻收發(fā)器需要繼續(xù)激活，直到整個(gè)下行幀都解調(diào)完畢。如果在第一接收窗口檢測到數(shù)據(jù)幀，且這個(gè)數(shù)據(jù)幀的地址和MIC校驗(yàn)通過確認(rèn)是給這個(gè)終端，那終端就不必開

10、啟第二個(gè)接收窗口。3.3.5 網(wǎng)絡(luò)發(fā)送消息給終端如果網(wǎng)絡(luò)想要發(fā)一個(gè)下行消息給終端，它會(huì)精確地在兩個(gè)接收窗口的起始點(diǎn)發(fā)起傳輸。3.3.6 接收窗口的重要事項(xiàng)終端在第一或第二接收窗口收到下行消息后，或者在第二接收窗口階段，不能再發(fā)起另一個(gè)上行消息。3.3.7 其他協(xié)議的收發(fā)處理節(jié)點(diǎn)在LoRaWAN收發(fā)窗口階段可以收發(fā)其他協(xié)議，只要終端能滿足當(dāng)?shù)匾笠约凹嫒軱oRaWAN協(xié)議。2梳理解析LoRaWAN第3章，主要是講了接收窗口這回事，只要記住張圖就行。目前RX1 一般是在上行后1秒開始，RX2是在上行后2秒開始。3源碼分析3.1 源碼流程在梳理這章節(jié)的對應(yīng)代碼時(shí)，自己手動(dòng)做了張思維導(dǎo)圖。有時(shí)是這樣，

11、代碼再有層 次感，也不及一個(gè)圖。好，請收下。3.2 發(fā)送完成就開始RX1和RX2延時(shí)staticvoidOnRadioTxDone(void)./Setuptimersif(IsRxWindowsEnabled=true)TimerSetValue(&RxWindowTimer1,RxWindow1Delay);TimerStart(&RxWindowTimer1);if(LoRaMacDeviceClass!=CLASS_C)TimerSetValue(&RxWindowTimer2,RxWindow2Delay);TimerStart(&RxWindowTi

12、mer2);if(LoRaMacDeviceClass=CLASS_C)|(NodeAckRequested=true)TimerSetValue(&AckTimeoutTimer,RxWindow2Delay+ACK_TIMEOUT+ randr(-ACK_TIMEOUT_RND,ACK_TIMEOUT_RND);TimerStart(&AckTimeoutTimer);3.3 接收窗口的射頻處理從上面一步，我們已經(jīng)清晰的知道，對應(yīng)的處理肯定是在OnRxWindowlTimerEvent和 OnRxWindow2TimerEvent 中。？這兩個(gè)接收窗口的處理，會(huì)對速率和信道

13、進(jìn)行設(shè)置，按照 LoRaWAN協(xié)議中文版配套文件地區(qū)參數(shù)(物理層)？中對各地區(qū)的要求分別進(jìn)行處理。比如這個(gè)470的處理，對上行信道對 48取余得到下行信道。RxWindowSetup(LORAMAC_FIRST_RX1_CHANNEL+(Channel%48)*LORA MAC_STEPWIDTH_第4章MAC幀格式LoRa所有上下行鏈路消息都會(huì)攜帶 PHY載荷，PHY載荷以1字節(jié)MAC頭(MHDR)開始，緊接著 MAC載荷(MACPayload),最后是4字節(jié)的MAC校驗(yàn)碼(MIC)。射頻PHY層：Preamble PHDR PHDR_CRCPHYPayloadCRC圖5.射頻PHY結(jié)構(gòu)(注

14、意CRC只有上行鏈路消息中存在)PHY載荷：MHDRMICMACPayload或者M(jìn)HDRJoin-RequestMIC或者M(jìn)HDRJoin-ResponseMIC圖6.PHY載荷結(jié)構(gòu)MAC載荷：FHDRFPortFRMPayload圖7.MAC載荷結(jié)構(gòu)FHDR:DevAddrFCtrlFCntFOpts圖8.幀頭結(jié)構(gòu)圖9.LoRa幀格式元素(即圖58)4.1 MAC 層(PHYPayload)4MICSize(bytes)11.MPHYPayloadMHDRMACPayloadMACPayload字段的最大長度 M,在第6章有詳細(xì)說明。4.2 MAC 頭（MHDR 字段）Bit#7.54.2

15、1.0MHDRbitsMTypeRFUMajorMAC頭中指定了消息類型（MType）和幀編碼所遵循的LoRaWAN規(guī)范的主版本號(hào) （Major）。4.2.1 消息類型（MType位字段）LoRaWAN定義了六個(gè)不同的 MAC消息類型：joinrequest,joinaccept,unconfirmeddataup/down以及 confirmeddataup/down。MType描述000JoinRequest001JoinAccept010UnconfirmedDataUp011UnconfirmedDataDown100ConfirmedDataUp101ConfirmedDataDow

16、n110RFU111Proprietary表1.MAC消息類型 Join-requestandjoin-accept 消息join-request和join-accept都是用在空中激活流程中，具體見章節(jié) 6.2d DatamessagesDatamessagesffl來彳輸MAC命令和應(yīng)用數(shù)據(jù)，這兩種命令也可以放在單個(gè)消息中 發(fā)送。？Confirmed-datamessage® 收者需要應(yīng)答。？Unconfirmed-datamessage接收者則不需要應(yīng)答。？Proprietarymessagesffl來處理非標(biāo)準(zhǔn)的消息格式，不能和標(biāo)準(zhǔn)消息互通，只能用來和 具有相同拓展格式的消息

17、進(jìn)行通信。不同消息類型用不同的方法保證消息一致性，下面會(huì)介紹每種消息類型的具體情況。4.2.2 數(shù)據(jù)消息的主版本（Major位字段）Major位字段描述注意：Major定義了激?5過程中（joinprocedure）使用的消息格式（見章節(jié) 6.2）和MACPayload的前4字節(jié)（見第4章）。終端要根據(jù)不同的主版本號(hào)實(shí)現(xiàn)不同最小版 本的消息格式。終端使用的最小版本應(yīng)當(dāng)提前通知網(wǎng)絡(luò)服務(wù)器。4.3 MAC 載荷(MACPayload)MAC載荷，也就是所謂的 數(shù)據(jù)幀”，包含：幀頭（FHDR）、端口（ FPort）以及幀載荷（FRMPayload）,其中端口和幀載荷是可選的。4.3.1 幀頭（FHD

18、R）FHDR是由終端短地址（DevAddr）、1字節(jié)幀控制字節(jié)（FCtrl）、2字節(jié)幀計(jì)數(shù)器（FCnt）和用來傳輸MAC命令的幀選項(xiàng)（FOpts,最多15個(gè)字節(jié)）組成。Size(bytes)4120.15FHDRDevAddrFCtrlFCntFOptsFCtrl在上下行消息中有所不同，下行消息如下:Bit#76543.0FCtrlbitsADRADRACKReqACKFPendingFOptsLen上行消息如下:Bit#76543.0FCtrlbitsADRADRACKReqACKRFUFOptsLen幀頭中自適應(yīng)數(shù)據(jù)速率的控制 （ADR,ADRACKReqinFCtrl）LoRa網(wǎng)絡(luò)允許終

19、端采用任何可能的數(shù)據(jù)速率。 LoRaWAN協(xié)議利用該特性來優(yōu)化固 定終端的數(shù)據(jù)速率。這就是自適應(yīng)數(shù)據(jù)速率 （AdaptiveDataRate（ADR）。當(dāng)這個(gè)使能 時(shí)，網(wǎng)絡(luò)會(huì)優(yōu)化使得盡可能使用最快的數(shù)據(jù)速率。移動(dòng)的終端由于射頻環(huán)境的快速變化，數(shù)據(jù)速率管理就不再適用了，應(yīng)當(dāng)使用固定的數(shù)據(jù)速率。如果ADR的位字段有置位，網(wǎng)絡(luò)就會(huì)通過相應(yīng)的MAC命令來控制終端設(shè)備的數(shù)據(jù)速率。如果ADR位沒設(shè)置，網(wǎng)絡(luò)則無視終端的接收信號(hào)強(qiáng)度，不再控制終端設(shè)備的數(shù)據(jù)速率。ADR位可以根據(jù)需要通過終端及網(wǎng)絡(luò)來設(shè)置或取消。不管怎樣，ADR機(jī)制都應(yīng)該盡可能使能，幫助終端延長電池壽命和擴(kuò)大網(wǎng)絡(luò)容量。注意：即使是移動(dòng)的終端，可能

20、在大部分時(shí)間也是處于非移動(dòng)狀態(tài)。因此根據(jù)它的移動(dòng)狀態(tài)，終端也可以請求網(wǎng)絡(luò)使用 ADR來幫助優(yōu)化數(shù)據(jù)速率。如果終端被網(wǎng)絡(luò)優(yōu)化過的數(shù)據(jù)速率高于自己默認(rèn)的數(shù)據(jù)速率，它需要定期檢查下網(wǎng)絡(luò)仍能收到上行的數(shù)據(jù)。每次上行幀計(jì)數(shù)都會(huì)累加 (是針對于每個(gè)新的上行包，重傳包就不再增加計(jì)數(shù))，終端增加ADR_ACK_CNT計(jì)數(shù)。如果直到ADR_ACK_LIMIT次上行(ADR_ACK_CNT>=ADR_ACK_LIMIT) 都沒有收到下行回復(fù)，它就得置高ADR應(yīng)答請求位(ADRACKReq )。網(wǎng)絡(luò)必須在規(guī)定時(shí)間內(nèi)回復(fù)一個(gè)下行幀，這個(gè)時(shí)間是通過ADR_ACK_DELAY 來設(shè)置，上行之后收到任何下行幀就要把A

21、DR_ACK_CNT的計(jì)數(shù)重置。當(dāng)終端在接收時(shí)隙中的任何回復(fù)下行幀的ACK位字段不需要設(shè)置，表示網(wǎng)關(guān)仍在接收這個(gè)設(shè)備的上行幀。如果在下一個(gè)ADR_ACK_DELAY上行時(shí)間內(nèi)都沒收到回復(fù)(例如，在總時(shí)間ADR_ACK_LIMIT+ADR_ACK_DELAY 之后)，終端必須切換至H下一個(gè)更彳氐速率，使得能夠獲得更遠(yuǎn)傳輸距離來重連網(wǎng)絡(luò)。終端如果在每次ADR_ACK_LIMIT到了之 后依舊連接不上，就需要每次逐步降低數(shù)據(jù)速率。如果終端用它的默認(rèn)數(shù)據(jù)速率，那就不需要置位ADRACKReq ,因?yàn)闊o法幫助提高鏈路距離。注意：不要ADRACKReq立刻回復(fù)，這樣給網(wǎng)絡(luò)預(yù)留一些余量，讓它做出最好的下 行

22、調(diào)度處理 注意：上行傳輸時(shí)，如果 ADR_ACK_CNT>=ADR_ACK_LIMIT 并且當(dāng)前數(shù)據(jù)速率比設(shè)備的最小數(shù)據(jù)速率高，就要設(shè)置ADRACKReq ,其它情況下不需要。 消息應(yīng)答位及應(yīng)答流程(ACKinFCtrl)收到confirmed類型的消息時(shí)，接收端要回復(fù)一條應(yīng)答消息(應(yīng)答位ACK要進(jìn)行置位) 如果發(fā)送者是終端，網(wǎng)絡(luò)就利用終端發(fā)送操作后打開的兩個(gè)接收窗口之一進(jìn)行回復(fù)。如果發(fā)送者是網(wǎng)關(guān)，終端就自行決定是否發(fā)送應(yīng)答。？應(yīng)答消息只會(huì)在收到消息后回復(fù)發(fā)送，并且不重發(fā)。注意：為了讓終端盡可能簡單，盡可能減少狀態(tài)，在收到confirmation類型需要確認(rèn)的數(shù)據(jù)幀，需要立即發(fā)送一個(gè)嚴(yán)格

23、的應(yīng)答數(shù)據(jù)幀?；蛘撸K端會(huì)延遲發(fā)送應(yīng)答，在它下一個(gè)數(shù)據(jù)幀中再攜帶。 重傳流程當(dāng)需要應(yīng)答卻沒收到應(yīng)答時(shí)就會(huì)進(jìn)行重發(fā)，重發(fā)的個(gè)數(shù)由終端自己定，可能每個(gè)終端都不一樣，這個(gè)參數(shù)也可以由網(wǎng)絡(luò)服務(wù)器來設(shè)置調(diào)整。注意：一些應(yīng)答機(jī)制的示例時(shí)序圖在第18章中有提供。注意：如果終端設(shè)備重發(fā)次數(shù)到達(dá)了最大值，它可以降低數(shù)據(jù)速率來重連。至于后面是否再重發(fā)還是說丟棄不管，都取決于終端自己。注意：如果網(wǎng)絡(luò)服務(wù)器重發(fā)次數(shù)到達(dá)了最大值，它就認(rèn)為該終端掉線了，直到它再 收到終端的消息。一旦和終端設(shè)備的連接出現(xiàn)問題時(shí)，要不要重發(fā)都取決于網(wǎng)絡(luò)服 務(wù)器自己。注意：在重傳期間的數(shù)據(jù)速率回退的建議策略在章節(jié)18.4中有描述。 幀掛起位（

24、FPendinginFCtrl只在下行有效）幀掛起位（FPending）只在下行交互中使用，表示網(wǎng)關(guān)還有掛起數(shù)據(jù)等待下發(fā)，需要當(dāng) 端盡快發(fā)送上行消息來再打開一個(gè)接收窗口。FPending的詳細(xì)用法在章節(jié)18.3。 幀計(jì)數(shù)器（FCnt）每個(gè)終端有兩個(gè)計(jì)數(shù)器跟蹤數(shù)據(jù)幀的個(gè)數(shù)，一個(gè)是上行鏈路計(jì)數(shù)器（ FCntUp）,由 終端在每次上行數(shù)據(jù)給網(wǎng)絡(luò)服務(wù)器時(shí)累加；另一個(gè)是下行鏈路計(jì)數(shù)器（FCntDown ）,由服務(wù)器在每次下行數(shù)據(jù)給終端時(shí)累計(jì)。網(wǎng)絡(luò)服務(wù)器為每個(gè)終端跟蹤上行幀計(jì)數(shù)及 產(chǎn)生下行幀計(jì)數(shù)。終端入網(wǎng)成功后，終端和服務(wù)端的上下行幀計(jì)數(shù)同時(shí)置0。每次發(fā)送消息后，發(fā)送端與之對應(yīng)的FCntUp或FCntDo

25、wn就會(huì)加1。接收方會(huì)同步保存 接收數(shù)據(jù)的幀計(jì)數(shù)，對比收到的計(jì)數(shù)值和當(dāng)前保存的值，如果兩者相差小于 MAX_FCNT_GAP （要考慮計(jì)數(shù)器滾動(dòng)）,接收方就按接收的幀計(jì)數(shù)更新對應(yīng)值。如 果兩者相差大于MAX_FCNY_GAP就說明中間丟失了很多數(shù)據(jù)，這條以及后面的數(shù) 據(jù)就被丟掉。LoRaWAN的幀計(jì)數(shù)器可以用16位和32位兩種，節(jié)點(diǎn)上具體執(zhí)行哪種計(jì)數(shù)，需要 在帶外通知網(wǎng)絡(luò)側(cè)，告知計(jì)數(shù)器的位數(shù)。 ？如果采用16位幀計(jì)數(shù)，F(xiàn)Cnt字段的值可以使用幀計(jì)數(shù)器的值，此時(shí)有需要的話通 過在前面填充0 （值為0）字節(jié)來補(bǔ)足；如果采用32位幀計(jì)數(shù)，？FCnt就對應(yīng)計(jì)數(shù)器32位的16個(gè)低有效位（上行數(shù)據(jù)使用上行

26、FCnt,下行數(shù)據(jù)使用 下行FCnt）。終端在相同應(yīng)用和網(wǎng)絡(luò)密鑰下，不能重復(fù)用相同的FCntUp數(shù)值，除非是重傳。幀可選項(xiàng)（FOptsLeninFCtrl,FOpts）? FCtrl字節(jié)中的FOptsLen位字段描述了整個(gè)幀可選項(xiàng)（FOpts）的字段長度。FOpts字段存放MAC命令，最長15字節(jié)，詳細(xì)的MAC命令見章節(jié)4.4。如果FOptsLen為0,貝U FOpts為空。在FOptsLen非0時(shí)，則反之。如果 MAC命令在FOpts字段中體現(xiàn)，port。不能用（FPort要么不體現(xiàn)，要么非 0）。MAC命令不能同時(shí)出現(xiàn)在 FRMPayload和FOpts中，如果出現(xiàn)了，設(shè)備丟掉該組數(shù) 據(jù)。

27、4.3.2 端口字段（FPort）如果幀載荷字段不為空，端口字段必須體現(xiàn)出來。端口字段有體現(xiàn)時(shí)，若 FPort的值為0表示FRMPayload只包含了 MAC命令；具體見章節(jié)4.4中的MAC命令。FPort的數(shù)值從1 H 223(0x01.0xDF)都是由應(yīng)用層使用。FPort的值從224到255(0xE0.0xFF)是保留用做未來的標(biāo)準(zhǔn)應(yīng)用拓展Size(bytes)7.230.10.NMACPayloadFHDRFPortFRMPayloadN是應(yīng)用程序載荷的字節(jié)個(gè)數(shù)。N的有效范圍具體在第7章有定義。N應(yīng)該小于等于：？N<=M-1-(FHDR 長度)？M是MAC載荷的最大長度。4.3.

28、3 MAC 幀載荷加密(FRMPayload)如果數(shù)據(jù)幀攜帶了載荷，F(xiàn)RMPayload必須要在MIC計(jì)算前進(jìn)行加密。？加密機(jī)制是采用的 AES128算法。默認(rèn)的，加密和加密由LoRaWAN層來給所有的FPort來執(zhí)行。如果加密/解密由應(yīng)用層來做更方便的話，也可以在 LoRaWAN層之上2&特定FPorts來執(zhí)行，除了端口0。具體哪個(gè)節(jié)點(diǎn)的哪個(gè) FPort在LoRaWAN層之外要做加解密，必須要和服務(wù)器通過out-of-band信道來交互(見第19章)。 LoRaWAN的加密密鑰K根據(jù)不同的FPort來使用：FPortK0NwkSKey1.1. 55AppSKey表3:FPort歹U表

29、具體加密是這樣：？pld=FRMPayload?對于每個(gè)數(shù)據(jù)幀，算法定義了一個(gè)塊序列Ai, i從1到k, k=ceil(len(pld)/16):Size(bytes) 1414411Ai0x014x0x00DirDevAddrFCntUporFCntDown0x00i方向字段(Dir)在上行幀時(shí)為0,在下行幀時(shí)為1.?塊Ai通過加密，得到一個(gè)由塊 Si組成的序列SoSi二aes128_encrypt(K,Ai)fori=1.k?S=S1|S2|.|Sk通過異或計(jì)算對payload進(jìn)行加解密： LoRaWAN層之上的加密？如果LoRaWAN之上的層級(jí)在已選的端口上(但不能是端口 0,這是給MA

30、C 命令保留的)提供了預(yù)加密的 FRMPayload給LoRaWAN , LoRaWAN則不再 對FRMPayload進(jìn)行修改，直接將FRMPayload從MACPayload傳至H應(yīng)用層， 以及從應(yīng)用層傳到MACPayload。4.4消息校驗(yàn)碼(MIC)消息檢驗(yàn)碼要計(jì)算消息中所有字段。？msg=MHDR|FHDR|FPort|FRMPayloadMIC是按照RFC4493來計(jì)算：cmac二aes128_cmac(NwkSKey,B0|msg)?MIC=cmac0.3塊B0的定義如下：1len(msg)Size(bytes) 141441B00x49 4x0x00 Dir DevAddr FC

31、ntUporFCntDown 0x00方向字段(Dir)在上行幀時(shí)為0,在下行幀時(shí)為1.LoRaWAN第4章，主要講述了 MAC幀格式，對所有涉及的字段都做了解釋數(shù)據(jù)幀頭DevAddrFC trlF Cn tFO pts數(shù)Prea mblePHDRPHDR _CRCMH DRFHDRFP ortFRMPa yload據(jù)幀M ACPrea mblePHDRPHDR _CRCMH DRMACPayload千言萬語匯成一句話，哦不，匯成一個(gè)表。M CIC RCM CIC RPHPreaPHPHDRPHYPayloadCYmbleDR_CRCR日C層好了，幀格式是大家隨手都能看到的東西，本尊作為IoT

32、小能手，如果不能提出一些稍有深度的信息增量，就對不起這個(gè)稱號(hào)了。所以，有些協(xié)議設(shè)計(jì)層面的心得要 分享下：1 .特別酷的ADR（速率自適應(yīng)）機(jī)制？2 .這個(gè)章節(jié)中最亮眼的莫過于速率自適應(yīng)機(jī)制，簡直是為LoRa網(wǎng)絡(luò)量身定做的：一旦使能了 FCtrl中的ADR位，距離近信號(hào)好的節(jié)點(diǎn)用高速率，距離遠(yuǎn)信號(hào)弱的節(jié)點(diǎn)用低速率，不小心被調(diào)高了速率，則自動(dòng)降下來。這樣，盡可 能地提高了傳輸速率，也有效提高了網(wǎng)絡(luò)容量。我已經(jīng)見過不少廠家，拿這 個(gè)協(xié)議的公知特點(diǎn)當(dāng)產(chǎn)品賣點(diǎn)了。3 .可同時(shí)攜帶數(shù)據(jù)和命令的 MAC幀？4 . 一般來說，應(yīng)用除了數(shù)據(jù)，出于管理需要，肯定還會(huì)涉及命令。比如基站要查詢節(jié)點(diǎn)狀態(tài)，或者節(jié)點(diǎn)要請求

33、變更信道等。所以LoRaWAN協(xié)議設(shè)計(jì)上利用FOpts把數(shù)據(jù)和命令揉在一個(gè) MAC幀里，這樣可以提高交互效率，有效地降低功耗。這在寸土寸金，哦不，寸庫侖（電量單位）寸金的物聯(lián)網(wǎng)應(yīng)用中， 是一個(gè)很有必要的設(shè)計(jì)。3源碼解析這章的處理基本都在srcmacLoRaMac.c中，下面按照MAC幀格式的字段逐個(gè)解析 下。3.1 MAC 層 MHDR在LoRaWAN的數(shù)據(jù)API中處理了 MHDR ,這個(gè)字段內(nèi)容比較少， 就按需選擇了消II類型是 confirm 還是 unconfirm。 ?另外在管理API中的Join-Req的消息類型。具體可見 LoRaMacMcpsRequest(，口 LoRaMacM

34、lmeRequest()這兩個(gè)函數(shù)。3.2 MACPayloadMACPayload的組幀都在PrepareFrame(這個(gè)函數(shù)中處理，將 macHdr和macPayload 的fCtrl、FPort、FRMPayload者B傳遞進(jìn)去，完成整個(gè) MAC層的數(shù)據(jù)組幀。LoRaMacBuffer就存放了 MACPayload的數(shù)據(jù)，這個(gè)變量的組幀和協(xié)議字段定義是 對應(yīng)。MACPayload的組幀處理，在大流程上是對 join和數(shù)據(jù)兩種類型的幀分 別處理，用兩個(gè)case分開。為了方便閱覽，我把函數(shù)代碼框架提煉了出來。LoRaMacStatus_tPrepareFrame(LoRaMacHeader_

35、t*macHdr,LoRaMacFrameCtrl_t*fCtrl,uint8_tfPort,void*fBuffer,uint16_tfBuf ferSize)switch(macHdr->Bits.MType)caseFRAME_TYPE_JOIN_REQ:./省略break;caseFRAME_TYPE_DATA_CONFIRMED_UP:NodeAckRequested=true;/IntentionalfalltroughcaseFRAME_TYPE_DATA_UNCONFIRMED_UP:.fCtrl->Bits.AdrAckReq=AdrNextDr(fCtrl-&g

36、t;Bits.Adr,true,&LoR aMacParams.ChannelsDatarate);.if(SrvAckRequested=true)SrvAckRequested=false;fCtrl->Bits.Ack=1;LoRaMacBufferpktHeaderLen+=(LoRaMacDevAddr)&0xFF;LoRaMacBufferpktHeaderLen+=(LoRaMacDevAddr>>8)&0xFF;LoRaMacBufferpktHeaderLen+=(LoRaMacDevAddr>>16)&0xFF;

37、LoRaMacBufferpktHeaderLen+=(LoRaMacDevAddr>>24)&0xFF;LoRaMacBufferpktHeaderLen+=fCtrl->Value;LoRaMacBufferpktHeaderLen+=UpLinkCounter&0xFF;LoRaMacBufferpktHeaderLen+=(UpLinkCounter>>8)&0xFF;/CopytheMACcommandswhichmustbere-sendintotheMACcommandbu ffermemcpy1(&MacComman

38、dsBufferMacCommandsBufferIndex,MacCom mandsBufferToRepeat,MacCommandsBufferToRepeatIndex);MacCommandsBufferIndex+=MacCommandsBufferToRepeatIndex;if(payload!=NULL)&&(payloadSize>0)if(MacCommandsBufferIndex<=LORA_MAC_COMMAND_MAX_LENGTH)& &(MacCommandsInNextTx=true)fCtrl->Bits.

39、FOptsLen+=MacCommandsBufferIndex;/UpdateFCtrlfieldwithnewvalueofOptionsLengthLoRaMacBuffer0x05=fCtrl->Value;for(i=0;i<MacCommandsBufferIndex;i+)LoRaMacBufferpktHeaderLen+=MacCommandsBufferi;elseif(MacCommandsBufferIndex>0)&&(MacCommandsInNextTx)payloadSize=MacCommandsBufferIndex;pay

40、load=MacCommandsBuffer;framePort=0;MacCommandsInNextTx=false;/StoreMACcommandswhichmustbere-sendincasethedevicedoesno treceiveadownlinkanymoreMacCommandsBufferToRepeatIndex=ParseMacCommandsToRepeat(M acCommandsBuffer,MacCommandsBufferIndex,MacCommandsBuffer ToRepeat);if(MacCommandsBufferToRepeatInde

41、x>0)MacCommandsInNextTx=true;MacCommandsBufferIndex=0;if(payload!=NULL)&&(payloadSize>0)LoRaMacBufferpktHeaderLen+=framePort;if(framePort=0)LoRaMacPayloadEncrypt(uint8_t*)payload,payloadSize,LoRaM acNwkSKey,LoRaMacDevAddr,UP_LINK,UpLinkCounter,LoRaMacPay load);elseLoRaMacPayloadEncrypt

42、(uint8_t*)payload,payloadSize,LoRaM acAppSKey,LoRaMacDevAddr,UP_LINK,UpLinkCounter,LoRaMacPay load);memcpy1(LoRaMacBuffer+pktHeaderLen,LoRaMacPayload,payload Size);LoRaMacBufferPktLen=pktHeaderLen+payloadSize;LoRaMacComputeMic(LoRaMacBuffer,LoRaMacBufferPktLen,LoRaM acNwkSKey,LoRaMacDevAddr,UP_LINK,

43、UpLinkCounter,&mic);LoRaMacBufferLoRaMacBufferPktLen+0=mic&0xFF;LoRaMacBufferLoRaMacBufferPktLen+1=(mic>>8)&0xFF;LoRaMacBufferLoRaMacBufferPktLen+2=(mic>>16)&0xFF;LoRaMacBufferLoRaMacBufferPktLen+3=(mic>>24)&0xFF;LoRaMacBufferPktLen+=LORAMAC_MFR_LEN;break;caseFR

44、AME_TYPE_PROPRIETARY:省略break;default:returnLORAMAC_STATUS_SERVICE_UNKNOWN;returnLORAMAC_STATUS_OK;Join-request的組幀處理對應(yīng)協(xié)議第 6 章 6.2.4Join-requestmessage ?數(shù)據(jù)幀的組幀處理則稍微復(fù)雜些，尤其是FHDR,下面逐個(gè)字段講解下FHDR。3.2.1 MACPayload 中的 FHDR 1.FHDR 中的 DevAddrLoRaMacBufferpktHeaderLen+=(LoRaMacDevAddr)&0xFF;?LoRaMacBufferpkt

45、HeaderLen+=(LoRaMacDevAddr>>8)&0xFF;?LoRaMacBufferpktHeaderLen+=(LoRaMacDevAddr>>16)&0xFF;?LoRaMacBufferpktHeaderLen+=(LoRaMacDevAddr>>24)&0xFF; 2.FHDR 中的 FCtrl首先ADR位段是在傳入PrepareFrame(之前，就做了處理。？二AdrCtrlOn;接著AdrAckReq位段，在長期失聯(lián)情況下會(huì)發(fā)送 AdrAckReq確認(rèn)鏈路。？fCtrl->Bits.AdrAckReq

46、二AdrNextDr(fCtrl->Bits.Adr,true,&LoRaMacParams.ChannelsDa tarate);最后FOptsLen位段，會(huì)在下面計(jì)算完 FOpts之后更新。 3.FHDR 中的 FCntLoRaMacBufferpktHeaderLen+=UpLinkCounter&OxFF;?LoRaMacBufferpktHeaderLen+=(UpLinkCounter>>8)&0xFF;這個(gè)UpLinkCounter會(huì)在物理層發(fā)送完成后會(huì)按照協(xié)議進(jìn)行累加?？梢钥吹竭@是個(gè)32位計(jì)數(shù)器，按照協(xié)議規(guī)定，如果采用32位幀計(jì)數(shù)，F(xiàn)C

47、nt就對應(yīng)計(jì)數(shù)器32位的16個(gè)低有效位工這是上行的，另外下行的也類似。 4.FHDR 中的 FOpts把MAC命令放入F0pts中，并且更新F0ptsLen。MAC命令，要么使用非零的 FPort來和數(shù)據(jù)一起傳輸，要么使用 FPort0來單獨(dú)傳輸。CopytheMACcommandswhichmustbere-sendintotheMACcommandbu ffermemcpy1(&MacCommandsBufferMacCommandsBufferIndex,MacCom mandsBufferToRepeat,MacCommandsBufferToRepeatIndex);MacC

48、ommandsBufferIndex+=MacCommandsBufferToRepeatIndex;if(payload!=NULL)&&(payloadSize>0)if(MacCommandsBufferIndex<=LORA_MAC_COMMAND_MAX_LENGTH)& &(MacCommandsInNextTx=true) fCtrl->Bits.FOptsLen+=MacCommandsBufferIndex;/UpdateFCtrlfieldwithnewvalueofOptionsLengthLoRaMacBuffer0x0

49、5=fCtrl->Value;for(i=0;i<MacCommandsBufferIndex;i+)LoRaMacBufferpktHeaderLen+=MacCommandsBufferi; elseif(MacCommandsBufferIndex>0)&&(MacCommandsInNextTx)payloadSize=MacCommandsBufferIndex;payload=MacCommandsBuffer;framePort=0;3.2.2 MACPayload 中的 FPort這個(gè)是在應(yīng)用層一直傳遞進(jìn)去的，協(xié)議棧默認(rèn)是用了端口2。這個(gè)是后期

50、大家在應(yīng)用時(shí)要調(diào)整的，類似于IP端口，不同的端口對應(yīng)不同的服務(wù)。3.3 MIC解析在函數(shù)PrepareFrame(的最后是調(diào)用 LoRaMacComputeMic()計(jì)算出整個(gè) MAC層的校驗(yàn)碼。應(yīng)用層這邊基本不用改這邊就暫時(shí)不細(xì)究了。第5章MAC命令 對網(wǎng)絡(luò)管理者而言，有一套專門的MAC命令用來在服務(wù)器和終端 MAC層之間交互。 這套MAC命令對應(yīng)用程序（不管是服務(wù)器端還是終端設(shè)備的應(yīng)用程序 ）是不可見的。單個(gè)數(shù)據(jù)幀中可以攜帶 MAC命令，要么在FOpts字段中捎帶，要么在獨(dú)立幀中將FPort設(shè)成0后放在FRMPayload里。如果采用FOpts捎帶的方式，MAC命令是不 加密并且不長度超過

51、15字節(jié)。如果采用獨(dú)立幀放在 FRMPayload的方式，那就必須 采用加密方式，并且不超過 FRMPayload的最大長度。注意：如果MAC命令不想被竊聽，那就必須以獨(dú)立幀形式放在FRMPayload中。每個(gè)MAC命令是由1字節(jié)CID跟著一段可能為空的字節(jié)序列組成的。CIDCommand由誰發(fā)送終網(wǎng)端關(guān)描述0x02LinkCheckReqx終端利用這個(gè)命令來判斷網(wǎng)絡(luò)連接質(zhì)量0x02LinkCheckAnsxLinkCheckReq的回復(fù)。包含接收信號(hào)強(qiáng)度，告知終端 收質(zhì)量0x03LinkADRReqx向終端請求改變數(shù)據(jù)速率，發(fā)射功率，重傳率以及信道0x03LinkADRAnsxLinkADR

52、Req 的回復(fù)。0x04DutyCycleReqx向終端設(shè)置發(fā)送的最大占空比。0x04DutyCycleAnsxDutyCycleReq 的回復(fù)。0x05RXParamSetupReqx向終端設(shè)置接收時(shí)隙參數(shù)。0x05RXParamSetupAnsxRXParamSetupReq 的回復(fù)。0x06DevStatusReqx向終端查詢其狀態(tài)。0x06DevStatusAnsx返回終端設(shè)備的狀態(tài)，即電池余量和鏈路解調(diào)預(yù)算。0x07NewChannelReqx創(chuàng)建或修改1個(gè)射頻信道定義。0x07NewChannelAnsxNewChannelReq 的回復(fù)。0x08RXTimingSetupReqx

53、設(shè)置接收時(shí)隙的時(shí)間。0x08RXTimingSetupAnsxRXTimingSetupReq 的回復(fù)。0x800xFF私有xx給私啟網(wǎng)絡(luò)命令拓展做預(yù)留。表4: MAC命令表注意：MAC命令的長度雖然沒有明確給出，但是 MAC執(zhí)行層必須要知道。因此未 知的MAC命令無法被忽略，且前面未知的MAC命令會(huì)終止MAC命令的處理隊(duì)列。 所以建議按照LoRaWAN協(xié)議介紹的MAC命令來處理MAC命令。這樣所有基于 LoRaWAN協(xié)議的MAC命令都可以被處理，即使是更高版本的命令。2梳理解析從LoRaWAN第4章的幀格式可以得到如下信息：MAC命令，要么使用FPortO來單獨(dú)傳輸，要么使用非零的 FPor

54、t來和數(shù)據(jù)一起傳輸。LoRaWAN第5章，LoRaWAN出于網(wǎng)絡(luò)管理需要，提出了 9條MAC命令，這個(gè)章節(jié)是對9條命令進(jìn)行具體的描述。說個(gè)題外話，CLAA（中國LoRa應(yīng)用聯(lián)盟）在9條命令以外還擴(kuò)充了一些 MAC命令。現(xiàn)階段協(xié)議還不能公開，所以我就不多說了。中興目前作為LoRa聯(lián)盟董事會(huì)成員，也許以后會(huì)把這些拓展 MAC命令引入到LoRaWAN協(xié)議也說不準(zhǔn)，大家暫且當(dāng)個(gè)課外知識(shí)了解下就好。3代碼位置MAC命令枚舉/*!*LoRaMACmoteMACcommands*LoRaWANSpecificationV1.0.1,chapter5,table4*/ typedefenumeLoRaMacM

55、oteCmd /*!*LinkCheckReq*/MOTE_MAC_LINK_CHECK_REQ=0x02,/*!*LinkADRAns*/MOTE_MAC_LINK_ADR_ANS=0x03,/*!*DutyCycleAns*/MOTE_MAC_DUTY_CYCLE_ANS=0x04,/*!*RXParamSetupAns*/MOTE_MAC_RX_PARAM_SETUP_ANS=0x05, /*!*DevStatusAns*/MOTE_MAC_DEV_STATUS_ANS=0x06,/*!*NewChannelAns*/MOTE_MAC_NEW_CHANNEL_ANS=0x07, /*!*RXTimingSetupAns*/MOTE_MAC_RX_TIMING_SETUP