UNIT-5 ZIGBEE

What is ZigBee?

ZigBee is built on top of the IEEE 802.15.4 standard. ZigBee provides routing and multi-hop
functions to the packet-based radio protocol. It is a product of the ZigBee Alliance. The
Alliance is an association of companies working together to ensure the success of this open
global standard.

ZigBee and IEEE 802.15.4 are standards-based protocols that provide the network
infrastructure required for wireless sensor network applications. 802.15.4 defines the
physical and MAC layers, and ZigBee defines the network and application layers.

The ZigBee stack is loosely based on the OSI 7-layer model. It implements only the
functionality that is required in the intended markets.

Logical Device Types:

The ZigBee stack resides on a ZigBee logical device. There are three logical device types:
• Coordinator : This device starts and controls the network. The coordinator stores
information about the network, which includes acting as the Trust Center and being the
repository for security keys.
• Router: These devices extend network area coverage, dynamically route around
obstacles, and provide backup routes in case of network congestion or device failure.
They can connect to the coordinator and other routers, and also support child devices.
• End device: These devices can transmit or receive a message, but cannot perform any
routing operations. They must be connected to either the coordinator or a router, and do
not support child devices.

In a ZigBee network there is one and only one coordinator per network.
The number of routers and/or end devices depends on the application requirements and the
conditions of the physical site.
Within networks that support sleeping end devices, the coordinator or one of the routers
must be designated as a Primary Discovery Cache Device. These cache devices provide
server services to upload and store discovery information, as well as respond to discovery
requests, on behalf of the sleeping end devices.

Typical Applications:

There are numerous applications that are ideal for the redundant, self-configuring and self-
healing capabilities of ZigBee wireless mesh networks. Key ones include
• Energy Management and Efficiency—To provide greater information and control of energy
usage, provide customers with better service and more choice, better manage resources,
and help to reduce environmental impact.
• Home Automation—To provide more flexible management of lighting, heating and cooling,
security, and home entertainment systems from anywhere in the home.
• Building Automation—To integrate and centralize management of lighting, heating, cooling
and security.
• Industrial Automation—To extend existing manufacturing and process control systems
reliability. The interoperable nature of ZigBee means that these applications can work
together, providing even greater benefits.
• In the Personal Home and Health Care (PHHC) --- ZigBee can monitor a patient’s
condition, including heart rate, movement (to detect a fall), blood pressure and other
medical information.

Why ZigBee ?
The ZigBee standard was developed to address the following needs:

• Low cost
• Secure
• Reliable and self healing
• Flexible and extendable
• Low power consumption
• Easy and inexpensive to deploy
• Global with use of unlicensed radio bands
• Integrated intelligence for network set-up and message routing
ZigBee is the only standards-based technology that addresses the unique needs of most
remote monitoring and control sensory network applications.

About the ZigBee Alliance

The ZigBee Alliance is an association of over 285 companies working together to enable
reliable, cost-effective, low-power, wirelessly networked, monitoring and control products
based on an open global standard. Their focus is on the following:
• Defining the network, security and application software layers
• Providing interoperability and conformance testing specifications
• Promoting the ZigBee brand globally to build market awareness
• Managing the evolution of the technology

ZigBee Architecture:
Each layer in the stack knows nothing about the layer above it. The layer above it could be
considered a “ master ” that commands its “ slave ” below it to do the work. Each layer
builds more and more sophistication upon the foundation of the lower layers.
Between the layers are Service Access Points (SAPs). SAPs provide an API that isolates
the inner workings of that layer from the layers above and below.
The two lowest layers, the MAC and PHY, are defined by the IEEE 802.15.4 specification.
The PHY layer simply translates packets into over-the-air bits and back again. The MAC
layer provides the concept of a network, including a PAN ID, and networking discovery
through beacon requests and responses.
Application (APL) Layer
The top layer in the ZigBee protocol stack consists of the Application Framework, ZigBee
Device Object (ZDO), and Application Support (APS) Sublayer.
Application Framework
The Application Framework contains the ZigBee Cluster Library and provides a framework
within which applications run. Endpoints are the mechanism used to distinguish one
application from another.
Application Objects
Software at an endpoint that controls the ZigBee device. A single ZigBee node supports up
to 240 application objects. Each application object supports endpoints numbered between 1
and 240 (with endpoint 0 reserved for the ZigBee Device Object (ZDO)).
ZigBee Device Object (ZDO)
The ZDO layer (which includes the ZigBee Device Profile, ZDP), is responsible for local and
over-the-air management of the network. It provides services to discover other nodes and
services in the network, and is directly responsible for the current state of this node on the
network. The ZDO is always endpoint zero.
ZDO Management Plane
Facilitates communication between the APS and NWK layers with the ZDO. Allows the ZDO
to deal with requests from applications for network access and security using ZDP (ZigBee
Device Profile) messages.
Application Support (APS) Sublayer
Responsible for providing a data service to the application and ZigBee device profiles. It
also provides a management service to maintain binding links and the storage of the
binding table itself.
Security Service Provider (SSP)
Provides security mechanisms for layers that use encryption (NWK and APS). Initialized
and configured through the ZDO.
Network (NWK) Layer
The NWK layer is responsible for mesh networking, which includes broadcasting packets
across the network, determining routes for unicasting packets, and generally making sure
packets are sent reliably from one node to another. The network layer also has a set of
commands for Security purposes, including secure joining and rejoining. ZigBee networks
are all secured at the NWK layer, and the entire payload of the NWK frame is encrypted.
Medium Access Control (MAC) Layer
Responsible for providing reliable communications between a node and its immediate
neighbors, helping to avoid collisions and improve efficiency. The MAC Layer is also
responsible for assembling and decomposing data packets and frames.
Physical (PHY) Layer
Provides the interface to the physical transmission medium (e.g. radio). The PHY layer
consists of two layers that operate in two separate frequency ranges. The lower frequency
PHY layer covers both the 868MHz European band and the 915MHz band used in countries
such as the US and Australia. The higher frequency PHY layer (2.4GHz) is used virtually
worldwide.

Zigbee layer Descriptions

