詳解LoRaWAN協議

作者：小爐灶

LoRaWAN協議定義了使用LoRa的MAC層規范，處在協議應用層與物理層中間的實現規范。LoRa沒有開放的規范化物理層協議，而LoRa物理模塊的接口上很多參數都可以進行配置，LoRaWAN同時對一些數據發送格式做了相應的限制。

物理層消息結構
上行帶有CRC，而下行沒有。

層間組包格式

簡要參數說明：DevAddr 為設備地址(包含網絡地址信息),Fport復用port域，如果為0表示有效負載為MAC命令，此時FOptsLen為0；FOptsLen:options長度為，FCnt為幀計數；MIC加密完整性檢查包含MHDR和FHDR FPort和 FRMPayload;MType為消息類型，指示上下行消息及是否是需要Confirm的消息，如果是confirmed消息則需要回復ACK。Major是LoRaWAN的版本號；ADR 和 ADRAckReq提供服務端用于自適應數據速率控制；ACK確認最新的幀信息；FOpts用于在發送數據時同時攜帶MAC Command；CID為MAC 命令ID，Args為命令參數；FRMPayload為使用key長128比特AES加密的有效數據。MAC header的最小長度為13字節，最大為28字節；上行沒有目標地址，而下行沒有源地址。上圖不是協議上原始的消息結構圖，協議結構圖如下，對于每個元素的細節展開參考規范LoRaWAN-v1.1.pdf RFU 填充為0，需要省略的單元MType亦即message type依賴在相應版本Major下的消息類型。FPort如果payload不為空，則FPort必須存在如果FRMPayload只有MAC commands則此域為0。1-223用于上層應有端口，224用于MAC協議測試，225-255留給后續協議擴展。

三種終端類型
三種終端類型，classA、classB、classC，其耗能和數據延時比較如下,而classB和classC的終端可支持組播方式。

ClassA類型終端收發方式如下: 在上行發送后，Receive_Dealy誤差+/-20微秒時刻進行下行接收，如果網絡在RX1和RX2都發送給同一終端數據，則需要發送同幀數據。終端如果在RX1成功接收到檢查成功的數據，則不可再在RX2繼續接收數據。RX1的頻率和速率和上行發送的頻率和速率滿足一定的函數關系式(在相關流程中說明)，在缺省情況下第一個窗口的數據傳輸速率和上行發送相同，第二個窗口則采用固定可配置的頻率和速率，可以通過MAC Command進行配置。窗口長度至少足夠檢測下行的preamble，如果檢測到下行的preamble，則需要接收到相應frame解調結束。網絡需要在RX1或RX2窗口邊界才能開始發起數據。終端在前一次上行發送成功后如果沒有正確解碼到下行數據并且RX2窗口仍未超時的情況下，不可再次出發上行發送。

ClassB類型的終端，在支持CLassA類型的接收方式之外，還需周期性監測網絡下行的ping slot，而為了實現周期性的同步，引入beacon來攜帶時間信息，終端可以利用beacon(beacon周期性128秒進行發送，ping slot周期可配置)進行時、頻估計，并作出相應調整。ping slot和Beacon的時序關系如下，Beacon由網關周期性發送。Beacon攜帶4個字節時間信息，單位為秒(Sunday 6th of January 1980 的0點開始計時),同時攜帶還有GwSpecific及CRC等。ClassA、ClassB轉換通過ClassB比特位來進行。ClassB: 設置為1時，告訴網絡服務器端，設備切換到ClassB模式。而在ClassA模式下，為保證能夠盡快接收到下行數據，引入Frame Pending bit Fpending inFCtrl只用在下行，表示下行仍有數據發送，需要終端盡快發送上行以打開下行接收窗口。Beacon丟失后可以維持2小時，此時終端根據自身條件維護時間，在此種情況，需要擴展ping和beacon的接收窗口來補償頻率及時間補漂移。對于移動中的終端，GwSpecific 可以攜帶GPS坐標信息,由于classB需要網關發送ping消息，網絡需要知道距離終端最近的網關位置。兩種方式來保證設備部丟失：周期性上行發送以或是小區變化時的上行發送，前者不需要檢測gateway specific，而后者需要通過此ID來判斷小區變化。beacon和ping slot亦可使用跳頻發送。

