【ember zigbee】第三章：ug103-02-fundamentals-zigbee 学习笔记(中)

写在前面

• 索引
  • 【ember zigbee】序章:协议栈相关文档学习笔记
  • 【ember zigbee】第二章：ug103-02-fundamentals-zigbee 学习笔记(上)
  • 【ember zigbee】第三章：ug103-02-fundamentals-zigbee 学习笔记(中)
  • 【ember zigbee】第四章：ug103-02-fundamentals-zigbee 学习笔记(下)

1. zigbee路由概念

1.1、概念

  Zigbee has several routing mechanisms that can be used based on the network and expected traffic patterns. In Zigbee Specification, document 05-3474, section 3.4 describes the frame format for command frames, and section 3.6.3 describes routing behavior.
  The application designer should choose which mechanism to use as part of the system architecture and design. In actual practice one application may use several of these routing mechanisms, because some devices may be performing one-to-one communications while other devices may be communicating to a central monitoring device. The types of routing discussed below are:

• Table Routing
• Broadcast Routing
• Multicast Routing
• Many-to-One/Source Routing

• Zigbee有几种路由机制，可以根据网络和预期的流量模式选择合适的路由机制。 在Zigbee规范中，文档05-3474的第3.4节描述了命令帧的帧格式，第3.6.3节描述了路由行为。
• 应用程序设计人员应选择将哪种机制用作系统体系结构和设计的一部分。 在实际实践中，一个应用可以使用这些路由机制中的若干个，因为一些设备可以执行一对一通信，而其他设备可以与中央监控设备通信。 下面讨论的路由类型是：
  • 路由表
  • 广播路由
  • 组播路由
  • 多对一/源路由

1.1.1 路由表

  Routes are formed when one node sends a route request to discover the path to another node. After a route is discovered between the two nodes, the source node sends its message to the first node in the route, as specified in the source node’s routing table. Each intermediate node uses its own routing table to forward the message to the next node (that is “hop”) along the route until the message reaches its destination. If a route fails, a route error is sent back to the originator of the message who can then rediscover the route.

• 当一个节点发送路由请求以发现到另一个节点的路径成功后，就会形成路由。在两个节点之间发现路由后，源节点将消息发送到路由中的第一个节点，之后的中间节点查找自己的路由表，然后将消息转发到路由的下一个节点（即“跳”），直到消息到达其目的地。如果路由失败，则会向消息的发起者发送路由错误，然后该发起者可以重新发现路由。

1.1.2 广播路由

  Broadcast routing is a mechanism to send a message to all devices in a network. Network-level broadcast options exist to send to routers only, to all non-sleeping nodes including end devices, or also to send to sleeping end devices. A broadcast message is repeated by all router-capable devices in the network three times to ensure delivery to all devices. While a broadcast is a reliable means of sending a message, it should be used sparingly because of the impact on network performance. Repeated broadcasts can limit any other traffic that may be occurring in the network. Broadcasts are also not a reliable means of delivery to a sleeping device because the parent device is responsible for buffering the message for the sleeping child but may drop the message before the end device wakes to receive it.

• 广播路由是一种向网络中的所有设备发送消息的机制。路由广播的选项有仅发送到路由器、发送到包括终端设备的所有非休眠节点、或者发送到所有设备，包含休眠终端设备。网络中所有支持路由器的设备将会重复广播消息三次，以确保消息传送到所有设备。虽然广播是发送消息的可靠方法，但由于对网络性能的影响，应谨慎使用广播。重复广播可以限制网络中可能发生的任何其他流量。广播也不是传递给睡眠设备的可靠方式，因为父设备虽然会负责缓冲睡眠设备的消息，但可能在睡眠设备唤醒接收消息之前，就丢弃该帧消息了。

1.1.3 组播路由

  Multicast routing provides a one-to-many routing option. A multicast is used when one device wants to send a message to a group of devices, such as a light switch sending an on command to a bank of 10 lights. Under this mechanism, all the devices are joined into a multicast group. Only those devices that are members of the group will receive messages, although other devices will route these multicast messages. A multicast is a filtered limited broadcast. It should be used only as necessary in applications, because over-use of broadcast mechanisms can degrade network performance. A multicast message is never acknowledged.

• 组播路由提供一对多路由选项。 当一个设备想要向一组设备发送消息时使用多播，例如向一组10个灯发送灯开启命令。 在此机制下，所有设备都加入了组播组。 只有那些属于该组成员的设备才会收到消息，但其他设备将路由这些多播消息。 多播是过滤的有限广播。 它应该仅在应用程序中使用时使用，因为广播机制的过度使用会降低网络性能。当然，组播消息是不会应答的。

1.1.4 Many-to-One/源路由表

  Many-to-one routing is a simple mechanism to allow an entire network to have a path to a central control or monitoring device. Under normal table routing, the central device and the devices immediately surrounding it would need routing table space to store a next hop for each device in the network, as well as an entry to the central device itself. Given the memory limited devices often used in Zigbee networks, these large tables are undesirable.
  Under many-to-one routing, the central device, known as a “concentrator,” sends a single route discovery that established a single route table entry in all routers to provide the next hop to the central device. This yields a result similar to that of table routing, but with a single many-to-one route request rather than many individual, one-to-one route requests from each router towards the concentrator.
  All devices in the network then have a next hop path to the concentrator and only a single table entry is used. However, often the central device also needs to send messages back out into the network. This would result in a more significant increase in route table size, particularly for those nodes closest to the concentrator, since they are relay points in the concentrator’s many outbound routes to the rest of the network. Instead, incoming messages to the concentrator first use a route record message to store the sequence of hops used along the route. The concentrator then stores these next hop routes in reverse order as “source routes” in a locally held table known as a “source route table”. Outgoing messages include this source route in the network header of the message. The message is then routed using next hops from the network header instead of from the route table. This provides for large scalable networks without increasing the memory requirements of all devices. It should be noted that the concentrator requires some additional memory if it is storing these source routes.

• 多对一路由是一种简单的机制，允许整个网络具有到中央控制或监视设备的路径。在正常的路由表中，中央设备及其周围的设备将网络中每个设备的下一跳存储到路由表空间来，以及中央设备本身的入口。考虑到Zigbee网络中经常使用的存储器容量受限，这些大型表的存储通常是是不被欢迎的。
• 在多对一路由下，中央设备被称为“集中器”，它发送一个单一的路由发现，在所有路由器中建立一个单一的路由表条目，以提供中央设备的下一个跳转。这产生类似于路由表的结果，但是，使用单个多对一路由请求而不是从每个路由器向集中器的一对一路由请求。
• 然后，网络中的所有设备都具有到集中器的下一跳路径，并且仅使用单个表条目。但是，中央设备通常还需要将消息发送回网络。这将导致路由表大小的更显着增加，特别是对于最靠近集中器的那些节点，因为它们是集中器的许多到达网络其余部分的出站路由中的中继点。相反，到集中器的传入消息首先使用路由记录消息来存储沿路由使用的跳跃序列。然后，集中器以相反的顺序将这些下一跳路由存储为本地保持的表中的“源路由”，称为“源路由表”。传出消息包括消息的网络头中的此源路由。然后使用网络标头中的下一跳而不是路由表来路由消息。这提供了大型可扩展网络，而不会增加所有设备的内存要求。应该注意，如果存储这些源路由，则集中器需要一些额外的存储器。

