ZigBee

ZigBee is a IEEE 802.15.4 based, low power, low data rate supporting wireless
networking standard, which is basically used for two-way communication between sensors
and control system. It is a short-range communication standard like Bluetooth and Wi-Fi,
covering range of 10 to 100 meters. The difference being while Bluetooth and Wi-Fi are high
data rate communications standard supporting transfer of complex structure like media,
software etc.,
ZigBee Technology supports transfer of simple data like that from sensors. It supports low
data rate of about 250 kbps. The operating frequencies are 868 MHz, 902 to 928 MHz and 2.4
GHz. ZigBee Technology is used mainly for applications requiring low power, low cost, low
data rate and long battery life.

Zigbee Architecture

Zigbee system structure consists of three different types of devices such as Zigbee
coordinator, Router and End device.
Every Zigbee network must consist of at least one coordinator which acts as a root and bridge
of the network.
The coordinator is responsible for handling and storing the information while performing
receiving and transmitting data operations.
Zigbee routers act as intermediary devices that permit data to pass to and fro through them to
other devices.
End devices have limited functionality to communicate with the parent nodes such that the
battery power is saved. The number of routers, coordinators and end devices depends on the
type of network such as star, tree and mesh networks.
Zigbee protocol architecture consists of a stack of various layers where IEEE 802.15.4 is
defined by physical and MAC layers while this protocol is completed by accumulating
Zigbee’s own network and application layers.

Physical Layer: This layer does modulation and demodulation operations up on transmitting
and receiving signals respectively. This layer’s frequency, date rate and number of channels
are given below.
MAC Layer: This layer is responsible for reliable transmission of data by accessing different
networks with the carrier sense multiple access collision avoidance (CSMA). This also
transmits the beacon frames for synchronizing communication.
Network Layer: This layer takes care of all network related operations such as network setup,
end device connection and disconnection to network, routing, device configurations, etc.
Application Support Sub-Layer: This layer enables the services necessary for Zigbee device
object and application objects to interface with the network layers for data managing services.
This layer is responsible for matching two devices according to their services and needs.
Application Framework: It provides two types of data services as key value pair and generic
message services. Generic message is a developer defined structure, whereas the key value
pair is used for getting attributes within the application objects. ZDO provides an interface
between application objects and APS layer in Zigbee devices. It is responsible for detecting,
initiating and binding other devices to the network.

The ZigBee Network Layer

The network layer is required for multihop routing of data packets in the mesh network,
and is one of the key missing elements of 802.15.4. ZigBee uses the AODV public-domain
mesh algorithm. The ZigBee network layer uses a specific data frame format, documented
in Table 7.1, which is inserted at the beginning of the 802.15.4 payload.

7.1.1 Short-Address Allocation

ZigBee uses the 0x0000 – 0xFFF7 range for network node short addresses. The
ZigBee coordinator uses short address 0x0000. The allocation of other network
addresses, under control of the ZigBee Coordinator, depends on the routing technology
in use:
ZigBee supports two address allocation modes:

–
In stack profile 0x01, the network address depends on the position of the node in the
tree. The distributed address assignment mechanism uses CSkip, a tree-based
network address partition scheme designed to provide every potential parent with a
subblock of network addresses. In addition to the default meshed routing, a tree-
based routing can be used as a back-up (routers use the address allocation to decide
whether to forward the packet to a parent or to a child).
–
In stack profile 0x02 (ZigBee 2007, ZigBee Pro), a stochastic address assignment mech-
anism is used and ZigBee provides address-conflict detection and resolution mecha-
nisms.

7.1.2 Network Layer Frame Format

The network layer PDU format is illustrated in Table 7.1, and is transported as 802.15.4
payload (see Chapter 1).
Table 7.1 The ZigBee network layer frame format

Size
Field name (octets) Field details
Frame Control 2------------------------------XX : Frame type (00 : network data)
----------0010-- : Protocol version (always 0x02 for ZigBee
2006/2007/Pro)
--------XX------: Route discovery (0x01:enable)
-------X--------: Multicast (0 : unicast)
------X---------: Security (0 : disabled)
-----X----------: Source route (0 : not present)
----X-----------: Destination IEEE address (0 : not
specified)
---X------------: Source IEEE address (0 : not specified)
000---------------Reserved
Dest. Address 2 or 8 0xffff broadcast to all nodes including sleeping devices
0xfffd broadcast to all awake devices (RxOnIdle = True)
0xfffc broadcast only to routers, not to sleeping devices
Source address 2 or 8
Radius 1 Maximum number of hops allowed for this packet
Sequence number 1 Rolling counter
Payload Variable APS data, or network layer commands