Beacon的周期性發送方式及時序關系如下,DeviceTimeReq可以用于請求網絡時間，加快Beacon的發現過程。

ClassC模式的工作流程如下，支持ClassC的終端需要支持ClassA，不需支持classB，ClassC終端在發送時刻以外盡可能長時間處在下行接收狀態。ClassA和ClassC的模式轉換通過MAC命令來進行（DeviceModeInd 和 DeviceModeCnf）。

消息類型
消息類型，message type的類型如下，消息中主要指示負載數據類型或者Join流程消息類型。

Conifrmed Data需要接收端進行相應數據包的ACK應答，而Uncofirmed則是無應答要求數據。Joint / Rejoint程序用于OTA激活程序處理。數據消息可以傳輸MAC指令或應用層數據(可合并一起發送)。Confirmed消息是需要進行ACK確認的消息。Proprietary專用消息可用于非標準消息，但必須和標準消息不沖突，當終端或服務端不能識別相應消息時刻，可以選擇丟棄該消息。

Joint request包含JoinEUI DevEUI和DevNonce(2個字節，上電時值為0,每次發送Joint-request值加一，掉電時需要保留在NVM中non-volatile memory)，網絡跟蹤DevNonce值的變化，如果沒有改變的Joint-Request將作為無效消息丟棄。Joint-Request消息無需加密。

Join-accept如果網絡允許設備接入則會回復這條消息。使用跳頻技術的隨機接入，Join-Accept接收和ClassA下行接收類似，不過RX1和RX2的delay為JOIN_ACCEPT_DELAY1和JOIN_ACCEPT_DELA2由物理層特性定義。在join-accept成功后，需要發送RekeyInd、RekeyConf進行交互開啟新的加密模式。如果不允許終端接入，則網絡不會給終端任何回復。joint-accept中包含信息：JoinNonce、NetID、DevAddr、DLSettings、RxDelay、CFList。home_NetID為設備歸屬網絡的ID，屬于NetID一類。DLsettings包含OptNeg，指示網絡為1.0或是1.1，unset為1.0版本，set為1.1及其后續版本，包含RX1DRoffset(第一個接收窗和上行速率關系)，和RX2Data rate(速率大小索引)。JoinNonce用來獲取FNwkSIntKey,SNwkSIntKey, NwkSEncKey、AppSKey。JoinNonce每次處理Join-accept則加一。Join-Nonce需要一直累加，并且終端判斷該值不大于存儲值時認為消息無效。NetID24比特，當為私人或實驗網絡時，分配地址如下：

Rejoin的流程和Join-request類似，同樣回復join-accept。JoniReqType分為0xFF Join-request，0x00Rejoin-request type0，0x01 Rejoi、n-request type1，0x02：Rejon-request type2。Rejon-accept用于網絡間的切換，維持或改變設備在已有網絡上的地址。Rejoin-request，0包含NetID+DevEUI，重置所有無線相關參數。type1包含JoinEUI+DevEUI，作用和Joint-request類似，type3包含NetID+DevEUI，維護或改變設備地址，seesion秘鑰，幀號等，無線資源參數不變化。

設備激活
Join流程的作用是用于終端激活，終端激活的作用，是當設備剛開始工作時完成在相應網絡初始化的過程，沒有顯式定義的去激活過程，只能通過應用層處理。在終端接入LoRaWAN網絡進行有效服務之前，需要進行激活。激活的方式有兩種OTAA(Over-The-Air-Activation)和ABP(Activation By Personalization)。激活過程需要完整一些信息確認，DevAddr占用32比特，7bit用于指示網絡，25比特指示終端在網絡中的地址ID。得到的NwkKey、AppKey是用于產生終端完整保護及數據加密key的基礎，LoRaWAN采用AES128比特算法作為數據加密基礎。激活的流程參考

Join處理流程

