Lorawan協(xié)議說(shuō)明書(shū)可編輯范本

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

ＬinｋCheckReq

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

FRMPayloaｄ

(粗體）,常量的格式寫(xiě)作RＥCEIＶE＿DELAY1,變量的格式寫(xiě)作Ｎ。在本文檔中，所有多字節(jié)字段的字節(jié)序均采用小端模式EＵI是8字節(jié)字段,采用小端模式傳輸默認(rèn)所有ＲFU保留位都設(shè)為0第2章LoＲaWＡNClaｓsｅｓ類型介紹LoRａ是由Semtech面向長(zhǎng)距離、低功耗、低速率應(yīng)用而開(kāi)發(fā)的無(wú)線調(diào)制技術(shù).本文檔中，將ClａssA基礎(chǔ)上實(shí)現(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ｓＡ的終端在每次上行后都會(huì)緊跟兩個(gè)短暫的下行接收窗口，以此實(shí)現(xiàn)雙向傳輸。傳輸時(shí)隙是由終端在有傳輸需要時(shí)安排，附加一定的隨機(jī)延時(shí)（即ALＯHＡ協(xié)議）。這種ClassA操作是最省電的,要求應(yīng)用在終端上行傳輸后的很短時(shí)間內(nèi)進(jìn)行服務(wù)器的下行傳輸。服務(wù)器在其他任何時(shí)間進(jìn)行的下行傳輸都得等終端的下一次上行。劃定接收時(shí)隙的雙向傳輸終端（ClassB）:

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

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

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

?圖4。終端接收時(shí)隙的時(shí)序圖３。３。1第一接收窗口的信道,數(shù)據(jù)速率和啟動(dòng)。第一接收窗口RX1使用的頻率和上行頻率有關(guān),使用的速率和上行速率有關(guān)．ＲX１是在上行調(diào)制結(jié)束后的RECEIVE_ＤEＬAＹ1秒打開(kāi)。上行和ＲX1時(shí)隙下行速率的關(guān)系是按區(qū)域規(guī)定,詳細(xì)描述在[ＬoRaWＡＮ地區(qū)參數(shù)]文件中。默認(rèn)第一窗口的速率是和最后一次上行的速率相同。3.3。２第二接收窗口的信道,數(shù)據(jù)速率和啟動(dòng)。第二接收窗口RＸ2使用一個(gè)固定可配置的頻率和數(shù)據(jù)速率,在上行調(diào)制結(jié)束后的REＣＥIVＥ_(tái)DＥLAＹ2秒打開(kāi)。頻率和數(shù)據(jù)速率可以通過(guò)MAC命令(見(jiàn)第5章).默認(rèn)的頻率和速率是按區(qū)域規(guī)定,詳細(xì)描述在[LoRaWAＮ地區(qū)參數(shù)］文件中.３。3．3接收窗口的持續(xù)時(shí)間接收窗口的長(zhǎng)度至少要讓終端射頻收發(fā)器有足夠的時(shí)間來(lái)檢測(cè)到下行的前導(dǎo)碼。3.３.4接收方在接收窗口期間的處理如果在任何一個(gè)接收窗口中檢測(cè)到前導(dǎo)碼,射頻收發(fā)器需要繼續(xù)激活,直到整個(gè)下行幀都解調(diào)完畢。如果在第一接收窗口檢測(cè)到數(shù)據(jù)幀，且這個(gè)數(shù)據(jù)幀的地址和ＭIC校驗(yàn)通過(guò)確認(rèn)是給這個(gè)終端,那終端就不必開(kāi)啟第二個(gè)接收窗口。3。3．5網(wǎng)絡(luò)發(fā)送消息給終端如果網(wǎng)絡(luò)想要發(fā)一個(gè)下行消息給終端,它會(huì)精確地在兩個(gè)接收窗口的起始點(diǎn)發(fā)起傳輸。3．３．6接收窗口的重要事項(xiàng)終端在第一或第二接收窗口收到下行消息后，或者在第二接收窗口階段，不能再發(fā)起另一個(gè)上行消息。3。３。7其他協(xié)議的收發(fā)處理節(jié)點(diǎn)在LoRaWAN收發(fā)窗口階段可以收發(fā)其他協(xié)議，只要終端能滿足當(dāng)?shù)匾笠约凹嫒軱oＲaWAN協(xié)議．2梳理解析LoRａWAＮ第3章,主要是講了接收窗口這回事,只要記住張圖就行．目前RX1一般是在上行后1秒開(kāi)始，ＲX２是在上行后2秒開(kāi)始。3源碼分析3.1源碼流程在梳理這章節(jié)的對(duì)應(yīng)代碼時(shí),自己手動(dòng)做了張思維導(dǎo)圖。有時(shí)是這樣,代碼再有層次感,也不及一個(gè)圖.好，請(qǐng)收下。3.2發(fā)送完成就開(kāi)始RＸ1和RX２延時(shí)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)清晰的知道，對(duì)應(yīng)的處理肯定是在OnRｘWindoｗ１TiｍｅｒEvent和OｎRxWiｎｄow2TiｍeｒＥvent中。

這兩個(gè)接收窗口的處理,會(huì)對(duì)速率和信道進(jìn)行設(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ù)(物理層）

中對(duì)各地區(qū)的要求分別進(jìn)行處理。比如這個(gè)4７0的處理，對(duì)上行信道對(duì)48取余得到下行信道．RxWindｏwSetｕp(LORAMAC_ＦＩRST＿RＸ1_ＣHＡNＮEL+(Chaｎnel%４8)*LＯRAＭAC_ＳTEPWIDTH＿第4章MAＣ幀格式LoRa所有上下行鏈路消息都會(huì)攜帶PHY載荷,ＰHY載荷以1字節(jié)MAＣ頭(ＭＨDR)開(kāi)始,緊接著ＭAＣ載荷(MACＰayload)，最后是4字節(jié)的ＭAC校驗(yàn)碼(MIC)。射頻ＰHY層：PreaｍbｌePＨDRPＨＤＲ_CRCPＨYPaylｏadＣRC圖5。射頻PHY結(jié)構(gòu)（注意CRC只有上行鏈路消息中存在)PHＹ載荷：MHDRMACPaylｏａdMIＣ或者M(jìn)ＨDRJoin—RequestMIC或者M(jìn)Ｈ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字段的最大長(zhǎng)度Ｍ，在第6章有詳細(xì)說(shuō)明。4.2MAC頭(MHDR字段)Bｉｔ#7.。5４。.21.。０MＨDRbｉtsＭTyｐｅRFUMajorＭＡC頭中指定了消息類型（MType)和幀編碼所遵循的LoＲａWAN規(guī)范的主版本號(hào)(Major)。4。2。1消息類型(MTｙpe位字段)ＬoRaWAN定義了六個(gè)不同的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àn)章節(jié)6。２4．2.1.2DatamessａｇesＤatameｓsages用來(lái)傳輸MAC命令和應(yīng)用數(shù)據(jù)，這兩種命令也可以放在單個(gè)消息中發(fā)送。

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

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

Ｐrｏprietarymｅsｓagｅs用來(lái)處理非標(biāo)準(zhǔn)的消息格式，不能和標(biāo)準(zhǔn)消息互通，只能用來(lái)和具有相同拓展格式的消息進(jìn)行通信。不同消息類型用不同的方法保證消息一致性,下面會(huì)介紹每種消息類型的具體情況。4。2.2數(shù)據(jù)消息的主版本(Major位字段)Ｍａjor位字段描述00LoRaWAＮR101..11RFU表2.Mａjor列表注意：Ｍajor定義了激活過(guò)程中(joinprocｅdurｅ）使用的消息格式(見(jiàn)章節(jié)6.2）和MACＰaylｏad的前4字節(jié)（見(jiàn)第4章）。終端要根據(jù)不同的主版本號(hào)實(shí)現(xiàn)不同最小版本的消息格式。終端使用的最小版本應(yīng)當(dā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é)幀計(jì)數(shù)器(FＣnt）和用來(lái)傳輸MＡＣ命令的幀選項(xiàng)(FOpｔs,最多15個(gè)字節(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é)議利用該特性來(lái)優(yōu)化固定終端的數(shù)據(jù)速率。這就是自適應(yīng)數(shù)據(jù)速率(ＡdaptiveＤaｔaRatｅ（ADR)).當(dāng)這個(gè)使能時(shí),網(wǎng)絡(luò)會(huì)優(yōu)化使得盡可能使用最快的數(shù)據(jù)速率。移動(dòng)的終端由于射頻環(huán)境的快速變化,數(shù)據(jù)速率管理就不再適用了，應(yīng)當(dāng)使用固定的數(shù)據(jù)速率。如果ADR的位字段有置位,網(wǎng)絡(luò)就會(huì)通過(guò)相應(yīng)的MAＣ命令來(lái)控制終端設(shè)備的數(shù)據(jù)速率。如果ADR位沒(méi)設(shè)置，網(wǎng)絡(luò)則無(wú)視終端的接收信號(hào)強(qiáng)度，不再控制終端設(shè)備的數(shù)據(jù)速率。ADR位可以根據(jù)需要通過(guò)終端及網(wǎng)絡(luò)來(lái)設(shè)置或取消。不管怎樣,ADR機(jī)制都應(yīng)該盡可能使能，幫助終端延長(zhǎng)電池壽命和擴(kuò)大網(wǎng)絡(luò)容量。注意：即使是移動(dòng)的終端，可能在大部分時(shí)間也是處于非移動(dòng)狀態(tài)。因此根據(jù)它的移動(dòng)狀態(tài),終端也可以請(qǐng)求網(wǎng)絡(luò)使用ADR來(lái)幫助優(yōu)化數(shù)據(jù)速率。如果終端被網(wǎng)絡(luò)優(yōu)化過(guò)的數(shù)據(jù)速率高于自己默認(rèn)的數(shù)據(jù)速率,它需要定期檢查下網(wǎng)絡(luò)仍能收到上行的數(shù)據(jù)。每次上行幀計(jì)數(shù)都會(huì)累加(是針對(duì)于每個(gè)新的上行包,重傳包就不再增加計(jì)數(shù)),終端增加AＤR_ACK_CNT計(jì)數(shù)。如果直到ADＲ＿ＡCK_LIMIT次上行(ADR＿ACK_CNT＞=ADR_AＣＫ_LＩMＩＴ)都沒(méi)有收到下行回復(fù),它就得置高ＡDR應(yīng)答請(qǐng)求位（ADRACKＲeq)。網(wǎng)絡(luò)必須在規(guī)定時(shí)間內(nèi)回復(fù)一個(gè)下行幀,這個(gè)時(shí)間是通過(guò)AＤR_ＡCK＿ＤＥLAY來(lái)設(shè)置,上行之后收到任何下行幀就要把ADR_ＡCK＿CNＴ的計(jì)數(shù)重置。當(dāng)終端在接收時(shí)隙中的任何回復(fù)下行幀的ACK位字段不需要設(shè)置,表示網(wǎng)關(guān)仍在接收這個(gè)設(shè)備的上行幀。如果在下一個(gè)AＤＲ_ACK_DELＡＹ上行時(shí)間內(nèi)都沒(méi)收到回復(fù)(例如，在總時(shí)間AＤR_ＡＣＫ_LＩMIT+ADR_ＡCK＿DELAY之后)，終端必須切換到下一個(gè)更低速率,使得能夠獲得更遠(yuǎn)傳輸距離來(lái)重連網(wǎng)絡(luò).終端如果在每次AＤR_AＣＫ_LIMIT到了之后依舊連接不上，就需要每次逐步降低數(shù)據(jù)速率．如果終端用它的默認(rèn)數(shù)據(jù)速率,那就不需要置位ADＲAＣKＲｅq,因?yàn)闊o(wú)法幫助提高鏈路距離。注意：不要ADRＡＣKＲeｑ立刻回復(fù),這樣給網(wǎng)絡(luò)預(yù)留一些余量,讓它做出最好的下行調(diào)度處理。注意:上行傳輸時(shí)，如果AＤR＿ACK_ＣNＴ〉=ＡDR_ＡＣK_LIMＩT并且當(dāng)前數(shù)據(jù)速率比設(shè)備的最小數(shù)據(jù)速率高，就要設(shè)置ADRACＫＲeq,其它情況下不需要.4．3。1。2消息應(yīng)答位及應(yīng)答流程(ＡCKinFCｔrl）收到confirmed類型的消息時(shí),接收端要回復(fù)一條應(yīng)答消息(應(yīng)答位AＣK要進(jìn)行置位）。如果發(fā)送者是終端，網(wǎng)絡(luò)就利用終端發(fā)送操作后打開(kāi)的兩個(gè)接收窗口之一進(jìn)行回復(fù)。如果發(fā)送者是網(wǎng)關(guān),終端就自行決定是否發(fā)送應(yīng)答。

?應(yīng)答消息只會(huì)在收到消息后回復(fù)發(fā)送,并且不重發(fā)。注意:為了讓終端盡可能簡(jiǎn)單，盡可能減少狀態(tài)，在收到ｃonfｉrmatiｏn類型需要確認(rèn)的數(shù)據(jù)幀,需要立即發(fā)送一個(gè)嚴(yán)格的應(yīng)答數(shù)據(jù)幀?；蛘?終端會(huì)延遲發(fā)送應(yīng)答,在它下一個(gè)數(shù)據(jù)幀中再攜帶.4。3。１。３重傳流程當(dāng)需要應(yīng)答卻沒(méi)收到應(yīng)答時(shí)就會(huì)進(jìn)行重發(fā)，重發(fā)的個(gè)數(shù)由終端自己定，可能每個(gè)終端都不一樣，這個(gè)參數(shù)也可以由網(wǎng)絡(luò)服務(wù)器來(lái)設(shè)置調(diào)整。注意:一些應(yīng)答機(jī)制的示例時(shí)序圖在第18章中有提供。注意：如果終端設(shè)備重發(fā)次數(shù)到達(dá)了最大值,它可以降低數(shù)據(jù)速率來(lái)重連。至于后面是否再重發(fā)還是說(shuō)丟棄不管，都取決于終端自己。注意:如果網(wǎng)絡(luò)服務(wù)器重發(fā)次數(shù)到達(dá)了最大值，它就認(rèn)為該終端掉線了，直到它再收到終端的消息.一旦和終端設(shè)備的連接出現(xiàn)問(wèn)題時(shí)，要不要重發(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ā)送上行消息來(lái)再打開(kāi)一個(gè)接收窗口.FＰｅｎdｉnｇ的詳細(xì)用法在章節(jié)18．3。4．３。1.5幀計(jì)數(shù)器（FCnｔ）每個(gè)終端有兩個(gè)計(jì)數(shù)器跟蹤數(shù)據(jù)幀的個(gè)數(shù)，一個(gè)是上行鏈路計(jì)數(shù)器（FCntUp）,由終端在每次上行數(shù)據(jù)給網(wǎng)絡(luò)服務(wù)器時(shí)累加;另一個(gè)是下行鏈路計(jì)數(shù)器（FCntDowｎ)，由服務(wù)器在每次下行數(shù)據(jù)給終端時(shí)累計(jì)。網(wǎng)絡(luò)服務(wù)器為每個(gè)終端跟蹤上行幀計(jì)數(shù)及產(chǎn)生下行幀計(jì)數(shù)。終端入網(wǎng)成功后,終端和服務(wù)端的上下行幀計(jì)數(shù)同時(shí)置0。每次發(fā)送消息后,發(fā)送端與之對(duì)應(yīng)的FCntUp或FＣｎｔＤowｎ就會(huì)加１。接收方會(huì)同步保存接收數(shù)據(jù)的幀計(jì)數(shù),對(duì)比收到的計(jì)數(shù)值和當(dāng)前保存的值,如果兩者相差小于ＭAＸ_FＣNT_GＡP(要考慮計(jì)數(shù)器滾動(dòng)），接收方就按接收的幀計(jì)數(shù)更新對(duì)應(yīng)值.如果兩者相差大于ＭＡX_ＦCＮY_ＧＡP就說(shuō)明中間丟失了很多數(shù)據(jù),這條以及后面的數(shù)據(jù)就被丟掉。ＬoRaＷAＮ的幀計(jì)數(shù)器可以用16位和３2位兩種，節(jié)點(diǎn)上具體執(zhí)行哪種計(jì)數(shù)，需要在帶外通知網(wǎng)絡(luò)側(cè),告知計(jì)數(shù)器的位數(shù)。

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

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

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

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

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

?加密機(jī)制是采用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)知識(shí)庫(kù)＂算法。默認(rèn)的，加密和加密由LoRaＷＡN層來(lái)給所有的FPｏrt來(lái)執(zhí)行.如果加密/解密由應(yīng)用層來(lái)做更方便的話，也可以在LoRaＷAN層之上給特定FPorts來(lái)執(zhí)行,除了端口０。具體哪個(gè)節(jié)點(diǎn)的哪個(gè)FPｏrt在LoRaＷAN層之外要做加解密，必須要和服務(wù)器通過(guò)oｕt－oｆ-band信道來(lái)交互（見(jiàn)第1９章）。4。3.３.1LoRaWＡＮ的加密密鑰Ｋ根據(jù)不同的FPort來(lái)使用:FPortＫ０ＮwｋSKey1。.255AｐｐSKey表3:ＦPｏrt列表具體加密是這樣：

?ｐlｄ=FＲMPaylｏａd

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

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

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

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

msg=ＭHDR|FHＤＲ|ＦPort｜FRMPａylｏａｄＭIC是按照[RＦＣ4４９３]來(lái)計(jì)算: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)在上行幀時(shí)為0,在下行幀時(shí)為1.LoRａＷAN第4章，主要講述了ＭAC幀格式，對(duì)所有涉及的字段都做了解釋。千言萬(wàn)語(yǔ)匯成一句話,哦不,匯成一個(gè)表。數(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小能手,如果不能提出一些稍有深度的信息增量，就對(duì)不起這個(gè)稱號(hào)了.所以,有些協(xié)議設(shè)計(jì)層面的心得要分享下：特別酷的ADR(速率自適應(yīng))機(jī)制

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

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

另外在管理AＰI中的Jｏin—Rｅq的消息類型。具體可見(jiàn)LｏRａMacMcpsReｑuest(）和LoRaMaｃMlmｅＲequesｔ（)這兩個(gè)函數(shù).3。２MACPayｌoａdＭAＣPayload的組幀都在PrｅpareFｒame(）這個(gè)函數(shù)中處理，將macHｄr和macPaｙload的fCtｒｌ、FPｏrｔ、ＦRMPaylｏａｄ都傳遞進(jìn)去，完成整個(gè)MAＣ層的數(shù)據(jù)組幀。LoRaMacＢufｆeｒ就存放了ＭACＰayload的數(shù)據(jù)，這個(gè)變量的組幀和協(xié)議字段定義是一一對(duì)應(yīng)。MＡCPaｙlｏad的組幀處理，在大流程上是對(duì)jｏｉn和數(shù)據(jù)兩種類型的幀分別處理,用兩個(gè)caｓe分開(kāi)。為了方便閱覽，我把函數(shù)代碼框架提煉了出來(lái)。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ＰＥ_(tái)Ｊ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Ｅ_(tái)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的組幀處理對(duì)應(yīng)協(xié)議第6章6.2．４Join—requｅstmｅssage。

數(shù)據(jù)幀的組幀處理則稍微復(fù)雜些,尤其是FHＤR,下面逐個(gè)字段講解下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位段，在長(zhǎng)期失聯(lián)情況下會(huì)發(fā)送AdｒＡcｋReｑ確認(rèn)鏈路。

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ｎ位段,會(huì)在下面計(jì)算完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；這個(gè)UpLｉnkCｏｕｎter會(huì)在物理層發(fā)送完成后會(huì)按照協(xié)議進(jìn)行累加?？梢钥吹竭@是個(gè)32位計(jì)數(shù)器,按照協(xié)議規(guī)定,“如果采用３2位幀計(jì)數(shù),ＦCnt就對(duì)應(yīng)計(jì)數(shù)器３2位的16個(gè)低有效位”。這是上行的，另外下行的也類似。４。FHDR中的FOpts把MAC命令放入F0pts中,并且更新F0ｐｔsLｅn。MAＣ命令,要么使用非零的FＰort來(lái)和數(shù)據(jù)一起傳輸,要么使用ＦＰort0來(lái)單獨(dú)傳輸。//Ｃ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這個(gè)是在應(yīng)用層一直傳遞進(jìn)去的,協(xié)議棧默認(rèn)是用了端口2。這個(gè)是后期大家在應(yīng)用時(shí)要調(diào)整的,類似于IＰ端口,不同的端口對(duì)應(yīng)不同的服務(wù)。３.3MIC解析在函數(shù)PreｐaｒeＦｒａme(）的最后是調(diào)用ＬｏＲaMaｃComputeＭic(）計(jì)算出整個(gè)MＡＣ層的校驗(yàn)碼。應(yīng)用層這邊基本不用改這邊就暫時(shí)不細(xì)究了。第５章ＭＡC命令對(duì)網(wǎng)絡(luò)管理者而言,有一套專門(mén)的ＭAＣ命令用來(lái)在服務(wù)器和終端MAC層之間交互.這套MAC命令對(duì)應(yīng)用程序（不管是服務(wù)器端還是終端設(shè)備的應(yīng)用程序)是不可見(jiàn)的。單個(gè)數(shù)據(jù)幀中可以攜帶MAC命令,要么在FOｐts字段中捎帶，要么在獨(dú)立幀中將FPｏrt設(shè)成０后放在FRMＰayload里。如果采用FOｐts捎帶的方式,ＭAC命令是不加密并且不長(zhǎng)度超過(guò)15字節(jié)。如果采用獨(dú)立幀放在FRＭPａyloａd的方式，那就必須采用加密方式,并且不超過(guò)ＦRMＰayloａｄ的最大長(zhǎng)度。注意:如果MＡC命令不想被竊聽(tīng),那就必須以獨(dú)立幀形式放在FRMPayloaｄ中。每個(gè)MAC命令是由１字節(jié)ＣIＤ跟著一段可能為空的字節(jié)序列組成的。CIDCommaｎd由誰(shuí)發(fā)送描述終端網(wǎng)關(guān)０x０2LiｎｋＣhｅckReqx終端利用這個(gè)命令來(lái)判斷網(wǎng)絡(luò)連接質(zhì)量0x０2LｉnkCheckAnｓxＬｉnkCｈecｋReｑ的回復(fù)。包含接收信號(hào)強(qiáng)度，告知終端接收質(zhì)量0x０3ＬinkADRRｅｑx向終端請(qǐng)求改變數(shù)據(jù)速率，發(fā)射功率，重傳率以及信道0ｘ03LinｋADRＡｎsxLｉnkADRRｅq的回復(fù).0x04DutyCycｌｅRｅｑｘ向終端設(shè)置發(fā)送的最大占空比.0x04DutyCyｃleAnsxDutyCyｃlｅＲeq的回復(fù)。0ｘ05RＸParａmSetupＲｅqｘ向終端設(shè)置接收時(shí)隙參數(shù)．０x05RXPａｒａmSetuｐAnsｘRXPａｒamＳｅｔuｐＲeq的回復(fù).０ｘ0６DeｖStａt(yī)usReqx向終端查詢其狀態(tài)。0ｘ06ＤevStａt(yī)usAｎsx返回終端設(shè)備的狀態(tài)，即電池余量和鏈路解調(diào)預(yù)算.0x０7NeｗChannｅlＲeqx創(chuàng)建或修改1個(gè)射頻信道定義。０x07NewChannelAnsｘNewＣhanｎｅｌReq的回復(fù)。0x08RＸTimingＳeｔupRｅｑx設(shè)置接收時(shí)隙的時(shí)間。０x08RXTimingＳetuｐAnsｘRＸTiｍinｇSeｔupReｑ的回復(fù)。0x８0～０xFF私有xx給私有網(wǎng)絡(luò)命令拓展做預(yù)留。表4：ＭAＣ命令表注意：MAC命令的長(zhǎng)度雖然沒(méi)有明確給出，但是MAC執(zhí)行層必須要知道.因此未知的MAＣ命令無(wú)法被忽略，且前面未知的MAC命令會(huì)終止MAC命令的處理隊(duì)列。所以建議按照ＬoRaWＡN協(xié)議介紹的ＭＡＣ命令來(lái)處理MAC命令.這樣所有基于LoRaWAN協(xié)議的ＭAＣ命令都可以被處理,即使是更高版本的命令.2梳理解析從LoRaWＡN第4章的幀格式可以得到如下信息:MＡＣ命令，要么使用ＦＰort0來(lái)單獨(dú)傳輸,要么使用非零的FPort來(lái)和數(shù)據(jù)一起傳輸。ＬoRaＷAN第5章,LoRaWAN出于網(wǎng)絡(luò)管理需要，提出了9條MAＣ命令,這個(gè)章節(jié)是對(duì)９條命令進(jìn)行具體的描述。說(shuō)個(gè)題外話,CLＡA（中國(guó)LoＲａ應(yīng)用聯(lián)盟)在９條命令以外還擴(kuò)充了一些MAC命令?，F(xiàn)階段協(xié)議還不能公開(kāi),所以我就不多說(shuō)了.中興目前作為L(zhǎng)oRa聯(lián)盟董事會(huì)成員，也許以后會(huì)把這些拓展MAC命令引入到LｏRａＷAN協(xié)議也說(shuō)不準(zhǔn),大家暫且當(dāng)個(gè)課外知識(shí)了解下就好。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{/*！＊ＬinkCheｃｋＲｅq*／ＭOTＥ_(tái)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(jìn)Ａ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ìn)來(lái)，經(jīng)過(guò)層層篩選，最終到達(dá)ＰｒoceｓsMacCoｍmands（)來(lái)處理MAC命令．

這里代碼中涉及的兩種處理方式，可以跟協(xié)議對(duì)應(yīng)起來(lái):ｐort=０時(shí),ＭＡC命令放在FRMＰayload中，需要先解密再處理;port非零時(shí),Ｍ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ā)送及回復(fù)MAC命令的發(fā)送及回復(fù)處理都在這個(gè)函數(shù)中，AddMａｃCommand(）。協(xié)議棧對(duì)MAＣ命令發(fā)送的處理還是比較簡(jiǎn)單的，都是放在Fｏｐｔs中來(lái)傳輸,都在這個(gè)15字節(jié)的MacCommaｎｄsBｕfｆｅr中.LiｎｋADＲ是LｏRaWAN網(wǎng)絡(luò)管理中相當(dāng)重要的一個(gè)ＭAC命令,其解析占用了１83行.索性專門(mén)寫(xiě)篇源碼解析,記錄下．閱讀此文前,最好再把第五章的這個(gè)命令好好翻一翻，代碼和協(xié)議才能對(duì)應(yīng)上。我正在陸續(xù)對(duì)協(xié)議的各個(gè)章節(jié)進(jìn)行翻譯，具體其他章節(jié)的譯文，以及譯文之外的代碼解析，可點(diǎn)此查看帖子ＨYPEＲLINK”hｔtp：//blog。csｄn.nｅｔ／ｉoｔｉｓan/ａrtｉcle/detaiｌｓ／５39304５8”\ｔ"_ｂlanｋ”LoＲａ學(xué)習(xí)筆記_匯總。

?本文作者twowinｔeｒ,轉(zhuǎn)載請(qǐng)注明作者:Ｈ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沒(méi)開(kāi)，那么就立即丟棄本命令處理。這里的macIndｅｘ+=３是對(duì)應(yīng)LinkADRReq的剩余命令長(zhǎng)度３而言的。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ｐ都給解析了出來(lái)。４。按地區(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情況下，先檢查是否有未定義的頻點(diǎn),如果沒(méi)問(wèn)題則更新對(duì)應(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＿M(jìn)AX_TX＿POＷＥR，ＬＯRＡMAC_ＭIN_ＴX_POWER)=＝ｆaｌse)｛sｔaｔus&=０xFB;//TxPowerKO}7．全部判斷通過(guò)后更新參數(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?；貜?fù)MAＣ命令LiｎkADRAnsAddMacCoｍmanｄ（MOＴＥ_(tái)MＡC_LINＫ_AＤR_ANＳ，statｕs，0)；突然發(fā)現(xiàn)AddMａcＣommａnd的形參只有CID加2字節(jié)的回復(fù),我是太無(wú)聊,把終端所有ＭAC命令都翻了一遍，確認(rèn)所有pａyloａd確實(shí)是小于2字節(jié)。再次贊揚(yáng)LｏRaWAN協(xié)議的精簡(jiǎn)作風(fēng)。第6章終端激活為了加入LｏRaWＡN網(wǎng)絡(luò),每個(gè)終端需要初始化及激活。終端的激活有兩種方式,一種是空中激活Oｖeｒ-The-ＡｉrＡcｔｉｖaｔion(OTＡA),當(dāng)設(shè)備部署和重置時(shí)使用;另一種是獨(dú)立激活A(yù)ｃtivａt(yī)ｉｏｎＢｙＰersoｎalizatｉon（ABP)，此時(shí)初始化和激活這兩步就在一個(gè)步驟內(nèi)完成。twｏwiｎter備注:ABP這個(gè)詞不太好翻譯，通常會(huì)翻成個(gè)性化激活,也就是通過(guò)獨(dú)立配置參數(shù)的方式激活。但總感覺(jué)少點(diǎn)味道，與空中激活擺在一起,感覺(jué)獨(dú)立激活這個(gè)詞在語(yǔ)義上更有并列感。當(dāng)然這是我的主觀感覺(jué),建議大家和同行交流時(shí),還是說(shuō)ＡBＰ激活吧.６。1終端激活后的數(shù)據(jù)存儲(chǔ)激活后，終端會(huì)存儲(chǔ)如下信息:設(shè)備地址(ＤevAｄｄr),應(yīng)用ID(ＡpｐEUＩ),網(wǎng)絡(luò)會(huì)話密鑰（NwkＳKey）,應(yīng)用會(huì)話密鑰（AppSＫｅｙ)。6。１。1終端地址(DevAddr)終端地址(DeｖAｄｄｒ)由可標(biāo)識(shí)當(dāng)前網(wǎng)絡(luò)設(shè)備的３2位ID所組成，具體格式如下:Bｉｔ#[3１。.25][24。。0］DevＡｄdrbitｓＮｗkIＤNwkAddr它的高7位是NｗｋＩd，用來(lái)區(qū)別同一區(qū)域內(nèi)的不同網(wǎng)絡(luò)，另外也保證防止節(jié)點(diǎn)竄到別的網(wǎng)絡(luò)去．它的低25位是NwkAｄdr,是終端的網(wǎng)絡(luò)地址,可以由網(wǎng)絡(luò)管理者來(lái)分配.6．1.2應(yīng)用ID(ＡppＥUI）

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

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

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

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

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

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

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

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

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

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

?整個(gè)代碼結(jié)構(gòu)非常清晰，用一個(gè)宏（OVEＲ_ＴHE_ＡＩR_ＡＣTIVAＴION)分開(kāi)兩段,分別對(duì)應(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