PHY Defines the physical operation of the Zigbee device including receive sensitivity, channel
rejection, output power, number of channels, chip modulation, and transmission rate
specifications. Most Zigbee applications operate on the 2.4 GHz ISM band at a 250 kb/s
data rate. See the IEEE 802.15.4 specification for details.

MAC Manages RF data transactions between neighboring devices (point to point). The MAC
includes services such as transmission retry and acknowledgment management, and
collision avoidance techniques (CSMA-CA).

Network Adds routing capabilities that allows RF data packets to traverse multiple devices
(multiple hops) to route data from source to destination (peer to peer).

APS (AF) Application layer that defines various addressing objects including profiles, clusters, and
endpoints.

ZDO Application layer that provides device and service discovery features and advanced
network management capabilities.

ZigBee Addressing Scheme

The MatrixMultimedia ZigBee kit uses Version 2 XBEE ZigBee modules which are
configured to associate up to seven child nodes. Every node on a ZigBee network can
have up to three different types of address assigned to it:
• a MAC address;
• a network address;
• a name.
MAC Address:
Each ZigBee node comes complete with its own unique 64-bit MAC address, assigned by
the IEEE. As a result, it is also known as the IEEE address or extended address.
This can be used to secure the network against unwanted communication. By scanning the
MAC address of a node wanting to join a network and referring to a list of permitted MAC
addresses, the co-ordinator can allow or deny access to that node.
Network Addresses:
This is a sixteen bit address which identifies the node to the rest of the network. It is not
globally unique, so that two nodes on separate networks may have the same network
address. The network address is also called the short address and is allocated by the
parent node, router or co-ordinator, when the node joins the network. The co-ordinator
always takes the network address 0x0000. Having sixteen bits gives a possible 216 nodes
(65536) on the network.
Name address :
Each node can be assigned an optional name address string of up to twenty ASCII
characters. The name address is useful for creating dynamic networks that are capable of
scanning for particular node types. For example, all nodes which include sensors can be
given a name starting with SN. When the co-ordinator is adding nodes to the network it can
scan the node names and if the scanned name begins with SN, then it knows that the node
has sensors available. This allows for a network to be formed and then at a later date extra
sensor nodes can be added to the network without having to edit the existing code.

ASSOCIATION
Forming a Network
➢ There are two ways to join a ZigBee network: MAC association and NWK rejoin.
When forming a network, a ZigBee coordinator first performs an active scan (it sends
beacon requests) on all channels defined in its configuration files. It then selects the
channels with the fewer networks, and if there is a tie performs a passive scan to determine
the quietest channel. It finally broadcasts a 802.15.4 beacon for the selected PAN ID on the
selected radio channel, then remains silent (or repeats the beacon periodically, depending
on the implementation). Depending on the configuration of the stack, the scan duration on
each channel can range from 31 ms to several minutes, so the network-forming process
can take significant time. If there are any ZigBee routers associated to the network, they will
typically repeat the beacon with an offset in time relative to their parent’s beacon (an
extension of 802.15.4:2003).

Joining a Parent Node in a Network Using 802.15.4 Association(MAC Association)

MAC association is the bare-bones default, which every ZigBee device must support, since
it is actually mandated by and implemented in the underlying MAC layer. In this case, a
ZigBee router or coordinator that wishes to allow other devices to join must issue a NLME-
PERMIT-JOINING.request.

Then the joining device, after it has discovered which network to join and to which specific
device on that network it should make its request, must issue a NLME-JOIN.request with
the rejoinflag set to FALSE. This last request kicks off a MAC protocol, as shown below,
whereby joining device makes a request to join the network and the receiving device
issues a response, which includes an address for the device to use while associated with
that network. Note that MAC association is an unsecured protocol since all the associated
frames are sent in the clear (with no security).

Network Rejoin: Using NWK Rejoin

A device that loses connection to the network can attempt to rejoin using the ZigBee
NWK layer rejoin command, which also triggers a beacon request.
If it rejoins a different parent (e.g., because the original parent no longer responds), the
node will be allocated a different short address, and must broadcast a device announce to
the network in order to update bindings that may be configured in other nodes.
What this means, first of all, is that it is not subject to the MAC's built-in mechanism for
permitting devices to join the network and can be used whether the ZigBee router has
issued a NLME-PERMIT-JOINING.request or not. Second, it means that the transaction
may be secured if the joining device knows the current NWK key. This could be true if the
device is actually rejoining the network, or else if the device is joining for the first time but
has obtained the NWK key via some out-of-band mechanism. The figure shown below omits
the optional network discovery steps shown in the previous case to stress the point that it is
not necessary to discover which devices have permitted joining.

PAN Ids: :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.

ZigBee PAN IDs are 16-bit numbers that range from 0x0000 to 0x3fff. 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.
Network Layer in Zigbee Architecture:

Network Layer provides interface between MAC layer and the application layer. It is
responsible for routing and establishing different Zigbee network topologies namely Star,
Mesh and Tree topologies.

When a coordinator attempts to establish a Zigbee network, an energy scan is initiated to

find the best RF channel for its new network. When a channel has been chosen, the
coordinator assigns a PAN-ID which will be applied to all the devices that join the network.

PAN-ID is a 16 bit number that is used as a network identifier. A node is allowed to

communicate on a network only when it undergoes the association process. The
association function is used to join a node to a parent.

Function of Network Layer in Zigbee Architecture

Network Layer in Zigbee architecture is responsible for the following functions:

• Initiation of a network
• Assigning node addresses
• Configuring of new devices
• Providing secured transmission

Network Layer Frame Format:

The network layer PDU format is illustrated in below Table
Field name Size (octets) Field details
Frame Control 2 --------------XX : Frame type (00 : network
data)
-----0010--:Protocol version (always 0x02 for
ZigBee2006/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 :
notspecified)
 ---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

Routing Support Primitives:

The network layer provides a number of command frames listed in below table. 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.
Packet Forwarding
At the network layer, ZigBee packets can be:
– Unicast: the message is sent to the 16-bit address of the destination node.In a unicast
message, the network address of the destination node is provided as the destination
address in the MAC layer header of the message. Only the device that has this address
accepts the message. The destination device may then transmit an acknowledgment, as a
unicast message back to the source node, to confirm reception of the message.