ZigBee 101

7.1.3 Packet Forwarding

At the network layer, ZigBee packets can be:
–
Unicast: the message is sent to the 16-bit address of the destination node
–
Broadcast: if broadcast address 0xFFFF is used, the message is sent to all network
nodes. If broadcast address 0xFFFD is used, the message is sent to all nonsleeping
nodes. If broadcast address 0xFFFC is used, the message is broadcast to routers only
(including the ZigBee coordinator). A radius parameter adjusts the number of hops
that each broadcast message may travel. The number of simultaneous broadcasts in a
ZigBee network is limited by the size of the broadcast transaction table (BTT), which
requires an entry for each broadcast in progress. The minimal size of the BTT is
specified in ZigBee application profiles, for example, 9 for HA.
–
Multicast that is, sent to a 16-bit group ID.

7.1.4 Routing Support Primitives

The network layer provides a number of command frames listed in Table 7.2.
The route request command enables a node to discover a route to the desired destination,
and causes routers to update their routing tables. At the MAC level, the route request
command is sent to the broadcast address (0xffff) and the current destination PAN ID.
The response, if any, is a route reply command that causes routers on the path to update
their routing tables.
 102 The Internet of Things

Table 7.2 ZigBee routing layer primitives

Command Frame Identifier Command Name Reference

0x01 Route request

0x02 Route reply
0x03 Network Status
0x04 Leave
0x05 Route record
0x06 Rejoin request
0x07 Rejoin response
0x08 Link status
0x09 Network report
0x0a Network update

7.1.5 Routing Algorithms

[Link] Broadcast, Groupcast, Multicast
At the 802.15.4 level, messages sent to multiple destinations are always broadcast. At
the network layer, however, ZigBee offers more possibilities, depending on the
destination address:

–
0xffff broadcast to all nodes including sleeping devices;
–
0xfffd broadcast to all awake devices (RxOnIdle = True);
–
0xfffc broadcast only to routers, not to end devices.

In order to avoid 802.15.4 collisions, broadcast packet are relayed after a random delay
of about 100 ms and therefore propagate ten times more slowly than unicast messages.
The radius parameter is decremented at each hop, so the broadcast propagation can be
controlled with the initial radius value (see Table 7.1).
ZigBee also uses a broadcast transaction table (BTT) in order to avoid any looping of
broadcast messages: each broadcast packet is uniquely identified by its source address and
network sequence number. When relaying a broadcast message, routers keep a copy of this
unique identifier for 9 s (broadcast timeout), and will drop any looped packet. If the
BTT is full, all broadcast messages are dropped. Routers that do not hear all neighbor
routers retransmit a broadcast message may retransmit the broadcast message,
implementing a form of implicit acknowledge mechanism.
Groupcast and multicast are implemented by the APS layer:

–
APS messages sent to group addresses are filtered by the APS layer of the receiving
node, so that only endpoints (and all of them) of member nodes will receive the message.
However, all nodes receive the message (destination set to 0xffff at the network
layer)
–
In ZigBee Pro, the radius is not decremented when the message is forwarded by a
group member. This makes it possible to restrict the 802.15.4 broadcast propagation
to group members only, allowing some slack (apsNonmemberRadius) in order to
cope with disconnected groups. ZigBee Pro calls this “multicast”.

[Link] Neighbor Routing

This mode is not formally documented in ZigBee, but most vendors use it. If a router R
already knows that the destination of a packet is a neighbor router or a child device of
R, it can send the packet directly to this node. ZigBee end devices, however, must
always route outgoing packets to their parent.

[Link] Meshed Routing

This is the default routing model of ZigBee. It implements the advanced ad-hoc on-demand
distance vectoring (AODV) algorithm.
The principle of AODV is illustrated on Figure 7.3.
Node A needs to set up a route to node D. It broadcasts a route request (see Table
7.3) to network address 0xfffc (routers only), which propagates through the network.
Each ZigBee router that receives that message forwards it to its neighbors, adding their
local estimation of quality of the link over which they received the route request to the
path cost parameter of the route request. Note that the route we are discovering is in the
A to D direction, while the path costs actually used are in the D to A direction. This is
because the sender of the route request, which is broadcasting the message, cannot
transmit different values of the link cost, therefore the receiving node needs to update
the path cost. ZigBee mesh routing assumes symmetrical link quality.

