LoRaWAN學習筆記2.1—LoRaWAN協定
--樊渝江
升特官方在2017年11月推出了LoRaWAN-Specification-v1.1，新協定在架構上有些變化，但大體沒有變。等1.1推出一段時間後我會針對新協定修改一些伺服器程式。
言歸正傳，目前大家都還是使用的老版本協定LoRaWAN-Specification-v1.0.2版本，你能買到的并且支援LoRaWAN标準的産品，都是基于這個版本開發的，是以我們以此版本開始分析。這個版本熟悉了再去看1.1版本也不是什麼難事，如果有那就是英語問題。
在開始看的時候希望大家能先閱讀一下《LoRaWAN-Specification-v1.0.2》，也有英語大神翻譯的縮減版，名字叫《LoRa規範CLASS-A》，如果看英語困難就去看中文版本的吧，翻譯的挺好。《LoRa規範CLASS-A》 下載下傳 位址
現在就讓我們來見識見識這個協定。
LoRaWAN的定義我在上一個筆記裡已經講過了，如果還不了解的話就翻翻上一篇，或者百度一下。現在我們直接開始幹貨。
LoRaWAN将終端通信模式分為了三類，分别為CLASSA,CLASS B,CLASS C。
ClASS A：雙向終端裝置，通過在終端裝置上行鍊路傳輸後開放兩個下行鍊路視窗，使Class A 的裝置可以雙向通信。傳輸時隙由終端裝置決定，該傳輸時隙基于其自身的通信需求，在随機時間基準（ALOHA型協定，全随機，當兩個包頻率相同，發射時間相同，1301會接收信号強度強的那個包，這是我實測過得。）上進行小變動。由于應用層隻在終端裝置上行連結傳輸後較短的時間内需要來自伺服器的下行鍊路通信，是以 CLASS A 模式的裝置是功耗最低的終端裝置系統。伺服器在其他任意時刻的下行鍊路都需要等待直到下一個确定的上行鍊路。伺服器不能主動向終端發資料，必須等到終端上發了資料後才能給他下發資料。
CLASS B：具有确定接收時隙的雙向終端裝置，CLASS B 裝置考慮了更多接收時隙。除 CLASS A 的随機接收視窗外，CLASS B 裝置會在确定的時間内打開額外的接收視窗。為保證終端裝置在确定的時間内打開接收視窗，終端裝置會從網關接收到一個時間同步信标。這使伺服器知道終端裝置何時在監聽。這種方式就是時鐘同步方式，能使系統的終端數更多，可惜1.0.2官方提供的源碼中，并沒有。在1.1協定中有描寫Class B，希望源碼中含有Class B模式。
CLASS C：具有最大接收時隙的雙向終端裝置，CLASS C 的終端裝置具有接近于連續地開放接收視窗，接收視窗隻在傳輸時關閉。相對于CLASS A 和 CLASS B，CLASS C 終端裝置會消耗更多的能量，但是在 CLASS C 模式下，伺服器到終端裝置通信的延時最短。
簡單意思就是一直把接收打開，隻有發送時不能接收，其他時間都在接收，對于有線供電且不考慮低功耗的可以考慮這種方式，這種方式伺服器可以主動下發資料。
官方要求LoRaWAN裝置至少要有CLASS A功能，後面我們就圍繞CLASS A講，CLASS B目前在此版本協定中代碼上還不支援，就沒有深研究，懂了CLASS A ，CLASS C自然就明白了。
下面我們就開始講講CLASS A的工作方式。
上下行資料鍊路消息，上行是終端往伺服器發，下行是伺服器往終端發。
在CLASS A模式，終端和伺服器的通信方式如下：終端發完資料後延時1s（RECEIVE_DELAY1）開啟接收視窗1（以下稱RX1）,RX1開啟1s，如果在1s内RX1沒收到資料，開啟視窗2（以下稱為RX2），接收到了就不需要開啟RX2了。看圖（圖是我截的）：
RECEIVE_DELAY1（接收延時1）：協定規定是1s（正負20us）,實際操作可以更具項目來調。
RECEIVE_DELAY2（接收延時2）：協定規定是2s（正負20us）,實際操作可以更具項目來調。
注：RX1開啟時間為1s，RX2開啟時間沒有具體規定，隻說了什麼時候開，沒說開多久，我設的3s，開久了浪費電。
上行鍊路消息
上行鍊路資訊由終端裝置通過一個或多個網關傳輸給網絡伺服器。下行裝置使用LoRa 射頻傳輸包顯性模式，模式包括 LoRa 的實體資料頭和它的 CRC 校驗。有效負荷（PHYPayload）的完整性由 CRC 進行保護。無線收發器将 PHDR, PHDR_CRC 和有效負荷 CRC 字段插入其中。
上行鍊路 PHY：
下行鍊路資訊
每一個下行鍊路消息都由網絡伺服器通過唯一的網關轉接傳輸給一個終端裝置。下行消息使用射頻資料包顯性模式，該模式包括一個實體資料頭和 CRC 頭。
下行鍊路 PHY：
注：下行沒有CRC校驗，而上行的有，如果是LoRaWAN标準協定標頭為0x34，私有協定為0x12。
我們需要的有用資料就在PHYPayload裡,除了標頭其他就不管了，硬體知道完成。
我總結了一個excel供大家參考，下載下傳位址：http://download.csdn.net/download/fanyujiang2004/9964880
此版本有點老，由于其他原因新版本的就沒有上傳了。
可以清晰的看見上行通信包的結構，從上往下第一個是終端入網包(OTAA模式用)，第二個是入網成功後伺服器下發的确認包（OTAA模式用），第三個是正常通信時的上行包，第四個是正常通信時的下行包。裡面有很多名詞定義，我們在後續分析包的時候會一一解釋，文章的最後我也會寫一個單獨的表。
MHDR:
MHDR為一個位元組，通過位的組合來表示包的類型。
MHDR 為0x00 就為入網申請包
0x20就是入網成功的下行确認包
通過分析MHDR中的第5位到第7位，就能确定資料包的類型。
入網申請包：
入網包MIC計算方法cmac=aes128_cmac(AppKey,MHDR|AppEUI|DevEUI|DevNonce)
MIC=cmac[0..3]
AppEUI：在 IEEE EUI64 具有全球唯一應用 ID，可以單獨識别終端裝置的應用服務提供商（等等）。AppEUI 在激活程式執行前已儲存在終端裝置中。
DevEUI：是全球終端 ID，符合 IEEE EUI64，用來唯一辨識終端裝置。
DevNonce：是個随機值，終端裝置最近使用的一些(數量自定義)DevNonce 會儲存在網絡伺服器（NS）。如果終端發送的入網請求中的 DevNonce 在 NS 中可以查到，該請求就會被忽略。取LoRa晶片的RSSI随機值，得到DevNonce。
AppKey：是AES-128的應用密鑰，密鑰隻有應用供應商知曉和掌握，在出廠的時候AppKey已經寫在伺服器和終端裡，這兩端儲存的AppKey必須相同，要不然無法入網。終端裝置通過無線激活入網時，通過AppKey衍生會話密鑰 NwkSKey和AppSKey，并分發相應的終端裝置，用來加密、校驗網絡通訊和應用資料。
入網同意下行包：
入網申請包中帶有資料AppNonce（3位元組）、NetID（3位元組）、DevAddr（4位元組）、DLSeting（1位元組）、RxDelay（1位元組）、CFList（0~16位元組），而且整個MACPayload+MIC都被加密，加密鑰匙是AppKey。
計算方法如下：
入網同意下行包加密
aes128_decrypt(AppKey,AppNonce | NetID | DevAddr |DLSettings | RxDelay | CFList | MIC)
MIC校驗
cmac =aes128_cmac(AppKey,MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay |CFList)
MIC = cmac[0..3]
NwkSKey和AppSKey計算方法：
NwkSKey =aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16) （pad16函數附加 0 位元組以便于資料長度是一個 16 的倍數）
AppSKey = aes128_encrypt(AppKey, 0x02 |AppNonce | NetID | DevNonce | pad16)
AppNonce：是由網絡伺服器産生的一個随機數或唯一 ID，終端裝置用它來衍生兩個會話密鑰：NwkSKey 和 AppSKey，伺服器也會利用公式算出這兩個秘鑰，兩端都儲存此秘鑰。
NetID：NetID的低7位稱作NwkID，這低7位也是DevAddr（終端短址）的高7位。區域相鄰或重疊的網絡的NwkID不能相同。餘下的高17位由網絡營運商自由配置設定。
DevAddr：終端的短位址和DevEUI有對應關系。他的組成結構如下：
| Bit | [31..25] | [24..0] |
| DevAddr | NwkID | NwkAddr |
NwkAddr：終端裝置網絡位址，該位址可以有由網絡管理者配置設定。 NwkID：在NetID中有解釋
DLSeting：結構如下：
| Bits | 7 | 6..4 | 3..0 |
| DLsettings | RFU | DLsettings | RX2DataRate |
RxDelay：遵循着在 RXTimingSetupReq 指令中的延時字段一樣的慣例。預設0x00。 RX1Droffset 字段設定上行鍊路資料和被用作在第一接收時隙（RX1）中與終端裝置通信的下行鍊路資料之前的偏移。偏移預設值為 0。下行資料率通常小于等于上行鍊路資料率。偏移量被用來考慮在某些區字段基站的最大功率密度限制以及平衡上行鍊路和下行鍊路射頻通信線路的邊界。上行鍊路和下行鍊路資料率的實際關系是有區域特異性的，并且在“實體層”部分會詳細介紹。
CFList：這個字段是根據不同地區的标準來設定的，如果是CN470标準的話，此字段為空。
NwkSKey：是配置設定給終端裝置的網絡會話密鑰。伺服器和終端用它來計算和校驗所有消息的MIC（消息一緻碼），來保證收發的資料一緻。也可以用來對MAC負載（Fport為0時，MAC指令放在Payload裡面）的消息進行加/解密。
AppSKey：是配置設定給終端裝置的應用會話密鑰。伺服器和終端用來對FRMPayload字段進行加解密。也可以用來計算和校驗應用層MIC。