1.2、使用link status来提升路由性能

  The information in this section is provided for those wishing to understand the details of the network layer’s operation, which can prove useful during troubleshooting. Otherwise, link status messages are handled automatically by the stack and application writers need not be concerned with it.
  Links in wireless networks often have asymmetrical link quality due to variations in the local noise floor, receiver sensitivity, and transmit power. The routing layer must use knowledge of the quality of links in both directions in order to establish working routes and to optimize the reliability and efficiency of those routes. It can also use the knowledge to establish reliable two-way routes with a single discovery.
  Zigbee routers keep track of inbound link quality in the neighbor table, typically by averaging LQI (Link Quality Indicator) measurements made by the physical layer. To handle link asymmetry, the Zigbee PRO stack profile specifies that routers obtain and store costs of outgoing links as measured by their neighbors. This is accomplished by exchanging link status information through periodic one hop broadcasts, referred to as “link status” messages. The link status algorithm is explained below, as implemented in EmberZNet PRO.

• 本节中的信息是为那些希望了解网络层操作细节的人提供的，这在故障排除过程中非常有用。通常来说，链接状态消息应由堆栈自动处理，应用程序编写者无需关心它。
• 在无线网络中，由于噪声、接收器灵敏度和发射功率的变化，链路质量往往是不对称（A的信号B能接收到，B的信号A接收不到）。路由层必须利用双向链路质量来建立工作路由，并优化这些路由的可靠性和效率。并通过一次发现建立可靠的双向路由。
• Zigbee路由器通常通过平均物理层进行的LQI（链路质量指示器）测量来跟踪邻居表中的入站链路质量。为了处理链路不对称，Zigbee PRO堆栈配置文件指定路由器获取并存储由其邻居测量的传出链路的成本。这是通过周期性的一跳广播交换链路状态信息来实现的，称为“链路状态”消息。下面解释链路状态算法，如EmberZNet PRO中所实现的。

1.2.1 Description of Relevant Neighbor Table Fields

  Zigbee routers store information about neighboring Zigbee devices in a neighbor table. For each router neighbor, the entry includes the following fields:

• average incoming LQI
• outgoing cost
• age

  The incoming LQI field is an exponentially weighted moving average of the LQI for all incoming packets from the neighbor. The incoming cost for the neighbor is computed from this value using a lookup table.
  The outgoing cost is the incoming cost reported by the neighbor in its neighbor exchange messages. An outgoing cost of 0 means the cost is unknown. An entry is called “two-way” if it has a nonzero outgoing cost, and “one-way” otherwise.
  The age field measures the amount of time since the last neighbor exchange message was received. A new entry starts at age 0. The age is incremented every EM_NEIGHBOR_AGING_PERIOD, currently 16 seconds. Receiving a neighbor exchange packet resets the age to EM_MIN_NEIGHBOR_AGE, as long as the age is already at least EM_MIN_NEIGHBOR_AGE (currently defined to be 3). This makes it possible to recognize nodes that have been recently added to the table and avoid evicting them, which reduces thrashing in a dense network. If the age is greater than EM_STALE_NEIGHBOR (currently 6), the entry is considered stale and the outgoing cost is reset to 0.

• Zigbee路由器在邻居表中存储有关邻近Zigbee设备的信息。对于每个路由器邻居，该条目包括以下字段：
  • 数据接收的平均链路质量
    • 传入的LQI字段是来自邻居的所有传入分组的LQI的指数加权移动平均值。 使用查找表从该值计算邻居的传入成本。
  • 数据发送所需要的能量
    • 传出成本是邻居与邻居之间交换消息中报告的传入成本。输出成本为0表示成本未知。如果一个条目的输出成本不为零，则称为“双向”，否则称为“单向”。
  • 邻居表的有效时间
    • age字段测量自上次邻居交换消息收到以来的时间量。 新条目从0岁开始。年龄增加EM_NEIGHBOR_AGING_PERIOD，目前为16秒。 只要年龄已经至少为EM_MIN_NEIGHBOR_AGE（当前定义为3），接收邻居交换数据包会将年龄重置为EM_MIN_NEIGHBOR_AGE。 这使得可以识别最近添加到表中的节点并避免驱逐它们，这减少了密集网络中的颠簸。 如果年龄大于EM_STALE_NEIGHBOR（当前为6），则该条目被视为陈旧，并且传出成本将重置为0。（ps：age字段会通过接收到新的link status来将age重新置0，如果太久没收到邻居发来的link status 时，就默认为老旧的邻居，再发现新邻居的时候，就会将旧邻居剔出。）

1.2.2 信号链路质量帧（Link Status）

  Routers send link status messages every 16 seconds plus or minus 2 seconds of jitter. If the router has no two-way links it sends them eight times faster. The packet is sent as a one-hop broadcast with no retries. In the EmberZNet PRO stack, they are sent as Zigbee network command frames.
  The payload contains a list of short IDs of all non-stale neighbors, along with their incoming and outgoing costs. The incoming cost is always a value between 1 and 7. The outgoing cost is a value between 0 and 7, with the value 0 indicating an unknown outgoing cost. For frame format details, refer to the Zigbee specification. Link status messages are also automatically decoded by the Simplicity Studio Network Analyzer for easy reference.
  Upon receipt of a link status message, either a neighbor entry already exists for that neighbor, or one is added if there is space or if the neighbor selection policy decides to replace an old entry with it. If the entry does not get into the table, the packet is simply dropped. If it does get in, then the outgoing cost field is updated with the incoming cost to the receiving node as listed in the sender’s neighbor exchange message. If the receiver is not listed in the message, the outgoing cost field is set to 0. The age field is set to EM_MIN_NEIGHBOR_AGE.

• 路由器每16秒（±2s）发送链路状态消息。如果路由器没有双向链路，它将发送速度提高八倍。数据包作为单跳广播发送，不重试。在EmberZNet PRO堆栈中，它们作为Zigbee网络命令帧发送。
• 有效负载（payload）包含所有非陈旧邻居的短ID列表，以及它们的传入和传出成本。传入成本始终为1到7之间的值。传出成本是0到7之间的值，值0表示未知的传出成本。有关帧格式的详细信息，请参阅Zigbee规范。链接状态消息也由Simplicity Studio网络分析仪自动解码，以便于参考。
• 在接收到链路状态消息时，该邻居已经存在邻居条目，或者如果存在空间或者邻居选择策略决定用它替换旧条目，则添加一个邻居条目。如果条目没有进入表中，则只丢弃数据包。如果确实进入，则输出成本字段将根据发送方的邻居交换消息中列出的接收节点的传入成本进行更新。如果消息中未列出接收方，则输出成本字段将设置为0.年龄字段设置为EM_MIN_NEIGHBOR_AGE。