加密及數據完整性保護
LoRaWAN為了提高數據的安全性、可靠性，提供了加密和完整性保護MIC。Device root keys (AppKey & NwkKey) 為IEEE 802.15.4 中AES-128比特的密鑰，在OTAA模式下，NwkKey 用來產生FNwkSIntKey,SNwkSIntKey和NwkSEncKey，而AppKey用來產生AppSKey。在v1.0版本中AppSKey亦是由NwkKey產生的。只支持ABP模式的設備不需要NwkKey和Appkey。JSIntKey和JSEncKey也是從NwkKey來得到，前者用于Rejoin-Request type1和對應Join-Accept回復的MIC，后者用于加密Rejoin-Request觸發的Join-Accept。在激活之后，終端可以得到的信息: DevAddr NwkSEncKey SNwkSIntKey FNwkSIntKey及AppSKey。DevAddr用于指示終端在當前網絡中的身份，由于AddrPrefix和NwkAddr組成，AddrPrefix由網絡服務器身份NetID獲取。DevAddr共占用32比特，其中有7：24比特用來表示AddrPrefix，其他表示NwkAddr。AddrPrefix有Lora聯盟分配，私有網絡和實驗網絡可以用7比特b0000000和b0000001表示。如果使用OTAA方式，需要采用join程序進行交互，joint-request用于發起請求，而join-accept用于網絡應答，同時終端可以得到NwKkey和AppKey，在ABP模式下不需要通過Join流程來完成信息交互，設備端本身存有所需的DevAddr、FNwkSIntKey, SNwkSIntKey, NwkSEncKey 和AppSKey。OTAA模式下需要終端攜帶JointEUI、DevEUI，前者是網絡中設備標識，而后者是設備全球唯一標識。當ABP模式設備接入網絡時，首先應當觸發ResetInd/ResetCnf流程。而在OTAA模式設備上需要完成Joint程序后出發RekeyInd、RekeyConf流程(只在OTA模式及1.1的網絡中支持，用于確認密鑰更新)。Key的產生過程在V1.0和V1.1中略有差別，具體參考如下

V1.0版本中的產生方式

V1.1版本中的產生方式

MAC Command處理
LoRaWAN的MAC命令提供了有效定制終端參數的方式，如LinkCheckReq可以用于終端測試其連接情況，其他的命令都是提供服務端使用，這些命令可以用于控制的終端的數據速率、功率輸出、數據重傳次數，接收周期、接收窗口等配置參數；同時還有一些命令可以用于請求終端報告電池、接收質量等相關信息。MAC指令可以作為有效的數據內容攜帶在FRMPayLoad里面同時FPort設置為0，也可以與數據共存，放置在FOpts中，此種情況下最長15字節。每個ID(command identifer)占用1個字節。MAC指令按照接收順序處理回復，同一幀收到的MAC指令必須在同一幀內進行回復。優先發送MAC指令回復在FOpts和FRMPayload，如果超過FRMPayload長度，則只發送可發長度，網絡服務端將對為回復的MAC指令進行重新發送。網絡計算MAC指令回復內容FRMPayload Size的方式：在ADR為0是認為最大FRMPayload為最低速率，ADR比特為1時網絡認為最大Payload size為上次上行發送速率對應的大小。設備只對接收到的MAC命令做一次回復，如果消息丟失，網絡需要重發命令。網絡在接收到新的上行而沒有對MAC命令回復時決定是否需要重發命令，由于RxParamSetupReq、RxTimingSetup和DlChannelReq影響下行信道參數，他們的ACK方式有所不同。網絡需要在RX1、RX2窗口回復終端的MAC命令，如果終端沒有收到回復，則自主調度重傳機制。

MAC命令交互及功能

ClassB增加

ClassC增加

