Route Discovery & Route Repair

1. Route Discovery

当单播消息从一台设备发送到另一台设备，并且没有预先存在的路由时，会发起路由发现。
我们假设没有现有的路由，因此网络软件将开始路由发现过程。为简单起见，假设所有设备的路由表都为空。
以设备A向设备C发送消息为例，如下图所示。设备A将向整个网络广播一条消息，要求设备C回复。此广播消息还用于建立回A的临时路由，因为每个中间设备都会记录从哪个设备接收到该消息。路由在中间节点上更新——注意，这些是临时条目，它们的生存期比常规条目短，并且不打算被重用。因为A是单跳邻居，所以B和D不需要存储它的路由信息。

C可以使用B或D作为返回A的下一跳，Zigbee将此选择留给实现;Silicon Labs使用加权算法来选择最可靠的下一跳。
当消息到达设备C时，C通过步骤1中构造的临时路由向设备A 发送一条特殊的单播消息(称为路由响应消息( Route Response message))，如下图所示。中间设备使用此消息建立回C的(永久)路由。

因为C是一个单跳邻居，所以B不需要存储关于它的路由信息。D没有参与这一部分的发现过程，因为在上面的步骤中D没有被A选中。当消息到达设备A时，表示路由发现完成
新的路由可以用来从A到C发送数据消息。
Zigbee PRO网络将检测非对称射频链路，并在路由发现过程中避免它们。这样可以提高发现过程和生成的路由的可靠性。
在一定的超时时间内(在EmberZNet 3.0和更高版本中为1分钟)未被使用的路由被标记为重用，新的路由可能会覆盖该内存位置。在某些情况下，可能需要一条新路由，而一个或多个中间设备将没有可用的路由表项;在这种情况下，消息将被报告为无法传递到发送节点。

应用程序指定接收方是否应该发送端到端确认(这称为APS确认)。如果是，在等待确认超时的情况下，发送方将在成功交付时收到通知。在超时的情况下，可能需要修复路由。

2. Route Repair

当发送带有请求确认的单播消息时，发送设备将在消息成功传递时得到通知。如果没有收到此确认，则可以采取步骤修复路由。路由修复的步骤与上面的路由发现完全相同，但损坏的节点(下图中的B)不参与，导致路由选择不同。

更新A的路由表，显示下一跳为D，消息沿新的路径成功传递，如下图所示。

如果没有可用的替代路径，则通知发送方无法传递消息。在EmberZNet PRO中，这由EmberStatus为EMBER_DELIVERY_FAILED (0x66)的响应表示。
在执行路由修复之前，EmberZNet PRO将尝试再次发送消息。当消息选项中同时设置了EMBER_APS_OPTION_RETRY和EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY时，会自动进行路由修复。