1、第1章介紹本文檔描述了 LoRaWAN網絡協議，是針對電池供電的終端設備（不管移動還是固定 位置）進行優化的一套網絡協議。LoRaWAN網絡通常采用星型拓撲結構，由拓撲中的 網關來轉發終端與后臺網絡服 務器間的消息。網關通過標準IP連接來接入網絡服務器，而終端則通過單跳的LoRa 或者FSK來和一個或多個 網關通訊。雖然主要傳輸方式是 終端上行傳輸給網絡服務 器，但所有的傳輸通常都是雙向的。終端和網關間的通訊被分散到不同的信道頻點和數據速率上。數據速率的選擇需要 權衡距離和消息時長兩個因素，使用不同數據速率的設備互不影響。LoRa的數據速率范圍可以從0.3kbps到50kbps。為了最大程度地

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

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

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

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

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

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

8、HDR_CRC。下行PHY:PreamblePHDRPHDR_CRCPHYPayload圖3.下行PHY幀格式3.3 接收窗口每個上行傳輸后終端都要開兩個短的接收窗口。接收窗口開始時間的規定，是以傳 輸結束時間為參考甘ansmit-RXi | RX2圖4.終端接收時隙的時序圖3.3.1 第一接收窗口的信道，數據速率和啟動。第一接收窗口 RX1使用的頻率和上行頻率有關，使用的速率和上行速率有關。RX1是在上行調制結束后的 RECEIVE_DELAY1秒打開。上行和RX1時隙下行速率的關 系是按區域規定，詳細描述在LoRaWAN地區參數文件中。默認第一窗口的速率是 和最后一次上行的速率相同。3.3

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

10、啟第二個接收窗口。3.3.5 網絡發送消息給終端如果網絡想要發一個下行消息給終端，它會精確地在兩個接收窗口的起始點發起傳輸。3.3.6 接收窗口的重要事項終端在第一或第二接收窗口收到下行消息后，或者在第二接收窗口階段，不能再發起另一個上行消息。3.3.7 其他協議的收發處理節點在LoRaWAN收發窗口階段可以收發其他協議，只要終端能滿足當地要求以及兼容LoRaWAN協議。2梳理解析LoRaWAN第3章，主要是講了接收窗口這回事，只要記住張圖就行。目前RX1 一般是在上行后1秒開始，RX2是在上行后2秒開始。3源碼分析3.1 源碼流程在梳理這章節的對應代碼時，自己手動做了張思維導圖。有時是這樣，

11、代碼再有層 次感，也不及一個圖。好，請收下。3.2 發送完成就開始RX1和RX2延時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 接收窗口的射頻處理從上面一步，我們已經清晰的知道，對應的處理肯定是在OnRxWindowlTimerEvent和 OnRxWindow2TimerEvent 中。？這兩個接收窗口的處理，會對速率和信道

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

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

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

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

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

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

19、端采用任何可能的數據速率。 LoRaWAN協議利用該特性來優化固 定終端的數據速率。這就是自適應數據速率 （AdaptiveDataRate（ADR）。當這個使能 時，網絡會優化使得盡可能使用最快的數據速率。移動的終端由于射頻環境的快速變化，數據速率管理就不再適用了，應當使用固定的數據速率。如果ADR的位字段有置位，網絡就會通過相應的MAC命令來控制終端設備的數據速率。如果ADR位沒設置，網絡則無視終端的接收信號強度，不再控制終端設備的數據速率。ADR位可以根據需要通過終端及網絡來設置或取消。不管怎樣，ADR機制都應該盡可能使能，幫助終端延長電池壽命和擴大網絡容量。注意：即使是移動的終端，可能

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

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

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

23、的應答數據幀。或者，終端會延遲發送應答，在它下一個數據幀中再攜帶。 重傳流程當需要應答卻沒收到應答時就會進行重發，重發的個數由終端自己定，可能每個終端都不一樣，這個參數也可以由網絡服務器來設置調整。注意：一些應答機制的示例時序圖在第18章中有提供。注意：如果終端設備重發次數到達了最大值，它可以降低數據速率來重連。至于后面是否再重發還是說丟棄不管，都取決于終端自己。注意：如果網絡服務器重發次數到達了最大值，它就認為該終端掉線了，直到它再 收到終端的消息。一旦和終端設備的連接出現問題時，要不要重發都取決于網絡服 務器自己。注意：在重傳期間的數據速率回退的建議策略在章節18.4中有描述。 幀掛起位（

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

25、wn就會加1。接收方會同步保存 接收數據的幀計數，對比收到的計數值和當前保存的值，如果兩者相差小于 MAX_FCNT_GAP （要考慮計數器滾動）,接收方就按接收的幀計數更新對應值。如 果兩者相差大于MAX_FCNY_GAP就說明中間丟失了很多數據，這條以及后面的數 據就被丟掉。LoRaWAN的幀計數器可以用16位和32位兩種，節點上具體執行哪種計數，需要 在帶外通知網絡側，告知計數器的位數。 ？如果采用16位幀計數，FCnt字段的值可以使用幀計數器的值，此時有需要的話通 過在前面填充0 （值為0）字節來補足；如果采用32位幀計數，？FCnt就對應計數器32位的16個低有效位（上行數據使用上行

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

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

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

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

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

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

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

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

34、lmeRequest()這兩個函數。3.2 MACPayloadMACPayload的組幀都在PrepareFrame(這個函數中處理，將 macHdr和macPayload 的fCtrl、FPort、FRMPayload者B傳遞進去，完成整個 MAC層的數據組幀。LoRaMacBuffer就存放了 MACPayload的數據，這個變量的組幀和協議字段定義是 對應。MACPayload的組幀處理，在大流程上是對 join和數據兩種類型的幀分 別處理，用兩個case分開。為了方便閱覽，我把函數代碼框架提煉了出來。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的組幀處理對應協議第 6 章 6.2.4Join-requestmessage ?數據幀的組幀處理則稍微復雜些，尤其是FHDR,下面逐個字段講解下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位段，在長期失聯情況下會發送 AdrAckReq確認鏈路。？fCtrl->Bits.AdrAckReq

46、二AdrNextDr(fCtrl->Bits.Adr,true,&LoRaMacParams.ChannelsDa tarate);最后FOptsLen位段，會在下面計算完 FOpts之后更新。 3.FHDR 中的 FCntLoRaMacBufferpktHeaderLen+=UpLinkCounter&OxFF;?LoRaMacBufferpktHeaderLen+=(UpLinkCounter>>8)&0xFF;這個UpLinkCounter會在物理層發送完成后會按照協議進行累加。可以看到這是個32位計數器，按照協議規定，如果采用32位幀計數，FC

47、nt就對應計數器32位的16個低有效位工這是上行的，另外下行的也類似。 4.FHDR 中的 FOpts把MAC命令放入F0pts中，并且更新F0ptsLen。MAC命令，要么使用非零的 FPort來和數據一起傳輸，要么使用 FPort0來單獨傳輸。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這個是在應用層一直傳遞進去的，協議棧默認是用了端口2。這個是后期

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

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

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

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

54、t來和數據一起傳輸。LoRaWAN第5章，LoRaWAN出于網絡管理需要，提出了 9條MAC命令，這個章節是對9條命令進行具體的描述。說個題外話，CLAA（中國LoRa應用聯盟）在9條命令以外還擴充了一些 MAC命令。現階段協議還不能公開，所以我就不多說了。中興目前作為LoRa聯盟董事會成員，也許以后會把這些拓展 MAC命令引入到LoRaWAN協議也說不準，大家暫且當個課外知識了解下就好。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