自適應速率控制 ADR(Adaptive data rate control)
如果上行ADR設置為1，則網絡可以通過MAC命令進行速率和發送功率的控制，否則網絡不會嘗試改變速率或發送功率，但可能改變信道和數據重復次數。如果下行ADR設置為1只表明網絡處于可以進行ADR控制的狀態。如果下行ADR比特位0，在移動的終端則需要reset上行ADR比特，按照自身策略進行速率控制，而靜止的終端則忽略此狀態，進行正常ADR控制。LinkADRReqMAC指令可以用于調整速率和功率。終端發送功率默認為最大值或當地允許的最大值，如果網絡終端的速率大于缺省的速率或者發送功率小于缺省的功率，終端需要周期確認網絡能夠收到上行幀。為了實現這個功能，引入ADR_ACK_CNT計數器，如果發送次數(重復傳輸不計算在內，只考慮新的數據傳輸)超過門限設置ADR_ACK_LIMIT時仍未收到下行的任何數據，則需要設置ADRACKReq比特位，網絡需要在ADR_ACK_DELAY幀長時間內做出回復，下行接收到數據，則復位ADR_ACK_CNT計數器。如果在ADR_ACK_LIMIT + ADR_ACK_DELAY時間內網絡沒有回復，終端需要通過回復缺省配置功率和降低速率的方式重新連接，當ADR_ACK_DELAY超時時速率一步步進行降低，如果一直到達最低速率都未能重新獲得連接，終端需要重新恢復功率、速率、頻點信道初始配置。當速率和功率和缺省值相等時，表示無法提升連接性能，此時ADRACKReq不應使用，三個條件可觸發此流程: 速率高于缺省速率、配置功率小于缺省功率或是目前配置的可用信道為缺省可用信道的子集。

數據的ACK與重傳
當數據為Confirmed模式需要ACK的時候，網關需要在終端上行打開的下行周期進行發送，而終端則可自行調度，ACK只針對最新收到的數據進行。在沒有收到ACK的情況，服務端采用新的幀號進行發送。而上行confirmed 和unconfirmed幀都是重傳NbTrans次，除非收到下行有效傳輸。重傳次數可以由網絡根據不同的Qos配置，重傳間可以使用跳頻，而重傳間隔各個終端可以自行決定。而設備收到ACK時需要停止相應幀的重復傳輸。對于uncofirmed數據，ClassA在RX1或RX2收到有效數據則停止重復發送，calssB&C在RX1收到數據時停止重復發送。NbTrans上行傳輸次數，對confirmed和unconfirmed消息都采用，缺省值為1，有效范圍1-15，如果接收到的配置值為0，則保持現有值不變。

FCnt: Frame counter，在LoRaWAN1.1版本設備需要維護三個計數器，而在1.0之前版本只需要兩個，差別在于原來計數分上行下行兩個FCntUp和FCntDown，而在1.1后的版本采用單獨的NFCntDown用于MAC交互的port0和Fport未存在的時刻，而AFCntDown用于其他port，邏輯上NFCntDown由網絡服務端維護，AFCntDown由應用服務器端維護。在OTAA模式下，當成共處理Joint-accept時刻，將Frame Counter全部reset到0，而在ABP設備上初始為0，在設備存貨周期內都不會重置，甚至掉電也需維持。計數器總共32比特，而發送在消息中的FCnt只有最后16比特，設備對于重復的數據只需ACK一次。

關于信道配置
參考LoRaWAN-Regional-Parameters-v1.1rA.PDF，由于ISM屬于非授權公共免費頻譜，但需要滿足一定的限制條件，各個頻率及地區限制以及相適應的物理參數在文檔中做了詳細的說明。

名詞解釋
FNwkSIntKey: Forwarding Network session integrity key
SNwkSIntKey: Serving Network session integrity key
NwkSEncKey: Network session encryption key v1.0中mac payload的MIC和加密key相同。
AppSKey: Application session key ()用于應用層服務端和設備端的數據加密。
Session Context 分為Network Session和Application Session，network session上下文包括信息F/SNwkSIntKey、NwkSEncKey 、FCntUp 、FCntDwn (LW 1.0) or NFCntDwn (LW 1.1)、DevAddr。Application session上下文包括：AppSKey 、FCntUp 、FCntDown (LW 1.0) or AFCntDwn (LW 1.1)。
OTAA: Over-The-Air Activationvia
ABP: Activation By Personalization
MIC: message integrity code

文章轉載自：CSDN

—END—

開發板、書籍免費申請

01

02

 內容合作 | 視頻、課程合作 | 開發板合作| 轉載開白 

 請聯系小助手微信：15889572951（微信同號）

點擊閱讀原文，下載《通信原理》