– 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.
In a broadcast message, the MAC layer destination address is 0xFFFF. All active devices in
the network receive and analyse the message. As other nodes detect the broadcast, they
retransmit the message to extend the range of the broadcast.
This form of addressing is used when:
• joining or rejoining a network;
• discovering routes in the network;

– Multicast that is, sent to a 16-bit group ID.

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”.

Routing and route discovery :

In order for a message to travel from source node to destination node, there must be a
mechanism that allows one node to locate and send data to another.
In a simple star network, this is not a complex task, as all end devices communicate directly
through the central co-ordinator. Other topologies demand a more multifaceted approach,
and routes are learned and established in a number of ways.
In a cluster tree network, there are two options, tree routing and route discovery. For small,
static networks, tree routing is the best option. If there is a risk that nodes might stop
working, or if reliable data delivery is essential, tree routing may be ineffective, and it may
be better to use the more complex route discovery process.
In a mesh network, routing must rely on the route discovery process to build and maintain
routing tables in FFD devices.
1.Tree routing overview :
The plan is to use the tree structure to route packets from source to destination. The first
decision the source device must make is which way, up or down the tree, should the packet
be sent. The answer is found by examining the addressing structure. Basically, if the
destination node is a descendant, the device sends the packet to one of its children;
otherwise, it sends it to its parent. When a device receives the packet, it checks to see
whether it, or one of its child devices, is the destination. If so, the device either accepts the
packet itself, or passes it to the appropriate child device. If not, it passes the packet to its
parent .
The problem with this is that the path taken by the packet may be longer than necessary
because it followed the tree structure, rather than looking for the shortest possible path.
Routing efficiency is improved when ZigBee allows routers to discover shortcuts, using the
path discovery process. Each router involved must maintain a routing table mapping
destination addresses to next hop device addresses.
2.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.
3. Meshed Routing:
A key component of the Zigbee protocol is the ability to support mesh networking. In a mesh
network, nodes are interconnected with other nodes so that multiple pathways connect each
node. Connections between nodes are dynamically updated and optimized through
sophisticated, built-in mesh routing table.

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:
Node A needs to set up a route to node D. It broadcasts a route request (see) 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.
(insert meshed routing image)

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 . 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.
4. 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.

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

APPLICATION LAYER IN ZIGBEE ARCHITECTURE:

The Application Layer in Zigbee architecture consists of sub layers namely:
• Application Support Sub Layer
• Application Framework
Application Support Sub Layer (APS)
The APS provides services to the application layer and the network layer through
Application Support Data Entitiy(APSDE) and Application Support Management
Entity(APSME). It is responsible for matching two devices according to their services. The
APS frame over-the-air includes Endpoints, Clusters, ProfileIDs, and Groups.
This layer is responsible for filtering of packets for end devices, checks for duplicity of
packets which is common in a network that supports automatic retries. To maximize the
chance of successful transmission, it performs automatic retries, when the
acknowledgement is requested by the sender.
It is involved in maintaining binding tables. Binding is the connection between the endpoint
on the node to one or more endpoints on other nodes. The address mapping associates a
64-bit MAC address with a Zigbee 16-bit network address.

Function of Application Support Sub Layer (APS)

Application Support Sub Layer (APS) is responsible for the following functions:

• Maintaining binding tables.

• Address definition, mapping and management.
• Ensuring communication between devices.
• Filtering out packets for non-registered end devices or profiles that don’t match and
reassembling of the packets.
• Filtering out packets for non-registered endpoints, or profiles that don't match
• Generating end-to-end acknowledgment with retries
• Maintaining the local binding table
• Maintaining the local groups table
• Maintaining the local address map

APS Frame Format:

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.
Frame Control: 0x00
Destination Endpoint: 0x08
Cluster Identifier: On/off (0x0006)
Profile Identifier: HA (0x0104)
Source Endpoint: 0x08
Counter: 0x22
Application Framework
The Application Framework depends on the vendor who has chosen for specific
applications to interact with Zigbee protocol. This represents how end points are
implemented, how data requests and data confirmation is executed for that particular
vendor.

Bindings:
Binding in ZigBee allows an endpoint on one node to be connected, or “bound” to one or
more endpoints on another node. Think of a switch controlling a light, or a temperature
sensor sending its data to a thermostat. The sender (switch or temperature sensor) is
“bound” to the receiving device (light or thermostat).
Binding is unidirectional, in that the switch is bound to the light, but the light isn't bound to
the switch.
Bindings are stored locally by the sending node (the switch or temperature sensor). Each
binding table entry stores the following information:
• Source endpoint
• Destination NwkAddr and endpoint or destination group
• Cluster ID

❖ ZigBee devices can have up to 240 endpoints, so each physical device can support
multiple bindings.
❖ Bindings can be stored within the source device, for example, a remote control could
store the addresses and endpoint IDs of all applications it needs to communicate with.
This is known as direct binding or source binding.
❖ Binding information can also be stored in a binding cache, with an intermediary device
providing a lookup table that maps all source and destination endpoints. This is known as
indirect binding.
❖ The APS layer keeps a local binding table, a table which indicates the nodes or groups in
the network that this node wishes to speak to.
❖ The APS layer keeps a local binding table, a table which indicates the nodes
or groups in the network that this node wishes to speak to.
❖ The binding table can be managed locally through an API (APSME-BIND.request) 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.

Src EP Destination Addr Addr/Grp Dst EP Cluster ID

5 0x1234 A 12 0x0006
6 0x796F A 240 0x0006
5 0x9999 G – 0x0006
5 0x5678 A 44 0x0006
Groups:
Groups are a way of collecting a set of nodes into a single addressable entity. A single data
request can reach every node in a group. Groups are an optional feature in the ZigBee
specification, but are mandatory in some profiles, such as in the Home Automation Profile.
Groups are interesting in that an entire set of devices can perform an action all at once. A
ZigBee-enabled home theater system could dim the lights, turn on the DVD player,
television, and surround-sound speakers, lower the shades, and turn off the telephone
ringer, all with a single over-the-air command.
Within nodes, applications reside on endpoints. When a groupcast is received, a node
checks its endpoints to see if any are members of that group ID. If none match, then the
packet is discarded by ZigBee. If there is a match, then the packet is sent to the relevant
endpoint(s).
In this three-node example, two lights belong to the same group, but on different endpoints.
The switch sends a data request to that group to toggle the light (see below figure).

