Lorawan協(xié)議說明書

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

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

3、作參數(shù)，例如發(fā)射占空比和發(fā)射時長等，在另一份文檔LoRaWAN地區(qū)參數(shù)中做具體描述。將這份文檔分開，是為了加入新地區(qū)參數(shù)時不影響基礎的協(xié)議規(guī)范。1.1 LoRaWAN Classes所有的LoRaWAN設備都必須至少實現(xiàn)本文檔描述的 Class A 功能。另外也可以實現(xiàn)本文檔中描述的 Class B 和 Class C 及后續(xù)將定義的可選功能。不管怎么樣，設備都必須兼容 Class A。1.2 文檔約定MAC命令的格式寫作 LinkCheckReq (粗斜體)，位和位域的格式寫作 FRMPayload (粗體)，常量的格式寫作 RECEIVE_DELAY

4、1，變量的格式寫作 N。在本文檔中，· 所有多字節(jié)字段的字節(jié)序均采用小端模式· EUI 是8字節(jié)字段，采用小端模式傳輸· 默認所有RFU保留位都設為0第2章 LoRaWAN Classes 類型介紹LoRa 是由Semtech面向長距離、低功耗、低速率應用而開發(fā)的無線調制技術。本文檔中，將 Class A 基礎上實現(xiàn)了更多功能的設備稱為“更高 class 終端”。2.1 LoRaWAN ClassesLoRa網(wǎng)絡包含基礎LoRaWAN（稱之為Class A）和可選功能（Class B，Class C）: 圖1.LoRaWAN Classes·

5、雙向傳輸終端(Class A)： Class A 的終端在每次上行后都會緊跟兩個短暫的下行接收窗口，以此實現(xiàn)雙向傳輸。傳輸時隙是由終端在有傳輸需要時安排，附加一定的隨機延時(即ALOHA協(xié)議)。這種Class A 操作是最省電的，要求應用在終端上行傳輸后的很短時間內進行服務器的下行傳輸。服務器在其他任何時間進行的下行傳輸都得等終端的下一次上行。· 劃定接收時隙的雙向傳輸終端(Class B)： Class B 的終端會有更多的接收時隙。除了Class A 的隨機接收窗口，Class B 設備還會在指定時間打開別的接收窗口。為了讓終端可以在指定時間打開接收窗口，終端

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

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

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

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

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

11、次感，也不及一個圖。好，請收下。3.2 發(fā)送完成就開始RX1和RX2延時static void OnRadioTxDone( void ) . / Setup timers if( IsRxWindowsEnabled = true ) TimerSetValue( &RxWindowTimer1, RxWindow1Delay ); TimerStart( &RxWindowTimer1 ); if( LoRaMacDeviceClass != CLASS_C ) TimerSetValue( &RxWindowTimer2, RxWindow2Delay ); Ti

12、merStart( &RxWindowTimer2 ); if( ( LoRaMacDeviceClass = CLASS_C ) | ( NodeAckRequested = true ) ) TimerSetValue( &AckTimeoutTimer, RxWindow2Delay + ACK_TIMEOUT + randr( -ACK_TIMEOUT_RND, ACK_TIMEOUT_RND ) ); TimerStart( &AckTimeoutTimer ); .3.3 接收窗口的射頻處理從上面一步，我們已經(jīng)清晰的知道，對應的處理肯定是在OnRxWindo