1.2.3 网络层如何使用双向成本

  As mentioned above, the routing algorithm makes use of the bidirectional cost information to avoid creating broken routes, and to optimize the efficiency and robustness of established routes. For the reader familiar with the Zigbee route discovery process, this subsection gives details of how the outgoing cost is used. The mechanism is surprisingly simple, but provides all the benefits mentioned above.
  Upon receipt of a route request command frame, the neighbor table is searched for an entry corresponding to the transmitting device. If no such entry is found, or if the outgoing cost field of the entry has a value of 0, the frame is discarded and route request processing is terminated.
  If an entry is found with non-zero outgoing cost, the maximum of the incoming and outgoing costs is used for the purposes of the path cost calculation, instead of only the incoming cost. This value is also used to increment the path cost field of the route request frame prior to retransmission.

• 如上所述，路由算法利用双向成本信息来避免创建中断路由，并优化已建立路由的效率和稳健性。 对于熟悉Zigbee路由发现过程的读者，本小节详细介绍了如何使用传出成本。
• 在接收到路由请求命令帧时，在邻居表中搜索对应于发送设备的条目。 如果没有找到这样的条目，或者条目的输出成本字段具有值0，则丢弃该帧并终止路由请求处理。
• 如果找到具有非零传出成本的条目，则传入和传出成本的最大值用于路径成本计算，而不是仅用于传入成本。 该值还用于在重传之前递增路由请求帧的路径成本字段。

1.2.4 Key Concept: Rapid Response

  Rapid response allows a node that has been powered on or reset to rapidly acquire two-way links with its neighbors, minimizing the amount of time the application must wait for the stack to be ready to participate in routing. This feature is 100% Zigbee-compatible.
  If a link status message is received that contains no two-way links, and the receiver has added the sender to its neighbor table, then the receiver sends its own link status message immediately in order to get the sender started quickly. The message is still jittered by 2 seconds to avoid collisions with other rapid responders. To avoid a chain reaction, rapid responders must themselves have at least one two-way link.

• 快速响应允许已启动或重置的节点快速获取与其邻居的双向链路，从而最大限度地缩短应用程序必须等待堆栈准备好参与路由的时间。
• 如果收到的链路状态消息不包含双向链路，并且接收方已将发送方添加到其邻居表，则接收方立即发送其自己的链路状态消息，以便快速启动发送方。 该消息仍然被抖动2秒，以避免与其他快速响应者发生冲突。 为了避免连锁反应，快速反应者必须自己至少有一个双向联系。

1.2.5 Key Concept: Connectivity Management

  By nature Zigbee devices are RAM-constrained, but often Zigbee networks are dense. This means that each router is within radio range of a large number of other routers. In such cases, the number of neighbors can exceed the maximum number of entries in a device’s neighbor table. In such cases, the wrong choice of which neighbors to keep can lead to routing inefficiencies or worse — a disconnected network. The EmberZNet PRO stack employs 100% Zigbee-compatible algorithms to manage the selection of neighbors in dense networks to optimize network connectivity.

• 本质上Zigbee设备受RAM限制，但Zigbee网络通常很密集。 这意味着每个路由器都在大量其他路由器的无线电范围内。 在这种情况下，邻居的数量可以超过设备邻居表中的最大条目数。 在这种情况下，错误选择保留哪些邻居会导致路由效率低下或更糟 - 网络断开。 EmberZNet PRO堆栈采用100％Zigbee兼容算法来管理密集网络中邻居的选择，以优化网络连接。

1.3 Route Discovery & Repair

  Routing in Zigbee is automatically handled by the networking layer, and the application developer usually does not need to be concerned with its behavior. However, it is useful to have a feel for how the network behaves when a route needs to be discovered or repaired.

• Zigbee中的路由由网络层自动处理，应用程序开发人员通常不需要关心其行为。 但是，了解在需要发现或修复路径时网络的行为方式很有用。

1.3.1 Route Discovery

  Route discovery is initiated when a unicast message is sent from one device to another and there is no pre-existing route.
  We assume that there is no existing route so the networking software will begin the process of route discovery. For simplicity, assume that the routing tables of all devices are blank.

• 当单播消息从一个设备发送到另一个设备并且没有预先存在的路由时，将启动路由发现。
• 我们假设没有现有路由，因此网络软件将开始路由发现过程。 为简单起见，假设所有设备的路由表都是空白的。

  For example, assume that device A needs to send a message to device C, as shown in the following figure. Device A will broadcast a message to the entire network asking the device C to reply. This broadcast message also serves to establish a temporary route back to A, as each intermediate device records the device from which it received the message. Routes are updated on intermediate nodes — note that these are temporary entries that have a shorter lifetime than regular entries and are not intended for re-use. Because A is a one-hop neighbor, B and D do not need to store routing information about it.

• 例如，假设设备A需要向设备C发送消息，如下图所示。 设备A将向整个网络广播消息，要求设备C回复。 该广播消息还用于建立返回A的临时路由，因为每个中间设备记录从其接收消息的设备。 路由在中间节点上更新 - 请注意，这些是临时条目，其生命周期比常规条目短，并且不打算重复使用。 因为A是一跳邻居，所以B和D不需要存储关于它的路由信息。

  C could use either B or D as its next hop back to A. Zigbee leaves this choice to the implementation; Silicon Labs uses a weighting algorithm to choose the most apparently reliable next hop.
  When the message reaches device C, C sends a special unicast message (called a Route Response message) back to A using the temporary route constructed in step 1, as shown in the following figure. This message is used by intermediate devices to establish a (permanent) route back to C.

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

  Because C is a one-hop neighbor, B does not need to store routing information about it. D is not involved in this part of the discovery process because it was not selected by A in the above step. When the message reaches device A, the route discovery is complete and the new route can be used to send data messages from A to C.
  Zigbee PRO networks will detect asymmetric RF links and avoid them during route discovery. This improves the reliability of the discovery process and the resulting routes.

• 由于C是单跳邻居，因此B不需要存储有关它的路由信息。 D不参与发现过程的这一部分，因为在上述步骤中A没有选择它。 当消息到达设备A时，路由发现完成，新路由可用于从A到C发送数据消息。
• Zigbee PRO网络将检测非对称RF链路并在路由发现期间避免它们。 这提高了发现过程和结果路由的可靠性。

  Routes that have not been used within a certain timeout period (1 minute in EmberZNet 3.0 and later) are marked for re-use and new routes may then overwrite that memory location. In some cases a new route may be needed and one or more intermediate devices will not have an available routing table entry; in this case the message will be reported as undeliverable to the sending node.
  The application specifies if an end-to-end acknowledgment should be sent by the receiver (this is called an APS acknowledgment). If yes, the sender will be notified upon successful delivery of in the case of a timeout waiting for acknowledgment. In the case of a timeout, the route may need to be repaired.