Only the receiving node(s) need to be part of the group. The sending node needs to know
which group to transmit to, but does not need to be a member of that group.

ZigBee Security
ZigBee security, which is based on a 128-bit AES algorithm, adds to the security model
provided by IEEE 802.15.4. ZigBee’s security services include methods for key establish-
ment and transport, device management, and frame protection.
The ZigBee specification defines security for the MAC, NWK and APS layers. Security for
applications is typically provided through Application Profiles.
Trust Center
The Trust Center decides whether to allow or disallow new devices into its network.
The Trust Center may periodically update and switch to a new Network Key. It first broad-
casts the new key encrypted with the old Network Key. Later, it tells all devices to switch to
the new key.
The Trust Center is usually the network coordinator, but is also able to be a dedicated
device. It is responsible for the following security roles:
• Trust Manager, to authenticate devices that request to join the network
• Network Manager, to maintain and distribute network keys
• Configuration Manager, to enable end-to-end security between devices
Security Keys:
ZigBee uses three types of keys to manage security: Master, Network and Link.
1.Master Keys:
These optional keys are not used to encrypt frames. Instead, they are used as an initial
shared secret between two devices when they perform the Key Establishment Procedure
(SKKE) to generate Link Keys.
Keys that originate from the Trust Center are called Trust Center Master Keys, while all
other keys are called Application Layer Master Keys.
2.Network Keys
These keys perform security Network Layer security on a ZigBee network. All devices on a
ZigBee network share the same key.
High Security Network Keys must always be sent encrypted over the air, while Standard
Security Network Keys can be sent either encrypted or unencrypted. Note that High
Security is supported only for ZigBee PRO.
3.Link Keys
These optional keys secure unicast messages between two devices at the Application
Layer.
Keys that originate from the Trust Center are called Trust Center Link Keys, while all other
keys are called Application Layer Link Key
Security Modes
ZigBee PRO offers two different security modes: Standard and High.
Feature Standard* High
Network Layer security
provided using a Network Yes Yes
Key
APS Layer security
Yes Yes
provided using Link Keys**
Centralized control and
Yes Yes
update of keys
Ability to switch from active
Yes Yes
to secondary keys
Ability to derive Link Keys
Yes
between devices
Entity authentication and
permissions table Yes
supported
* Called “Residential” in ZigBee 2006
** Not supported in ZigBee 2006

Standard Security Mode

In Standard Security mode, the list of devices, master keys, link keys and network keys can
be maintained by either the Trust Center or by the devices themselves. The Trust Center is
still responsible for maintaining a standard network key and it controls policies of network
admittance. In this mode, the memory requirements for the Trust Center are far less than
they are for High Security mode.
High Security Mode
In High Security mode, the Trust Center maintains a list of devices, master keys, link keys
and network keys that it needs to control and enforce the policies of network key updates
and network admittance. As the number of devices in the network grows, so too does the
memory required for the Trust Center.
The additional security capabilities inherent in ZigBee PRO are critical as ZigBee is used in
increasingly important applications. The control of critical systems infrastructure, whether in
a commercial building, utility grid, industrial plant, or a home security system must not be
compromised.

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.
NWK Level Security:
ZigBee provides optional integrity protection and encryption. 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). 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 NLDE-data.Request primitive.
Auxiliary Security Header
The auxiliary header contains data about the security of the packet that a receiving node uses to
correctly authenticate and decrypt the packet. This data includes the type of key used, the
sequence number (if it is the network key), the IEEE (long) address of the device that secured
the data, and the frame counter.
Authentication and Encryption
Zigbee uses a 128-bit symmetric key to encrypt all transmissions at the network layer. The
network and auxiliary headers are sent in the clear but authenticated, while the network payload
is authenticated and encrypted. AES-128 is used to create a hash of the entire network portion
of the message (security header and payload), which is appended to the end of the message.
This hash is known as the Message Integrity Code (MIC) and is used to authenticate the
message by ensuring it has not been modified. A receiving device hashes the message and
verifies the calculated MIC against the value appended to the message. Alterations to the
message invalidate the MIC and the receiving node will silently discard the message. Note:
Zigbee presently uses a 4-byte MIC.

Message Integrity Code (MIC)

The nonce (see figure 3) used in the AES-CCM* encryption process is a 13-octet string
constructed using the security control field, the frame counter, and the source address fields
of the Zigbee security header. The size of the MIC can be 32 bits, 64 bits, or 128 bits

Application Layer Security

APS security is intended to provide a way to send messages securely within a Zigbee
network such that no other device can decrypt the data except the source and destination.
This is different from network security, which provides only hop-by-hop security. In that
case, every device that is part of the network hears the packet being sent to its destination
and decrypts it.

APS security uses a shared key (link key) that only the source and destination know about,
thus providing end-to-end security. Both APS layer and network layer encryption can be
used simultaneously to encrypt the contents of a message. In that case, the APS layer
security is applied first, and then the network 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.

The services provided by each security level are listed in below table
Security
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07
control
encrypon No Yes
MIC bit No
No MIC 32 64 128 32 64 128
size MIC

In addition, the application-layer security provides its own optional integrity and encryption
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.
Zigbee Device Object: Zigbee provides API for ZDO access.

The Zigbee Device Object (ZDO) is simply the application running on endpoint 0 in every
Zigbee device. (Remember, application endpoints are numbered 1 through 240.)

This application, ZDO, keeps track of the state of the Zigbee device on and off the network,
and provides an interface to the Zigbee Device Profile (ZDP), a specialized Application
Profile (with profile ID 0x0000) for discovering, configuring, and main-taining Zigbee devices
and services on the network.

ZDO not only interacts with APS, but also interacts directly with the network layer. ZDO
controls the network layer, telling it when to form or join a network, and when to leave, and
provides the application interface to network layer management services. For example,
ZDO can be configured to continue attempting to join a net-work until it is successful, or
until a user-specified number-of-retries has occurred before giving up, and informing the
application of the join failure.