13、w1TimerEvent和OnRxWindow2TimerEvent中。 這兩個接收窗口的處理，會對速率和信道進行設置，按照LoRaWAN協(xié)議中文版_配套文件 地區(qū)參數(shù)(物理層) 中對各地區(qū)的要求分別進行處理。比如這個470的處理，對上行信道對48取余得到下行信道。RxWindowSetup( LORAMAC_FIRST_RX1_CHANNEL + ( Channel % 48 ) * LORAMAC_STEPWIDTH_第4章 MAC幀格式LoRa所有上下行鏈路消息都會攜帶PHY載荷，PHY載荷以1字節(jié)MAC頭(MHDR)開始，緊接著MAC載荷(MACPayload)，最

14、后是4字節(jié)的MAC校驗碼(MIC)。射頻PHY層：PreamblePHDRPHDR_CRCPHYPayloadCRC圖5.射頻PHY結構(注意 CRC只有上行鏈路消息中存在)PHY載荷：MHDRMACPayloadMIC或者MHDRJoin-RequestMIC或者MHDRJoin-ResponseMIC圖6.PHY載荷結構MAC載荷：FHDRFPortFRMPayload圖7.MAC載荷結構FHDR：DevAddrFCtrlFCntFOpts圖8.幀頭結構圖9.LoRa幀格式元素(即圖58)4.1 MAC層(PHYPayload)Size (bytes)11.M4PHYPayloadMHDR

15、MACPayloadMICMACPayload字段的最大長度M，在第6章有詳細說明。4.2 MAC頭(MHDR字段)Bit#7.54.21.0MHDR bitsMTypeRFUMajorMAC頭中指定了消息類型(MType)和幀編碼所遵循的LoRaWAN規(guī)范的主版本號(Major)。4.2.1 消息類型(MType位字段)LoRaWAN定義了六個不同的MAC消息類型：join request, join accept, unconfirmed data up/down, 以及 confirmed data up/down 。MType描述000Join Request001Join Accep

16、t010Unconfirmed Data Up011Unconfirmed Data Down100Confirmed Data Up101Confirmed Data Down110RFU111Proprietary表1.MAC消息類型· 4.2.1.1 Join-request and join-accept 消息join-request和join-accept都是用在空中激活流程中，具體見章節(jié)6.2· 4.2.1.2 Data messagesData messages 用來傳輸MAC命令和應用數(shù)據(jù)，這兩種命令也可以放在單個消息中發(fā)送。 Confirmed-

17、data message 接收者需要應答。 Unconfirmed-data message 接收者則不需要應答。 Proprietary messages 用來處理非標準的消息格式，不能和標準消息互通，只能用來和具有相同拓展格式的消息進行通信。不同消息類型用不同的方法保證消息一致性，下面會介紹每種消息類型的具體情況。4.2.2 數(shù)據(jù)消息的主版本(Major位字段)Major位字段描述00LoRaWAN R101.11RFU表2.Major列表注意：Major定義了激活過程中(join procedure)使用的消息格式（見章節(jié)6.2）和MAC Payload的前4字節(jié)（見

18、第4章）。終端要根據(jù)不同的主版本號實現(xiàn)不同最小版本的消息格式。終端使用的最小版本應當提前通知網(wǎng)絡服務器。4.3 MAC載荷(MACPayload)MAC載荷，也就是所謂的“數(shù)據(jù)幀”，包含：幀頭（FHDR）、端口（FPort）以及幀載荷(FRMPayload），其中端口和幀載荷是可選的。4.3.1 幀頭(FHDR)FHDR是由終端短地址(DevAddr)、1字節(jié)幀控制字節(jié)(FCtrl)、2字節(jié)幀計數(shù)器(FCnt)和用來傳輸MAC命令的幀選項(FOpts，最多15個字節(jié))組成。Size(bytes)4120.15FHDRDevAddrFCtrlFCntFOptsFCtrl在上下行消息中有所不同，下

19、行消息如下：Bit#76543.0FCtrl bitsADRADRACKReqACKFPendingFOptsLen上行消息如下：Bit#76543.0FCtrl bitsADRADRACKReqACKRFUFOptsLen· 4.3.1.1 幀頭中 自適應數(shù)據(jù)速率 的控制(ADR, ADRACKReq in FCtrl)LoRa網(wǎng)絡允許終端采用任何可能的數(shù)據(jù)速率。LoRaWAN協(xié)議利用該特性來優(yōu)化固定終端的數(shù)據(jù)速率。這就是自適應數(shù)據(jù)速率(Adaptive Data Rate (ADR)。當這個使能時，網(wǎng)絡會優(yōu)化使得盡可能使用最快的數(shù)據(jù)速率。移動的終端由于射頻環(huán)境的快速變化，數(shù)據(jù)速率

20、管理就不再適用了，應當使用固定的數(shù)據(jù)速率。如果ADR的位字段有置位，網(wǎng)絡就會通過相應的MAC命令來控制終端設備的數(shù)據(jù)速率。如果ADR位沒設置，網(wǎng)絡則無視終端的接收信號強度，不再控制終端設備的數(shù)據(jù)速率。ADR位可以根據(jù)需要通過終端及網(wǎng)絡來設置或取消。不管怎樣，ADR機制都應該盡可能使能，幫助終端延長電池壽命和擴大網(wǎng)絡容量。注意：即使是移動的終端，可能在大部分時間也是處于非移動狀態(tài)。因此根據(jù)它的移動狀態(tài)，終端也可以請求網(wǎng)絡使用ADR來幫助優(yōu)化數(shù)據(jù)速率。如果終端被網(wǎng)絡優(yōu)化過的數(shù)據(jù)速率高于自己默認的數(shù)據(jù)速率，它需要定期檢查下網(wǎng)絡仍能收到上行的數(shù)據(jù)。每次上行幀計數(shù)都會累加(是針對于每個新的上行包，重傳包

21、就不再增加計數(shù))，終端增加 ADR_ACK_CNT 計數(shù)。如果直到ADR_ACK_LIMIT次上行(ADR_ACK_CNT >= ADR_ACK_LIMIT)都沒有收到下行回復，它就得置高ADR應答請求位(ADRACKReq)。 網(wǎng)絡必須在規(guī)定時間內回復一個下行幀，這個時間是通過ADR_ACK_DELAY來設置，上行之后收到任何下行幀就要把ADR_ACK_CNT的計數(shù)重置。當終端在接收時隙中的任何回復下行幀的ACK位字段不需要設置，表示網(wǎng)關仍在接收這個設備的上行幀。如果在下一個ADR_ACK_DELAY上行時間內都沒收到回復(例如，在總時間ADR_ACK_LIMIT+ADR_ACK_DE

22、LAY之后)，終端必須切換到下一個更低速率，使得能夠獲得更遠傳輸距離來重連網(wǎng)絡。終端如果在每次ADR_ACK_LIMIT到了之后依舊連接不上，就需要每次逐步降低數(shù)據(jù)速率。如果終端用它的默認數(shù)據(jù)速率，那就不需要置位ADRACKReq，因為無法幫助提高鏈路距離。注意：不要ADRACKReq立刻回復，這樣給網(wǎng)絡預留一些余量，讓它做出最好的下行調度處理。注意：上行傳輸時，如果 ADR_ACK_CNT >= ADR_ACK_LIMIT 并且當前數(shù)據(jù)速率比設備的最小數(shù)據(jù)速率高，就要設置 ADRACKReq，其它情況下不需要。· 4.3.1.2 消息應答位及應答流程(ACK in FCtrl

23、)收到confirmed類型的消息時，接收端要回復一條應答消息(應答位ACK要進行置位)。如果發(fā)送者是終端，網(wǎng)絡就利用終端發(fā)送操作后打開的兩個接收窗口之一進行回復。如果發(fā)送者是網(wǎng)關，終端就自行決定是否發(fā)送應答。 應答消息只會在收到消息后回復發(fā)送，并且不重發(fā)。注意：為了讓終端盡可能簡單，盡可能減少狀態(tài)，在收到confirmation類型需要確認的數(shù)據(jù)幀，需要立即發(fā)送一個嚴格的應答數(shù)據(jù)幀。或者，終端會延遲發(fā)送應答，在它下一個數(shù)據(jù)幀中再攜帶。· 4.3.1.3 重傳流程當需要應答卻沒收到應答時就會進行重發(fā)，重發(fā)的個數(shù)由終端自己定，可能每個終端都不一樣，這個參數(shù)也可以由網(wǎng)絡服務器來

24、設置調整。注意：一些應答機制的示例時序圖在第18章中有提供。注意：如果終端設備重發(fā)次數(shù)到達了最大值，它可以降低數(shù)據(jù)速率來重連。至于后面是否再重發(fā)還是說丟棄不管，都取決于終端自己。注意：如果網(wǎng)絡服務器重發(fā)次數(shù)到達了最大值，它就認為該終端掉線了，直到它再收到終端的消息。一旦和終端設備的連接出現(xiàn)問題時，要不要重發(fā)都取決于網(wǎng)絡服務器自己。注意：在重傳期間的數(shù)據(jù)速率回退的建議策略在章節(jié)18.4中有描述。· 4.3.1.4 幀掛起位(FPending in FCtrl 只在下行有效)幀掛起位(FPending)只在下行交互中使用，表示網(wǎng)關還有掛起數(shù)據(jù)等待下發(fā)，需要終端盡快發(fā)送上行消息來再打開一個

25、接收窗口。FPending的詳細用法在章節(jié)18.3。· 4.3.1.5 幀計數(shù)器(FCnt)每個終端有兩個計數(shù)器跟蹤數(shù)據(jù)幀的個數(shù)，一個是上行鏈路計數(shù)器（FCntUp），由終端在每次上行數(shù)據(jù)給網(wǎng)絡服務器時累加；另一個是下行鏈路計數(shù)器（FCntDown），由服務器在每次下行數(shù)據(jù)給終端時累計。 網(wǎng)絡服務器為每個終端跟蹤上行幀計數(shù)及產(chǎn)生下行幀計數(shù)。 終端入網(wǎng)成功后，終端和服務端的上下行幀計數(shù)同時置0。 每次發(fā)送消息后，發(fā)送端與之對應的 FCntUp 或 FCntDown 就會加1。 接收方會同步保存接收數(shù)據(jù)的幀計數(shù)，對比收到的計數(shù)值和當前保存的值，如果兩者相差小于 MAX_FCNT_GAP

26、（要考慮計數(shù)器滾動），接收方就按接收的幀計數(shù)更新對應值。如果兩者相差大于 MAX_FCNY_GAP 就說明中間丟失了很多數(shù)據(jù)，這條以及后面的數(shù)據(jù)就被丟掉。LoRaWAN的幀計數(shù)器可以用16位和32位兩種，節(jié)點上具體執(zhí)行哪種計數(shù)，需要在帶外通知網(wǎng)絡側，告知計數(shù)器的位數(shù)。 如果采用16位幀計數(shù)，F(xiàn)Cnt字段的值可以使用幀計數(shù)器的值，此時有需要的話通過在前面填充0（值為0）字節(jié)來補足；如果采用32位幀計數(shù)， FCnt就對應計數(shù)器32位的16個低有效位(上行數(shù)據(jù)使用上行FCnt，下行數(shù)據(jù)使用下行FCnt)。終端在相同應用和網(wǎng)絡密鑰下，不能重復用相同的FCntUp數(shù)值，除非是重傳。&

27、#183; 4.3.1.6 幀可選項(FOptsLen in FCtrl, FOpts) FCtrl 字節(jié)中的FOptsLen位字段描述了整個幀可選項(FOpts)的字段長度。FOpts字段存放MAC命令，最長15字節(jié)，詳細的MAC命令見章節(jié)4.4。如果FOptsLen為0，則FOpts為空。在FOptsLen非0時，則反之。如果MAC命令在FOpts字段中體現(xiàn)，port0不能用(FPort要么不體現(xiàn)，要么非0)。MAC命令不能同時出現(xiàn)在FRMPayload和FOpts中，如果出現(xiàn)了，設備丟掉該組數(shù)據(jù)。4.3.2 端口字段(FPort)如果幀載荷字段不為空，端口字段必須體現(xiàn)出來。端口

28、字段有體現(xiàn)時，若FPort的值為0表示FRMPayload只包含了MAC命令；具體見章節(jié)4.4中的MAC命令。 FPort的數(shù)值從1到223(0x01.0xDF)都是由應用層使用。 FPort的值從224到255(0xE0.0xFF)是保留用做未來的標準應用拓展。Size(bytes)7.230.10.NMACPayloadFHDRFPortFRMPayloadN是應用程序載荷的字節(jié)個數(shù)。N的有效范圍具體在第7章有定義。N應該小于等于： N <= M - 1 - (FHDR長度) M是MAC載荷的最大長度。4.3.3 MAC幀載荷加密(FRMPayload)如果數(shù)據(jù)幀

29、攜帶了載荷，F(xiàn)RMPayload必須要在MIC計算前進行加密。 加密機制是采用IEEE802.15.4/2006的AES128算法。默認的，加密和加密由LoRaWAN層來給所有的FPort來執(zhí)行。如果加密/解密由應用層來做更方便的話，也可以在LoRaWAN層之上給特定FPorts來執(zhí)行，除了端口0。具體哪個節(jié)點的哪個FPort在LoRaWAN層之外要做加解密，必須要和服務器通過out-of-band信道來交互(見第19章)。· 4.3.3.1 LoRaWAN的加密密鑰K根據(jù)不同的FPort來使用：FPortK0NwkSKey1.255AppSKey表3: FPort列表具體

30、加密是這樣： pld = FRMPayload 對于每個數(shù)據(jù)幀，算法定義了一個塊序列Ai，i從1到k，k = ceil(len(pld) / 16)：Size(bytes)1414411Ai0x014 x 0x00DirDevAddrFCntUp or FCntDown0x00i方向字段(Dir)在上行幀時為0，在下行幀時為1. 塊Ai通過加密，得到一個由塊Si組成的序列S。Si = aes128_encrypt(K, Ai) for i = 1.k S = S1 | S2 | . | Sk通過異或計算對payload進行加解密：· 4.3.3

31、.2 LoRaWAN層之上的加密 如果LoRaWAN之上的層級在已選的端口上(但不能是端口0，這是給MAC命令保留的)提供了預加密的FRMPayload給LoRaWAN，LoRaWAN則不再對FRMPayload進行修改，直接將FRMPayload從MACPayload傳到應用層，以及從應用層傳到MACPayload。4.4 消息校驗碼(MIC)消息檢驗碼要計算消息中所有字段。 msg = MHDR | FHDR | FPort | FRMPayloadMIC是按照RFC4493來計算：cmac = aes128_cmac(NwkSKey, B0 | msg) M

32、IC = cmac0.3塊B0的定義如下：Size(bytes)1414411B00x494 x 0x00DirDevAddrFCntUp or FCntDown0x00len(msg)方向字段(Dir)在上行幀時為0，在下行幀時為1.LoRaWAN第4章，主要講述了MAC幀格式，對所有涉及的字段都做了解釋。千言萬語匯成一句話，哦不，匯成一個表。數(shù)據(jù)幀頭DevAddrFCtrlFCntFOpts數(shù)據(jù)幀PreamblePHDRPHDR_CRCMHDRFHDRFPortFRMPayloadMICCRCMAC層PreamblePHDRPHDR_CRCMHDRMACPayloadMICCRCPHY層P

33、reamblePHDRPHDR_CRCPHYPayloadCRC好了，幀格式是大家隨手都能看到的東西，本尊作為IoT小能手，如果不能提出一些稍有深度的信息增量，就對不起這個稱號了。所以，有些協(xié)議設計層面的心得要分享下：1. 特別酷的ADR(速率自適應)機制 這個章節(jié)中最亮眼的莫過于速率自適應機制，簡直是為LoRa網(wǎng)絡量身定做的：一旦使能了FCtrl中的ADR位，距離近信號好的節(jié)點用高速率，距離遠信號弱的節(jié)點用低速率，不小心被調高了速率，則自動降下來。這樣，盡可能地提高了傳輸速率，也有效提高了網(wǎng)絡容量。我已經(jīng)見過不少廠家，拿這個協(xié)議的公知特點當產(chǎn)品賣點了。2. 可同時攜帶數(shù)據(jù)和命令的M

34、AC幀 一般來說，應用除了數(shù)據(jù)，出于管理需要，肯定還會涉及命令。比如基站要查詢節(jié)點狀態(tài)，或者節(jié)點要請求變更信道等。所以LoRaWAN協(xié)議設計上利用FOpts把數(shù)據(jù)和命令揉在一個MAC幀里，這樣可以提高交互效率，有效地降低功耗。這在寸土寸金，哦不，寸庫侖(電量單位)寸金的物聯(lián)網(wǎng)應用中，是一個很有必要的設計。3 源碼解析這章的處理基本都在 srcmacLoRaMac.c 中，下面按照MAC幀格式的字段逐個解析下。3.1 MAC層MHDR在LoRaWAN的數(shù)據(jù)API中處理了MHDR，這個字段內容比較少，就按需選擇了消息類型是confirm還是unconfirm。 另外在管理API

35、中的Join-Req的消息類型。具體可見 LoRaMacMcpsRequest() 和 LoRaMacMlmeRequest() 這兩個函數(shù)。3.2 MACPayloadMACPayload 的組幀都在 PrepareFrame() 這個函數(shù)中處理，將macHdr和macPayload的fCtrl、FPort、FRMPayload都傳遞進去，完成整個MAC層的數(shù)據(jù)組幀。LoRaMacBuffer就存放了MACPayload的數(shù)據(jù)，這個變量的組幀和協(xié)議字段定義是一一對應。MACPayload的組幀處理，在大流程上是對join和數(shù)據(jù)兩種類型的幀分別處理，用兩個case分開。為了方便閱覽，我把函數(shù)代

36、碼框架提煉了出來。LoRaMacStatus_t PrepareFrame( LoRaMacHeader_t *macHdr, LoRaMacFrameCtrl_t *fCtrl, uint8_t fPort, void *fBuffer, uint16_t fBufferSize ) switch( macHdr->Bits.MType ) case FRAME_TYPE_JOIN_REQ: ./ 省略 break; case FRAME_TYPE_DATA_CONFIRMED_UP: NodeAckRequested = true; /Intentional falltrough c

37、ase FRAME_TYPE_DATA_UNCONFIRMED_UP: . fCtrl->Bits.AdrAckReq = AdrNextDr( fCtrl->Bits.Adr, true, &LoRaMacParams.ChannelsDatarate ); . if( SrvAckRequested = true ) SrvAckRequested = false; fCtrl->Bits.Ack = 1; LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr ) & 0xFF; LoRaMacBufferpktHea

38、derLen+ = ( LoRaMacDevAddr >> 8 ) & 0xFF; LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr >> 16 ) & 0xFF; LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr >> 24 ) & 0xFF; LoRaMacBufferpktHeaderLen+ = fCtrl->Value; LoRaMacBufferpktHeaderLen+ = UpLinkCounter & 0xFF; LoR

