Lorawan協(xié)議說明書Word版

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

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

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

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

5、ass A 的終端在每次上行后都會緊跟兩個短暫的下行接收窗口，以此實現(xiàn)雙向傳輸。傳輸時隙是由終端在有傳輸需要時安排，附加一定的隨機延時(即ALOHA協(xié)議)。這種Class A 操作是最省電的，要求應(yīng)用在終端上行傳輸后的很短時間內(nèi)進行服務(wù)器的下行傳輸。服務(wù)器在其他任何時間進行的下行傳輸都得等終端的下一次上行。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ 劃定接收時隙的雙向傳輸終端(Class B)：Class B 的終端會有更多的接收時隙。除了Class A 的隨機接收窗口，Class B 設(shè)備還會在指定時間打開別的接收窗口。為了讓終端可以在指定時間打開接收窗口，終端需要從網(wǎng)關(guān)接收時間

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

7、3章 PHY 幀格式LoRa 有上行消息和下行消息。3.1 上行消息上行消息是由終端發(fā)出，經(jīng)過一個或多個網(wǎng)關(guān)轉(zhuǎn)發(fā)給網(wǎng)絡(luò)服務(wù)器。上行消息使用 LoRa 射頻幀的嚴格模式，消息中含有 PHDR 和 PHDR_CRC 。載荷有CRC校驗來保證完整性。PHDR，PHDR_CRC 及載荷 CRC 域都通過射頻收發(fā)器加入。上行 PHY:PreamblePHDRPHDR_CRCPHYPayloadCRC圖2.上行PHY幀格式傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！3.2 下行消息下行消息是由網(wǎng)絡(luò)服務(wù)器發(fā)出，經(jīng)過單個網(wǎng)關(guān)轉(zhuǎn)發(fā)給單個終端。下行消息使用射頻幀的嚴格模式，消息中包含 PHDR 和 PH

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

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

10、認是給這個終端，那終端就不必開啟第二個接收窗口。3.3.5 網(wǎng)絡(luò)發(fā)送消息給終端如果網(wǎng)絡(luò)想要發(fā)一個下行消息給終端，它會精確地在兩個接收窗口的起始點發(fā)起傳輸。3.3.6 接收窗口的重要事項終端在第一或第二接收窗口收到下行消息后，或者在第二接收窗口階段，不能再發(fā)起另一個上行消息。3.3.7 其他協(xié)議的收發(fā)處理節(jié)點在LoRaWAN收發(fā)窗口階段可以收發(fā)其他協(xié)議，只要終端能滿足當?shù)匾笠约凹嫒軱oRaWAN協(xié)議。2 梳理解析LoRaWAN第3章，主要是講了接收窗口這回事，只要記住張圖就行。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！目前RX1一般是在上行后1秒開始，RX2是在上行后2秒開始。3