The over-the-air Application Profile supported by ZDO, called the Zigbee Device Profile
(ZDP), is no different than any other, and in most stacks is handled just like any other
application object on an endpoint. ZDP services are separated into client and server. Client
side services (also called requests), are always optional in Zigbee, but many of the server
side ZDP services (also called responses), are mandatory. Nearly every service follows the
same pattern when used. A client device (the node which is doing the asking) first makes a
request. The server device then sends the response back to the client device. The cluster
number for the response is exactly the same as the cluster number for the request, but with
the high bit set. For example, the ZDP command IEEE_ addr_req(zb_zdo_ieee_addr_req)
is cluster 0x0001, and IEEE_addr_cb (zb_zdo_addr_cb) is cluster 0x8001.

It doesn't matter how many hops the nodes are from each other. The nodes A and B could
be 10 hops away from each other, and the ZDP request/response mechanism will work in
exactly the same way, just as it does for applications sending data on an application
endpoint.

For sleeping devices, the parents of the device keep track of the IEEE and short address of
the child, and will respond for them. However, all other information about the sleeping
device, such as the list of active endpoints, are not recorded by the parent and must be
retrieved directly from the devices themselves.

ZDP services include the following categories:

● Device discovery services
● Service discovery services
● Binding services
● Management services

ZDP Device discovery services (Mandatory):

The ZigBee Device Profile (ZDP) contains a set of commands for discovering various
aspects about nodes in the network. The ZigBee specification calls these “ device discovery
services, ” which can be confusing because endpoints contain device IDs which really
describe individual ZigBee applications running in that node. So, when you see ZDP Device
Discovery, think node-wide (not application/endpoint specific) services.
Device discovery services have a few things in common:

● They provide additional information about a node.

● They are all optional from the client side, but some server side processing is

mandatory (a common subset among all ZigBee devices).

● They are node-wide, and do not represent any particular application, or Application Profile
residing on an endpoint in the node.

The ZDP device discovery services are listed below in below table. Notice that all the ZDP
services on the client side are optional. ZigBee does not require that a node be able to send
NWK_addr_req , for example. But on the server side of this equation (a node receiving a
NWK_addr_req and responding to it), the ZDP service is mandatory.

Since sleeping devices are not capable of receiving such requests, a cache mechanism is
provided. The discovery cache is a database of nodes that registered to the cache after a
find node cache requests, and stores cached descriptor data.

ZDP primitives with mandatory server-side processing:

Table 5.1: ZigBee Device Profile Device Discovery Services

Unicast (U),
Client Server
Device Discovery Broadcast
Transmission Processing
Services (B) or Either
(Request) (Response)
(U,B)
NWK_addr_req U,B O M
IEEE_addr_req U O M
Node_Desc_req U O M
Power_Desc_req U O M
Complex_Desc_r
U O O
eq
User_Desc_req U O O
User_Desc_set U O O
Device_annce B O M

What happens if a given client issues two ZDP requests in a row? How does the client
application know which response belongs to which request? Some stack vendors have
solved this problem by only allowing a single request to be issued at any one time. Other
stack vendors, such as Freescale, provide a transaction ID which correlates the request
with the response. This rolling 8-bit transaction ID is sent with each request, meaning, in
theory, that a single application could have up to 256 requests in flight at once. Normally,
however, an application makes one or two requests, and then waits for the response.

ZDP primitives with optional server-side processing:

– Complex_Desc_req, User_Desc_req,
– Discovery_Cache_req,
– User_Desc_set,
 – System_Server_Discover_req,
– D iscovery_store_req,
– Node_Desc_store_req,
– Power_Desc_store_req,
– Active_EP_store_req,
– Simple_Desc_store_req,
– Remove_node_cache_req,
– Find_node_cache_req,
– Extended_Simple_Desc_req,
– Extended_Active_EP_req
ZDP Service discovery services (Mandatory):

Service Discovery
In addition to the services related to devices, or nodes, ZDP also contains a variety of
standard services for querying the applications within those nodes (below table). As with the
device discovery services, most of the ZDP service discovery services are optional. Only a
few service side responses are required.

Discovering and Matching Endpoints

Discovering application endpoints and the services they support is a common
commissioning step in ZigBee. Different manufacturers may choose different endpoints for
their applications. For example, a manufacturer of a switch (Leviton, perhaps) may choose
endpoint 3 for their switch. Philips may choose endpoint 8 for their light. So how does an
application which needs to bind this switch to the light find these endpoints?

ZDP Network Management Services (Mandatory)

These services implement the network features corresponding to the node type
(coordinator, router or end device), for example, managing network scan procedures,
interference detection, and so on. It provides the related interfaces for local applications.
Remote nodes can also send a remote management command to permit or disallow joining
on particular routers or to generally allow or disallow joining via the trust center. Only the
Mgmt_Permit_Joining_req/rsp server-side processing is mandatory, all other primitives are
optional:

– Mgmt_NWK_Disc_req/ Mgmt_NWK_Disc_rsp (control network scanning).

– Mgmt_Lqi_req / Mgmt_Lqi_rsp (getting the neighbor list from a remote device).
– Mgmt_Rtg_req./ Mgmt_Rtg_rsp (getting the routing table from a neighbor device).
– Mgmt_Bind_req. Mgmt_Bind_rsp (getting the binding table from a neighbor device).
– Mgmt_Leave_req / Mgmt_Leave_rsp (request a remote device to leave the network).
– Mgmt_Direct_Join_req / Mgmt_Direct_Join_rsp (requesting that a remote device permit a
device designated by DeviceAddress to join the network directly).
– Mgmt_Cache_req / Mgmt_Cache_rsp (allows to retrieve a list of ZigBee end devices
registered
with a primary discovery cache device).
– Mgmt_NWK_Update_req / Mgmt_NWK_Update_rsp (allows communication of updates to
the network configuration parameters).

ZDP Binding Management Services (Optional)

These primitives enable binding management and maintenance of the bindings table (e.g.,
processes device replacement notifications).

