<h2 id="lorawan-server-端架构">LoRaWAN Server 端架构</h2>
<p>LoRaWAN 的server包括 NS(Network server)、AS(application server)、CS(Custom server)....</p>
<p>其中NS和AS是比不可少的，是完成LoRaWAN协议的重要组成部分</p>
<h2 id="ns-职责">NS 职责</h2>
<p>NS是直接与GW通信的服务器，也是AS和GW之间的桥梁</p>
<p>我所知道的工作有如下几点：</p>
<ol>
<li>验证数据的合法性(校验MIC)</li>
<li>从GW的信息中提取数据，整理成NS 的JSON数据包</li>
<li>将校验合法的数据打包成新的JSON包上传至AS</li>
<li>OTAA入网时向AS发送请求入网消息，然后再将入网信息告诉AS，当获取AS传来的入网的信息，告诉GW</li>
<li>GW 和 AS之间的数据通道</li>
</ol>
<p>有几点需要注意的是NS端的数据不进行AES解密工作。</p>
<h2 id="as-职责">AS 职责</h2>
<p>AS是server端的数据处理中心</p>
<p>它的工作有如下几点:</p>
<ol>
<li>上行数据的解密</li>
<li>下行数据的加密</li>
<li>OTAA入网请求的处理(同意入网/生成APPSKEY/NWKSKEY)</li>
</ol>
<h2 id="cs-职责">CS 职责</h2>
<p>CS负责将AS给的数据处理成用户自定义的数据协议格式，也就是说，CS端必须是用户来完成的，因为上面运行的是用户的协议。这里也就不再多说了。</p>
<h2 id="抓包分析">抓包分析</h2>
<p>以下是我在本地服务器端通过抓到得来的数据，我们通过分析数据包来理解数据的走向已及现有的server端处理流程。抓包使用的是tcpdump。</p>
<p>1.NS->AS数据<br />
这是一帧从NS->AS的数据，使用的是TCP方式，AS的数据端口为4000。从data部分我们可以看出来，这是一个未解密的数据。</p>
<p>15:30:53.662471 IP localhost.60795 > localhost.4000: Flags [P.], seq 13:328, ack 14, win 442, options [nop,nop,TS val 414153 ecr 414145], length 315</p>
<p>0x0000: 4500 016f aee3 4000 4006 8ca3 7f00 0001</p>
<p>0x0010: 7f00 0001 ed7b 0fa0 5505 b988 2261 4f1b</p>
<p>0x0020: 8018 01ba ff63 0000 0101 080a 0006 51c9</p>
<p>0x0030: 0006 51c1 7b22 6170 7022 3a7b 226d 6f74</p>
<p>0x0040: 6565 7569 223a 2234 6137 3730 3032 3031</p>
<p>0x0050: 3631 3031 3622 2c22 6469 7222 3a22 7570</p>
<p>0x0060: 222c 2273 6571 6e6f 223a 3532 332c 2275</p>
<p>0x0070: 7365 7264 6174 6122 3a7b 2270 6f72 7422</p>
<p>0x0080: 3a32 2c22 7061 796c 6f61 6422 3a22 5645</p>
<p>0x0090: 7666 6f56 2b72 6631 5838 4177 316e 6c52</p>
<p>0x00a0: 7077 227d 2c22 6d6f 7465 7478 223a 7b22</p>
<p>0x00b0: 6672 6571 223a 3437 312e 352c 2264 6174</p>
<p>0x00c0: 7222 3a22 5346 3132 4257 3132 3522 2c22</p>
<p>0x00d0: 636f 6472 223a 2234 2f35 222c 2261 6472</p>
<p>0x00e0: 223a 6661 6c73 657d 2c22 6777 7278 223a</p>
<p>0x00f0: 5b7b 2265 7569 223a 2266 6666 6562 3832</p>
<p>0x0100: 3765 6266 3231 6130 3722 2c22 7469 6d65</p>
<p>0x0110: 223a 2232 3031 362d 3131 2d32 3454 3135</p>
<p>0x0120: 3a33 303a 3533 5a22 2c22 7469 6d65 6672</p>
<p>0x0130: 6f6d 6761 7465 7761 7922 3a66 616c 7365</p>
<p>0x0140: 2c22 6368 616e 223a 342c 2272 6663 6822</p>
<p>0x0150: 3a30 2c22 7273 7369 223a 2d37 392c 226c</p>
<p>0x0160: 736e 7222 3a2d 3136 2e35 7d5d 7d7d 00</p>
<p>提取其中的数据部分为：</p>
<p><img alt="提取其中的数据部分" data-entity-type="file" data-entity-uuid="fb3c2c87-0d28-4dc4-bc43-72b832d11f15" src="/sites/default/files/inline-images/%E6%8F%90%E5%8F%96%E5%85%B6%E4%B8%AD%E7%9A%84%E6%95%B0%E6%8D%AE%E9%83%A8%E5%88%86.JPG" /></p>
<p>再把app.userdata.payload 做base64解码之后，得到的payload内容是这个:</p>
<p>app.userdata.payload base64 decoded:</p>
<p>\x54 \x4b \xdf \xa1 \x5f \xab \x7f \x55</p>
<p>\xfc \x03 \x0d \x67 \x95 \x1a \x70</p>
<p>此时看到的payload因为是加密的，所以完全看不出来数据内容是什么。</p>
<p>不过在这里，我们可以看到，NS已经将GW上传的数据做了一定的解析，封装成了另外一种JSON格式，由此，我们不难得出，NS做的工作包括--base64解码/MIC校验/GW数据包的重新组包</p>
<p>2.AS->CS数据<br />
这是一帧从AS->CS的数据，使用的是TCP方式，CS的数据端口为5000。从data部分我们可以看出来，这是一个已经解密完成的数据了。</p>
<p><img alt="数据" data-entity-type="file" data-entity-uuid="53a6a533-1378-4d04-b649-b94a13cd1da5" src="/sites/default/files/inline-images/%E6%95%B0%E6%8D%AE.JPG" /></p>
<p>提取其中的数据部分为：</p>
<p><img alt="提取其中的数据部分" data-entity-type="file" data-entity-uuid="99eb6dde-9d42-497a-be23-b5ab47ef0762" src="/sites/default/files/inline-images/%E6%95%B0%E6%8D%AE2.JPG" /></p>
<p>再把app.userdata.payload 做base64解码之后，得到的payload内容是这个:</p>
<p>\x01 \x02 \x03 \x04 \x05 \x06 \x07 \x08</p>
<p>\x09 \x0a \x0b \x0c \x0d \x0e \x0f</p>
<p>而此时，数据已经完全解密了，可以看到数据就是在AS解密的，解密完再发送给CS，CS再做进一步用户协议的处理。</p>
<p>在这里，我们可以看到，AS已经将NS传输过来的JSON包的payload部分做了解密，然后再传给了CS。所以解密工作是在AS完成的。</p>
<p>文章来源：<a href="http://www.cnblogs.com/answerinthewind/" id="Header1_HeaderTitle">AnswerInTheWind</a></p>