LoRaWAN：复杂度vs自由度
图1：LoRaWAN的传统网络模型图
上图仅仅是企业级LoRaWAN网络的模型图。仅仅包括ED/GW/NS/AS，分别指设备、网关、网络服务、应用服务。如果是运营商级别网路，还需要增加一个JS（Join Server），以满足漫游的需求。此时，我们需要一个较为复杂的分布式网络以及信令系统。这超出了大多数的开发者能力，或者精力范围。
降维简化设计
全栈开发并不意味着要把所有的设计任务都揽在自己身上。技术复用、快速整合是最关键的一步。
如果LoRaWAN将来是一种普遍适用的LPWAN技术，那么在不久的将来，很快价格就会降低到和网卡一样便宜，一样通用。那么您会去做网卡制造业务么？从这个逻辑上说，未来硬件的毛利一定是越来越低。
如果LoRaWAN将来依然是一种小众技术，那么您会继续在LoRaWAN业务上投入这么多精力么？为什么在那么广泛的IoT场景中，LoRaWAN现在比其他更加热门？从这个逻辑上说，业界大体意识到：LoRaWAN的标准化开始了。
所以，回避大而全，复用现有技术，专注自己的优势非常重要。
- ED/GW硬件: 复用RF模块、EV板、甚至白牌的硬件
- ED/GW软件: 复用Arduino/mbed/Python/Node/Lua设计
- NS: 采用TTN网络服务，或者国内的NS服务
- AS: 采用通用的Flask/Node.js完成任务，集成RESTful API即可。如果有应用场景的现成设计更好。
- APP: 采用React Native，甚至依赖于移动端浏览器来完成设计。因为这大体上就是一个网络应用。
所以，设计任务降维成外购硬件、加载固件、对接NS，设计AS，忽略APP即可。
ED/GW设备设计
图2：LoRaWAN推荐的报文推送网关
在图1所示ED/GW/NS中，GW是一个比较重要的角色。但是从图2可以看到，GW其实仅仅工作在PHY/HAL层面，非常贴近硬件，不涉及到任何MAC层的操作，做的工作仅仅是将空口报文通过TCP/UDP发送给NS。反向也是如此。所有MAC层的操作，在ED和NS的对等实体中完成。AES加密MAC层数据交由GW传输而已。
此图解释了ED/GW所需要完成的设计任务。那么所需要的硬件平台呢？
图3：Arduino MKR1300 LoRaWAN ED/GW
MCU + SX127X是最基本的模型。
Arduino MKR1300采用了Murata的LoRaWAN模组，内置STM32L0/L1 MCU，并且提供了USB/UART转接。这种模式是最主流的ED/GW(1-ch)的硬件设计。当然为了实现低成本和低功耗，可以用国产RF模块，国产MCU或者STM8。因为LoRaWAN需要足够的ROM/RAM，尤其是ED必须实施完整的LoRaWAN堆栈。我个人不太推荐8bit MCU，片内资源太少。一如我在8051时代不推荐使用日系4bit MCU一样。
图4：MicroPython PyBoard
一般来说，MCU会选择STM32F0/F1/F4/L0/L4。从价格上说F4/L4略贵，但是由于支持MicroPython/Lua/JS/C++编程，可以适用于许多场景。我个人测试过CubeMX/ARM mbed/Arduino/MicroPython/Lua。不同的固件选择非常多。但是需要时间不断测试。
由于这些MCU大多具备USB端口，所以可以直接插入到任何系统中构建GW。低成本GW则使用WiFi SoC ESP32完成。这里不推荐ESP8266，GPIO过少。
图5：Linux SBC
Linux SBC是一种可选件，配合STM32F1/F4构成网关。不过它更大的价值在于可以灵活构建GW/NS一体化设计。更加适合小型企业的运行。实际上，它还有一个替代品，即智能路由器。智能路由器比树莓派之类的EVB更加低廉，更容易部署。
