LoRaWAN网关的计算模型

虽然闭门造车，但是也参考了不少其他LoRaWAN网关和云计算模型。

网络规模决定了计算模型

所以来，LoRaWAN只是一个LPWAN的空口协议，与TCP网络无关联。最简单的计算模型可以采用WSN的方式，但是大规模部署，却是需要更加严格的分层设计。

集中器、网络服务器和应用服务器

IBM和Semtech推荐的计算模型适合运营商，适合大规模组网。上图是另外一个开源的LoRaWAN服务器架构。

1. Gateway，SX1301组成的多通道网关，基于UDP的packet forwarder协议将LoRa原始报文转发给Convert进行处理；
2. Convert，转换器负责将报文转化为MQTT协议，上传给NS网络服务器；
3. NC，网络控制器，承担着网络配置任务，按理应该有个控制虚线连接到各个Gateway。
4. NS，网络服务器连接到NC网络控制器和Convert转换器，承担LoRa网络的配置和数据收发；
5. AS，应用服务器，运营商处的设备管理服务；
6. CS，客户服务器，通过REST调用AS的服务。

推测在大规模网络中，存在大量的网关，所以彼此的FDD/TDD/SDD/CDD策略需要专门的NC来控制。NC和Convert或许分布在同一机器中，但是不适用于大规模网络中。这四层服务器如果用于小规模私有服务，多少有些浪费。不过任务却需要集中部属到不同的设备中。

TTN之类的LoRa服务器适用于大多数的LoRaWAN网络，可以为小规模网络提供接入服务。

Nano/Pico 网关

Nano或Pico网关基于ESP32/ESP8266的MicroPython，以及树莓派之上的CPython，前端是SX127X SPI接口。

小规模单通道网络中往往都只占用单一频段，LoRaWAN中就不存在FDD/SDD/CDD，只需要考虑TDD的方向通道。但是如果有多个网关，也需要配置简单的控制。至于NS可以使用TNN网络。

我的想法

由于我对于AS/CS比较熟悉，NS或许会利用开源的设计来部署。但是单一网关上已经可以配置2/4/6/8路，所以除了TDD，需要考虑FDD/CDD的划分。

我会把Convert/Gateway合并在同一物理计算机中（OpenWRT/Linux BOX），而NS/AS合并成定制的LoRa设备与网路管理服务器。至于CS基本上就是客户资产。