• 在特定超时期限内（EmberZNet 3.0及更高版本中为1分钟）未使用的路由标记为可重复使用，然后新路由可能会覆盖该内存位置。 在某些情况下，可能需要新的路由，并且一个或多个中间设备将不具有可用的路由表条目; 在这种情况下，消息将被报告为无法传送到发送节点。
• 应用程序指定接收方是否应发送端到端确认（这称为APS确认）。 如果是，则在超时等待确认的情况下成功交付时将通知发送方。 在超时的情况下，可能需要修复路由。

1.3.2 Route Repair

  When a unicast message is sent with an acknowledgment requested, the sending device will be informed when the message is successfully delivered. If does not receive this acknowledgment, it can then take steps to repair the route. Route repair follows exactly the same steps as route discovery, above, but the damaged node (B, in the following figure) does not participate, resulting in a different route choice.

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

  The routing table for A is updated to reflect that the next hop is D and the message is successfully delivered along the new path, as shown in the following figure.

• 更新A的路由表以反映下一跳是D并且消息沿新路径成功传递，如下图所示。

  If no alternative path is available, the sender is informed that the message could not be delivered. In EmberZNet PRO this is denoted by a response with EmberStatus of EMBER_DELIVERY_FAILED (0x66).
  EmberZNet PRO will attempt to deliver a message again before performing the route repair. Route repair is performed automatically when EMBER_APS_OPTION_RETRY and EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY are both set in the message options.

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

1.4 重发和应答

  Zigbee and its underlying network layers provide a system of retries and acknowledgments that are designed to efficiently manage the uncertainty of RF communication. It is not necessary to understand this concept in order to start using Zigbee but it may be of interest to some application developers in specific situation.
  This section discusses retries and acknowledgments layer-by-layer:

• MAC retries and ACKs (802.15.4)
• NWK retries (Zigbee NWK layer)
• APS retries and ACKs (Zigbee APS layer)

• Zigbee及其底层网络层提供了重试和确认系统，旨在有效地管理RF通信的不确定性。 为了开始使用Zigbee，没有必要理解这个概念，但在特定情况下，某些应用程序开发人员可能会对此感兴趣。
  • MAC重试和ACK（802.15.4）
  • NWK重试（Zigbee NWK层）
  • APS重试和确认（Zigbee APS层）

1.4.1 MAC重试和ACK

The following figure illustrates the MAC layer transmission retry process.

  The MAC layer attempts transmission five times.

• Unicast retries will occur if the channel was not clear (CCA fail) or if the MAC level ACK was not received from the next hop destination.
• Broadcast retries will occur in the case of CCA failure but broadcast does not use the MAC ACK capability.

  These retries occur very quickly — maximum retry time for complete failure is approximately 37 ms. Note that the MAC ACK is sent back immediately from the sender without additional CCA — see 802.15.4 documentation for more information.

• MAC层尝试传输五次。
  • 如果信道未清除（CCA失败）或未从下一跳目的地接收到MAC级别ACK，则将发生单播重试。
  • 在CCA故障的情况下将发生广播重试，但是广播不使用MAC ACK能力。
• 这些重试非常快速 - 完全失败的最大重试时间约为37 ms。 请注意，MAC ACK会立即从发送方发回，而无需额外的CCA - 有关详细信息，请参阅802.15.4文档。

1.4.2 NWK重试

  NWK retries in Zigbee are vendor specific. The following figure illustrates the EmberZNet PRO stack’s NWK layer transmission retry process.

• NWK在Zigbee的重试对于每个供应商的有所不同。 下图说明了EmberZNet PRO堆栈的NWK层传输重试过程。

  The NWK retries occur only if the MAC layer indicates a transmission failure. They operate on a longer time scale than MAC retries and therefore give the network additional robustness in the presence of medium term (1-500 ms) interference.
  Silicon Labs’ interference research shows that the NWK layer retries are important for overcoming temporary interference from WiFi in certain situations.
  Unicast: unicast behavior is as described in the flow chart, with retries for up to 500 ms.

• Broadcast: broadcast messages are re-sent every 500 ms up to a total of 3 times (including the initial broadcast) or until all neighbors are heard to rebroadcast the message themselves (thereby ensuring complete delivery)

• 只有当MAC层指示传输失败时，才会发生NWK重试。 它们在比MAC重试更长的时间范围内运行，因此在存在中期（1-500 ms）干扰的情况下为网络提供额外的稳健性。
• Silicon Labs的干扰研究表明，在某些情况下，NWK层重试对于克服来自WiFi的临时干扰非常重要。
  • 单播：单播行为如流程图所述，重试时间最长为500毫秒。
  • 广播：广播消息每500毫秒重新发送一次，共计3次（包括初始广播）或直到听到所有邻居自己重播消息（从而确保完整传送）

1.4.3 APS重试和确认

下图说明了APS层重试过程。

  The APS layer has an ACK flag that controls whether it uses the additional logic to wait for an acknowledgment and retry if the acknowledgment is not heard. This represents a full end-to-end acknowledgment from the recipient device.
  The APS layer can be further optionally configured to repair the route to the destination in the case that the APS sending fails.
  There is no equivalent of the APS end-to-end acknowledgment for broadcast messages.

• APS层有一个ACK标志，用于控制是否使用附加逻辑等待确认，如果未听到确认则重试。 这表示来自接收方设备的完整端到端确认。
• APS层可以进一步可选地配置为在APS发送失败的情况下修复到目的地的路由。
• 对广播消息不需要APS端到端确认。

1.4.4 结论

  If it is possible to send a message to the destination, the automatic Zigbee behavior provides “maximum effort”, by attempting retries over several different time scales, from 1 ms to several seconds with optional end-to-end ACK and route repair.
  If the delivery fails, the application is recommended to wait a more significant amount of time before retrying — this gives the interference or failure time to clear up. In cases of extreme bandwidth congestion the application retries may actually contribute to the problem.

• 如果可以向目的地发送消息，则自动Zigbee行为通过尝试在几个不同的时间尺度上重试，从1毫秒到几秒，通过可选的端到端ACK和路由修复，提供“最大努力”。
• 如果传递失败，建议应用程序在重试之前等待更长的时间 - 这会给干扰或故障时间清除。 在极端带宽拥塞的情况下，应用程序重试实际上可能导致问题。

2、Zigbee协议栈

  Zigbee provides several separate stacks. This has been a point of confusion so the summary is as follows:

• Zigbee 2004 – was released in 2004 and supported a home control lighting profile. This stack was never extensively deployed with customers and is no longer supported.
• Zigbee 2006 – was released in 2006 and supports a single stack known as the Zigbee stack (explained below)
• Zigbee 2007 – was released in Q4 2007. It has two feature sets, Zigbee and Zigbee PRO.

