【正文】 據(jù)速率管理就不再適用了，應當使用固定的數(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ù)都會累加(是針對于每個新的上行包，重傳包就不再增加計數(shù))，終端增加 ADR_ACK_CNT 計數(shù)。如果直到ADR_ACK_LIMIT次上行(ADR_ACK_CNT = ADR_ACK_LIMIT)都沒有收到下行回復，它就得置高ADR應答請求位(ADRACKReq)。 網(wǎng)絡必須在規(guī)定時間內(nèi)回復一個下行幀，這個時間是通過ADR_ACK_DELAY來設置，上行之后收到任何下行幀就要把ADR_ACK_CNT的計數(shù)重置。當終端在接收時隙中的任何回復下行幀的ACK位字段不需要設置，表示網(wǎng)關仍在接收這個設備的上行幀。如果在下一個ADR_ACK_DELAY上行時間內(nèi)都沒收到回復(例如，在總時間ADR_ACK_LIMIT+ADR_ACK_DELAY之后)，終端必須切換到下一個更低速率，使得能夠獲得更遠傳輸距離來重連網(wǎng)絡。終端如果在每次ADR_ACK_LIMIT到了之后依舊連接不上，就需要每次逐步降低數(shù)據(jù)速率。如果終端用它的默認數(shù)據(jù)速率，那就不需要置位ADRACKReq，因為無法幫助提高鏈路距離。注意：不要ADRACKReq立刻回復，這樣給網(wǎng)絡預留一些余量，讓它做出最好的下行調(diào)度處理。注意：上行傳輸時，如果 ADR_ACK_CNT = ADR_ACK_LIMIT 并且當前數(shù)據(jù)速率比設備的最小數(shù)據(jù)速率高，就要設置 ADRACKReq，其它情況下不需要。 消息應答位及應答流程(ACK in FCtrl)收到confirmed類型的消息時，接收端要回復一條應答消息(應答位ACK要進行置位)。如果發(fā)送者是終端，網(wǎng)絡就利用終端發(fā)送操作后打開的兩個接收窗口之一進行回復。如果發(fā)送者是網(wǎng)關，終端就自行決定是否發(fā)送應答。應答消息只會在收到消息后回復發(fā)送，并且不重發(fā)。注意：為了讓終端盡可能簡單，盡可能減少狀態(tài)，在收到confirmation類型需要確認的數(shù)據(jù)幀，需要立即發(fā)送一個嚴格的應答數(shù)據(jù)幀。或者，終端會延遲發(fā)送應答，在它下一個數(shù)據(jù)幀中再攜帶。 重傳流程當需要應答卻沒收到應答時就會進行重發(fā)，重發(fā)的個數(shù)由終端自己定，可能每個終端都不一樣，這個參數(shù)也可以由網(wǎng)絡服務器來設置調(diào)整。注意：一些應答機制的示例時序圖在第18章中有提供。注意：如果終端設備重發(fā)次數(shù)到達了最大值，它可以降低數(shù)據(jù)速率來重連。至于后面是否再重發(fā)還是說丟棄不管，都取決于終端自己。注意：如果網(wǎng)絡服務器重發(fā)次數(shù)到達了最大值，它就認為該終端掉線了，直到它再收到終端的消息。一旦和終端設備的連接出現(xiàn)問題時，要不要重發(fā)都取決于網(wǎng)絡服務器自己。注意：。 幀掛起位(FPending in FCtrl 只在下行有效)幀掛起位(FPending)只在下行交互中使用，表示網(wǎng)關還有掛起數(shù)據(jù)等待下發(fā)，需要終端盡快發(fā)送上行消息來再打開一個接收窗口。 幀計數(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 （要考慮計數(shù)器滾動），接收方就按接收的幀計數(shù)更新對應值。如果兩者相差大于 MAX_FCNY_GAP 就說明中間丟失了很多數(shù)據(jù)，這條以及后面的數(shù)據(jù)就被丟掉。LoRaWAN的幀計數(shù)器可以用16位和32位兩種，節(jié)點上具體執(zhí)行哪種計數(shù)，需要在帶外通知網(wǎng)絡側(cè)，告知計數(shù)器的位數(shù)。如果采用16位幀計數(shù)，F(xiàn)Cnt字段的值可以使用幀計數(shù)器的值，此時有需要的話通過在前面填充0（值為0）字節(jié)來補足；如果采用32位幀計數(shù)，F(xiàn)Cnt就對應計數(shù)器32位的16個低有效位(上行數(shù)據(jù)使用上行FCnt，下行數(shù)據(jù)使用下行FCnt)。終端在相同應用和網(wǎng)絡密鑰下，不能重復用相同的FCntUp數(shù)值，除非是重傳。 幀可選項(FOptsLen in FCtrl, FOpts)FCtrl 字節(jié)中的FOptsLen位字段描述了整個幀可選項(FOpts)的字段長度。FOpts字段存放MAC命令，最長15字節(jié)。如果FOptsLen為0，則FOpts為空。在FOptsLen非0時，則反之。如果MAC命令在FOpts字段中體現(xiàn)，port0不能用(FPort要么不體現(xiàn)，要么非0)。MAC命令不能同時出現(xiàn)在FRMPayload和FOpts中，如果出現(xiàn)了，設備丟掉該組數(shù)據(jù)。 端口字段(FPort)如果幀載荷字段不為空，端口字段必須體現(xiàn)出來。端口字段有體現(xiàn)時，若FPort的值為0表示FRMPayload只包含了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載荷的最大長度。 MAC幀載荷加密(FRMPayload)如果數(shù)據(jù)幀攜帶了載荷，F(xiàn)RMPayload必須要在MIC計算前進行加密。默認的，加密和加密由LoRaWAN層來給所有的FPort來執(zhí)行。如果加密/解密由應用層來做更方便的話，也可以在LoRaWAN層之上給特定FPorts來執(zhí)行，除了端口0。具體哪個節(jié)點的哪個FPort在LoRaWAN層之外要做加解密，必須要和服務器通過outofband信道來交互(見第19章)。 LoRaWAN的加密密鑰K根據(jù)不同的FPort來使用：FPortK0NwkSKey1..255AppSKey表3: FPort列表具體加密是這樣：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..kS = S1 | S2 | .. | Sk通過異或計算對payload進行加解密： LoRaWAN層之上的加密如果LoRaWAN之上的層級在已選的端口上(但不能是端口0，這是給MAC命令保留的)提供了預加密的FRMPayload給LoRaWAN，LoRaWAN則不再對FRMPayload進行修改，直接將FRMPayload從MACPayload傳到應用層，以及從應用層傳到MACPayload。 消息校驗碼(MIC)消息檢驗碼要計算消息中所有字段。msg = MHDR | FHDR | FPort | FRMPayloadMIC是按照[RFC4493]來計算：cmac = aes128_cmac(NwkSKey, B0 | msg)MIC = cmac[0..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層PreamblePHDRPHDR_CRCPHYPayloadCRC好了，幀格式是大家隨手都能看到的東西，本尊作為IoT小能手，如果不能提出一些稍有深度的信息增量，就對不起這個稱號了。所以，有些協(xié)議設計層面的心得要分享下：1. 特別酷的ADR(速率自適應)機制這個章節(jié)中最亮眼的莫過于速率自適應機制，簡直是為LoRa網(wǎng)絡量身定做的：一旦使能了FCtrl中的ADR位，距離近信號好的節(jié)點用高速率，距離遠信號弱的節(jié)點用低速率，不小心被調(diào)高了速率，則自動降下來。這樣，盡可能地提高了傳輸速率，也有效提高了網(wǎng)絡容量。我已經(jīng)見過不少廠家，拿這個協(xié)議的公知特點當產(chǎn)品賣點了。2. 可同時攜帶數(shù)據(jù)和命令的MAC幀一般來說，應用除了數(shù)據(jù)，出于管理需要，肯定還會涉及命令。比如基站要查詢節(jié)點狀態(tài)，或者節(jié)點要請求變更信道等。所以LoRaWAN協(xié)議設計上利用FOpts把數(shù)據(jù)和命令揉在一個MAC幀里，這樣可以提高交互效率，有效地降低功耗。這在寸土寸金，哦不，寸庫侖(電量單位)寸金的物聯(lián)網(wǎng)應用中，是一個很有必要的設計。3 源碼解析這章的處理基本都在 \src\mac\ 中，下面按照MAC幀格式的字段逐個解析下。 MAC層MHDR在LoRaWAN的數(shù)據(jù)API中處理了MHDR，這個字段內(nèi)容比較少，就按需選擇了消息類型是confirm還是unconfirm。另外在管理API中的JoinReq的消息類型。具體可見 LoRaMacMcpsRequest() 和 LoRaMacMlmeRequest() 這兩個函數(shù)。 MACPayloadMACPayload 的組幀都在 PrepareFrame() 這個函數(shù)中處理，將macHdr和macPayload的fCtrl、FPort、FRMPayload都傳遞進去，完成整個MAC層的數(shù)據(jù)組幀。LoRaMacBuffer就存放了MACPayload的數(shù)據(jù)，這個變量的組幀和協(xié)議字段定義是一一對應。MACPayload的組幀處理，在大流程上是對join和數(shù)據(jù)兩種類型的幀分別處理，用兩個case分開。為了方便閱覽，我把函數(shù)代碼框架提煉了出來。LoRaMacStatus_t PrepareFrame( LoRaMacHeader_t *macHdr, LoRaMacFrameCtrl_t *fCtrl, uint8_t fPort, void *fBuffer, uint16_t fBufferSize ){ switch( macHdr ) { case FRAME_TYPE_JOIN_REQ: ...// 省略 break。 case FRAME_TYPE_DATA_CONFIRMED_UP: NodeAckRequested = true。 //Intentional falltrough case FRAME_TYPE_DATA_UNCONFIRMED_UP: ... fCtrl = AdrNextDr( fCtrl, true, amp。 )。 ... if( SrvAckRequested == true ) { SrvAckRequested = false。 fCtrl = 1。 } LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr ) amp。 0xFF。 LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr 8 ) amp。 0xFF。 LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr 16 ) amp。 0xFF。 LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr 24 ) amp。 0xFF。 LoRaMacBuffer[pktHeaderLen++] = fCtrlValue。 LoRaMacBuffer[pktHeaderLen++] = UpLinkCounter amp。 0xFF。 LoRaMacBuffer[pktHeaderLen++] = ( UpLinkCounter 8 ) amp。 0xFF。