– End_Device_Bind_req / End_Device_Bind_res;
– Bind_req / Bind_res;
– Unbind_req / Unbind_res;
– Bind_Register_req / Bind_Register_res;
– Replace_Device_req/ Replace_Device_res;
– Store_Bkup_Bind_Entry_req/ Store_Bkup_Bind_Entry_res;
– Remove_Bkup_Bind_Entry_req/ Remove_Bkup_Bind_Entry_res;
– Backup_Bind_Table_req/ Backup_Bind_Table_res;
– Recover_Bind_Table_req / Recover_Bind_Table_res;
– Backup_Source_Bind_req / Backup_Source_Bind_res;
– Recover_Source_Bind_req / Recover_Source_Bind_res.

Group Management
Although one would expect group management over the network to be part of the core ZDP
primitives, these were added later as part of the ZCL groups cluster (cluster ID 0x0004).

The ZigBee Cluster Library (ZCL):

The cluster library provides support for communication between applications, including
over the air configuration of group tables, reading and setting attribute values, sub-
scribing to certain attribute-value changes, and so on.

ZigBee Cluster Library Concepts The ZigBee Cluster Library is a collection of clusters
and attributes that have specific meaning, even across profiles. For example, there is an
OnOff cluster that defines how to turn something off, on, or toggle it. This cluster works
for light switches, pumps, garage door openers and any other device that can be turned
on or off.

• A ZigBee node contains an 802.15.4 radio, and is a single addressable entity on the
ZigBee network

• ZigBee nodes contain one or more application endpoints (applications)

• A device, in ZCL terms, resides on an endpoint. Examples of a devices are an
OnOffLight or a Thermostat. A single ZigBee node may contain multiple devices. For
example, a single ZigBee node could control 4 separate lights, all individually
controllable. An endpoint’s simple descriptor describes the device on that endpoint,
including the list of input and output clusters.

• Each cluster is a collection of commands and attributes. In programming terms, a

cluster is an object. For example, a DimmableLight contains a level-control cluster. This
cluster contains attributes that describe it’s current level and another attribute that
describes the transition time when going to a new level. There are commands on that
cluster to turn the light off, turn the light fully on, or to step or move to any light level
over time.

• Attributes are the state of the cluster, or the data. An example of an attribute for the
OnOff cluster is whether the device is presently on or off. Attributes have types, may be
a single byte, a 16-bit word, or even a length encoded string. The ZigBee Cluster
Library contains clusters defining many functional domains. The BeeStack
implementation of the ZigBee Cluster Library contains a data and code driven way of
generically defining devices, clusters and attributes, and providing multiple instantiations
of a given device within a single node if desired.

The ZigBee Cluster Library defines

• functional domains
• cluster sets for that functional domain
• mandatory and optional clusters, attributes, commands and functional descriptions
• cluster identifiers
• explicit device descriptions are not defined

Application Profiles (e.g. HA) defines:

• application domains
• related elements from the cluster library collected into application domains
• device descriptions for each required device
• any specialized or deviated use of ZCL cluster
BeeStack implements the Home Automation application profile, and contains the mandatory
and many of the optional clusters from that specification.

Cluster
A cluster is a set of related commands and attributes. Each cluster is defined by a ZigBee
application profile and identified by a cluster ID (0x0000 to 0xFFFF). Commands are
identified by a command ID (0x00 to 0xFF), and attributes by an attribute ID (0x0000 to
0xFFFF).
Clusters are composed of a server side and a client side. Each application residing on a
ZigBee device lists the clusters that it supports as a server in its simple descriptor input
cluster list, and the clusters that it supports as a client in the simple descriptor output cluster
list.
An application that implements the server side typically exposes a set of attributes, and
must be able to receive and process the primitives defined by the cluster to read or
manipulate these attributes. It may also support attribute-reporting commands, which are
sent to requesting devices that implement the client side of the cluster.
Vice versa an application that implements the client side of the cluster may use any of the
commands supported by the server side, and must support receiving attribute reporting
commands, if it requests such notifications.
Each cluster is defined only within a given application profile. However, in order to avoid any
confusion and to redefine common clusters multiple times, the clusters defined by the
ZigBee cluster library (ZCL) use the same cluster IDs for each ZigBee public application
profile. Table 7.6 lists some of the clusters defined by the ZCL, which therefore have the
same meaning for all public application profiles defined by ZigBee.
Clusters are directional: for each endpoint, the endpoint simple descriptor contains the list of
input clusters (commands that it accepts and properties that can be written to the endpoint),
and the list of output clusters (commands that it may send and properties that may be read).

The ZigBee Cluster Library is organized into functional domains, such as General,
Closures, HVAC, and Lighting. Clusters from these functional domains are used in the
ZigBee Public Profiles to produce descriptions of devices, such as a dimming light, a
dimmer switch, or a thermostat. Each Public Profile may also define its own specialized
clusters, such as the Automatic Metering (later renamed to Smart Energy) Price Cluster.

Cluster ID Cluster Name

0x0000 Basic cluster
0x0001 Power configuration cluster
0x0002 Temperature configuration cluster
0x0003 Identify cluster
0x0004 Groups cluster
0x0005 Scenes cluster
0x0006 OnOff cluster
0x0007 OnOff configuration cluster
0x0008 Level control cluster
0x000a Time cluster
0x000b Location cluster

Zigbee General Commands:

0x00 Read attributes Read a list of attributes, whose 16-

bit identifiers are passed as payload
0x01 Read attributes response Includes a list of attribute
records as payload.
0x02 Write attributes Write a list of
attributes, as described by a list of
attribute records in payload.
0x03 Write attributes undivided
Write attributes, all or nothing mode.
0x04 Write attributes response
Response with a list of status codes,
for each
parameter
0x05 Write attributes no response
Write attributes, best effort mode
0x06 Configure reporting Only
specific attributes support reporting
in a cluster
0x07 Configure reporting response
0x08 Read reporting configuration
Request to get the reporting
configuration
parameters for one or more attributes
0x09 Read reporting configuration
response
0x0a Report attributes Reporting for
one or more attributes of a cluster,
0x0b Default response Basic
success/error response
0x0c Discover attributes Specifies a
starting 16-bit attribute identifier
0x0d Discover attributes response
0x0e Read attributes structured Used
to read only specific index positions
(up to 15)
0x0f Write attributes structured
Used to write only specific index
positions (up to
15) for array-type attributes
0x10 Write attributes structured
response