The Zigbee and Zigbee PRO stacks are complete implementations of the MAC, networking layer, security services and the application framework. Devices implementing Zigbee and Zigbee PRO can interoperate by acting as end devices in the other type of network. For example, if a network is formed around a Zigbee PRO coordinator it can have Zigbee PRO routers only, but both Zigbee and Zigbee PRO end devices.
  Note: The Zigbee 2004 stack is not interoperable with Zigbee 2007.

• Zigbee提供了几个独立的堆栈。 这一点令人困惑，所以摘要如下：
  • Zigbee 2004 - 于2004年发布，支持家庭控制照明配置文件。 此堆栈从未与客户广泛部署，不再受支持。
  • Zigbee 2006 - 于2006年发布，支持称为Zigbee堆栈的单个堆栈（如下所述）
  • Zigbee 2007 - 于2007年第四季度发布。它有两个功能集，Zigbee和Zigbee PRO。
• Zigbee和Zigbee PRO堆栈是MAC，网络层，安全服务和应用程序框架的完整实现。 实现Zigbee和Zigbee PRO的设备可以作为其他类型网络中的终端设备进行互操作。 例如，如果在Zigbee PRO协调器周围形成网络，它只能有Zigbee PRO路由器，但Zigbee和Zigbee PRO终端设备都可以。
  注意：Zigbee 2004堆栈不能与Zigbee 2007互操作。

  The Zigbee stack is formed around a central coordinator and uses tree addressing to establish the network.
  The Zigbee PRO stack is formed around a central coordinator but uses a stochastic addressing scheme to avoid limitations with the tree. Table routing is always used and additional features are available such as:

• Network level multicasts
• Many-to-one and source routing
• Frequency agility
• Asymmetric link handling
• PAN ID Conflict
• Fragmentation
• Standard or high security.

Silicon Labs does not recommend deploying systems on the Zigbee stack because the Zigbee PRO stack has a number of features that are necessary for long term network stability and reliability. The Zigbee stack is typically used for small static networks.
  Note: The Zigbee 2007 specification includes updates to the Zigbee stack to allow the use of frequency agility and fragmentation on this stack. This stack remains interoperable with the Zigbee 2006 stack and therefore use of these features must be limited to those networks which can handle the complexity of some devices having these capabilities and some devices not.

• Zigbee堆栈围绕中央协调器形成，并使用树寻址来建立网络。
• Zigbee PRO堆栈围绕中央协调器形成，但使用随机寻址方案来避免对树的限制。始终使用表路由，并提供其他功能，例如：
  • 网络级多播
  • 多对一和源路由
  • 频率捷变
  • 不对称链接处理
  • PAN ID冲突
  • 碎片
  • 标准或高安全性。
• Silicon Labs不建议在Zigbee堆栈上部署系统，因为Zigbee PRO堆栈具有许多长期网络稳定性和可靠性所必需的功能。 Zigbee堆栈通常用于小型静态网络。
• 注意：Zigbee 2007规范包括对Zigbee堆栈的更新，以允许在此堆栈上使用频率捷变和分段。该堆栈仍然可以与Zigbee 2006堆栈互操作，因此这些功能的使用必须限于那些可以处理具有这些功能的某些设备的复杂性而某些设备没有的复杂性的网络。

2.1 Zigbee设备对象(ZDO)

  The ZDO (occupying Endpoint 0 of each node) is a stack-level entity defined by the Zigbee Networking Specification for use in network management and information gathering. This section explains how to make use of ZDO functionality in the EmberZNet PRO stack and/or EZSP. An example is described as well.
  The ZDO, an entity in the stack, provides network management capabilities that nodes can use to learn about each other, about the network in general, or for managing certain stack-level functionality. Many features of the ZDO must be implemented as part of a Zigbee Certified Platform (ZCP) and are therefore available on all Zigbee/Zigbee PRO devices, making them useful as an interoperable way to gather and manage system properties on a Zigbee network. The ZDO is implemented through an OTA messaging format known as the Zigbee Device Profile.

• ZDO（占用每个节点的端点0）是由Zigbee网络规范定义的用于网络管理和信息收集的堆栈级实体。 本节介绍如何在EmberZNet PRO堆栈和/或EZSP中使用ZDO功能。 还描述了一个例子。
• ZDO是堆栈中的一个实体，它提供网络管理功能，节点可以使用这些功能来了解彼此，了解一般网络或管理某些堆栈级功能。 ZDO的许多功能必须作为Zigbee认证平台（ZCP）的一部分实现，因此可在所有Zigbee / Zigbee PRO设备上使用，这使它们可用作在Zigbee网络上收集和管理系统属性的可互操作方式。 ZDO通过称为Zigbee设备配置文件的OTA消息传递格式实现。

  The following basic guidelines apply to using the ZDO for network management:

• Broadcasts requests must go to broadcast mask 0xFFFD.
• Requests should always be sent to destination endpoint 0, with application profile ID 0x0000, as this indicates that the ZDO (intrinsic in the stack) should handle the message. The source endpoint generally corresponds to the portion of your application that is interested in the requested information.
• Responses to ZDO requests come from source endpoint 0, to the destination endpoint corresponding to the source used for the Request.
• If a particular ZDO request handler is not implemented in the stack, a status of EMBER_ZDP_NOT_SUPPORTED (0x84) will be returned in the response.
• Cluster ID is used to indicate the Request or Response type being sent.
• Most requests can be sent as unicast, broadcast or multicast, just like any other APS frame (with optional APS acknowledgment), and responses arrive in the IncomingMessageHandler like any other incoming APS message. However, certain kinds of requests, if sent as broadcasts, will not generate a response (in the interest of network bandwidth conservation). There are also certain requests
  that cannot be sent broadcast. For more information on these specific commands, please refer to the Zigbee core specification (document 14-0392).
• stack/include/zigbee-device-stack.h details the frame formats for commands and responses, including which request types are supported by the EmberZNet PRO stack. Further details about the frame formats are described in the Zigbee Device Profile (ZDP) section of the Zigbee Networking Specification (Zigbee document 14-0392).
• Utility functions (provided as source code) for generating ZDO requests and parsing certain kinds of responses can be found in app/util/zigbee-framework/zigbee-device-library.h. (There is also an alternative version of this file for EZSP host applications.)
• All ZDO requests and responses begin with the transaction sequence number as the first byte of the payload. This allows a request to be matched up with a particular response.

