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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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)
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.
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 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.
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.
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.
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.
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:
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是否應該在将來的關聯請求期間對“某些裝置”執行認證時才适用。
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):
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.
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.
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.
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.
擴充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。
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.
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.
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).