39、aMacBufferpktHeaderLen+ = ( UpLinkCounter >> 8 ) & 0xFF; / Copy the MAC commands which must be re-send into the MAC command buffer memcpy1( &MacCommandsBufferMacCommandsBufferIndex, MacCommandsBufferToRepeat, MacCommandsBufferToRepeatIndex ); MacCommandsBufferIndex += MacCommandsBuffer

40、ToRepeatIndex; if( ( payload != NULL ) && ( payloadSize > 0 ) ) if( ( MacCommandsBufferIndex <= LORA_MAC_COMMAND_MAX_LENGTH ) && ( MacCommandsInNextTx = true ) ) fCtrl->Bits.FOptsLen += MacCommandsBufferIndex; / Update FCtrl field with new value of OptionsLength LoRaMacBuffe

41、r0x05 = fCtrl->Value; for( i = 0; i < MacCommandsBufferIndex; i+ ) LoRaMacBufferpktHeaderLen+ = MacCommandsBufferi; else if( ( MacCommandsBufferIndex > 0 ) && ( MacCommandsInNextTx ) ) payloadSize = MacCommandsBufferIndex; payload = MacCommandsBuffer; framePort = 0; MacCommandsInNex

42、tTx = false; / Store MAC commands which must be re-send in case the device does not receive a downlink anymore MacCommandsBufferToRepeatIndex = ParseMacCommandsToRepeat( MacCommandsBuffer, MacCommandsBufferIndex, MacCommandsBufferToRepeat ); if( MacCommandsBufferToRepeatIndex > 0 ) MacCommandsInN