Attributes
Attributes are identified by a 16-bit number. The ZCL library provides commands to: read or
set attributes; require reporting on an attribute, either periodic or based on a change of
value.

Commands
Commands are identified by an 8-bit number. The first 4 bits of cluster-specific commands
(defined only within the scope of a given cluster) are set to zero. For instance, command
0x00 of the OnOff cluster (0x0006) means “Off”. Other identifiers are reserved for cross-
cluster commands.

Clusters within the ZCL are organized into a number of different functional domains including
Lighting, HVAC (Heating, Ventilation, Air Conditioning), Measurement and Sensing, Security
and Safety, and General.
ZigBee Application Profiles:

Profiles:

Every data request in ZigBee is sent (and received) on an Application Profile. Application
Profile IDs are 16-bit numbers and range from 0x0000 to 0x7fff for public profiles and
0xbf00 to 0xffff for manufacturer specific profiles. Think of a profile as a domain space of
related applications and devices.

The application profile is a collection of devices employed for a specific application. The
profile defines the data exchange form for the application functions of a Zigbee physical
device. A profile consists of one or more endpoints, each with one or more clusters
associated. The aim of profiles is to provide interoperability between different manufactures.
There are three types of profiles:

• public (standard), managed by the CSA.

• private, defined by Zigbee vendors for restricted use.
• published, this concerns previously private profiles that become published ones the
owner profile decide to publish it.

ZigBee profiles are used in cases for which the ZigBee technology is intended. For
example, the ZigBee Alliance has defined a profile for home automation, smart energy
management, building automation, and toys. There are two types of application profiles:
public and vendor-specific.

• An application profile defines a set of messages and attributes standardized for use
in a particular context.
• Application profiles are identified by an application profile ID (0x0000 to 0xFFFF).
• Each manufacturer can define proprietary messages within its own private
application profile, but the ZigBee alliance defines a set of public application profiles,
which enable cross-vendor interoperability for the target applications.
• Profile IDs 0xBF00 to 0xFFFF are reserved for manufacturer specific profiles (MSP)
• Profile IDs 0x0000 to 0x7FFF are reserved for public application profiles

ZigBee Public Profile Ids:

Profile ID Profile Name

0101 Industrial Plant Monitoring (IPM)
0104 Home Automation (HA)
0105 Commercial Building Automation (CBA)
0107 Telecom Applications (TA)
0108 Personal Home & Hospital Care (PHHC)
0109 Advanced Metering Initiative (AMI)
Examples of public profiles include:
• Home automation
• Smart Energy
• Commercial building automation
 1.The Home Automation (HA) Application Profile:

ZigBee Home Automation is primarily focused on sporadic real time control of devices, that
is, the network is normally quiet, but when a user presses a button on a device, he expects
to see the result of that button press across the network quickly.

The HA profile determines the following settings:

– It uses stack profile 0x01 or 0x02.
– Channels 11, 14, 15, 19, 20, 24, 25 are preferred.
– The trust center link key is hardcoded in the profile, the trust center distributes a network ey.
– The minimum number of entries of entries in the broadcast transaction table is nine.

Device name Device ID Supported clusters

Mc/Ms: mandatory on client or server side,
Oc/Os: optional on client or server side
Generic OnOff Switch 0x0103 Ms: OnOff (0x0006)
Os: OnOffSwitch Config (0x0007)
Lighting On/Off Light 0x0100 Ms: OnOff (0x0006)
Ms: Scenes (0x0005)

2. ZigBee Smart Energy 1.0 (ZSE or AMI)

ZigBee Smart Energy 1.0 is a public application profile (profile 0x0109), documented in
“ZigBee SMART ENERGY PROFILE SPECIFICATION (rev 15, 1/12/2008)”. It defines the
smart energy devices and clusters required to build an energy-management system (EMS)

The ZigBee Smart Energy 1 (ZSE) public application was defined to enable usage of ZigBee
for automatic metering, demand response and prepayment applications required by utilities.

ZSE defines several new clusters listed in Table

Price 0x0700
Demand response and load control 0x0701
Simple metering 0x0702
Message 0x0703
Registration 0x0704
AMI tunneling (complex metering) 0x0705
Prepayment 0x0706

A.Smart Energy Extensions of ZigBee

ZigBee SE defines a simplified APS layer designed for basic “inter-PAN” communication,
that is, communication between a PAN and a device that has not joined. The specification
mentions the “refrigerator magnet” with an LCD screen as a target.
Such messages can be sent unicast, broadcast or sent to a group, but without any security.

B. Smart Energy Devices

ZigBee SE defines the following “smart energy” devices:
Energy Service Portal (ESP, Device Id 0x0500)
The energy service portal is a server controlled by the utility company that connects to the
metering and energy management devices within the home. The ESP acts as the coordinator
and trust center of the network.
The ESP must support the server side of the price, message, demand response/load control
and time clusters, and optionally of the complex metering, simple metering and pre-payment.
It may support the client side of the simple metering, complex metering, price and repayment
clusters.
Metering Device (Device Id 0x0501)
A metering device must support the client side of the metering cluster, optionally of the
complex metering cluster. It may support the client side of the metering prepayment, price
and message clusters.
In-Premises Display Service (Device Id 0x0502)
The device is designed to be used as a simple user interface, displaying graphs or messages,
and able to signal button press events. It must implement the client side of at least one of the
price, simple metering and messaging clusters.
Programmable Communicating Thermostat (PCT, Device Id 0x0503)
This device is designed to control heating and cooling systems. It must implement the client
side of the Demand response/load control and time clusters. It may implement the client side
of the prepayment, price, simple metering and message clusters.
Load Control Device (Device Id 0x0504)
This device is designed to manage the electric consumption of devices in a generic way. It
must implement the client side of the demand response/load control and time clusters. It may
implement the client side of the price message cluster.
Range Extender Device (Device Id 0x0008)
A device announcing this device Id must be a pure ZigBee router, not supporting any other
function.
Smart Appliance Device (Device Id 0x0505)
Smart appliances are able to participate in energy-management policies. They must
implement the client side of the price and time clusters, and optionally of the demand
response/load control and message clusters.
Prepayment Terminal Device (Device Id 0x0506)
This device is not fully specified yet. It is designed to support advance payment of services,
and various display functions.

