Lorawan協(xié)議說明書可編輯范本

第1章介紹本文檔描述了LoRａWＡN網(wǎng)絡(luò)協(xié)議,是針對電池供電的終端設(shè)備（不管移動還是固定位置)進行優(yōu)化的一套網(wǎng)絡(luò)協(xié)議.LoＲaWAN網(wǎng)絡(luò)通常采用星型拓撲結(jié)構(gòu),由拓撲中的網(wǎng)關(guān)來轉(zhuǎn)發(fā)終端與后臺網(wǎng)絡(luò)服務(wù)器間的消息。網(wǎng)關(guān)通過標準ＩP連接來接入網(wǎng)絡(luò)服務(wù)器，而終端則通過單跳的LoＲa或者ＦSＫ來和一個或多個網(wǎng)關(guān)通訊。雖然主要傳輸方式是終端上行傳輸給網(wǎng)絡(luò)服務(wù)器,但所有的傳輸通常都是雙向的.終端和網(wǎng)關(guān)間的通訊被分散到不同的信道頻點和數(shù)據(jù)速率上。數(shù)據(jù)速率的選擇需要權(quán)衡距離和消息時長兩個因素，使用不同數(shù)據(jù)速率的設(shè)備互不影響。LｏＲa的數(shù)據(jù)速率范圍可以從0。3kbｐs到50kbps.為了最大程度地延長終端的電池壽命和擴大網(wǎng)絡(luò)容量,LoRa網(wǎng)絡(luò)使用速率自適應(yīng)(ADＲ）機制來獨立管理每個終端的速率和RＦ輸出。雖然每個設(shè)備可以在任意信道,任意時間,發(fā)送任意數(shù)據(jù),但需要注意遵守如下規(guī)定:終端的每次傳輸都使用偽隨機方式來改變信道。頻率的多變使得系統(tǒng)具有更強的抗干擾能力。終端要遵守相應(yīng)頻段和本地區(qū)的無線電規(guī)定中的發(fā)射占空比要求。終端要遵守相應(yīng)頻段和本地區(qū)的無線電規(guī)定中的發(fā)射時長要求.twoｗinter注:發(fā)射占空比，意思是發(fā)射時長占總時長的比例。按照無線電規(guī)定，每個設(shè)備不能瘋狂發(fā)射霸占信道，總得給別人一點機會。這份文檔主要講述協(xié)議細節(jié)，一些基于各地區(qū)規(guī)定的操作參數(shù),例如發(fā)射占空比和發(fā)射時長等,在另一份文檔[LoRａWAＮ地區(qū)參數(shù)］中做具體描述。將這份文檔分開,是為了加入新地區(qū)參數(shù)時不影響基礎(chǔ)的協(xié)議規(guī)范。1。1LoＲaWANClａsseｓ所有的LoＲaWAN設(shè)備都必須至少實現(xiàn)本文檔描述的ＣlasｓA功能。另外也可以實現(xiàn)本文檔中描述的ＣlaｓsB和ClasｓC及后續(xù)將定義的可選功能。不管怎么樣,設(shè)備都必須兼容CｌａssA.1。2文檔約定MAC命令的格式寫作

ＬinｋCheckReq

(粗斜體),位和位域的格式寫作

FRMPayloaｄ

(粗體）,常量的格式寫作RＥCEIＶE＿DELAY1,變量的格式寫作Ｎ。在本文檔中，所有多字節(jié)字段的字節(jié)序均采用小端模式EＵI是8字節(jié)字段,采用小端模式傳輸默認所有ＲFU保留位都設(shè)為0第2章LoＲaWＡNClaｓsｅｓ類型介紹LoRａ是由Semtech面向長距離、低功耗、低速率應(yīng)用而開發(fā)的無線調(diào)制技術(shù).本文檔中，將ClａssA基礎(chǔ)上實現(xiàn)了更多功能的設(shè)備稱為“更高claｓｓ終端”。２。1LoＲaＷANClaｓｓesLoRａ網(wǎng)絡(luò)包含基礎(chǔ)ＬoRaWAN(稱之為ＣlａssA)和可選功能(ＣlａsｓB，CｌaｓsC):

?圖1。ＬoRaWＡNClasses雙向傳輸終端（CｌassA）：

ＣｌasｓＡ的終端在每次上行后都會緊跟兩個短暫的下行接收窗口，以此實現(xiàn)雙向傳輸。傳輸時隙是由終端在有傳輸需要時安排，附加一定的隨機延時（即ALＯHＡ協(xié)議）。這種ClassA操作是最省電的,要求應(yīng)用在終端上行傳輸后的很短時間內(nèi)進行服務(wù)器的下行傳輸。服務(wù)器在其他任何時間進行的下行傳輸都得等終端的下一次上行。劃定接收時隙的雙向傳輸終端（ClassB）:

ClasｓB的終端會有更多的接收時隙。除了ClassＡ的隨機接收窗口,ＣｌaｓsＢ設(shè)備還會在指定時間打開別的接收窗口。為了讓終端可以在指定時間打開接收窗口，終端需要從網(wǎng)關(guān)接收時間同步的信標Ｂeacon。這使得服務(wù)器可以知道終端正在監(jiān)聽。最大化接收時隙的雙向傳輸終端(ClａｓsC):

ClassＣ的終端基本是一直打開著接收窗口，只在發(fā)送時短暫關(guān)閉.ClａｓｓC的終端會比ClａssA和ClａｓｓB

?更加耗電,但同時從服務(wù)器下發(fā)給終端的時延也是最短的。2.２文檔范圍這份LoＲａWAN協(xié)議還描述了與ClassA不同的其他Ｃlａsｓ的額外功能。更高Class的終端必須滿足ClａｓsA定義的所有功能。注意：物理層幀格式,ＭAＣ幀格式，以及協(xié)議中更高ｃlass和ClassＡ相同的內(nèi)容都寫在了ＣｌａssA部分，避免內(nèi)容重復.第３章PHY幀格式LoRa有上行消息和下行消息。3。1上行消息上行消息是由終端發(fā)出,經(jīng)過一個或多個網(wǎng)關(guān)轉(zhuǎn)發(fā)給網(wǎng)絡(luò)服務(wù)器。上行消息使用LoRa射頻幀的嚴格模式，消息中含有PＨDＲ和PHDR_CRC。載荷有CRＣ校驗來保證完整性。PHDR,PHDＲ_CRC及載荷CRＣ域都通過射頻收發(fā)器加入。上行PHＹ：ＰｒｅaｍblｅPHDＲＰHDＲ_CRCPＨYPayｌｏadＣRＣ圖2。上行PHY幀格式3。2下行消息下行消息是由網(wǎng)絡(luò)服務(wù)器發(fā)出，經(jīng)過單個網(wǎng)關(guān)轉(zhuǎn)發(fā)給單個終端。下行消息使用射頻幀的嚴格模式,消息中包含PHDＲ和PHDR_ＣRC.下行PHY：ＰrｅamblePHDRＰHDR_CＲCPHＹPaｙload圖3。下行PHY幀格式３。3接收窗口每個上行傳輸后終端都要開兩個短的接收窗口。接收窗口開始時間的規(guī)定,是以傳輸結(jié)束時間為參考。

?圖4。終端接收時隙的時序圖３。３。1第一接收窗口的信道,數(shù)據(jù)速率和啟動。第一接收窗口RX1使用的頻率和上行頻率有關(guān),使用的速率和上行速率有關(guān)．ＲX１是在上行調(diào)制結(jié)束后的RECEIVE_ＤEＬAＹ1秒打開。上行和ＲX1時隙下行速率的關(guān)系是按區(qū)域規(guī)定,詳細描述在[ＬoRaWＡＮ地區(qū)參數(shù)]文件中。默認第一窗口的速率是和最后一次上行的速率相同。3.3。２第二接收窗口的信道,數(shù)據(jù)速率和啟動。第二接收窗口RＸ2使用一個固定可配置的頻率和數(shù)據(jù)速率,在上行調(diào)制結(jié)束后的REＣＥIVＥ_DＥLAＹ2秒打開。頻率和數(shù)據(jù)速率可以通過MAC命令(見第5章).默認的頻率和速率是按區(qū)域規(guī)定,詳細描述在[LoRaWAＮ地區(qū)參數(shù)］文件中.３。3．3接收窗口的持續(xù)時間接收窗口的長度至少要讓終端射頻收發(fā)器有足夠的時間來檢測到下行的前導碼。3.３.4接收方在接收窗口期間的處理如果在任何一個接收窗口中檢測到前導碼,射頻收發(fā)器需要繼續(xù)激活,直到整個下行幀都解調(diào)完畢。如果在第一接收窗口檢測到數(shù)據(jù)幀，且這個數(shù)據(jù)幀的地址和ＭIC校驗通過確認是給這個終端,那終端就不必開啟第二個接收窗口。3。3．5網(wǎng)絡(luò)發(fā)送消息給終端如果網(wǎng)絡(luò)想要發(fā)一個下行消息給終端,它會精確地在兩個接收窗口的起始點發(fā)起傳輸。3．３．6接收窗口的重要事項終端在第一或第二接收窗口收到下行消息后，或者在第二接收窗口階段，不能再發(fā)起另一個上行消息。3。３。7其他協(xié)議的收發(fā)處理節(jié)點在LoRaWAN收發(fā)窗口階段可以收發(fā)其他協(xié)議，只要終端能滿足當?shù)匾笠约凹嫒軱oＲaWAN協(xié)議．2梳理解析LoRａWAＮ第3章,主要是講了接收窗口這回事,只要記住張圖就行．目前RX1一般是在上行后1秒開始，ＲX２是在上行后2秒開始。3源碼分析3.1源碼流程在梳理這章節(jié)的對應(yīng)代碼時,自己手動做了張思維導圖。有時是這樣,代碼再有層次感,也不及一個圖.好，請收下。3.2發(fā)送完成就開始RＸ1和RX２延時staｔｉcvｏidOnRａdioTｘDｏｎe(void)｛。．。/／Setupｔｉmｅrsif（ＩsRxWindowsEnaｂleｄ==true){TimerSetＶalue(＆RxWｉｎdowTｉmeｒ1，ＲxWiｎdｏw1Ｄelａy)；TimｅｒＳtart（&RxWindowＴimer1)；if(LoRａMacDeviceClａsｓ！=ＣLAＳS_C){TｉmerＳetValue(＆RxWｉndowＴiｍｅr2,ＲxＷｉnｄｏｗ2Ｄeｌay);TｉｍerＳtart(&RｘＷinｄｏwＴｉｍer2)；}if(（LoRaＭａcDevｉceClasｓ＝=ＣLASＳ_C)||(NｏdｅAｃkRｅquｅsteｄ=＝trｕe））｛TimerSetVａlｕｅ（&ＡcｋTｉmeoutＴｉmer，ＲxWiｎdow2Dｅlａy+ＡCK＿TＩMＥOUＴ＋rａnｄr(－ACK_TIMEOUT_RNＤ，ACK＿TIMEＯUT_ＲＮD）);TimerＳtａrt（&AckＴimｅｏutTimer）;}｝.。．}3。3接收窗口的射頻處理從上面一步，我們已經(jīng)清晰的知道，對應(yīng)的處理肯定是在OnRｘWindoｗ１TiｍｅｒEvent和OｎRxWiｎｄow2TiｍeｒＥvent中。

這兩個接收窗口的處理,會對速率和信道進行設(shè)置,按照HＹＰERLINK”hｔtｐ:/／blog.cｓdn。nｅt/ｉotisaｎ/artiｃlｅ／dｅtails/５５０5６092"＼t”＿bｌaｎk”LoＲaWＡN協(xié)議中文版_配套文件地區(qū)參數(shù)(物理層）

中對各地區(qū)的要求分別進行處理。比如這個4７0的處理，對上行信道對48取余得到下行信道．RxWindｏwSetｕp(LORAMAC_ＦＩRST＿RＸ1_ＣHＡNＮEL+(Chaｎnel%４8)*LＯRAＭAC_ＳTEPWIDTH＿第4章MAＣ幀格式LoRa所有上下行鏈路消息都會攜帶PHY載荷,ＰHY載荷以1字節(jié)MAＣ頭(ＭＨDR)開始,緊接著ＭAＣ載荷(MACＰayload)，最后是4字節(jié)的ＭAC校驗碼(MIC)。射頻ＰHY層：PreaｍbｌePＨDRPＨＤＲ_CRCPＨYPaylｏadＣRC圖5。射頻PHY結(jié)構(gòu)（注意CRC只有上行鏈路消息中存在)PHＹ載荷：MHDRMACPaylｏａdMIＣ或者MＨDRJoin—RequestMIC或者MＨDＲＪｏｉn－ＲesｐｏnｓeMIC圖6.PＨＹ載荷結(jié)構(gòu)MAC載荷：FHDRFPortFRＭPaｙloaｄ圖7．ＭAC載荷結(jié)構(gòu)FHDＲ:DevAdｄrFCtｒｌFCntFＯpts圖８．幀頭結(jié)構(gòu)圖9。ＬoRa幀格式元素(即圖5~8)4．1MAC層(ＰHYＰaylｏad)Siｚe(bytes)１1..M4PHＹPayloａdＭHDRMAＣPaylｏａdＭICMＡCPayloａd字段的最大長度Ｍ，在第6章有詳細說明。4.2MAC頭(MHDR字段)Bｉｔ#7.。5４。.21.。０MＨDRbｉtsＭTyｐｅRFUMajorＭＡC頭中指定了消息類型（MType)和幀編碼所遵循的LoＲａWAN規(guī)范的主版本號(Major)。4。2。1消息類型(MTｙpe位字段)ＬoRaWAN定義了六個不同的MAC消息類型：jｏinrequeｓt,joinａccｅpt,uncｏnfｉｒmeｄdataup/dｏwn，以及confirｍｅdｄａt(yī)ａup／dｏwｎ。MType描述000JoinＲequest001ＪｏinＡccept010UｎｃonｆiｒmedDatａＵｐ01１UnconfirｍｅdDａt(yī)aDown100ConｆirmｅdDａt(yī)aＵp１0１ＣonfirmedDａt(yī)aDown11０RFＵ111Pｒoｐｒｉetarｙ表1。MＡＣ消息類型4。2。１.1Jｏｉn—ｒequｅstａndjoiｎ—acｃeｐt消息joｉn-reｑuest和joｉn—aｃcept都是用在空中激活流程中，具體見章節(jié)6。２4．2.1.2DatamessａｇesＤatameｓsages用來傳輸MAC命令和應(yīng)用數(shù)據(jù)，這兩種命令也可以放在單個消息中發(fā)送。

Confirｍeｄ-dａt(yī)ａｍesｓage接收者需要應(yīng)答。

Uｎconfirmed—daｔａmeｓsage接收者則不需要應(yīng)答.

Ｐrｏprietarymｅsｓagｅs用來處理非標準的消息格式，不能和標準消息互通，只能用來和具有相同拓展格式的消息進行通信。不同消息類型用不同的方法保證消息一致性,下面會介紹每種消息類型的具體情況。4。2.2數(shù)據(jù)消息的主版本(Major位字段)Ｍａjor位字段描述00LoRaWAＮR101..11RFU表2.Mａjor列表注意：Ｍajor定義了激活過程中(joinprocｅdurｅ）使用的消息格式(見章節(jié)6.2）和MACＰaylｏad的前4字節(jié)（見第4章）。終端要根據(jù)不同的主版本號實現(xiàn)不同最小版本的消息格式。終端使用的最小版本應(yīng)當提前通知網(wǎng)絡(luò)服務(wù)器。4.3MAC載荷（MACPａyｌｏaｄ)MAC載荷，也就是所謂的“數(shù)據(jù)幀”,包含:幀頭(ＦHＤR)、端口（FPort）以及幀載荷(FRＭPaｙloａd），其中端口和幀載荷是可選的.4.３。1幀頭(ＦHDＲ)FHDR是由終端短地址(ＤevＡddr)、1字節(jié)幀控制字節(jié)（FCｔrl）、2字節(jié)幀計數(shù)器(FＣnt）和用來傳輸MＡＣ命令的幀選項(FOpｔs,最多15個字節(jié)）組成。Sｉze（bｙｔes)４120．.１5FHＤRDeｖAｄｄrFCtrlＦCntFOptｓFＣｔrl在上下行消息中有所不同,下行消息如下:Bit#76５4[3。。0］FCtrlbitsADRADRAＣKReｑACＫFＰeｎｄｉnｇFOｐtｓLeｎ上行消息如下：Bｉt＃7654［3..0］ＦＣtｒｌbitｓADＲAＤRＡCKＲeqACKRFUFOpｔsLｅn4。3。1。1幀頭中自適應(yīng)數(shù)據(jù)速率的控制(ADR，ADRACKReqｉnFCtｒl)ＬoRa網(wǎng)絡(luò)允許終端采用任何可能的數(shù)據(jù)速率。LｏRaWAN協(xié)議利用該特性來優(yōu)化固定終端的數(shù)據(jù)速率。這就是自適應(yīng)數(shù)據(jù)速率(ＡdaptiveＤaｔaRatｅ（ADR)).當這個使能時,網(wǎng)絡(luò)會優(yōu)化使得盡可能使用最快的數(shù)據(jù)速率。移動的終端由于射頻環(huán)境的快速變化,數(shù)據(jù)速率管理就不再適用了，應(yīng)當使用固定的數(shù)據(jù)速率。如果ADR的位字段有置位,網(wǎng)絡(luò)就會通過相應(yīng)的MAＣ命令來控制終端設(shè)備的數(shù)據(jù)速率。如果ADR位沒設(shè)置，網(wǎng)絡(luò)則無視終端的接收信號強度，不再控制終端設(shè)備的數(shù)據(jù)速率。ADR位可以根據(jù)需要通過終端及網(wǎng)絡(luò)來設(shè)置或取消。不管怎樣,ADR機制都應(yīng)該盡可能使能，幫助終端延長電池壽命和擴大網(wǎng)絡(luò)容量。注意：即使是移動的終端，可能在大部分時間也是處于非移動狀態(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ù)),終端增加AＤR_ACK_CNT計數(shù)。如果直到ADＲ＿ＡCK_LIMIT次上行(ADR＿ACK_CNT＞=ADR_AＣＫ_LＩMＩＴ)都沒有收到下行回復,它就得置高ＡDR應(yīng)答請求位（ADRACKＲeq)。網(wǎng)絡(luò)必須在規(guī)定時間內(nèi)回復一個下行幀,這個時間是通過AＤR_ＡCK＿ＤＥLAY來設(shè)置,上行之后收到任何下行幀就要把ADR_ＡCK＿CNＴ的計數(shù)重置。當終端在接收時隙中的任何回復下行幀的ACK位字段不需要設(shè)置,表示網(wǎng)關(guān)仍在接收這個設(shè)備的上行幀。如果在下一個AＤＲ_ACK_DELＡＹ上行時間內(nèi)都沒收到回復(例如，在總時間AＤR_ＡＣＫ_LＩMIT+ADR_ＡCK＿DELAY之后)，終端必須切換到下一個更低速率,使得能夠獲得更遠傳輸距離來重連網(wǎng)絡(luò).終端如果在每次AＤR_AＣＫ_LIMIT到了之后依舊連接不上，就需要每次逐步降低數(shù)據(jù)速率．如果終端用它的默認數(shù)據(jù)速率,那就不需要置位ADＲAＣKＲｅq,因為無法幫助提高鏈路距離。注意：不要ADRＡＣKＲeｑ立刻回復,這樣給網(wǎng)絡(luò)預留一些余量,讓它做出最好的下行調(diào)度處理。注意:上行傳輸時，如果AＤR＿ACK_ＣNＴ〉=ＡDR_ＡＣK_LIMＩT并且當前數(shù)據(jù)速率比設(shè)備的最小數(shù)據(jù)速率高，就要設(shè)置ADRACＫＲeq,其它情況下不需要.4．3。1。2消息應(yīng)答位及應(yīng)答流程(ＡCKinFCｔrl）收到confirmed類型的消息時,接收端要回復一條應(yīng)答消息(應(yīng)答位AＣK要進行置位）。如果發(fā)送者是終端，網(wǎng)絡(luò)就利用終端發(fā)送操作后打開的兩個接收窗口之一進行回復。如果發(fā)送者是網(wǎng)關(guān),終端就自行決定是否發(fā)送應(yīng)答。

?應(yīng)答消息只會在收到消息后回復發(fā)送,并且不重發(fā)。注意:為了讓終端盡可能簡單，盡可能減少狀態(tài)，在收到ｃonfｉrmatiｏn類型需要確認的數(shù)據(jù)幀,需要立即發(fā)送一個嚴格的應(yīng)答數(shù)據(jù)幀。或者,終端會延遲發(fā)送應(yīng)答,在它下一個數(shù)據(jù)幀中再攜帶.4。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ù)速率回退的建議策略在章節(jié)1８。４中有描述.4。3。1.4幀掛起位(ＦＰendiｎginＦCｔｒl只在下行有效）幀掛起位(FPｅnding)只在下行交互中使用,表示網(wǎng)關(guān)還有掛起數(shù)據(jù)等待下發(fā),需要終端盡快發(fā)送上行消息來再打開一個接收窗口.FＰｅｎdｉnｇ的詳細用法在章節(jié)18．3。4．３。1.5幀計數(shù)器（FCnｔ）每個終端有兩個計數(shù)器跟蹤數(shù)據(jù)幀的個數(shù)，一個是上行鏈路計數(shù)器（FCntUp）,由終端在每次上行數(shù)據(jù)給網(wǎng)絡(luò)服務(wù)器時累加;另一個是下行鏈路計數(shù)器（FCntDowｎ)，由服務(wù)器在每次下行數(shù)據(jù)給終端時累計。網(wǎng)絡(luò)服務(wù)器為每個終端跟蹤上行幀計數(shù)及產(chǎn)生下行幀計數(shù)。終端入網(wǎng)成功后,終端和服務(wù)端的上下行幀計數(shù)同時置0。每次發(fā)送消息后,發(fā)送端與之對應(yīng)的FCntUp或FＣｎｔＤowｎ就會加１。接收方會同步保存接收數(shù)據(jù)的幀計數(shù),對比收到的計數(shù)值和當前保存的值,如果兩者相差小于ＭAＸ_FＣNT_GＡP(要考慮計數(shù)器滾動），接收方就按接收的幀計數(shù)更新對應(yīng)值.如果兩者相差大于ＭＡX_ＦCＮY_ＧＡP就說明中間丟失了很多數(shù)據(jù),這條以及后面的數(shù)據(jù)就被丟掉。ＬoRaＷAＮ的幀計數(shù)器可以用16位和３2位兩種，節(jié)點上具體執(zhí)行哪種計數(shù)，需要在帶外通知網(wǎng)絡(luò)側(cè),告知計數(shù)器的位數(shù)。

?如果采用16位幀計數(shù)，F(xiàn)Cnt字段的值可以使用幀計數(shù)器的值,此時有需要的話通過在前面填充0（值為0）字節(jié)來補足;如果采用32位幀計數(shù)，

?FＣnt就對應(yīng)計數(shù)器32位的16個低有效位(上行數(shù)據(jù)使用上行FCnｔ，下行數(shù)據(jù)使用下行FCｎt）。終端在相同應(yīng)用和網(wǎng)絡(luò)密鑰下,不能重復用相同的FCntUp數(shù)值,除非是重傳。４.3.1。６幀可選項（FＯptｓＬeninＦＣtｒl,FＯptｓ)

?FCtrl字節(jié)中的FOｐtsＬｅn位字段描述了整個幀可選項（ＦOpts)的字段長度.FOｐts字段存放MAC命令,最長15字節(jié)，詳細的MAＣ命令見章節(jié)4.4.如果FOptsLｅn為0,則ＦＯｐtｓ為空．在FOptsLen非0時,則反之。如果MAＣ命令在FOpts字段中體現(xiàn)，porｔ0不能用（FPoｒt要么不體現(xiàn),要么非0）。MＡC命令不能同時出現(xiàn)在FＲMＰayloaｄ和FＯptｓ中,如果出現(xiàn)了,設(shè)備丟掉該組數(shù)據(jù)。4.３.２端口字段(FPort)如果幀載荷字段不為空，端口字段必須體現(xiàn)出來。端口字段有體現(xiàn)時,若FPort的值為0表示ＦRMＰayｌｏad只包含了MAＣ命令;具體見章節(jié)4。4中的MAC命令。FＰort的數(shù)值從1到22３(０x01．.0ｘDF)都是由應(yīng)用層使用。FPorｔ的值從224到２５5（0xＥ0..0xＦF)是保留用做未來的標準應(yīng)用拓展。Sｉzｅ(byｔeｓ）7。.2３0..10..NMACPayloａdFHDＲＦＰoｒtFＲMPaｙloａdN是應(yīng)用程序載荷的字節(jié)個數(shù)。N的有效范圍具體在第７章有定義。Ｎ應(yīng)該小于等于:

Ｎ<=M—1—(FＨDR長度)

?M是MAＣ載荷的最大長度。4.３.3MAC幀載荷加密(FRＭPayloａｄ）如果數(shù)據(jù)幀攜帶了載荷，F(xiàn)RMPaｙlｏad必須要在MIC計算前進行加密。

?加密機制是采用IEＥE802.1５。4/２00６的ＡES1２8HYPＥRLＩNK"http:／/lib。csｄn。ｎｅt/baｓe/daｔasｔｒuctｕre”＼ｏ”算法與數(shù)據(jù)結(jié)構(gòu)知識庫＂算法。默認的，加密和加密由LoRaＷＡN層來給所有的FPｏrt來執(zhí)行.如果加密/解密由應(yīng)用層來做更方便的話，也可以在LoRaＷAN層之上給特定FPorts來執(zhí)行,除了端口０。具體哪個節(jié)點的哪個FPｏrt在LoRaＷAN層之外要做加解密，必須要和服務(wù)器通過oｕt－oｆ-band信道來交互（見第1９章）。4。3.３.1LoRaWＡＮ的加密密鑰Ｋ根據(jù)不同的FPort來使用:FPortＫ０ＮwｋSKey1。.255AｐｐSKey表3:ＦPｏrt列表具體加密是這樣：

?ｐlｄ=FＲMPaylｏａd

對于每個數(shù)據(jù)幀，算法定義了一個塊序列Ａｉ，ｉ從1到ｋ,ｋ＝cｅil（ｌｅｎ（ｐｌd）/16):Size(byｔes)141４41１Ａi0x０1４x０ｘ00DiｒDevAdｄrＦCnｔUporＦCntDｏwｎ0x０0i方向字段（Dir)在上行幀時為0，在下行幀時為1.

?塊Ai通過加密,得到一個由塊Si組成的序列S。Sｉ=aｅs128＿ｅncryｐt(K,Ai)foｒｉ＝1．.k

?S=Ｓ1|S2|.．|Sk通過異或計算對ｐａｙlｏad進行加解密:4。３。3.2LoＲａWＡＮ層之上的加密

如果LoRａWAN之上的層級在已選的端口上(但不能是端口０,這是給ＭAC命令保留的)提供了預加密的FRMＰayloａｄ給ＬoRaWAN,ＬｏRaＷＡN則不再對FRＭＰaylｏａd進行修改,直接將FRMPａylｏad從ＭＡCPayload傳到應(yīng)用層,以及從應(yīng)用層傳到MACPayｌｏad。4．4消息校驗碼(ＭＩＣ）消息檢驗碼要計算消息中所有字段。

msg=ＭHDR|FHＤＲ|ＦPort｜FRMPａylｏａｄＭIC是按照[RＦＣ4４９３]來計算:cmａc=aeｓ1２８_cmaｃ（ＮwｋSKey,Ｂ0|msｇ)

?MＩC=cｍａｃ［０。。3］塊Ｂ0的定義如下:Size(bｙtes）1４14４11B０0x494x0x00DｉｒDevＡddrFCｎtUporＦＣnｔDoｗｎ０ｘ００l(fā)ｅn（msg)方向字段(Dir)在上行幀時為0,在下行幀時為1.LoRａＷAN第4章，主要講述了ＭAC幀格式，對所有涉及的字段都做了解釋。千言萬語匯成一句話,哦不,匯成一個表。數(shù)據(jù)幀頭DeｖＡddｒFＣtrlFCntFＯptｓ數(shù)據(jù)幀PrｅambｌePHDRＰHDR_ＣRCMHDＲFHＤRFＰｏrｔFＲMＰayloadMIＣＣRＣMＡC層PreaｍblePHDＲPＨDR＿CRＣＭHＤＲMACPayｌoadＭICCRCPＨY層ＰｒeambｌePＨＤＲPHDR_ＣRCＰHＹPayloaｄＣRC好了,幀格式是大家隨手都能看到的東西,本尊作為ＩoT小能手,如果不能提出一些稍有深度的信息增量，就對不起這個稱號了.所以,有些協(xié)議設(shè)計層面的心得要分享下：特別酷的ADR(速率自適應(yīng))機制

這個章節(jié)中最亮眼的莫過于速率自適應(yīng)機制,簡直是為ＬｏRa網(wǎng)絡(luò)量身定做的:一旦使能了FCtｒl中的ＡＤR位,距離近信號好的節(jié)點用高速率,距離遠信號弱的節(jié)點用低速率，不小心被調(diào)高了速率,則自動降下來。這樣,盡可能地提高了傳輸速率，也有效提高了網(wǎng)絡(luò)容量.我已經(jīng)見過不少廠家，拿這個協(xié)議的公知特點當產(chǎn)品賣點了．可同時攜帶數(shù)據(jù)和命令的MAＣ幀

一般來說,應(yīng)用除了數(shù)據(jù)，出于管理需要,肯定還會涉及命令。比如基站要查詢節(jié)點狀態(tài)，或者節(jié)點要請求變更信道等。所以ＬoRaＷＡN協(xié)議設(shè)計上利用FOpts把數(shù)據(jù)和命令揉在一個MAC幀里，這樣可以提高交互效率,有效地降低功耗。這在寸土寸金,哦不，寸庫侖(電量單位）寸金的物聯(lián)網(wǎng)應(yīng)用中，是一個很有必要的設(shè)計.３源碼解析這章的處理基本都在\srｃ\ｍac＼ＬoＲａMac.ｃ中,下面按照MＡC幀格式的字段逐個解析下.3．１MＡC層MHＤR在LoRaWAN的數(shù)據(jù)ＡＰI中處理了ＭHＤR,這個字段內(nèi)容比較少,就按需選擇了消息類型是coｎfirm還是unconｆirm.

另外在管理AＰI中的Jｏin—Rｅq的消息類型。具體可見LｏRａMacMcpsReｑuest(）和LoRaMaｃMlmｅＲequesｔ（)這兩個函數(shù).3。２MACPayｌoａdＭAＣPayload的組幀都在PrｅpareFｒame(）這個函數(shù)中處理，將macHｄr和macPaｙload的fCtｒｌ、FPｏrｔ、ＦRMPaylｏａｄ都傳遞進去，完成整個MAＣ層的數(shù)據(jù)組幀。LoRaMacＢufｆeｒ就存放了ＭACＰayload的數(shù)據(jù)，這個變量的組幀和協(xié)議字段定義是一一對應(yīng)。MＡCPaｙlｏad的組幀處理，在大流程上是對jｏｉn和數(shù)據(jù)兩種類型的幀分別處理,用兩個caｓe分開。為了方便閱覽，我把函數(shù)代碼框架提煉了出來。LoRａMacStatuｓ_tPrepareFramｅ（LｏRaMacHeader＿t＊mａcHｄr,ＬoRａＭacFrameCｔrｌ_t*fＣｔrｌ，uｉnt8_ｔｆPoｒt,void＊fＢｕｆfer，uinｔ16_ｔfBuｆｆerＳize）｛swiｔch(macHdr—＞Bitｓ．MＴype)｛caseFRAME_TYＰＥ_ＪOIN＿REQ：。.。/／省略bｒｅak；caｓeFＲAME_TYＰE_ＤATＡ_CＯNFＩRＭED＿UP:ＮｏdｅAckReqｕeｓteｄ=tｒｕe;//IntenｔionalｆaｌltroughｃaｓｅＦRAMＥ＿TYPＥ_DＡTA_ＵＮCOＮFIＲMED_UP:。.。fCtrl—>Ｂits．AdrAckReq＝AdrNextDr(fCｔrl-〉Biｔs。Aｄｒ，true,&LoRaＭacＰaraｍs。CｈanｎelsＤatarａt(yī)e)；．..iｆ(SｒｖAｃkRequeｓteｄ==truｅ){SｒvAｃｋReqｕeｓted=ｆalｓe;fCtｒｌ—>Biｔs。Ack=1；}LoＲａMａcＢufｆer[pktHeadｅrLen++］＝(LoRaMacDevＡｄdr）＆０xFF;LｏRａMａcＢufｆer[pktHｅaｄerLen＋＋］＝(LoRａMacDevAddｒ〉>8）&0ｘFF;LｏRaMａcBｕffer[pｋtHｅaderＬen+＋]=(LoRaMaｃDevＡddr>>１6）&0xFＦ;LoRaMａcBuffer[ｐktHｅａｄｅrLｅn＋+］=（LoRaMacDｅvAddr〉>2４)＆0xFF;LoRaMａcＢｕｆfer[ｐktHeaｄｅｒLeｎ+＋］＝ｆＣtrl-〉Ｖaｌue;ＬoRａMaｃＢｕffｅr[pktHeａderLen＋+]=UpLiｎkCｏuｎteｒ&0xFＦ;LｏRａMａcBufｆeｒ[pktＨｅaｄeｒＬeｎ++]=(ＵpLiｎkCounteｒ>〉８)&０xFF；/／ＣoｐyｔheMACcommandsｗhｉcｈｍustｂere—othｅMACcomｍandbuffermemcpy1(＆MａcCoｍmandsBuffer[MａｃCｏmｍａnｄsＢｕffｅrIndex],MａcCommandsBuffｅｒＴoＲepeａt(yī),MａｃＣｏmmandsBuｆferToReｐｅatIｎdex)；ＭacCommａndsBuｆfeｒInｄex+=ＭacＣommａnｄsBufferToRepeatIndeｘ;if（(ｐａyｌoad!＝NＵLL)&＆(ｐａyloadSizｅ〉0))｛ｉf（（MａcCoｍｍaｎdsＢｕfferIndex〈=LOＲA_ＭＡＣ_ＣOMＭAＮD_MＡX_LＥNGTH）&＆(ＭacCoｍｍａndsInNextTx==tｒue））{fＣｔｒl->Ｂits。FOｐtsLeｎ+=MacCoｍmaｎdsBufferＩnｄex；／/UpdａｔeFCｔｒlfieldｗiｔhneｗｖaluｅofOpｔiｏnｓＬengthＬoＲaMａcＢｕffｅｒ［0x０５］=fＣtrl->Value;ｆoｒ(i=0；i〈MaｃCommanｄsBufferＩndｅx;ｉ++）{LｏRaMaｃＢuｆｆer［pktHeaderLen++]=MacＣommanｄsBuffer[ｉ];｝｝}ｅlｓe{iｆ(（MaｃCoｍｍaｎdｓBufｆerＩndex〉0）＆&(ＭaｃCｏｍｍandsInNexｔＴｘ))｛ｐayloａdSizｅ＝MacＣommaｎdsＢufｆｅrIndeｘ;payloａd=MacＣommaｎdsBuｆfer;frａｍePort=0;}}MacCｏmmandsInNextTx=ｆaｌse;//SｔｏreMACｃommandswhｉcｈmustｂere—senｄincasethｅdevｉｃeｄoeｓnotreceｉveadowｎliｎkａｎymoreMaｃCｏmmandsBuｆferＴoRｅpeatInｄeｘ=PaｒsｅＭacComｍａｎdsToRepeat（MaｃCommａndsＢuｆfer,MａcCｏｍｍandsＢufｆerＩndex,MacComｍandsBuｆferToRepｅａt(yī)）；ｉf(MacCommａndsBｕffｅrＴoRepｅatIｎdｅｘ〉0){MａcCommaｎｄsＩnＮeｘｔTx=trｕe；}MaｃCｏmmandsＢuｆferIｎdex=0;if(（payload?。絅UＬL)&＆（ｐａyloadSiｚe＞０)){LoRaMacＢuffeｒ[pｋtHｅaｄeｒLen++］＝fｒaｍePｏrt;ｉf(frａmｅPｏｒt==0)｛LｏRaMａｃPayloadEncrｙpt(（ｕint８_t＊)ｐayload，ｐaｙloaｄSizｅ，LoRaMａcＮwｋSKey,LoRaMacDｅｖＡddr,UP_LINK,UpＬｉnｋＣｏｕnter,LoRaＭacPayloaｄ）;｝ｅlse{LoＲaMacPayｌoadＥncｒｙｐt((uiｎt8＿t*)paylｏad，paｙｌoadSize,LｏRaＭacAｐpSKey,LｏRaMacDｅｖAddr,UP_LＩNK，UpLinkＣｏunter,LoRaＭacPａyloaｄ）；}memｃpｙ1(LｏRaMacＢufｆeｒ+pkｔHeａderＬen,LoRaMacPayload,paylｏadＳize);｝LoRaMacＢｕfferPｋｔLen=pｋtＨｅadｅrLen＋payloａdSize；LoRaMacCompｕteMic(ＬoRaＭacBuｆfeｒ，LoRaＭａｃBuffｅrPktLen，LoRaMacNwkSＫeｙ，LoRaMａcDｅｖAddｒ,UＰ_LＩNK,ＵｐＬｉnｋCountｅr,&mic)；LoRaMａcBuffer［LｏＲａMacBufｆerＰktLen+０]＝ｍic&０xFF；LｏRaＭacBｕffeｒ[LｏRaMacBuffｅｒPktＬen+１]＝(mｉc〉＞８）＆0xFＦ;LoRaMａcBｕｆfｅr[LoＲaMacBufｆｅｒPktLｅn+2］＝(mｉｃ>>1６)＆0xFF;LoＲaMacBuffer[LoRａMacBufｆｅrＰktＬen＋3]=(ｍic〉>24)&0ｘFF;ＬoRaMａcBuｆferＰktLen+＝LＯＲAＭＡC_MFＲ_LEN;ｂreaｋ;ｃaseＦＲAＭＥ＿TＹＰE_PROPRIETAＲY:。。.//省略ｂreak;deｆault：reｔuｒnLORAＭAC_STATUS_SERVＩCE_ＵＮKＮＯＷN;｝ｒｅｔurnLORAMAC＿STＡTUS_OK；｝Join-rｅｑuest的組幀處理對應(yīng)協(xié)議第6章6.2．４Join—requｅstmｅssage。

數(shù)據(jù)幀的組幀處理則稍微復雜些,尤其是FHＤR,下面逐個字段講解下FＨDR。3。2。1MＡCPaｙloａｄ中的FＨDＲ1．FＨＤＲ中的DevAddｒLoRaMａcＢuffer[pktＨeaderＬen＋＋］=(LoRａMａcDevＡdｄr）＆0xFF;

LoRａＭaｃBｕffeｒ［pｋtＨeａｄerLｅn++]=(LoＲaMａcDevAddr>>８)&0xFF;

?LoRaＭacBuffer[pktHｅaｄerLen++］＝(LoRaＭaｃDevAddr＞＞1６）&0xFF;

?LoRaMacBuffer[pktHeadｅrLeｎ＋+]=（LoRaＭaｃDｅvAddｒ〉〉2４)＆0xFF；2。ＦＨDR中的FＣｔrｌ首先ADR位段是在傳入PｒepａreFramｅ()之前，就做了處理。

?fCtrｌ。Biｔs。Adr=AｄrＣｔrlOn;接著ＡdrAckReq位段，在長期失聯(lián)情況下會發(fā)送AdｒＡcｋReｑ確認鏈路。

fＣtrl—〉Biｔs.ＡdrAcｋReq=AdrＮextDr（ｆＣｔｒl—>Bitｓ.Adr,true，&LoRａMacＰaraｍs。ＣｈannｅlｓＤatarａt(yī)e);最后F0ｐtsＬeｎ位段,會在下面計算完FOpts之后更新。3。FHDR中的FCnｔLoRａMacBｕffeｒ［ｐkｔＨeadｅrLｅn++]=ＵpLｉnｋCounｔer＆0xFF;

ＬoＲaMacBuｆfer[pkｔHeadｅrLen＋+］=（UｐLiｎkＣouｎｔer>>8)&０xFF；這個UpLｉnkCｏｕｎter會在物理層發(fā)送完成后會按照協(xié)議進行累加。可以看到這是個32位計數(shù)器,按照協(xié)議規(guī)定,“如果采用３2位幀計數(shù),ＦCnt就對應(yīng)計數(shù)器３2位的16個低有效位”。這是上行的，另外下行的也類似。４。FHDR中的FOpts把MAC命令放入F0pts中,并且更新F0ｐｔsLｅn。MAＣ命令,要么使用非零的FＰort來和數(shù)據(jù)一起傳輸,要么使用ＦＰort0來單獨傳輸。//ＣopｙｔｈeMACｃoｍｍａndｓwｈicｈmｕｓtbeｒe—sendiｎtothｅＭAＣcｏmｍandbufferｍemcpy1(&ＭａcCｏｍｍaｎdsBufｆer[MaｃComｍandsBufｆerＩndex],MacCoｍmaｎdsＢuffeｒToRepeat,MacＣoｍmanｄsBｕfferTｏRepeａt(yī)Iｎdex）;MaｃCoｍmandsＢｕｆferＩndex+＝MacCoｍｍａnｄsBuffｅrToReｐeａｔIndex;if(（payload!=NULＬ)&&(payloadＳizｅ>0))｛if((ＭacＣommａｎdsBufferＩndｅx<=LORA＿ＭAC_COＭMAＮD_MAX＿LＥNGTＨ）&&（MacCｏmmａnｄsInNｅｘtTｘ==ｔrue)){fＣtrｌ—＞Bits.FOｐｔsLen＋=MacCommandｓBuｆferInｄex；//ＵpdaｔeFCtrlｆieｌｄwithnｅwvａlueofOptioｎｓＬeｎgthＬoRaMａｃＢuｆfer[0ｘ0５]=ｆCtｒl—>Value;for(i=0；i<MａｃCoｍmａｎdsＢufｆｅrIｎdex；i++){LoＲaMacBｕffer[pkｔHｅaderLen++]=MaｃCｏmｍanｄsBuｆfer[i];}｝｝eｌｓｅ｛ｉf((MacCoｍｍandｓBuffｅrIndex>０）＆&（ＭacCommａｎdsＩｎNexｔＴx))｛ｐayloaｄＳize=MacCｏmｍandｓBｕｆferIndex;ｐaylｏad=MaｃCｏｍmanｄsBｕffer;fraｍePort=0;｝}３.2.2MACPayload中的ＦPoｒt這個是在應(yīng)用層一直傳遞進去的,協(xié)議棧默認是用了端口2。這個是后期大家在應(yīng)用時要調(diào)整的,類似于IＰ端口,不同的端口對應(yīng)不同的服務(wù)。３.3MIC解析在函數(shù)PreｐaｒeＦｒａme(）的最后是調(diào)用ＬｏＲaMaｃComputeＭic(）計算出整個MＡＣ層的校驗碼。應(yīng)用層這邊基本不用改這邊就暫時不細究了。第５章ＭＡC命令對網(wǎng)絡(luò)管理者而言,有一套專門的ＭAＣ命令用來在服務(wù)器和終端MAC層之間交互.這套MAC命令對應(yīng)用程序（不管是服務(wù)器端還是終端設(shè)備的應(yīng)用程序)是不可見的。單個數(shù)據(jù)幀中可以攜帶MAC命令,要么在FOｐts字段中捎帶，要么在獨立幀中將FPｏrt設(shè)成０后放在FRMＰayload里。如果采用FOｐts捎帶的方式,ＭAC命令是不加密并且不長度超過15字節(jié)。如果采用獨立幀放在FRＭPａyloａd的方式，那就必須采用加密方式,并且不超過ＦRMＰayloａｄ的最大長度。注意:如果MＡC命令不想被竊聽,那就必須以獨立幀形式放在FRMPayloaｄ中。每個MAC命令是由１字節(jié)ＣIＤ跟著一段可能為空的字節(jié)序列組成的。CIDCommaｎd由誰發(fā)送描述終端網(wǎng)關(guān)０x０2LiｎｋＣhｅckReqx終端利用這個命令來判斷網(wǎng)絡(luò)連接質(zhì)量0x０2LｉnkCheckAnｓxＬｉnkCｈecｋReｑ的回復。包含接收信號強度，告知終端接收質(zhì)量0x０3ＬinkADRRｅｑx向終端請求改變數(shù)據(jù)速率，發(fā)射功率，重傳率以及信道0ｘ03LinｋADRＡｎsxLｉnkADRRｅq的回復.0x04DutyCycｌｅRｅｑｘ向終端設(shè)置發(fā)送的最大占空比.0x04DutyCyｃleAnsxDutyCyｃlｅＲeq的回復。0ｘ05RＸParａmSetupＲｅqｘ向終端設(shè)置接收時隙參數(shù)．０x05RXPａｒａmSetuｐAnsｘRXPａｒamＳｅｔuｐＲeq的回復.０ｘ0６DeｖStａt(yī)usReqx向終端查詢其狀態(tài)。0ｘ06ＤevStａt(yī)usAｎsx返回終端設(shè)備的狀態(tài)，即電池余量和鏈路解調(diào)預算.0x０7NeｗChannｅlＲeqx創(chuàng)建或修改1個射頻信道定義。０x07NewChannelAnsｘNewＣhanｎｅｌReq的回復。0x08RＸTimingＳeｔupRｅｑx設(shè)置接收時隙的時間。０x08RXTimingＳetuｐAnsｘRＸTiｍinｇSeｔupReｑ的回復。0x８0～０xFF私有xx給私有網(wǎng)絡(luò)命令拓展做預留。表4：ＭAＣ命令表注意：MAC命令的長度雖然沒有明確給出，但是MAC執(zhí)行層必須要知道.因此未知的MAＣ命令無法被忽略，且前面未知的MAC命令會終止MAC命令的處理隊列。所以建議按照ＬoRaWＡN協(xié)議介紹的ＭＡＣ命令來處理MAC命令.這樣所有基于LoRaWAN協(xié)議的ＭAＣ命令都可以被處理,即使是更高版本的命令.2梳理解析從LoRaWＡN第4章的幀格式可以得到如下信息:MＡＣ命令，要么使用ＦＰort0來單獨傳輸,要么使用非零的FPort來和數(shù)據(jù)一起傳輸。ＬoRaＷAN第5章,LoRaWAN出于網(wǎng)絡(luò)管理需要，提出了9條MAＣ命令,這個章節(jié)是對９條命令進行具體的描述。說個題外話,CLＡA（中國LoＲａ應(yīng)用聯(lián)盟)在９條命令以外還擴充了一些MAC命令?，F(xiàn)階段協(xié)議還不能公開,所以我就不多說了.中興目前作為LoRa聯(lián)盟董事會成員，也許以后會把這些拓展MAC命令引入到LｏRａＷAN協(xié)議也說不準,大家暫且當個課外知識了解下就好。3代碼位置MAC命令枚舉/*!＊LoRaMAＣｍoｔｅMＡCcommaｎds＊*LoＲaＷAＮSpecifiｃatｉｏnＶ1。0.1,cｈapter5，taｂle４*/ｔyｐedｅfenｕmeLoＲaMacＭotｅCmd{/*?。蘨nkCheｃｋＲｅq*／ＭOTＥ_MＡC_LＩＮK_ＣHECK_REＱ=0x02,/*!*ＬｉnkADRAｎs＊/MOTE_ＭAC_ＬINK_ADR_ANS=0x0３，/＊！＊DutyCycleAns＊/MOTE_ＭAC＿DUTY＿CYCLE＿ANＳ=0ｘ04,／*!*RXＰａramＳeｔupAns＊／MＯTE_ＭAＣ_RX_PＡRＡM_SETUP_ＡNＳ=0x05，/*！*DeｖStatusAns*/MOＴE_MAC_DＥV＿STAＴUS_ＡＮＳ=0x０6,／*！*NｅwChａnnelAns＊/ＭOTE_MＡC＿ＮＥW＿CHANＮEＬ_AＮS=0ｘ０7,/＊!＊RXTimｉngSeｔupＡｎｓ*/MOTE＿MＡC＿RX_ＴIMＩNG_SＥTＵP＿ANS＝0x08,}LoRaＭaｃMｏtｅCmd_ｔ;/＊!＊LoRaMACseｒvｅrMACｃomｍands＊＊LｏRａWＡNＳpecｉfiｃatｉonV1。０。1ｃhapteｒ５，ｔaｂle4*/typedeｆenｕｍeＬoＲaＭacSrvＣmd｛/＊!*LiｎｋCheckAｎs＊/SRＶ_MAＣ_LINK＿CHEＣK_ANS=0x０２,/*!*LinｋADRＲeq*/SRＶ_MAC_ＬINＫ＿ADR_RＥQ=０ｘ03,/*!*DutyＣyclｅReq*／SＲV＿ＭAC_DUTY_CYCＬE_ＲEQ=0x04，/*!*RＸPaｒamSｅtupＲｅｑ＊/ＳRV_MAC_RX＿PARＡＭ＿SＥTUP_REＱ＝0x0５，/＊?。狣ｅｖStａｔｕsReq＊／ＳRV_MAC_DＥV_STATUＳ_ＲＥQ=0ｘ06,/*!*NewCｈａnnelReq＊／SRV_MＡC＿NＥW_ＣHＡNNＥL_ＲEQ=０x07，/*!＊ＲXTｉminｇＳetuｐReq＊/ＳRＶ_MAC_RX_TＩMＩNＧ_SETUP_RＥＱ＝0x０8,}ＬoRaMacSｒｖCｍd＿t;MAC命令的接收處理OnRaｄｉoRxDｏne()攜帶著MAC幀進來，經(jīng)過層層篩選，最終到達ＰｒoceｓsMacCoｍmands（)來處理MAC命令．

這里代碼中涉及的兩種處理方式，可以跟協(xié)議對應(yīng)起來:ｐort=０時,ＭＡC命令放在FRMＰayload中，需要先解密再處理;port非零時,ＭAＣ命令放在foｐts中。iｆ（port=＝０)｛if(fCtrl．Ｂits。FＯpｔsＬen＝＝0){LoRaMaｃPayloadＤeｃryｐt(ｐaylｏad+ａppPａylｏadＳtａｒｔIｎdex，frameＬen,nwkＳＫeｙ,addｒｅｓs,ＤＯWN_LINK，dowｎLiｎｋCoｕntｅr,ＬｏRaMａｃRxPayload)；//DｅcodeｆraｍｅpａyloaｄMACcommaｎdsＰroceｓsMacCｏｍmａnds（LoRaMａcRxPayloａｄ,0,fraｍｅＬen,snr）;｝｝else｛ｉf(ｆＣtｒl.Biｔs。FOptｓLen〉0){／/DeｃodeOptionsfieldMＡCcommanｄｓ.OmｉtthefＰort.ProceｓsMacＣoｍmaｎds（paｙｌoaｄ，8,aｐpPaｙｌｏａdＳｔａrtInｄex-1，ｓnr)；}}MＡC命令的發(fā)送及回復MAC命令的發(fā)送及回復處理都在這個函數(shù)中，AddMａｃCommand(）。協(xié)議棧對MAＣ命令發(fā)送的處理還是比較簡單的，都是放在Fｏｐｔs中來傳輸,都在這個15字節(jié)的MacCommaｎｄsBｕfｆｅr中.LiｎｋADＲ是LｏRaWAN網(wǎng)絡(luò)管理中相當重要的一個ＭAC命令,其解析占用了１83行.索性專門寫篇源碼解析,記錄下．閱讀此文前,最好再把第五章的這個命令好好翻一翻，代碼和協(xié)議才能對應(yīng)上。我正在陸續(xù)對協(xié)議的各個章節(jié)進行翻譯，具體其他章節(jié)的譯文，以及譯文之外的代碼解析，可點此查看帖子ＨYPEＲLINK”hｔtp：//blog。csｄn.nｅｔ／ｉoｔｉｓan/ａrtｉcle/detaiｌｓ／５39304５8”\ｔ"_ｂlanｋ”LoＲａ學習筆記_匯總。

?本文作者twowinｔeｒ,轉(zhuǎn)載請注明作者:ＨYPＥRLＩNＫ”ｈttp:/／blog.cｓｄｎ。nｅt/iｏtｉsａｎ／”\t”＿blａnｋ”ｈttｐ:/／blｏｇ。ｃsdn.ｎeｔ/iotｉsan／ＬiｎkＡDRReｑ的源碼解析按照代碼思路走一遍。1。解析DataRate_ＴXＰｏｗeｒ字段daｔarate＝pａｙload[maｃIndex+＋]；txPoｗeｒ=dａｔarate&０x0F;datａｒate＝(datarａｔe＞〉４）&０x０Ｆ;if(（AｄrCｔrlＯｎ==falsｅ）&＆（（ＬｏＲaＭacPａrams。ＣｈａnnelsDａｔarate！=dataratｅ)｜|（LoＲaMacＰａraｍｓ。ＣhanｎelsTxＰowｅr!=txＰower))){//ADRdisabledｄon'thaｎdleADRrequestsifservertｒiestochangedaｔarateorｔxpｏwer／/Answerｔｈeserveｒwithfaｉlｓtａt(yī)us//ＰoweｒＡCK=０／/ＤatarateACK＝0／／Channelｍask＝０AddＭａcＣommａnｄ(ＭOTE_ＭAC_LINK＿ＡＤＲ_ANS,0,0）；mａcIndｅx＋＝３；//Ｓｋipovertｈeremainｉnｇbytesｏｆtheｒequｅｓtｂreak；｝如果終端ADR沒開，那么就立即丟棄本命令處理。這里的macIndｅｘ+=３是對應(yīng)LinkADRReq的剩余命令長度３而言的。2.解析ＣhMask字段cｈＭａｓk＝(uint1６_t)payload［maｃIndeｘ＋＋];cｈMａsk|=（uint16_t)payｌｏad[macIｎdex++]<〈8;３。解析Redｕndaｎcy字段nbRep=paｙloaｄ［mａｃＩｎｄex＋+];chMaskCntl=(nbRep〉〉4）&0x07;nｂＲep&＝０x0Ｆ;if(nｂRep==0)｛nbＲep=１;}把字段中的ｃｈＭaskCntl和ｎbReｐ都給解析了出來。４。按地區(qū)規(guī)定處理chＭaskCntl,及判斷ChMaｓｋ有效性＃eｌiｆｄｅfinｅd(USE_BANＤ_470）ｉf(ｃhＭaｓkＣｎtl＝=6)｛／／Enａblｅaｌl125ｋHzchannelsfor(uint8＿ti=０,k=０;i＜LＯＲA＿ＭＡＸ_NB＿ＣHANNＥLS;i＋=16,k++){for（ｕint8＿tj=0；j〈1６;j++)｛if（Chａnnelｓ[i+ｊ]．Freqｕｅncy！=0）{channelsMaｓk[k]|＝1<〈ｊ;}}｝｝eｌseif（chＭaskCnｔl==7){ｓtaｔus&=0xＦＥ;／/ChanｎeｌｍaskKＯ}elｓｅ{ｆor(uint8_ti=0；i<16；ｉ++）{if（((chMask&(1<〈ｉ））！=0)＆&(Channelｓ［chＭaskCｎtｌ*16+i］.Fｒｅqueｎｃｙ==０）){/／Tｒyingtoenabｌｅanuｎｄｅfiｎｅｄｃｈanｎelstatus&=０ｘＦＥ;//ＣhannelmasｋＫＯ}｝cｈannｅlsＭask［chMaｓkCntl］=ｃhMask；}如果ｃhＭaskCntl為６，則所有信道都使能．如果chＭaskCntl為7,則由于未定義返回失敗。

其他有效cｈＭaskＣntl情況下，先檢查是否有未定義的頻點,如果沒問題則更新對應(yīng)的channelsMaｓｋ。5.判斷速率有效性if(Validａt(yī)eＤatarate(dataraｔｅ，channelsMaｓk)==false）{status&=0xFＤ;//ＤaｔａraｔeKＯ｝６.判斷發(fā)射功率有效性ｉｆ（ValｕeInRangｅ(txPower,LORＡMAC＿MAX_TX＿POＷＥR，ＬＯRＡMAC_ＭIN_ＴX_POWER)=＝ｆaｌse)｛sｔaｔus&=０xFB;//TxPowerKO}7．全部判斷通過后更新參數(shù)ｉｆ（(statuｓ&0ｘ０7）==０x07)｛LoRaMacPａrams。ＣhannｅｌsDaｔaraｔe=datａratｅ；LoRaMacPaｒams。ChａnneｌsTxＰower=txＰｏwer;mｅmcpy1（（uint8＿t＊)LoRaMaｃＰaraｍs．CｈannｅｌｓMａsk，(uinｔ8_ｔ＊）cｈaｎｎｅlsＭask，siｚeof(ＬｏRａMacParaｍs.CｈannelsMask))；LoRaMaｃPaｒａms．CｈanｎｅlsＮbＲｅp=nbRｅp；}8?；貜蚆AＣ命令LiｎkADRAnsAddMacCoｍmanｄ（MOＴＥ_MＡC_LINＫ_AＤR_ANＳ，statｕs，0)；突然發(fā)現(xiàn)AddMａcＣommａnd的形參只有CID加2字節(jié)的回復,我是太無聊,把終端所有ＭAC命令都翻了一遍，確認所有pａyloａd確實是小于2字節(jié)。再次贊揚LｏRaWAN協(xié)議的精簡作風。第6章終端激活為了加入LｏRaWＡN網(wǎng)絡(luò),每個終端需要初始化及激活。終端的激活有兩種方式,一種是空中激活Oｖeｒ-The-ＡｉrＡcｔｉｖaｔion(OTＡA),當設(shè)備部署和重置時使用;另一種是獨立激活Aｃtivａt(yī)ｉｏｎＢｙＰersoｎalizatｉon（ABP)，此時初始化和激活這兩步就在一個步驟內(nèi)完成。twｏwiｎter備注:ABP這個詞不太好翻譯，通常會翻成個性化激活,也就是通過獨立配置參數(shù)的方式激活。但總感覺少點味道，與空中激活擺在一起,感覺獨立激活這個詞在語義上更有并列感。當然這是我的主觀感覺,建議大家和同行交流時,還是說ＡBＰ激活吧.６。1終端激活后的數(shù)據(jù)存儲激活后，終端會存儲如下信息:設(shè)備地址(ＤevAｄｄr),應(yīng)用ID(ＡpｐEUＩ),網(wǎng)絡(luò)會話密鑰（NwkＳKey）,應(yīng)用會話密鑰（AppSＫｅｙ)。6。１。1終端地址(DevAddr)終端地址(DeｖAｄｄｒ)由可標識當前網(wǎng)絡(luò)設(shè)備的３2位ID所組成，具體格式如下:Bｉｔ#[3１。.25][24。。0］DevＡｄdrbitｓＮｗkIＤNwkAddr它的高7位是NｗｋＩd，用來區(qū)別同一區(qū)域內(nèi)的不同網(wǎng)絡(luò)，另外也保證防止節(jié)點竄到別的網(wǎng)絡(luò)去．它的低25位是NwkAｄdr,是終端的網(wǎng)絡(luò)地址,可以由網(wǎng)絡(luò)管理者來分配.6．1.2應(yīng)用ID(ＡppＥUI）

AppEＵI是一個類似IEＥEEUI６4的全球唯一ID,標識終端的應(yīng)用提供者。

APPEUI在激活流程開始前就存儲在終端中。6。１．3網(wǎng)絡(luò)會話密鑰（ＮwkＳKey)NwkSKey被終端和網(wǎng)絡(luò)服務(wù)器用來計算和校驗所有消息的MIC，以保證數(shù)據(jù)完整性。也用來對單獨MAＣ的數(shù)據(jù)消息載荷進行加解密。６。1.4應(yīng)用會話密鑰(ＡpｐＳKey）ＡppSＫｅy被終端和網(wǎng)絡(luò)服務(wù)器用來對應(yīng)用層消息進行加解密。當應(yīng)用層消息載荷有ＭIC時,也可以用來計算和校驗該應(yīng)用層MIC。6。2空中激活OTAＡ針對空中激活,終端必須按照加網(wǎng)流程來和網(wǎng)絡(luò)服務(wù)器進行數(shù)據(jù)交互。如果終端丟失會話消息,則每次必須重新進行一次加網(wǎng)流程。

?加網(wǎng)流程需要終端準備好如下這三個參數(shù):DｅvEUI，ＡppＥＵＩ，AppＫey.AＰPEＵI在上面的6.1.２已經(jīng)做了描述。注意:對于空中激活,終端不會初始化任何網(wǎng)絡(luò)密鑰。只有當終端加入網(wǎng)絡(luò)后，才會被分配一個網(wǎng)絡(luò)會話密鑰,用來加密和校驗網(wǎng)絡(luò)層的傳輸。通過這樣,使得終端在不同網(wǎng)絡(luò)間的漫游處理變得方便．同時使用網(wǎng)絡(luò)和應(yīng)用會話密鑰,使得網(wǎng)絡(luò)服務(wù)器中的應(yīng)用數(shù)據(jù),不會被網(wǎng)絡(luò)提供者讀取或者篡改。6.2。１終端ＩD(ＤevEUＩ)

ＤｅvEＵＩ是一個類似ＩEEEEＵI64的全球唯一IＤ，標識唯一的終端設(shè)備。６.2。２應(yīng)用密鑰(AppKey)

?ＡpｐＫeｙ是由應(yīng)用程序擁有者分配給終端，很可能是由應(yīng)用程序指定的根密鑰來衍生的，并且受提供者控制。當終端通過空中激活方式加入網(wǎng)絡(luò),AppKey用來產(chǎn)生會話密鑰NwkSKey和AppSKeｙ,會話密鑰分別用來加密和校驗網(wǎng)絡(luò)層和應(yīng)用層數(shù)據(jù)。6。2.３加網(wǎng)流程

?從終端角度看，加網(wǎng)流程是由和服務(wù)器的兩個ＭＡC命令交互組成的,分別是joiｎreqｕest和jｏiｎacｃeｐｔ。6.2.4Joｉn－requesｔ消息

加網(wǎng)流程總是由終端發(fā)送joiｎ—request來發(fā)起。Siｚe(ｂyｔes)882ＪoiｎReｑuｅstＡppＥＵＩDevEUＩDｅvNonｃｅｊoin—ｒequest消息包含了AppＥUI和DevＥUＩ,后面還跟了２個字節(jié)的聲明DevNoncｅ．DevＮonce是一個隨機值。網(wǎng)絡(luò)服務(wù)器為每個終端記錄過去的DevNonce數(shù)值,如果相同設(shè)備發(fā)出相同的DｅvＮｏnｃe的jｏiｎrｅquest就會忽略。joｉn－ｒｅquｅst消息的MIC數(shù)值（見第4章MＡＣ幀格式）按照如下公式計算:cmac=ａes12８_cmａc（AppＫeｙ,MＨDＲ|AppＥＵＩ｜DeｖＥUＩ|ＤｅvNoｎｃe)

MIＣ=cmaｃ[0．．3]ｊoin—rｅquest消息不用加密。6.2。5Joｉn—ａccｅpt消息

待補充．6.3獨立激活ABP在某些情況下，終端可以獨立激活．獨立激活是讓終端繞過jｏinｒｅｑuest—ｊｏｉｎaｃcｅpt的加網(wǎng)流程,直接加入到指定網(wǎng)絡(luò)中.獨立激活終端,意味著ＤevAｄｄr和兩個會話密鑰ＮwkＳKeｙ和ApｐSKey直接存儲在終端中，而不是ＤeｖＥUI,AppEUI，AppKｅy。終端在一開始就配置好了入網(wǎng)必要的信息。每個終端必須要有唯一的NｗkSKey和AppSKey。這樣,一個設(shè)備的密鑰被破解也不會造成其他設(shè)備的安全性危險。創(chuàng)建那些密鑰的過程中,密鑰不允許通過公開可用信息獲得(例如節(jié)點地址)。2梳理解析LoRaWAN第6章,主要對節(jié)點加網(wǎng)做了描述,它有兩種方式.如果要用一句話來總結(jié)的話,那就是這一句了，請看：如果是空中激活,則需要準備ＤevEUI，AppEUI，AｐpKeｙ這三個參數(shù),即設(shè)備自身MAＣ地址和要使用的應(yīng)用(應(yīng)用IＤ和密鑰）。

如果是AＢP激活,則直接配置DevAdｄｒ,NwkSKey，ApｐSKey這三個LoＲaWAＮ最終通訊的參數(shù),不再需要ｊoｉn流程。在這種情況下，這個設(shè)備是可以直接發(fā)應(yīng)用數(shù)據(jù)的。這里插個題外話，商用的LoＲａWAN網(wǎng)絡(luò)一般都是走OTAA流程，這樣安全性才得以保證。(twoｗinter，你數(shù)數(shù),這是一句話?)

(如果是空中激活,則需要準備DｅｖEUI，ＡppＥUＩ,AｐｐKｅｙ來joiｎ。如果是ABP激活，則直接配置DevAｄdr,NwkSＫeｙ，AppＳKｅy．）3代碼位置３.１激活處理協(xié)議的第6章,相關(guān)的核心代碼是這么幾行，位于＼sｒc\mac\maｉｎ。c。

?整個代碼結(jié)構(gòu)非常清晰，用一個宏（OVEＲ_ＴHE_ＡＩR_ＡＣTIVAＴION)分開兩段,分別對應(yīng)兩種激活方式。caｓeDＥＶIＣE＿STATE＿JOIN:{#ｉf(OVER_ＴHE＿AIR_ACTＩVＡTION！=0)ＭlmeReｑ＿tmlｍeＲeq;//InitiａlｉzeLｏRaMａcdeviceuniqｕｅIＤBｏaｒdGeｔUniqueIｄ（ＤｅvＥui);mlmeReq。Type=MLME_JOＩＮ;mｌmeReq．Ｒeq。Ｊoin。DevＥui=DevＥui；ｍlｍeReq.Req.Join.AppEui=ApｐEui;mｌmeReq。Ｒeq.Join.AppKｅy=AppＫey；if(NｅxｔTx=＝trｕe){ＬoＲａMａcMlmeRequeｓt(&mｌmeＲｅq);}ＤeｖiceＳtａt(yī)ｅ＝DEＶICE＿ＳTATE_SLＥEＰ；#else//CｈoｏsearaｎdoｍdeviｃeaddressｉfnｏtalreadydｅfiｎｅdinCｏmisｓionｉｎg。hｉｆ（DｅｖAddr==０){/／Randｏmseedｉｎitializａt(yī)ｉｏnｓｒaｎd1（BoardＧetRandomSeeｄ（)）；//ChｏoseａrａndoｍdeｖiceａddressDevAddｒ=randr（0,０x0１FFFFＦF);}mibRｅq。Ｔype=MIB_NET_ID；miｂRｅq.Paｒam.ＮetID＝LORAWAN_ＮＥＴＷORK_IＤ；LoRaMａｃMiｂSetReｑuestConfirm（&mｉbReq);mibReq.Type=MＩＢ_DEV_ＡDDＲ;mｉbＲeq。Ｐａｒaｍ.ＤevAddr＝ＤｅvＡddr;LoRaMacＭｉｂSetRequeｓtＣoｎfirm（＆mibReq)；mｉbReq。Tｙpe=MＩB_NＷK_SKEY；mｉｂReｑ.Ｐａrａｍ.NwkSKey=NwｋＳKey;LoRａＭacMibSｅtＲeｑuestConfirm(&mibReq)；ｍiｂRｅｑ．Tｙｐe=MIB_AＰＰ_SKEY；mibＲｅq。Ｐaram。AｐpSKｅy=ＡpｐSKｅｙ;LｏRaMaｃMibSetＲeqｕestCｏｎfirm(＆mｉbReq）；miｂＲeｑ。Tｙpｅ=ＭIB_ＮETＷORK_JOINＥD;mibRｅｑ．Param。ＩsNｅｔworkＪoinｅd=ｔruｅ;ＬoRａMac