43、extTx = true; MacCommandsBufferIndex = 0; if( ( payload != NULL ) && ( payloadSize > 0 ) ) LoRaMacBufferpktHeaderLen+ = framePort; if( framePort = 0 ) LoRaMacPayloadEncrypt( (uint8_t* ) payload, payloadSize, LoRaMacNwkSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, LoRaMacPayload ); else Lo

44、RaMacPayloadEncrypt( (uint8_t* ) payload, payloadSize, LoRaMacAppSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, LoRaMacPayload ); memcpy1( LoRaMacBuffer + pktHeaderLen, LoRaMacPayload, payloadSize ); LoRaMacBufferPktLen = pktHeaderLen + payloadSize; LoRaMacComputeMic( LoRaMacBuffer, LoRaMacBufferPktL

45、en, LoRaMacNwkSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, &mic ); LoRaMacBufferLoRaMacBufferPktLen + 0 = mic & 0xFF; LoRaMacBufferLoRaMacBufferPktLen + 1 = ( mic >> 8 ) & 0xFF; LoRaMacBufferLoRaMacBufferPktLen + 2 = ( mic >> 16 ) & 0xFF; LoRaMacBufferLoRaMacBufferPktLen

46、 + 3 = ( mic >> 24 ) & 0xFF; LoRaMacBufferPktLen += LORAMAC_MFR_LEN; break; case FRAME_TYPE_PROPRIETARY: ./ 省略 break; default: return LORAMAC_STATUS_SERVICE_UNKNOWN; return LORAMAC_STATUS_OK;Join-request的組幀處理對應協(xié)議第6章 6.2.4 Join-request message。 數(shù)據(jù)幀的組幀處理則稍微復雜些，尤其是FHDR，下面逐個字段講解下FHDR。3.2.