C. Smart Energy Clusters

(a) Demand Response and Load Control Cluster (0x0701)

Server-Side Commands

Load control event (0x00). This event is sent to the devices asked to implement a load control
action, and specifies the actions required. It includes the following parameters:

• Issuer Event ID: unique identifier that will be used to identify future event reports
related to this demand response and load control event.
•
Device Class: bit-encoded field indicating the device classes (end devices actually
performing the energy-demand response, as opposed to their ZigBee controllers)
needing to participate in an event. The classes defined include HVAC compressors,
Strip heaters, water heaters, electric vehicles, and so on.
•
Utility Enrolment Group: both the utility enrolment group field and the device class
must match the target device configured values, otherwise it will ignore the command.
 •
Start Time: UTC Timestamp or 0x00000000 for “now.”
•
Criticality Level: levels 1 to 9 are currently defined. Participation in levels 1 to 6 is
voluntary, participation in level 9 is mandatory. Level 1 signals an abnormal
percentage of nongreen sources in the delivered energy.
•
Cooling and heating temperature offsets: offsets, in units of 0.1 ◦C, to the local
temperature setpoint of the thermostat (added for cooling systems, subtracted for
heating systems), non-cumulative across sequential demand response events. 0xFF
when not used.
•
Cooling and heating temperature setpoint: request to replace the current setpoint by
the
indicated value between –273 ◦C and 327 ◦C in units of 0.01 ◦C, set to 0x8000 when
not used.
•
Average Load Adjustment Percentage: defines a load offset of -100 to +100 points
relative to 100%, with a resolution of 1 point. Interpretation is specific to the client
implementation. Set to 0x80 when not used.
•
Duty cycle: a percentage of time between 0 and 100%, 0xFF when not used.
•
Event Control: flags to indicate whether randomization of the start and end times is
required.
Cancel load control event (0x01): cancellation order specifying the issuer event Id, utility
enrollment group and device classes concerned.
Cancel all load control events (0x02): same as the cancel load control event command,
without the filtering parameters.
Client Side
The client side of the load control/demand response cluster must be able to store at least 3
scheduled events. Events exceeding the storage capacity should be retrieved as soon as
possible using command “get scheduled events”.
The client side maintains several attributes:
– The utility enrolment group;
– The start randomization period, and the stop randomization period, in minutes;
– The device class bitmask.
It implements two commands:
– Get Scheduled Events (0x01), which asks the server side to resend up to a certain
number of load control commands scheduled to start at or after the specified UTC time
stamp.
– Report Event Status (0x00), which reports the time at which the load-control event
(identified by its event ID) was effectively executed, the criticality level, the cooling or heating
set points, load adjustment percentage, duty cycle that were applied.
(b) Simple Metering Cluster (0x0702)
Server-Side Attributes

Server-Side Commands
GetProfileResponse (0x00) returns a number of period accumulators for periods ending
before a specified EndTime.
RequestMirror (0x01): request the ESP to mirror metering device data, using
RequestMirrorResponse command.
RemoveMirror (0x02): request the ESP to remove its mirror of metering device data.

Client-Side Commands
GetProfile (0x00): requests a number of period accumulators for periods ending before a
specified EndTime, for received or for delivered quantities.
RequestMirrorResponse (0x01): the ESP informs a sleepy metering device it has the ability
to store and mirror its data, which should be sent to the indicated endpointID.
RemoveMirror (0x02): the ESP no longer has the ability to mirror data.

(c) Price Cluster (0x0700)

Server-Side Attributes
6 price tiers labels are defined, by attributes “TierXpriceLabel” (0x0000 to 0x0006). The
price tiers are defined by command publish price.

Client-Side Commands
– getCurrentPrice (0x00): initiates a publish price command for the current time.
– getScheduledPrices (0x01): initiates a publish price command for all currently scheduled
times after the provided time stamp (up to a maximum number of scheduled times also
specified in the command).

Server-Side Commands
Publish price (0x00): this command defines a new price tier and is sent in response to a
getCurrentPrice or getScheduledPrices command. It contains the following subfields:
ProviderID: unique Id of the commodity provider;
Rate Label: 12 character UTF8 string related to current rate;
Issuer Event ID: unique identifier for this pricing information, must increase when newer
prices are published for the same period;
Current Time: UTC time of the sending node;
Unit of measure: 8-bit field defining the commodity and unit of measure;
Currency
Price Trailing Digit and Price tier: bit field indicating the price tier for this rate, and the position
of the decimal point in the published price;
Number of price tiers and Register tier: number of price tiers in use (0 to 6), for the current
tier, indication of which CurrenttierXSummationDelivered accumulator relates to the current
price tier;
StartTime: UTC start time of the current rate signal, 0x00000000 means “now”;
Duration in minutes: validity of this price signal. 0xffffffff means “until changed”;
Price: price per base unit;
PriceRatio (optional): ratio to the “normal” tariff;
Generation Price (optional): price for commodity received from the premises;
AlternateCostDelivered, Alternate cost unit and alternate cost trailing digit: cost using an
alternate measure, for example, grams of CO2 per kWh.
(d) Messaging Cluster (0x0703)

Server-Side Commands
DisplayMessage (0x00): specifies the level of importance of the message, whether a
confirmation is required, and the number of minutes the message must be displayed.
CancelMessage (0x01)

Client-Side Commands
GetLastMessage (0x00): request to send a DisplayMessage command
MessageConfirmation (0x01): used to acknowledge a message, provides a timestamp.

(e) Smart Energy Tunneling (Complex Metering) Cluster (0x0704)

Not defined yet, this cluster is a placeholder for future tunneling mechanisms for more
sophisticated metering protocols, for example, C.12 or DLMS/COSEM.

(f) Prepayment Cluster (0x0705)

Not defined yet.