• 以下基本准则适用于使用ZDO进行网络管理：
  • 广播请求必须转到广播掩码0xFFFD。
  • 应始终将请求发送到目标端点0，应用程序配置文件ID为0x0000，因为这表示ZDO（堆栈中的内部）应处理该消息。源端点通常对应于您对所请求信息感兴趣的应用程序部分。
  • 对ZDO请求的响应来自源端点0，到对应于用于请求的源的目标端点。
    如果堆栈中未实现特定的ZDO请求处理程序，则将在响应中返回状态EMBER_ZDP_NOT_SUPPORTED（0x84）。
  • 群集ID用于指示正​​在发送的请求或响应类型。大多数请求可以作为单播，广播或多播发送，就像任何其他APS帧一样（具有可选的APS确认），并且响应像任何其他传入的APS消息一样到达IncomingMessageHandler。但是，某些类型的请求，如果作为广播发送，将不会产生响应（为了保护网络带宽）。还有一些要求无法发送广播。有关这些特定命令的更多信息，请参阅Zigbee核心规范（文档14-0392）。
  • stack / include / zigbee-device-stack.h详细说明命令和响应的帧格式，包括EmberZNet PRO堆栈支持的请求类型。关于帧格式的进一步细节在Zigbee网络规范（Zigbee文档14-0392）的Zigbee设备配置文件（ZDP）部分中描述。
  • 可以在app/util/zigbee-framework/zigbee-device-library.h中找到用于生成ZDO请求和解析某些类型响应的实用程序函数（作为源代码提供）。 （EZSP主机应用程序还有此文件的替代版本。）
  • 所有ZDO请求和响应都以事务序列号作为有效负载的第一个字节开始。这允许请求与特定响应匹配。

  As an example, take the case of a Permit Joining ZDO transaction, which facilitates remote control of the PermitAssociation flag for one or more devices in the network.
  For this particular transaction, zigbee-device-stack.h explains the following:

• 例如，采用Permit Joining ZDO事务的情况，这有助于远程控制网络中一个或多个设备的PermitAssociation标志。
• 对于此特定事务，zigbee-device-stack.h解释了以下内容：

1. // Request: [duration:1] [permit:1]
2. // Response: [status:1]
3. #define PERMIT_JOINING_REQUEST 0x0036
4. #define PERMIT_JOINING_RESPONSE 0x8036

  So a Permit Joining request frame would use cluster ID 0x0036, and the response would arrive with cluster ID 0x8036. For the request parameters, the “duration” byte corresponds to the argument you would ordinarily provide to the PermitJoining call in EmberZNet PRO/ EZSP (a number of seconds to allow joining, or 0x00 for always-off joinin , or 0xFF for always-on joining). The “permit authentication” byte used to only be applicable when the recipient of the request was the Trust Center (TC) and controlled whether the TC should perform authentication on “certain devices” during future association requests.
  However, the current Zigbee Networking Specification mandates that the permit authentication byte be 0x01, so this argument in the Permit Joining Request is no longer significant.
  Permit Join Requests are typically sent as a broadcast to all routers, allowing devices to join at any router in the network after this broadcast request has been processed.

• 因此，Permit Joining请求帧将使用Cluster ID 0x0036，响应将以Cluster ID 0x8036到达。 对于请求参数，“duration”字节对应于您通常在EmberZNet PRO / EZSP中为PermitJoining调用提供的参数（允许加入的秒数，或者对于always-off joinin为0x00，对于always-on为0xFF）。 “permit authentication”字节仅用于请求的接收者是信任中心（TC）并且控制TC是否应该在将来的关联请求期间对“某些设备”执行认证时才适用。
• 但是，当前的Zigbee网络规范要求允许认证字节为0x01，因此许可连接请求中的此参数不再重要。
• 允许加入请求通常作为广播发送到所有路由器，允许设备在处理完广播请求后加入网络中的任何路由器。

2.1.1 ZDO高级用法

  Additionally, as of EmberZNet release 3.3.2, Silicon Labs has added the ability for the application (host MCU) to be informed about ZDO requests that the stack is handling, and/or informed about those that the stack does not handle (so that it can handle them itself),and also to give the host a chance to handle endpoint requests (instead of handling these automatically) if desired. Please see comments in the hal/ember-configuration.c file (in SoC platforms) or app/util/ezsp/ezsp-enum.h (for NCP platforms) in EmberZNet releases 3.3.2 and later for descriptions of these available options, which are described as EzspConfigId values 0x26-0x28 (in EZSP) or the following configuration defines (in SoC API):

• 此外，从EmberZNet版本3.3.2开始，Silicon Labs增加了应用程序（主机MCU）的能力，以便了解堆栈正在处理的ZDO请求，和/或告知堆栈无法处理的那些（以便 它可以自己处理它们，并且如果需要，还可以让主机有机会处理端点请求（而不是自动处理这些请求）。 请参阅EmberZNet版本3.3.2及更高版本中hal/ember-configuration.c文件（在SoC平台中）或 app/util/ezsp/ezsp-enum.h（对于NCP平台）中的注释，以获取这些可用选项的描述， 它们被描述为EzspConfigId值0x26-0x28（在EZSP中）或以下配置定义（在SoC API中）：

  EMBER_APPLICATION_RECEIVES_SUPPORTED_ZDO_REQUESTS
EMBER_APPLICATION_HANDLES_UNSUPPORTED_ZDO_REQUESTS
EMBER_APPLICATION_HANDLES_ENDPOINT_ZDO_REQUESTS
EMBER_APPLICATION_HANDLES_BINDING_ZDO_REQUESTS

2.2 Zigbee Profiles

  Before Zigbee 3.0, application profiles, or simply profiles, sat on top of the basic Zigbee stack. These were developed to specify the OTA messages required for device interoperability. A given application profile could be certified on either the Zigbee or Zigbee PRO stack. Now, Zigbee 3.0 has introduced an all-encompassing application layer specification for defining OTA behavior for all Zigbee applications.
  The following are the application profile groups that existed before Zigbee 3.0:

• Home Automation (HA) – Devices for typical residential and small commercial installations.
• Smart Energy (SE) – For utility meter reading and interaction with household devices.
• Commercial Building Automation (CBA) – Devices for large commercial buildings and networks.
• Telecom Application (TA) – Wireless applications within the telecom area.
• Health Care (HC) – Monitoring of personal health in the home or hospital environment.
• Retail – Monitoring and information delivery in a retail environment.
• Zigbee Light Link – Wireless control of LED lighting systems.

• 在Zigbee 3.0之前，应用程序配置文件或简单的配置文件位于基本的Zigbee堆栈之上。这些是为了指定设备互操作性所需的OTA消息而开发的。给定的应用程序配置文件可以在Zigbee或Zigbee PRO堆栈上进行认证。现在，Zigbee 3.0引入了一个包罗万象的应用层规范，用于为所有Zigbee应用程序定义OTA行为。
• 以下是Zigbee 3.0之前存在的应用程序配置文件组：
  • 家庭自动化（HA） - 典型住宅和小型商业设施的设备。
  • 智能能源（SE） - 用于公用仪表读数和与家用设备的交互。
  • 商业楼宇自动化（CBA） - 大型商业建筑和网络设备。
  • 电信应用（TA） - 电信领域内的无线应用。
  • 医疗保健（HC） - 监控家庭或医院环境中的个人健康。
  • 零售 - 零售环境中的监控和信息交付。
  • Zigbee Light Link - LED照明系统的无线控制。

  The Zigbee Cluster Library (ZCL) forms a generic basis for the Zigbee common application layer. This library defines common elements that are shared such as data types and allows reuse of simple devices such as on/off switch protocols between different profiles.
  Application profiles defined the roles and functions of devices in a Zigbee network. Two types of application profiles were administered by the Alliance:

• Public Application Profiles, developed by members of the Zigbee Alliance so that devices from different manufacturers can interoperate.
• Manufacturer-Specific Application Profiles, developed by product developers creating private networks for their own applications where interoperability is not required.

The Zigbee Alliance now recognizes one application layer, described by the Zigbee Base Device Behavior specification, which defines roles and functions of a device in any Zigbee network. These application behaviors interoperate with any other application.
  If you develop a product based upon your own private application layer specification, the Zigbee Alliance requires you to make use of a unique private profile identifier to ensure the product can successfully co-exist with other products. The Zigbee Alliance issues these unique private profile IDs to member companies upon request and at no charge.
  An application can also be developed using the common Zigbee 3.0 application layer with private extensions for specific features from a manufacturer.

• Zigbee集群库（ZCL）构成了Zigbee通用应用程序层的通用基础。该库定义了共享的公共元素，例如数据类型，并允许重用简单设备，例如不同配置文件之间的开/关切换协议。
• 应用程序配置文件定义了Zigbee网络中设备的角色和功能。联盟管理两种类型的应用程序配置文件：
  • 公共应用程序配置文件，由Zigbee联盟成员开发，以便来自不同制造商的设备可以互操作。
  • 特定于制造商的应用程序配置文件，由产品开发人员开发，为不需要互操作性的应用程序创建专用网络。
• Zigbee联盟现在识别一个应用层，由Zigbee基本设备行为规范描述，该规范定义了设备在任何Zigbee网络中的角色和功能。这些应用程序行为可与任何其他应用程序互操
• 如果您根据自己的私有应用层规范开发产品，Zigbee联盟要求您使用唯一的私有配置文件标识符，以确保产品可以与其他产品成功共存。 Zigbee Alliance可根据要求向会员公司免费发放这些独特的私人档案ID。
• 还可以使用常见的Zigbee 3.0应用程序层开发应用程序，该应用程序层具有来自制造商的特定功能的私有扩展。

2.3 Zigbee寻址方案

  The Zigbee PRO stack uses a stochastic address assignment mechanism. Under this mechanism the coordinator is still used to start the network. Each device (routers and end devices) that joins the network is given a randomly assigned address from the device it is joining. The device conducts conflict detection on this address using network level messages to ensure the address is unique. This address is then retained by a device, even if the parent address changes. A best practice is to let the stack assign the addresses.
  Under Zigbee PRO, provisions are intended for a commissioning tool for setup and configuration of networks. This commissioning tool can be used to assign addresses manually. Silicon Labs does not provide a commissioning tool. If you are interested in such a tool, refer to the ZCL Commissioning cluster for information.

• Zigbee PRO堆栈使用随机地址分配机制。 在这种机制下，协调器仍然用于启动网络。 连接网络的每个设备（路由器和终端设备）都会从其加入的设备中获得一个随机分配的地址。 设备使用网络级消息对此地址进行冲突检测，以确保地址是唯一的。 即使父地址发生更改，设备也会保留此地址。 最佳做法是让协议栈分配地址。
• 在Zigbee PRO下，规定用于设置和配置网络的调试工具。 该调试工具可用于手动分配地址。 Silicon Labs不提供调试工具。 如果您对此类工具感兴趣，请参阅ZCL调试群集以获取信息。

2.4 Extended PAN IDs

  Developers who have used stack software earlier than Zigbee 2007 should note a new and important change to PAN IDs. Zigbee has added an 8 byte extended PAN ID (EPID or XPID) to facilitate provisioning and PAN ID conflict detection. The extended PAN ID is now included in the beacon payload, following the existing 3 bytes.
  The Extended PAN ID was a network parameter in Zigbee 2007 (EmberZNet 3.x and later) was used in the Zigbee and Zigbee PRO feature sets. This extended PAN ID [EPID] can be thought of as an extension of the basic, 16-bit PAN ID [PID]. The EPID is a 64-bit value set for the entire network by the Zigbee Coordinator [ZC] at the time the personal area network [PAN] is formed and must not change while the PAN is operating (unlike the PID). Like the PID, all nodes within the same PAN share an EPID.
  Other than the scanning and joining processes, the EPID rarely appears in transmitted Zigbee packets due to its large overhead (8 bytes) in the header. However, the EPID is used during a Network Update transaction, where a Network Manager node informs the other devices in the PAN about a PID conflict or channel change, so that nodes moving to a new channel and/or PID can rely on the consistency of the EPID as a criteria for finding the moved network.
  Note that the Extended PAN ID (even if it’s zero) is saved to the non-volatile memory (as part of the tokens) once the node associates into the network, so it won’t change over the lifetime of the device until the device leaves the network.

• 早于Zigbee 2007使用堆栈软件的开发人员应该注意对PAN ID的一个新的重要更改。 Zigbee添加了一个8字节的扩展PAN ID（EPID或XPID），以便于配置和PAN ID冲突检测。扩展的PAN ID现在包含在信标有效载荷中，跟随现有的3个字节。
• 扩展PAN ID是Zigbee 2007中的网络参数（EmberZNet 3.x及更高版本）用于Zigbee和Zigbee PRO功能集。该扩展的PAN ID [EPID]可以被认为是基本的16位PAN ID [PID]的扩展。 EPID是在个人区域网络[PAN]形成时由Zigbee协调器[ZC]为整个网络设置的64位值，并且在PAN运行时不得更改（与PID不同）。与PID一样，同一PAN内的所有节点共享一个EPID。
• 除了扫描和连接过程之外，由于标头中的开销很大（8字节），EPID很少出现在传输的Zigbee数据包中。但是，在网络更新事务期间使用EPID，其中网络管理器节点通知PAN中的其他设备关于PID冲突或信道改变，以便移动到新信道和/或PID的节点可以依赖于EPID作为查找移动网络的标准。
• 请注意，一旦节点关联到网络中，扩展PAN ID（即使它为零）将保存到非易失性存储器（作为令牌的一部分），因此在设备的生命周期内它不会更改离开了网络。

2.4.1 Use in Scanning / Forming / Joining Process

  The EPID will appear (along with other information such as the PID) in the beacon results seen by an Active Scan, and when a join is initiated, if the EPID is non-zero in the join request, the EPID will take precedence as the primary criteria for matching up the joiner to the joinee (16-bit PAN ID is effectively ignored). However, it’s possible that some networks (particularly older ones) may not want (or be able) to deal with EPIDs, so the EPID would be zero in the network parameters from the beacon. If the requested EPID is all zeroes during the JoinNetwork operation, only the 16-bit PAN ID will be used to match to a network for the purposes of association.
  While Silicon Labs provides some sample utilities for scanning networks and parsing the results to make a determination about which one to join, this process will generally vary depending on the application design and the level of strictness desired in selecting a network. (For example, the joining device may simply want any available Zigbee PRO network; it may seek a closed network designed specifically for the application in use but may not care which closed network it chooses; or it may seek one specific closed network with specific properties, in the way that I want my laptop at home to join not just any home WiFi network, but my WiFi network in my home.)
  The following guidelines apply to EmberZNet in determining the expected behavior of a Form/Join action given a particular EPID:

• If an all-zero value is specified for extended PAN ID during FormNetwork, the stack will generate a random 64-bit value for this field.
• If an all-zero value is specified for extended PAN ID during JoinNetwork, the stack will use the 16-bit PAN ID specified in the JoinNetwork parameters as the primary criteria for selecting a network during the join process.
• If a non-zero value is specified for extended PAN ID during JoinNetwork, the stack will use the 64-bit extended PAN ID specified in the JoinNetwork parameters (even if 16-bit PAN ID is different) as the primary criteria for selecting a network during the join process.

• EPID将在主动扫描看到的信标结果中出现（连同其他信息，如PID），并且当启动加入时，如果加入请求中的EPID不为零，则EPID将优先为将joiner与joinee匹配的主要标准（16位PAN ID实际上被忽略）。然而，某些网络（特别是较旧的网络）可能不希望（或能够）处理EPID，因此EPID在来自信标的网络参数中将为零。如果在JoinNetwork操作期间请求的EPID全为零，则只有16位PAN ID将用于匹配网络以进行关联。

• 虽然Silicon Labs为扫描网络提供了一些示例实用程序并解析结果以确定要加入哪一个，但此过程通常会根据应用程序设计和选择网络所需的严格程度而有所不同。 （例如，加入设备可能只是想要任何可用的Zigbee PRO网络;它可能寻求专门为使用中的应用而设计的封闭网络，但可能不关心它选择哪个封闭网络;或者它可能寻求具有特定属性的特定封闭网络，就像我希望家里的笔记本电脑不仅可以加入任何家庭WiFi网络，而是加入我家中的WiFi网络。）

• 以下指南适用于EmberZNet在确定给定特定EPID的表单/加入操作的预期行为时：

  • 如果在FormNetwork期间为扩展PAN ID指定了全零值，则堆栈将为此字段生成随机64位值。
  • 如果在JoinNetwork期间为扩展PAN ID指定了全零值，则堆栈将使用JoinNetwork参数中指定的16位PAN ID作为在连接过程中选择网络的主要标准。
  • 如果在JoinNetwork期间为扩展PAN ID指定了非零值，则堆栈将使用JoinNetwork参数中指定的64位扩展PAN -ID（即使16位PAN ID不同）作为选择网络的主要标准在加入过程中。

2.4.2 Choosing an EPID

  While the PAN ID is meant to be a randomly chosen, 16-bit value, unique to each network, the EPID is often used more like the SSID field of WiFi networks to give them a user-friendly designation (which is often not so random and is either set by the manufacturer or the installer). However, Silicon Labs discourages using a fixed EPID for all deployments because (unlike the conflicts of the PAN ID) EPID conflicts cannot be resolved if they occur at runtime (because no other unique information exists to distinguish the PANs). Customers wishing to use non-random EPIDs should, at minimum, scan the network (either at the coordinator or through some external commissioning tool) and check that the new PAN’s preferred EPID is not already in use by some other PAN. One approach is to use a small set of preferred EPIDs when forming PANs so that the coordinator can have alternatives if the first choice is in conflict.
  OEMs creating consumer-grade products requiring customer installation (rather than by trained installers) should take particular care to ensure variety of EPIDs, as two customers living next door to each other may purchase the same product for their homes and would prefer to isolate their networks from each other. If those two neighboring homes were to each use PANs with the same EPID, network difficulties would likely arise for both users because the both homes would be considered as one network, and many network address conflicts could occur.

• 虽然PAN ID是一个随机选择的16位值，对于每个网络都是唯一的，但EPID通常更像是WiFi网络的SSID字段，以便为用户提供友好的指定（通常不是那么随意）并由制造商或安装人员设定）。但是，Silicon Labs不鼓励对所有部署使用固定的EPID，因为（与PAN ID的冲突不同）EPID冲突如果在运行时发生则无法解决（因为不存在区分PAN的其他唯一信息）。希望使用非随机EPID的客户至少应该扫描网络（在协调器或通过一些外部调试工具），并检查新PAN的首选EPID是否已被其他PAN使用。一种方法是在形成PAN时使用一小组优选的EPID，以便如果第一选择发生冲突，协调器可以有替代方案。
• 创建需要客户安装的消费级产品的OEM（而不是经过培训的安装人员）应特别注意确保各种EPID，因为住在彼此隔壁的两个客户可能会为他们的家庭购买相同的产品，并且更愿意隔离他们的网络彼此。如果这两个相邻的家庭都使用具有相同EPID的PAN，则两个用户可能会出现网络困难，因为这两个家庭将被视为一个网络，并且可能发生许多网络地址冲突。

2.4.3 EPID与PID对比

  Here is a quick overview of differences between the Extended PAN ID and the standard PAN ID:

• EPID is 64 bits; PID is 16 bits.
• EPID is usually used as stack’s criteria for matching to the requested network; PID is only used for matching criteria when EPID is all 0x00 bytes.
• EPID is only present in a few kinds of packets (beacons, Network Update messages); PID is present in almost all 802.15.4 frames
  (except MAC ACKs).
• EPID is used as criteria for uniquely identifying the network and for resolving conflicts of PID; PID is used for MAC destination filtering at the radio receiver.
• EPID may help provide some indication of the network’s identity in the scan results; PID should always be completely random, so it is not as useful in determining which PAN is the “right one”.
• EPID can be any value in range of 0x0000000000000001 to 0xFFFFFFFFFFFFFFFE (all 0’s and all F’s are reserved values); PID can be any value in the range of 0x0000 - 0xFFFE (all F’s constitute reserved value).

• 以下是扩展PAN ID与标准PAN ID之间差异的快速概述：
  • EPID是64位; PID是16位。
  • EPID通常用作匹配所请求网络的堆栈标准; 当EPID全为0x00字节时，PID仅用于匹配条件。
  • EPID仅存在于几种数据包（信标，网络更新消息）中; PID几乎存在于所有802.15.4帧中
    （MAC ACK除外）。
  • EPID用作唯一识别网络和解决PID冲突的标准; PID用于无线电接收器处的MAC目的地过滤。
  • EPID可以帮助在扫描结果中提供网络身份的一些指示; PID应始终是完全随机的，因此在确定哪个PAN是“正确的”时不那么有用。
  • EPID可以是0x0000000000000001到0xFFFFFFFFFFFFFFFE范围内的任何值（所有0和所有F都是保留值）; PID可以是0x0000 - 0xFFFE范围内的任何值（所有F构成保留值）。