47、1 MACPayload中的FHDR· 1.FHDR中的DevAddrLoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr ) & 0xFF; LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr >> 8 ) & 0xFF; LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr >> 16 ) & 0xFF; LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevA

48、ddr >> 24 ) & 0xFF;· 2.FHDR中的FCtrl首先 ADR 位段 是在傳入 PrepareFrame() 之前，就做了處理。 fCtrl.Bits.Adr = AdrCtrlOn;接著 AdrAckReq 位段，在長期失聯(lián)情況下會發(fā)送AdrAckReq確認鏈路。 fCtrl->Bits.AdrAckReq = AdrNextDr( fCtrl->Bits.Adr, true, &LoRaMacParams.ChannelsDatarate );最后 F0ptsLen 位段，會在下面計算完FOpts之后更

49、新。· 3.FHDR中的FCntLoRaMacBufferpktHeaderLen+ = UpLinkCounter & 0xFF; LoRaMacBufferpktHeaderLen+ = ( UpLinkCounter >> 8 ) & 0xFF;這個UpLinkCounter會在物理層發(fā)送完成后會按照協(xié)議進行累加?？梢钥吹竭@是個32位計數(shù)器，按照協(xié)議規(guī)定，“如果采用32位幀計數(shù)，F(xiàn)Cnt就對應計數(shù)器32位的16個低有效位”。這是上行的，另外下行的也類似。· 4.FHDR中的FOpts把MAC命令放入F0pts中，并且更新F0pts

