LoRaWAN 的server包括 NS(Network server)、AS(application server)、CS(Custom server)....

 

其中NS和AS是必不可少的，是完成LoRaWAN協(xié)議的重要組成部分

 

NS 職責(zé)

NS是直接與GW通信的服務(wù)器，也是AS和GW之間的橋梁

 

我所知道的工作有如下幾點：

 

驗證數(shù)據(jù)的合法性(校驗MIC)

從GW的信息中提取數(shù)據(jù)，整理成NS 的JSON數(shù)據(jù)包

將校驗合法的數(shù)據(jù)打包成新的JSON包上傳至AS

OTAA入網(wǎng)時向AS發(fā)送請求入網(wǎng)消息，然后再將入網(wǎng)信息告訴AS，當(dāng)獲取AS傳來的入網(wǎng)的信息，告訴GW

GW 和 AS之間的數(shù)據(jù)通道

有幾點需要注意的是NS端的數(shù)據(jù)不進(jìn)行AES解密工作。

 

AS 職責(zé)

AS是server端的數(shù)據(jù)處理中心

 

它的工作有如下幾點:

 

上行數(shù)據(jù)的解密

下行數(shù)據(jù)的加密

OTAA入網(wǎng)請求的處理(同意入網(wǎng)/生成APPSKEY/NWKSKEY)

CS 職責(zé)

CS負(fù)責(zé)將AS給的數(shù)據(jù)處理成用戶自定義的數(shù)據(jù)協(xié)議格式，也就是說，CS端必須是用戶來完成的，因為上面運行的是用戶的協(xié)議。這里也就不再多說了。

 

抓包分析

以下是我在本地服務(wù)器端通過抓到得來的數(shù)據(jù)，我們通過分析數(shù)據(jù)包來理解數(shù)據(jù)的走向已及現(xiàn)有的server端處理流程。抓包使用的是tcpdump。

 

1.NS->AS數(shù)據(jù)

這是一幀從NS->AS的數(shù)據(jù)，使用的是TCP方式，AS的數(shù)據(jù)端口為4000。從data部分我們可以看出來，這是一個未解密的數(shù)據(jù)。

 

 

提取其中的數(shù)據(jù)部分為：

 

 

再把app.userdata.payload 做base64解碼之后，得到的payload內(nèi)容是這個:

 

 

此時看到的payload因為是加密的，所以完全看不出來數(shù)據(jù)內(nèi)容是什么。

 

不過在這里，我們可以看到，NS已經(jīng)將GW上傳的數(shù)據(jù)做了一定的解析，封裝成了另外一種JSON格式，由此，我們不難得出，NS做的工作包括--base64解碼/MIC校驗/GW數(shù)據(jù)包的重新組包

 

2.AS->CS數(shù)據(jù)

這是一幀從AS->CS的數(shù)據(jù)，使用的是TCP方式，CS的數(shù)據(jù)端口為5000。從data部分我們可以看出來，這是一個已經(jīng)解密完成的數(shù)據(jù)了。

 

 

提取其中的數(shù)據(jù)部分為：

 

 

再把app.userdata.payload 做base64解碼之后，得到的payload內(nèi)容是這個:

 

 

而此時，數(shù)據(jù)已經(jīng)完全解密了，可以看到數(shù)據(jù)就是在AS解密的，解密完再發(fā)送給CS，CS再做進(jìn)一步用戶協(xié)議的處理。

 

在這里，我們可以看到，AS已經(jīng)將NS傳輸過來的JSON包的payload部分做了解密，然后再傳給了CS。所以解密工作是在AS完成的。