B
26

2 7
Path cost = 9
A D
1
1 Path cost = 2

1 1
Destination Next Hop
C
DC
Destination Next Hop
DD

Figure 7.3 ZigBee mesh route discovery.

Table 7.3 Route request parameters

Route Destination
request Destination IEEE
Command options identifier address Path cost address

(1 octet) (1 octet) (2 octets) (1 octet) (0 or 8

octets)
xxx00xxx: not a many-to-one route Sequence Intended Accumulator Only if bit 5
request number destination for path of the
xxx01xxx: many-to-one route length as the command
request and the sender supports command is option is
a
route record table propagated set to 1
xxx10xxx: many-to-one route
request and the sender does not
support a route record table
xxxxx1xx: the command frame
indicates the destination IEEE
address, otherwise set to 0
xxxxxx1x: route request for a
multicast group, and the
destination address field contains
the group ID, otherwise set to 0

Node D will wait for a while until it believes it has received all broadcast route requests,
then computes the lowest path cost and responds by a unicast route reply along the best
route that was just discovered (the parameters of the response are listed in Table 7.4).
Router C creates a routing table entry for D, recording the next hop to reach D (in this
simple case, D itself), and node A also creates a routing table entry for D, recording C
as the next hop router.

Table 7.4 Route response parameters

Route
request
Command identi- Originator Responder Originator IEEE Destination
options fier address address Path cost address IEEE address

(1 octet) (1 octet) (2 octets) (2 octets) (1 octet) (0 or 8 octets) (0 or 8 octets)

Address of the Address of the
originator of responder.
the route
request.
 Node A will continue to use this route as long as it works, or until the applications
requests calculation of a new route.
In ZigBee 2006 and 2007, routes are unidirectional: D will need to discover a route if
it needs to send a packet to A. In ZigBee Pro, D would also store the route to A,
assuming symmetry. ZigBee Pro routers “ping” each other every 15 s to make sure
links are indeed bidirectional, and eliminate one-way links for both directions.

[Link] Tree-Based Routing

Tree-based routing is a back-up routing mechanism (when no route exists or can be
discovered) that can be used only in ZigBee 2006/2007 networks which use Cskip-
based address allocation. Tree-based routing simply uses the fact that routers know the
blocks of addresses allocated to their router children, and to their children ZigBee end
devices: if the destination address is one of those, the router forwards the packet to the
appropriate child, otherwise it propagates the packet to its parent.
Because of the limited address space of 802.15.4 (64 K addresses), which limits the
size of CSkip address blocks, tree-based routing is limited to 5 parent/child
relationships, each node having a maximum of 20 children and 6 routers. This limits the
number of nodes to 31 101 in ZigBee 2006/2007.

[Link] Source Routing

ZigBee mesh networking is limited by the size of the routing table of routers. It works
and scales well in a peer to peer environment, but in environments where one node is a
preferred communication source that frequently communicates to all other nodes, then
this node and adjacent routers would need to store a routing table with as many entries
as nodes. This situation happens with data concentrators, used for metering
applications.
ZigBee Pro solves this problem by introducing source routing:
–
The concentrator broadcasts a many to one route request (up to five hops), which enables
routers along the path to record the shortest path to the concentrator.
–
When a node first sends a packet to the concentrator, it first sends a route record message
towards the concentrator, so that the concentrator will have a chance to learn the optimal
path back towards the node (assuming symmetric links).
–
The concentrator can now reach any node using source-routed messages (up to 5
intermediary routers can be specified). It still needs a lot of memory, but all routers in
the ZigBee network can now work with very small routing tables.

7.5 The ZigBee APS Layer

The APS layer is responsible for management and support of local applications. It
defines all the concepts that make it possible to develop and interconnect ZigBee
applications: endpoints, groups, bindings, and so on.
7.5.1 Endpoints, Descriptors
A given ZigBee device may implement multiple applications at the same 802.15.4 address.
Clearly some multiplexing mechanism is required to identify the source and destination
application of a message. This multiplexing identifier is called endpoint in the ZigBee
specification. Think of it as the equivalent of a port number in a TCP/IP network.
Each endpoint is further characterized by a simple descriptor. The simple descriptor
contains the endpoint number, application profile ID, application device ID (a 16-bit
number referring to a device definition, for example, a HA thermostat, used only for
informative purposes since it contains no technical data), an application version ID, the
list of input clusters and the list of output clusters.
The descriptor of an endpoint can be retrieved from any other node by using the ZDP
simple descriptor request command (Simple_Desc_req, see also Section 7.8.1).
In addition to the simple descriptor, specific to each endpoint, ZigBee devices have
additional descriptors applying to the whole node:

–
A node type descriptor: capabilities of the node;
–
A node power descriptor: node power characteristics;
–
A complex descriptor (optional): Further information about the device descriptions,
described as pairs of compressed XML tag and related field data;
–
A user descriptor: User-definable descriptor.

Profiles can be discovered by using the ZigBee device profile request primitive,
addressed to endpoint 0 (ZDO) of the device.

7.5.2 The APS Frame

APS data frames can be sent unicast (with or without application level end to end ac-
knowledgment, in addition to the MAC level hop per hop acknowledgment), groupcast,
multicast (ZigBee 2007 and ZigBee Pro), or broadcast. Groupcasts and broadcasts are
both supported by network-level broadcasts, and are not acknowledged.
At the application level, ZigBee allows application developers to use 64-bit or 16-bit
addresses, group addresses or indirect addressing in order to identify the destination
node, for instance in the [Link]. In all cases, the ZigBee stack resolves
that address to a 16-bit node address or to a group address before transmission.
This resolution mechanism uses the APS address map. This cache stores the mapping
of 64-bit IEEE addresses to 16-bit ZigBee short network addresses. It is used, for instance,
to resolve binding requests (which specify only a 64-bit IEEE address) to a 16-bit address.
The maintenance of this table is performed by listening to broadcast device announce
commands (e.g., when a device changes location and its 16-bit address changes, see
Figure 7.2 for an example).
 If a node does not have a cached route to the destination, it performs a route
discovery using ZDP commands IEEE address request and NWK address
requests. When a frame that required an end to end acknowledgment has not been
acked after 3 retries (typically a retry every 1.5 s, this delay is adjustable in most
stacks), another route discovery may be performed.

[Link] Groups
A group identifier (in the range 0x0000 to 0xFFFF) is an address that can be used at
APS layer level to send a message to multiple ZigBee applications residing on other
nodes (see Section [Link]). Any ZigBee node can belong to up to 16 groups. An
application residing on a ZigBee node on endpoint E adds itself to a group G by calling
the local Ad- dGroupRequest APS primitive: this function adds endpoint E to the list of
local members of group G.
Messages addressed to a group are broadcast at the ZigBee network layer (the
ZigBee network frame destination address is 0xffff) 1: ZigBee routers will forward a
copy of the packet to any neighbor. Group messages are therefore received and
processed by all nodes in the PAN network at the MAC layer, but the APS layer
forwards the message only to the endpoints (individual applications residing on the
node) that have registered to be members of the group ID.
The ZigBee HA profile recommends group addressing each time a message needs to
be sent to more than 4 nodes.

[Link] Indirect Addressing, Binding

Bindings are one of the publish/subscribe models implemented in the ZigBee specification
(together with attribute reporting, see Section 7.8).
Cluster C (see Section 7.8) on source endpoint E1 is bound to destination endpoint
E2 (typically hosted by a different node) if it sends events related to its output cluster
ID(s) to the corresponding input cluster ID(s) of E2. E1 can be bound to multiple target
endpoints. Each binding is unidirectional and independent, if E1 is bound to E2, E2
may or may not be bound to E1 (it is a totally different binding).
The binding table can be managed locally through an API ([Link])
or remotely via ZDP commands: The ZDP end-Device-Bind request is sent to endpoint
0 of the target node and specifies:

–
The target endpoint of the binding;
–
The source 64-bit IEEE address (the 16-bit ZigBee network address is resolved by
the APS network address map);

–
The source endpoint;
–
The list of input clusters and output clusters of the source

endpoint.
The local binding table lists, for each binding:

. The local source endpoint;

. The application layer destination address that can be a 802.15.4 address (64-bit format),
or a group ID (16-bit);
. The destination endpoint if the destination is not a group address;
. A cluster ID.

A typical use case is that a device looks for another node in the network with capabil-
ities corresponding to a match descriptor (supported application profile, cluster ID and
direction, e.g., a lamp supporting the on/off cluster as an input). It then binds to that
node using the End-Device-Bind command. In order to facilitate this configuration
operation, bindings may be specified for groups. ZigBee devices that can initiate or
process events have a button that places them in “identify mode” for about 10 s.
Command AddGroupI- fIdentifying can be broadcast and will automatically place the
nodes in “Identify” mode in the group.
At the application level, the binding table can be used through the indirect addressing
mode, for example, in the [Link] primitive. When indirect addressing is
used, the destination address (node address or group address) is resolved using the local
binding table, based on the endpoint ID of the sending application. Indirect addressing
is very flexible as it allows external nodes to configure the routing of messages across
ZigBee applications residing on different nodes (e.g., instruct a switch to send its on/off
events to a ZigBee-controlled relay).