11、源碼分析3.1 源碼流程在梳理這章節(jié)的對應(yīng)代碼時，自己手動做了張思維導(dǎo)圖。有時是這樣，代碼再有層次感，也不及一個圖。好，請收下。3.2 發(fā)送完成就開始RX1和RX2延時static void OnRadioTxDone( void ) . / Setup timers if( IsRxWindowsEnabled = true ) TimerSetValue( &RxWindowTimer1, RxWindow1Delay );傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ TimerStart( &RxWindowTimer1 ); if( LoRaMacDeviceClass !=

12、 CLASS_C ) TimerSetValue( &RxWindowTimer2, RxWindow2Delay ); TimerStart( &RxWindowTimer2 ); if( ( LoRaMacDeviceClass = CLASS_C ) | ( NodeAckRequested = true ) ) TimerSetValue( &AckTimeoutTimer, RxWindow2Delay + ACK_TIMEOUT + randr( -ACK_TIMEOUT_RND, ACK_TIMEOUT_RND ) ); TimerStart( &AckTimeoutTimer

13、); .3.3 接收窗口的射頻處理從上面一步，我們已經(jīng)清晰的知道，對應(yīng)的處理肯定是在OnRxWindow1TimerEvent和OnRxWindow2TimerEvent中。這兩個接收窗口的處理，會對速率和信道進行設(shè)置，按照LoRaWAN協(xié)議中文版_配套文件 地區(qū)參數(shù)(物理層)中對各地區(qū)的要求分別進行處理。比如這個470的處理，對上行信道對48取余得到下行信道。RxWindowSetup( LORAMAC_FIRST_RX1_CHANNEL + ( Channel % 48 ) * LORAMAC_STEPWIDTH_第4章 MAC幀格式LoRa所有上下行鏈路消息都會攜帶PHY載荷，PHY載荷

14、以1字節(jié)MAC頭(MHDR)開始，緊接著MAC載荷(MACPayload)，最后是4字節(jié)的MAC校驗碼(MIC)。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！射頻PHY層：PreamblePHDRPHDR_CRCPHYPayloadCRC圖5.射頻PHY結(jié)構(gòu)(注意 CRC只有上行鏈路消息中存在)PHY載荷：MHDRMACPayloadMIC或者MHDRJoin-RequestMIC或者MHDRJoin-ResponseMIC圖6.PHY載荷結(jié)構(gòu)MAC載荷：FHDRFPortFRMPayload圖7.MAC載荷結(jié)構(gòu)FHDR：DevAddrFCtrlFCntFOpts圖8.幀頭結(jié)構(gòu)圖9.

15、LoRa幀格式元素(即圖58)4.1 MAC層(PHYPayload)Size (bytes)11.M4PHYPayloadMHDRMACPayloadMICMACPayload字段的最大長度M，在第6章有詳細說明。4.2 MAC頭(MHDR字段)傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！Bit#7.54.21.0MHDR bitsMTypeRFUMajorMAC頭中指定了消息類型(MType)和幀編碼所遵循的LoRaWAN規(guī)范的主版本號(Major)。4.2.1 消息類型(MType位字段)LoRaWAN定義了六個不同的MAC消息類型：join request, join acc

16、ept, unconfirmed data up/down, 以及 confirmed data up/down 。MType描述000Join Request001Join Accept010Unconfirmed 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

17、.1.2 Data messagesData messages 用來傳輸MAC命令和應(yīng)用數(shù)據(jù)，這兩種命令也可以放在單個消息中發(fā)送。Confirmed-data message 接收者需要應(yīng)答。Unconfirmed-data message 接收者則不需要應(yīng)答。Proprietary messages 用來處理非標準的消息格式，不能和標準消息互通，只能用來和具有相同拓展格式的消息進行通信。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！不同消息類型用不同的方法保證消息一致性，下面會介紹每種消息類型的具體情況。4.2.2 數(shù)據(jù)消息的主版本(Major位字段)Major位字段描述00LoRa

18、WAN R101.11RFU表2.Major列表注意：Major定義了激活過程中(join procedure)使用的消息格式（見章節(jié)6.2）和MAC Payload的前4字節(jié)（見第4章）。終端要根據(jù)不同的主版本號實現(xiàn)不同最小版本的消息格式。終端使用的最小版本應(yīng)當提前通知網(wǎng)絡(luò)服務(wù)器。4.3 MAC載荷(MACPayload)MAC載荷，也就是所謂的“數(shù)據(jù)幀”，包含：幀頭（FHDR）、端口（FPort）以及幀載荷(FRMPayload），其中端口和幀載荷是可選的。4.3.1 幀頭(FHDR)FHDR是由終端短地址(DevAddr)、1字節(jié)幀控制字節(jié)(FCtrl)、2字節(jié)幀計數(shù)器(FCnt)和用來

19、傳輸MAC命令的幀選項(FOpts，最多15個字節(jié))組成。Size(bytes)4120.15FHDRDevAddrFCtrlFCntFOptsFCtrl在上下行消息中有所不同，下行消息如下：Bit#76543.0FCtrl bitsADRADRACKReqACKFPendingFOptsLen上行消息如下：Bit#76543.0FCtrl bitsADRADRACKReqACKRFUFOptsLen 4.3.1.1 幀頭中 自適應(yīng)數(shù)據(jù)速率 的控制(ADR, ADRACKReq in FCtrl)傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！LoRa網(wǎng)絡(luò)允許終端采用任何可能的數(shù)據(jù)速率。

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

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

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

23、_CNT = ADR_ACK_LIMIT 并且當前數(shù)據(jù)速率比設(shè)備的最小數(shù)據(jù)速率高，就要設(shè)置 ADRACKReq，其它情況下不需要。 4.3.1.2 消息應(yīng)答位及應(yīng)答流程(ACK in FCtrl)收到confirmed類型的消息時，接收端要回復(fù)一條應(yīng)答消息(應(yīng)答位ACK要進行置位)。如果發(fā)送者是終端，網(wǎng)絡(luò)就利用終端發(fā)送操作后打開的兩個接收窗口之一進行回復(fù)。如果發(fā)送者是網(wǎng)關(guān)，終端就自行決定是否發(fā)送應(yīng)答。應(yīng)答消息只會在收到消息后回復(fù)發(fā)送，并且不重發(fā)。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！注意：為了讓終端盡可能簡單，盡可能減少狀態(tài)，在收到confirmation類型需要確認的數(shù)據(jù)幀，

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

25、節(jié)18.4中有描述。 4.3.1.4 幀掛起位(FPending in FCtrl 只在下行有效)幀掛起位(FPending)只在下行交互中使用，表示網(wǎng)關(guān)還有掛起數(shù)據(jù)等待下發(fā)，需要終端盡快發(fā)送上行消息來再打開一個接收窗口。FPending的詳細用法在章節(jié)18.3。 4.3.1.5 幀計數(shù)器(FCnt)每個終端有兩個計數(shù)器跟蹤數(shù)據(jù)幀的個數(shù)，一個是上行鏈路計數(shù)器（FCntUp），由終端在每次上行數(shù)據(jù)給網(wǎng)絡(luò)服務(wù)器時累加；另一個是下行鏈路計數(shù)器（FCntDown），由服務(wù)器在每次下行數(shù)據(jù)給終端時累計。 網(wǎng)絡(luò)服務(wù)器為每個終端跟蹤上行幀計數(shù)及產(chǎn)生下行幀計數(shù)。 終端入網(wǎng)成功后，終端和服務(wù)端的上下行幀計數(shù)同時

26、置0。 每次發(fā)送消息后，發(fā)送端與之對應(yīng)的 FCntUp 或 FCntDown 就會加1。 接收方會同步保存接收數(shù)據(jù)的幀計數(shù)，對比收到的計數(shù)值和當前保存的值，如果兩者相差小于 MAX_FCNT_GAP （要考慮計數(shù)器滾動），接收方就按接收的幀計數(shù)更新對應(yīng)值。如果兩者相差大于 MAX_FCNY_GAP 就說明中間丟失了很多數(shù)據(jù)，這條以及后面的數(shù)據(jù)就被丟掉。LoRaWAN的幀計數(shù)器可以用16位和32位兩種，節(jié)點上具體執(zhí)行哪種計數(shù)，需要在帶外通知網(wǎng)絡(luò)側(cè)，告知計數(shù)器的位數(shù)。如果采用16位幀計數(shù)，傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！FCnt字段的值可以使用幀計數(shù)器的值，此時有需要的話通過

27、在前面填充0（值為0）字節(jié)來補足；如果采用32位幀計數(shù)，F(xiàn)Cnt就對應(yīng)計數(shù)器32位的16個低有效位(上行數(shù)據(jù)使用上行FCnt，下行數(shù)據(jù)使用下行FCnt)。終端在相同應(yīng)用和網(wǎng)絡(luò)密鑰下，不能重復(fù)用相同的FCntUp數(shù)值，除非是重傳。 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不能用(

28、FPort要么不體現(xiàn)，要么非0)。MAC命令不能同時出現(xiàn)在FRMPayload和FOpts中，如果出現(xiàn)了，設(shè)備丟掉該組數(shù)據(jù)。4.3.2 端口字段(FPort)如果幀載荷字段不為空，端口字段必須體現(xiàn)出來。端口字段有體現(xiàn)時，若FPort的值為0表示FRMPayload只包含了MAC命令；具體見章節(jié)4.4中的MAC命令。 FPort的數(shù)值從1到223(0x01.0xDF)都是由應(yīng)用層使用。 FPort的值從224到255(0xE0.0xFF)是保留用做未來的標準應(yīng)用拓展。Size(bytes)7.230.10.NMACPayloadFHDRFPortFRMPayloadN是應(yīng)用程序載荷的字節(jié)個數(shù)。N

29、的有效范圍具體在第7章有定義。N應(yīng)該小于等于：N Bits.MType ) case FRAME_TYPE_JOIN_REQ: ./ 省略 break; case FRAME_TYPE_DATA_CONFIRMED_UP: NodeAckRequested = true; /Intentional falltrough case FRAME_TYPE_DATA_UNCONFIRMED_UP: . fCtrl-Bits.AdrAckReq = AdrNextDr( fCtrl-Bits.Adr, true, &LoRaMacParams.ChannelsDatarate ); . if( Srv

30、AckRequested = true ) SrvAckRequested = false; fCtrl-Bits.Ack = 1; LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr ) & 0xFF; LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr 8 ) & 0xFF;傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr 16 ) & 0xFF; LoRaMacBufferpktHeaderLen+ = ( Lo

31、RaMacDevAddr 24 ) & 0xFF; LoRaMacBufferpktHeaderLen+ = fCtrl-Value; LoRaMacBufferpktHeaderLen+ = UpLinkCounter & 0xFF; LoRaMacBufferpktHeaderLen+ = ( UpLinkCounter 8 ) & 0xFF; / Copy the MAC commands which must be re-send into the MAC command buffer memcpy1( &MacCommandsBufferMacCommandsBufferIndex,

32、 MacCommandsBufferToRepeat, MacCommandsBufferToRepeatIndex ); MacCommandsBufferIndex += MacCommandsBufferToRepeatIndex; if( ( payload != NULL ) & ( payloadSize 0 ) ) if( ( MacCommandsBufferIndex Bits.FOptsLen += MacCommandsBufferIndex; / Update FCtrl field with new value of OptionsLength LoRaMacBuff

33、er0x05 = fCtrl-Value; for( i = 0; i 0 ) & ( MacCommandsInNextTx ) ) payloadSize = MacCommandsBufferIndex; payload = MacCommandsBuffer; framePort = 0; MacCommandsInNextTx = false; / Store MAC commands which must be re-send in case the device does not receive a downlink anymore MacCommandsBufferToRepe

34、atIndex = ParseMacCommandsToRepeat( MacCommandsBuffer, MacCommandsBufferIndex, MacCommandsBufferToRepeat ); if( MacCommandsBufferToRepeatIndex 0 ) MacCommandsInNextTx = true; MacCommandsBufferIndex = 0; if( ( payload != NULL ) & ( payloadSize 0 ) ) LoRaMacBufferpktHeaderLen+ = framePort; if( framePo

35、rt = 0 ) LoRaMacPayloadEncrypt( (uint8_t* ) payload, payloadSize, LoRaMacNwkSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, LoRaMacPayload );傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ else LoRaMacPayloadEncrypt( (uint8_t* ) payload, payloadSize, LoRaMacAppSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, LoRaMacPayload

36、); memcpy1( LoRaMacBuffer + pktHeaderLen, LoRaMacPayload, payloadSize ); LoRaMacBufferPktLen = pktHeaderLen + payloadSize; LoRaMacComputeMic( LoRaMacBuffer, LoRaMacBufferPktLen, LoRaMacNwkSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, &mic ); LoRaMacBufferLoRaMacBufferPktLen + 0 = mic & 0xFF; LoRaMac

37、BufferLoRaMacBufferPktLen + 1 = ( mic 8 ) & 0xFF; LoRaMacBufferLoRaMacBufferPktLen + 2 = ( mic 16 ) & 0xFF; LoRaMacBufferLoRaMacBufferPktLen + 3 = ( mic 24 ) & 0xFF; LoRaMacBufferPktLen += LORAMAC_MFR_LEN; break; case FRAME_TYPE_PROPRIETARY: ./ 省略 break; default: return LORAMAC_STATUS_SERVICE_UNKNOW

38、N; return LORAMAC_STATUS_OK;傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！Join-request的組幀處理對應(yīng)協(xié)議第6章 6.2.4 Join-request message。數(shù)據(jù)幀的組幀處理則稍微復(fù)雜些，尤其是FHDR，下面逐個字段講解下FHDR。3.2.1 MACPayload中的FHDR 1.FHDR中的DevAddrLoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr ) & 0xFF;LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr 8 ) & 0xFF;LoRaMa

