ZigBee Personal Area Network identifiers (or PAN IDs) are used to logically separate a collection of ZigBee nodes from other ZigBee nodes in the same vicinity or on the same physical channel. This allows network A and network B to exist in close proximity without interfering with each other, other than consuming over-the-air bandwidth that they both share. For example, take a look at Figure 4.12. The light and dark gray PANs share the same physical space, and in this case the same channel.
Figure 4.12: Separate ZigBee PANs May Coexist on the Same Channel
ZigBee PAN IDs are 16-bit numbers that range from 0x0000 to 0x3fff. Note this is different than the 802.15.4 specification, which allows PAN IDs from 0x0000 to 0xfffe.
Generally, ZigBee PAN IDs won't conflict (there are 16 K of them, and stacks are encouraged to choose random PAN IDs). ZigBee does not expect to have anything near 16,000 different networks, all within radio range. In our office, we may perhaps have 10 to 20 going at any given time on various channels, and we are developing ZigBee projects. That's a 1 in 13,107 (16 × 16 K/20) chance of a conflict in our case. Not very likely.
In ZigBee 2006, PAN IDs are unique on a given channel: that is, PAN ID 0x1234 could exist on channel 11 and a separate pan 0x1234 could exist on channel 12. In ZigBee 2007, that is disallowed because of the Frequency Agility feature, which allows a network to switch channels if it determines that the current channel is no longer appropriate.
When forming a network, ZigBee specifies that PAN ID 0xffff means the application doesn't care what the PAN ID is, and is requesting the ZigBee stack to pick one at random that does not conflict with any existing PAN IDs in the vicinity. When joining a network, PAN ID 0xffff means the node doesn't care which network it joins. Any PAN ID will do.
So how does an application decide which PAN ID to use, either for forming or joining? The simple answer is that the Application Profile decides. In Home Automation, the default PAN ID is 0xffff for all devices. For a private profile, any PAN ID may be used.
The following example, Example 4-3 ZigBee PAN IDs, shows how to pick which PAN ID a node will join. In the example, two PANs are formed on the same channel, PAN IDs 0x000a and 0x000b. I'll use channel 11 for the demo. Then a switch is started, which joins a PAN. The switch is initially compiled to search for PAN ID 0x000b, so it will always join that PAN (the Ncb Light). Notice the switch can control the NcbLight (see Figure 4.13).
Figure 4.13: Switch Joins PAN A
Next, the switch is recompiled to search for PAN ID 0x000a (or, if another SRB board is available, a second switch is started). Reset the switch and notice how it now joins PAN 0x000b this time, and controls the SrbLight, as opposed to the NcbLight (see Figure 4.14 ).
Figure 4.14: Switch Joins PAN B
Like most examples in the book, the example can be followed using the three-node Freescale Network Starter Kit. The BeeKit Solution file, capture file, and source code to the application can be found at http://www.zigbookexamples.com. See Chapter 3, "The ZigBee Development Environment," for a full explanation of how to download examples into the hardware. Download the following three projects to the respective boards:
Boot all three boards. Once they come up, press SW1 on the switch, and notice that it controls the NCB light, and not the SRB light. If you are sniffing over-the-air, you should see something like this:
Take a closer look at packet 6. Notice that the switch is attempting to associate with PAN A, not PAN B (see Destination PAN Identifier below):
Frame 6 (Length = 21 bytes)
Frame Control: 0xc823
Sequence Number: 59
Destination PAN Identifier: 0x000a
Destination Address: 0x0000
Source PAN Identifier: 0xffff
Source Address: 0x0050c209cc066801
Command Frame Identifier = Association Request: (0x01)
Capability Information: 0x84
... ...0. = Alternate PAN Coordinator: Not capable of becoming PAN Coordinator
.... ..0. = Device Type: RFD
.... .1.. = Power Source: Receiving power from alternating current mains
.... 0... = Receiver on when idle: Disables receiver when idle
..00 .... = Reserved
.0.. .... = Security Capability: Not capable of using security suite
1... .... = Allocate Address: Coordinator should allocate short address
Frame Check Sequence: Correct
Now, have a switch join PAN B. Leave both PAN coordinators running (both the NCB light and SRB light). If you have another SRB board like I do, then download the following project into a second board. Otherwise, reuse the SrbZedSwitchPanA from above and place the following project into that board:
Boot the switch for PAN B. Notice that it associates with PAN B and controls the SRB light which is on PAN B, not the NCB light on PAN A as the first switch did.
The default PAN ID is simply a property in BeeKit. Set it as you would other properties, or examine the constant directly in ApplicationConf.h:
#define mDefaultValueOfPanId_c 0x0B,0x00
Notice the PAN ID (in this case for network B) is a sequence of bytes, little Endian. Everything in ZigBee is little Endian over-the-air. Little Endian (as opposed to big Endian) simply means the lowest byte(s) come first. This may or may not be true of your application data (it is up to the application), but for everything the ZigBee generates, it's little Endian.
It's also easy enough to select the PAN ID under application control at run-time by modifying the variable gNwkData.aPanId. Do not adjust the PAN ID if already on a network—the NWK layer and MAC have some communication which occurs only at form/join time.
It's interesting to note that the ZigBee specification is rather vague on the topic of which channel on which to form or join a network. It says the node will scan the given set of channels and "choose the best one." This allows each OEM to have some flexibility, but still form and join in a standard way. On the Freescale platform, this process to "choose the best one " is exposed to the application in the file AppStackImpl.c. An algorithm could be made, for example, to only look for PAN IDs in the range 0x2000 through 0x20ff. See the function SearchForSuitableParentToJoin().
Sometimes a PAN ID is just not enough. A particular application may want to only join a network that has a particular (probably private profile) application on it. One way is to use a special PAN ID and hope, but that's not a very sure way to join the right network. Another way is to join the network and see if the application is on it, but this takes time to join the other network, and may require special code to be implemented.
ZigBee thought of this and provided a mechanism to join only those PANs which are released by your corporation, which leads us to extended PAN IDs.
The 16-bit PAN IDs allow separate ZigBee networks to share a channel.
The same PAN ID may be used in a different physical locality or on a different channel.