50、Len。MAC命令，要么使用非零的FPort來和數(shù)據(jù)一起傳輸，要么使用FPort0來單獨傳輸。/ Copy the MAC commands which must be re-send into the MAC command buffermemcpy1( &MacCommandsBufferMacCommandsBufferIndex, MacCommandsBufferToRepeat, MacCommandsBufferToRepeatIndex );MacCommandsBufferIndex += MacCommandsBufferToRepeatIndex;if( ( pa

51、yload != NULL ) && ( payloadSize > 0 ) ) if( ( MacCommandsBufferIndex <= LORA_MAC_COMMAND_MAX_LENGTH ) && ( MacCommandsInNextTx = true ) ) fCtrl->Bits.FOptsLen += MacCommandsBufferIndex; / Update FCtrl field with new value of OptionsLength LoRaMacBuffer0x05 = fCtrl->Value

52、; for( i = 0; i < MacCommandsBufferIndex; i+ ) LoRaMacBufferpktHeaderLen+ = MacCommandsBufferi; else if( ( MacCommandsBufferIndex > 0 ) && ( MacCommandsInNextTx ) ) payloadSize = MacCommandsBufferIndex; payload = MacCommandsBuffer; framePort = 0; 3.2.2 MACPayload中的FPort這個是在應用層一直傳遞進去的，協(xié)議棧默認是用了端口2。這個是后期大家在應用時要調整的，類似于IP端口，不同的端口對應不同的服務。3.3 MIC解析在函數(shù) PrepareFrame()的最后是調用LoRaMacComputeMic() 計算出整個MAC層的校驗碼。應用層這邊基本不用改這邊就暫時不細究了。第5章 MAC命令對網(wǎng)絡管理者而言，有一套專門的MAC命令用來在服務器和終端MAC層之間交互。這套MAC命令對應用程序(不管是服務器端還