1 Power Control Cluster
1.1 Overview
This cluster provides a mechanism to enable devices to operate at the lowest possible power output.
This is in order to minimize the radio coverage area of a particular device whilst ensuring good
quality communications in order to maximize the number of devices that can operate in a given
area.
The device that is controlling the ZigBee network should support the Power Control cluster server
and all other devices wishing to perform power control should support the Power Control cluster
client.
1.2 Power Control limits
Power Control limits may be imposed by the local device, regulatory bodies, or other entities. The
cluster tries to be agnostic of who is imposing them and instead provides the commands required to
enable power control to be implemented.
1.3 Server
There will be just one server in the system – usually the co-ordinator. The server collects the
attributes from an external source and makes them available to the clients in the system. All other
devices will be clients.
The following server attributes are used by this Cluster.
ID
Name
Type
Range
Acces
s
Default
0x0000
Received Power Threshold
0-255
Read
only
0x0a
0x0001
Received Power Tolerance
Unsigned
8-bit
integer
Unsigned
8-bit
integer
Manda
tory /
Option
al
M
0-255
Read
only
0x03
M
1.3.1 Received Power Threshold
This is an integer that denotes the target received signal level in 1dB steps to ensure that the
received signal is of good quality but is also as low as possible to maximize frequency re-use. A value
of 0 represents -100dBm. The value increases 1dB per step; e.g. a value of 0x0a corresponds to a
signal level of -90dBm (the default level in the TRD)
1.3.2 Received Power Tolerance
The received power tolerance denotes the allowable tolerance in 1dB steps on the received signal
strength. A value of 0x03 represents a tolerance of +/-3dB (the default level in the TRD)
1.3.3 Client
1.3.3.1 Attributes
There are no client attributes.
1.4 Change Power Command
(I think this may be the section that should really be in the network layer spec)
1.4.1 Commands generated
The Change Power Command is sent by a device when it wants to notify a communicating device
that it should change its power. It also indicates whether the sending device is operating at its
maximum or minimum TX power.
1.4.2 Payload format
Field Name
Power Alert
Octets
Data Type
1
8-bit
Enumeration
Change
Power
1
8-bit
Enumeration
Change Power:
This is an instruction to change power, either up or down. A value of 127 represents no change. Each
step represents 2dB power change above or below the current value. For example, a value of 130
instructs the device to increase power by 6dB, a value of 120 instructs it to reduce power by 14dB.
The Change Power command is sent by a device when it receives a packet with signal level outside
the band [Received Power Threshold +/- Received Power Tolerance]. The Value of the Change Power
message sent should aim to set the received power to Received Power Threshold.
Power Alert:
This is a simple alert to report that the device has reached either its maximum or minimum power.
Power Alert Value
0
0x10
Description
Device is at Minimum power
Device is at Maximum
power
On receipt of Power Alert value 0, the receiving device shall not request the sending device to
reduce power.
On receipt of Power Alert value 0x10, the receiving device shall not request the sending device to
increase power.
1.4.3 When generated
The algorithm relies on measuring the signal strength on each packet received and using this to
estimate the change (if any) in power that should be implemented by the sending device. This is
communicated using a dedicated packet format. The other device uses this packet to repeat the
process in reverse. Note that the dedicated power control packets will only be sent if the algorithm
determines a need to change power. Otherwise, the status quo is maintained. The algorithm is
described more fully by the flowchart in Figure 1.
Figure 1
This algorithm will establish the initial power settings for a pair of devices. Each device will need to
maintain a table defining the power to be used in communicating with any other device.
1.4.4 DevicePowerTableStructure
Does this need to be part of the neighbour table?
The DevicePower table structure contains the elements listed in Table 1. The table is not required to
be stored in persistent storage. The table defines the power level at which the device should send to
its neighbours. All devices should store this table for all connected devices to ensure that the correct
TX power is used.
Table 1 Registered Device Table Structure
Name
IEEEAddress
ZCL Type
IEEE Address
Power level
8-bit value
Range
0x0000000000000000
– 0xFFFFFFFFFFFFFFFF
0 – 28
Default Value
0x0000000000000000
0
IEEEAddress: This is the IEEE address of the device that wants to receive a Power Control updates.
Power level: This is an 8 bit value indicating the power setting that should be used when sending
packets to the associated IEEEAddress. 0 indicates maximum power. Each increment represents a
nominal 2dB step down in power to at least the minimum TX power level.
1.4.5
1.4.5.1
1.5 Behaviour in the event of a failure of communication
This should be part of the network layer somewhere – but where?
In addition to the cluster specific commands and algorithm, additional behaviour is required in the
event of a sudden temporary or permanent reduction in power due to fading, or a path loss change
caused by a change in environment – for example a metal cupboard being placed in the path
between 2 devices.
If the power reduction leaves the signal above sensitivity, but below Pth, then the above algorithm
will generate new power settings. If the power reduction cuts off communication altogether, then
the following process should be followed. Communication failure can be determined by the failure
to receive a MAC acknowledgement. This could be caused by a number of factors, including very
short term interference or memory shortages. Hence, a failure can only be assumed after there
have been a number of failed retransmissions. Hence, after 2 failed transactions, the sending device
should return to its maximum power level. If MAC acks are then received, the power control
algorithm can be invoked on the next packet sent.
If the receiving device does not receive expected communications for two transaction periods, it
should automatically return to its maximum power for the third transaction. For example, a Gas
Meter will remain on the originally negotiated power level for 2 of its 30m updates and return to
max power on the third if there is no acknowledgement from the first two.
If messages then get through, the normal power control algorithm can be invoked on the next
packets.
If messages continue to fail to get through after 4 failed transactions then the normal procedures for
orphaned devices are invoked.