[Link] APS Frame Format

The APS frame format is outlined in Table 7.5.
The format of the application level payload depends on the value of the application
profile identifier and the cluster identifier:

–
Application Profile ID 0x0000: the payload format is defined by the ZigBee device
profile (ZDP).
–
Application Profile IDs 0x0000 to 0x7FFF are reserved for public application profiles,
the payload format is defined by the ZigBee cluster library (ZCL)
–
Application Profile IDs 0xBF00 to 0xFFFF are reserved for manufacturer specific
profiles (MSP). The payload format is defined by the manufacturer but may also use
the ZCL.
Table 7.5 The APS frame format

Field name Bytes Field details

Frame Control 1-----------------------------XX : Frame type (00 : APS data)

----XX-- : Delivery mode (00 : unicast; 11 : group
addressing)
---X----: Indirect address mode (0 : ignored)
--X-----: Security (0 : none)
-X------: Ack (0 : not required)
0---------Reserved
Dest. Endpoint 1 16-bit destination address or group ID
Cluster identifier 2 0x0006: On/Off
Application Profile 2 0x0104: HA
identifier
Source endpoint 1
Counter 1 APS level counter
AF payload Variable up APS service data unit (ASDU): a ZCL frame, ZDP
to 80 bytes frame or application-specific payload
 7.6 ZigBee Security
7.6.1 ZigBee and 802.15.4 Security
ZigBee networks can choose whether to enable security or not. Devices compliant with
a public application profile must conform to their profile security settings.
ZigBee offers security services at two levels:

–
Network (NWK) level security;
–
Application (APS) level security.

None of these security services uses the MAC-level security defined by 802.15.4 (the
802.15.4 frame control field security bit is set to 0), which would encrypt the ZigBee
NWK header that is required by ZigBee routing. However, ZigBee simply transposes
the exact same mechanisms to the ZigBee network and application layer, and uses the

Security control (1 octet) Key seq. number

Frame counter (4 octets) Source address (0 or 8 octets)
(0 or 1 octet)

Bit 0–2 Security Bit 3–4 Bit 5 Extended nonce

Bit 6–7 Reserved
level Key identifier

Figure 7.4 Auxiliary Security header format.

same encryption and hash algorithm (AES-CCM ∗), so encryption acceleration modules
of 802.15.4 chips can still be used.
The ZigBee device object (ZDO) manages the security policies and configuration of
a device.

[Link] NWK Level Security

ZigBee provides optional integrity protection and encryption, as illustrated in Figure
7.6. When network-level integrity protection or encryption is used, the security bit in the
NWK control field is set to 1, indicating the presence of a security auxiliary frame
header, and a message-integrity protection code (MIC).
The NWK security auxiliary header is composed of four subfields, illustrated in
Figure 7.4.
In the security control subfield, the security level is set to the value of the MIB nwk
security-level parameter, by default 0x05. This value specifies whether the frame is only
integrity protected but not encrypted, or that it should also be encrypted, in which case
the entire network payload is encrypted. Network security is applied as configured in
=
the device network information base (NIB, nwkSecureAllFrames TRUE to secure all
frames) by default, but the application may override this setting frame by frame by
specifying the SecurityEnable parameter of the [Link] primitive.
The services provided by each security level are listed in Figure 7.5.
The MIC, as well as encryption, are computed using AES and CCS∗ (see Section
1.1), using the main or alternate network key.

[Link] Application Layer Security

The APS layer provides a number of security primitives that can be used by application
developers:

–
APSME-ESTABLISH-KEY to establish a link key with another ZigBee device using the SKKE
protocol.
–
APSME-TRANSPORT-KEY to transport security material from one device to another.
–
APSME-UPDATE-DEVICE to notify the trust center when a device joins or leaves the network.
–
APSME-REMOVE-DEVICE to instruct a router to remove a child from the network (used
by the trust center).
–
APSME-REQUEST-KEY to ask the trust center an application master key or the active
network
key.
–
APSME-SWITCH-KEY used by the trust center to tell a device to switch to a new
network key.
–
APSME-AUTHENTICATE used by two devices to authenticate each other.

