虚拟化网状网络

引言

虚拟网状网络有助于解决使用自定义收发器创建网状网络的问题。网状网络的所有拓扑都存储在 Azure 中。每个节点被归类为中继节点或控制器节点（在 Zigbee 术语中通常称为基站）。最近，一家芬兰公司成功地在一个网状网络中连接了百万个物联网设备，请阅读他们在网站上的相关介绍：http://www.wirepas.com/

因此，我想做得更好，并利用云基础设施来完成协议栈第 3 层繁重的计算工作，从而使其更加高效。无线收发器应该高效地完成第 2 层工作，同时所需的计算能力最少。

控制器节点与中继节点形成星型拓扑。然而，中继节点之间可以形成树型拓扑。

背景

该层提供主机寻址、消息转发和即时加入。对于物联网消息，在大多数情况下不需要重新构建消息，因此我们不需要增加平台的重构消息的负担。与 Zigbee 一样，通信通过基站控制器进行。节点 2 只能通过基站控制器与节点 4 通信。然而，节点 2 可以直接与节点 1 通信。

理想情况下，网状网络的网络寻址将需要以下寻址结构，用于协议栈中的第 3 层路由功能：

• 源地址 – 发送数据包的设备的 16 位地址。
• 目标地址 – 接收数据包的设备的 16 位地址。
• 跳数 – 中继数据包的最后一个系统的 16 位地址，用作返回路径的起点。跳数可以设置为目标地址，以防止中继，并设置为零以请求开放式中继。
• 大小 – 数据包的大小（字节），包括头部。
• 数据包类型 – 数据包的类型，例如连接协商、ping、扫描等。
• 序列号和响应 – 序列号和响应使用计数器和初始随机数进行维护，这意味着只有通信的两个系统才能轻松地将数据包注入网络并定向到对方。这并非安全措施，仅用于阻止注入恶意数据包，并允许网状网络轻松维护连接，而无需占用大量内存。
• CRC16 – 16 位循环冗余校验。在 CRC16、跳数 (Hop)、尝试次数 (Attempts) 和尝试次数 (Hops) 为零时生成 CRC。当这些字节处于零状态时，可以对数据包求和，并将总和插入后再传输。
• 分片和总分片 – 仅当数据包包含数据且数据超过 239 字节时才需要。数据包将被分割成最多 255 个分片，每个分片进行编号，以便在远端重新组装。
• 尝试次数 – 尝试计数器。
• 跳数 – 跳数计数器。

虚拟网状 API

在任何无线收发器上实现网状 API 的简化方法。每当节点收到消息时，它会检查其路由表中是否存在。如果不存在且是一个新的链路地址，它会将消息发送到基站控制器，并附带链路信息。

从上面的图表中可以看出，这些将是发送到基站控制器的链路信息。

1 - 2

4 - 5

5 - 3

利用链路信息，该服务将构建一个虚拟化的路由表。基于对节点之间传输数据和链路信息的先验知识，将构建一个高效的虚拟化网状网络。路由表会偶尔用新路由进行更新。对于低功耗节点，以基站控制器为中心的星型网状网络最适合，以最小化节点上的存储转发。目前正在测试基于树型拓扑，我们将重置并进行 OTA（空中下载）更新节点。

每个节点都有一个用于通信的地址和通道。

void begin(uint8_t _channel, uint16_t _node_address );
void update(void);
bool available(void); // check to see if the node is available
void peek(MeshHeader& header);
size_t read(MeshHeader& header, void* message, size_t maxlen);
bool write(MeshHeader& header,const void* message, size_t len);

使用 nrf24 无线收发器。

// nRF24L01(+) radio attached using Getting Started board
RF24 radio(9,10);
 
// Network uses that radio
RF24Network network(radio);
 
// Address of our node
const uint16_t this_node = 1;
 
// Address of the other node
const uint16_t other_node = 0;
 
// How often to send 'hello world to the other unit
const unsigned long interval = 2000; //ms
 
// When did we last send?
unsigned long last_sent;
 
// How many have we sent already
unsigned long packets_sent;
 
// Structure of our payload
struct payload_t
{
  unsigned long ms;
  unsigned long counter;
};

设置 -

void setup(void)
{
  Serial.begin(57600);
 
  SPI.begin();
  radio.begin();
  network.begin(/*channel*/ 90, /*node address*/ this_node);
}

在虚拟网状网络中，自发现的程度很低，因为 Azure 部署的网状拓扑管理器将负责管理拓扑。Azure 服务将拓扑发布到基站控制器，由基站控制器发布到中继节点。这将更新节点的路由拓扑。节点之间的相对定位的自发现是在节点启动时启动的，它将向所有节点发送一个发现 SOS。邻近节点会接收到 SOS 并将其传递下去，直到到达基站控制器。相对深度不会超过基站控制器 6 跳。如果超过 6 跳，则路由将被丢弃。在这些情况下，虚拟网状 MDM 将启动一个服务，将一个更靠近发送 SOS 节点的基站控制器连接起来。在放置每个节点之前，都会为其分配一个唯一的地点 ID，以便在 MDM 中进行资产管理。这有助于在发送网络 SOS 呼叫进行自动发现之前绘制出拓扑。SOS 数据包有助于根据节点所处的环境绘制出信号强度图。SOS 数据包必须间歇性发送，以便为分析引擎提供关于环境条件的足够信息。

添加额外的基站控制器以将网状网络的深度保持在 6 跳，成本不高。由于 MDM 基于的虚拟网状网络降低了通信成本。MDM 维护拓扑并从基站控制器收集分析数据。MDM 可以创建比网状节点之间繁琐通信计算出的 OSPF（最短路径优先）更健壮、更高效的路由。MDM 基于的网状管理器通过实现简单的 API 来帮助将不同的收发器桥接到网状网络。

关注点

使用低成本无线收发器创建网状网络是一个挑战，而基于 MDM 的虚拟网状网络有助于缓解这一问题。我将继续开发 MDM 平台，以构建分析并改进网状 API，从而在全球任何地方添加物联网传感器。

历史

在此处保持您所做的任何更改或改进的实时更新。