39、cBufferpktHeaderLen+ = ( LoRaMacDevAddr 16 ) & 0xFF;LoRaMacBufferpktHeaderLen+ = ( LoRaMacDevAddr 24 ) & 0xFF; 2.FHDR中的FCtrl首先 ADR 位段 是在傳入 PrepareFrame() 之前，就做了處理。fCtrl.Bits.Adr = AdrCtrlOn;接著 AdrAckReq 位段，在長期失聯(lián)情況下會發(fā)送AdrAckReq確認鏈路。fCtrl-Bits.AdrAckReq = AdrNextDr( fCtrl-Bits.Adr, true, &LoRaMacParam

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

41、F0pts中，并且更新F0ptsLen。MAC命令，要么使用非零的FPort來和數(shù)據(jù)一起傳輸，要么使用FPort0來單獨傳輸。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！/ Copy the MAC commands which must be re-send into the MAC command buffermemcpy1( &MacCommandsBufferMacCommandsBufferIndex, MacCommandsBufferToRepeat, MacCommandsBufferToRepeatIndex );MacCommandsBufferIndex +=

42、MacCommandsBufferToRepeatIndex;if( ( payload != NULL ) & ( payloadSize 0 ) ) if( ( MacCommandsBufferIndex Bits.FOptsLen += MacCommandsBufferIndex; / Update FCtrl field with new value of OptionsLength LoRaMacBuffer0x05 = fCtrl-Value; for( i = 0; i 0 ) & ( MacCommandsInNextTx ) ) payloadSize = MacCommandsBufferIndex; payload = MacCommandsBuffer; framePort = 0; 傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！3.2.2 MACPayload中的FPort這個是在應(yīng)用層一直傳遞進去的，協(xié)議棧默認是用了端口2。這個是后期大家在應(yīng)用時要調(diào)整的，類似于IP端口，不同的端口對應(yīng)不同的服務(wù)。