Security 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07

control

encryption No Yes

MIC bit No MIC 32 64 128 No MIC 32 64 128

size

Figure 7.5 AUX header security control field values. The key identifier is set of 0x01 for the
active network key (0x00 for link keys used by the APS layer).

In addition, the application-layer security provides its own optional integrity and en-
cryption services, based on the network key or on a link-specific key (associated to the
destination of the packet), under control of the application (TxOptions parameter).
Just like NWK security, the APS layer security will add an auxiliary security header
(AUX header), and an integrity code, as illustrated on Figure 7.6. The difference is that
the integrity protection scheme protects the APS header, auxiliary header and APS
payload, and when encryption is used, only the APS payload is encrypted.
 7.7.2 Key Types
– Master Keys
• Application master keys are distributed by the trust center (via unsecured key
trans- port) and used to set up link keys between two devices, and for mutual
authentication of devices.
• Trust center master keys are used to derive a link key for communication with the
trust center.

NWK layer security NWK layer MIC protects NWK header and payload

SYNCPHY HDR MAC HDRAUX

NWK HDR
HDR
(optionally encrypted) NWK payload MIC

APL layer MIC protects entire APS frame

APL layer security
SYNCPHY HDR MAC HDR NWKAPS AUX HDR
(optionally encrypted) APS payload MIC
HDRHDR

Figure 7.6 ZigBee NWK and APS security services.

–
Network keys are used for network management. They are preconfigured or configured
by the trust center, using unsecured key transport when standard security is used or using
the trust center link key in high-security mode.
• Standard network keys are used in the standard security mode, and can be used to
secure general application layer commands.
• High-security network keys are used in the high-security mode, they are not used
for communication between secure devices, which use link-specific keys instead.
–
Link keys can either be negotiated using SKKE, or configured by the trust center under
request of a device. Service specific keys are derived by hashing of the link key:
• The key-load key is used to protect transported master and link keys.
• The key-transport key is used to protect transported network keys.

A ZigBee device stores a (master key/link key) key pair for each device with which
they may use link-key-based communication. The device is identified by its 64-bit IEEE
address.

7.7.3 The Trust Center

Key distribution is not addressed by 802.15.4. For security purposes, ZigBee defines the
role of “trust center”, which is responsible for key distribution and joining policy.
In high-security mode, the trust center maintains a list of devices, master keys, link
keys and network keys. A device can be preloaded with the trust center address and
initial master key, or the master key can be sent via an unsecured key transport
primitive. The trust center, by default, is the ZigBee coordinator, but the coordinator
can designate another device, or the trust center can be preconfigured in devices.
 In low-security mode, a device communicates with its trust center using the current
network key, which can be preconfigured (as in the commercial building automation
profile) or configured via an unsecured key transport primitive during the joining
process (as in the home automation profile).

Figure 7.7 Security bootstrapping procedure in high-security mode.

The trust center is notified by ZigBee routers of joining devices by means of an Update-
Device command (see Figure 7.7). They can reject or accept the new joiner. In the latter
case the trust center communicates the joiner master key to the router, which relays it to
the joiner. This enables the trust center to establish a link key to the joiner, and to
finally securely communicate the NWK key to the joiner using a secure Transport-Key
command (key-transport key, derived from the link key).
Devices can also request the trust center to compute a link key pair for
communication with another device: the trust center will communicate the link key to
each device using Transport-Key commands.

[Link] SKKE
Secure ZigBee devices are configured with a link specific master key for each device
they may need to communicate securely with, or need to authenticate. A link key, distinct
from the master key, can be negotiated between ZigBee endpoints by using a symmetric
key establishment (SKKE) scheme using procedures defined in ANSI X9.63-2001.

[Link] Entity Authentication

ZigBee provides a APSME-AUTHENTICATE. Request primitive is used for
initiating entity authentication or responding to an entity authentication initiated by
another device. The request includes a random challenge and the response is a hash
based on the shared master key for the device pair and frame sequence numbers.
7.7.4 The ZDO Permissions Table
The ZDO optionally comprises a permissions configuration table. This table lists a number
of tasks categories (e.g., ApplicationSettings for authorization to configure bindings,
groups, and other application configuration commands) that can be requested from an
external entity to the ZDO. For each task category, the permissions configuration table
lists the addresses of devices authorized to perform these tasks (or specifies that any
device is authorized), and specifies whether the related commands need to be secured
with a link-specific key.