July, 2015
ZigBee-15-0276-03
Project
ZigBee Alliance
Title
GB868 Active Power Management
Date
Submitted
27 July, 2015
Source
[Alistair Hopper, Leslie Mulder, Faisal
Bhaiyat, Ramakrishna Boyina,Simon
Barfield]
[NXP, Exegin]
[address]
Re:
Active transmit power control
Abstract
Use of measured receive power and known transmit power to allow peer device to
set optimal transmit power for communication link.
Purpose
This document is a proposes a mechanism for the use of measured receive power
and known transmit power to allow peer device to set optimal transmit power for
communication link for consideration as part of the GB868 MAC/PHY or R22
Core network stack specification extensions.
Notice
This document has been prepared to assist the ZigBee Alliance. It is offered as a
basis for discussion and is not binding on the contributing individual(s) or
organization(s). The material in this document is subject to change in form and
content after further study. The contributor(s) reserve(s) the right to add, amend or
withdraw material contained herein.
Release
The contributor acknowledges and accepts that this contribution will be posted in
the member area of the ZigBee web site.
Submission
Page 1
Voice:
[ ]
Fax:
[ ]
E-mail:
[Alastair.Hopper@nxp.com,
ljm@exegin.com,
faisal.bhaiyat@nxp.com,
Ramakrishna.boyina@nxp.com,
simon.barfield@nxp.com]
NXP, Exegin
July, 2015
Legal
Notice
ZigBee-15-0276-03
Copyright © ZigBee Alliance, Inc. All rights Reserved. This information within this document is
the property of the ZigBee Alliance and its use and disclosure are restricted.
Elements of ZigBee Alliance specifications may be subject to third party intellectual property
rights, including without limitation, patent, copyright or trademark rights (such a third party may or
may not be a member of ZigBee). ZigBee is not responsible and shall not be held responsible in
any manner for identifying or failing to identify any or all such third party intellectual property
rights.
This document and the information contained herein are provided on an “AS IS” basis and ZigBee
DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUT LIMITATION ANY
INTELLECTUAL PROPERTY RIGHTS INCLUDING PATENT, COPYRIGHT OR
TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. IN NO
EVENT WILL ZIGBEE BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS,
LOSS OF USE OF DATA, INTERRUPTION OF BUSINESS, OR FOR ANY OTHER DIRECT,
INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL, PUNITIVE OR CONSEQUENTIAL
DAMAGES OF ANY KIND, IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS
DOCUMENT OR THE INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH LOSS OR DAMAGE. All Company, brand and product names may be
trademarks that are the sole property of their respective owners.
The above notice and this paragraph must be included on all copies of this document that are made.
ZigBee Alliance, Inc.
2400 Camino Ramon, Suite 375
San Ramon, CA 94583
Submission
Page 2
NXP, Exegin
July, 2015
ZigBee-15-0276-03
Introduction:
The Sub-GHz 802.15.4 frequencies are ideal for wireless applications which require long range and low
power consumption. The range in free space of 868 MHz at 27dB is 1km, unfortunately this creates
challenges in commissioning of networks. A lot of networks operating in the same channel space would
cause problems with finding a network of choice to join. The range on a 2.4 GHz solution is lower and
easier to manage.
All the devices will attempt to join on the high power channels at max power as per the TRD and hence
this could make joining a network difficult due to the volume of traffic. This volume of traffic responding
can be reduced greatly by beacon filtering, when using enhanced beaconing. Transmit power control will
reduce the TX power level of the responding coordinator and the TX power level of all subsequent
transmissions of the device to the coordinator
It is important that behavior doesn’t create unnecessary overhead for a 2.4 GHz solutions and hence the
recommendations are for the Sub GHz solutions only.
A sub-GHz MAC shall issue an Enhanced Beacon Request and it is mandatory for the Sub-GHz receiver
to accept the request and based on the outcome of matching of the criteria set out in the IE of the
Enhanced Beacon Request it shall respond with an Enhanced Beacon. It is mandatory for both the
Enhanced Beacon Request/Enhanced Beacon to use the ZigBee IEs.
A 2.4GHz solution may issue an Enhanced Beacon Request and a 2.4GHz receive, if capable, shall
respond with an Enhanced Beacon. If the Enhanced Beacon Request and Enhaned Beacon response is
supported they shall use the ZigBee IEs supported. If a 2.4GHz solution issues an Enhanced Beacon
Request and receives no response it shall issue a standard Beacon Request.
It is mandatory for both the 2.4 GHz and Sub GHz MAC solutions to present the standard beacon
information to the ZigBee layers when receiving an Enhanced Beacon.
MAC Power Level Negotiation:
The reference Rx Sensitivity is -99dbm.
The optimum power is defined as 20db above the reference and hence -79dbm.
Active Power management can be depicted using the following figure:
Submission
Page 3
NXP, Exegin
July, 2015
ZigBee-15-0276-03
node a
node b
Pmaxa
Pmaxb
Power in dB(m)
Ptxab
Ptxba
Pminb
Pmina
Popta
Poptb
Prxba
Excluded Receive Band
due to min LBT CCA levels
Prxab
PLBT1
PLBT2
20dB Margin
ΔPab
ΔPba
Psensitivity
Node a transmits a packet to node b with transmit power of Ptxab. This packet suffers losses over its
transmission path, which in this diagram are assumed to be exponential; other losses may also occur. At
node b the packet is received with a measured power of Prxab. A similar situation is depicted for a packet
from node b to node a, with transmit and receive power of Ptxba and Prxba. The use of the designators a
and b in the power variable are meant to be ordered from transmitter to receiver for both transmit and
receive.
Poptb, as determined either by decree or from empirical data is the desired receive power for node b
receiving a packet from node a or any other node, Prxab is the actual power and ΔPab is defined by
Δ𝑃𝑎𝑏 = 𝑃𝑜𝑝𝑡𝑏 − 𝑃𝑟𝑥𝑎𝑏
If ΔPab were communicated to node a then, assuming that the link loss is exponential. node a could adjust its
transmit power by that amount i.e.
𝑃𝑡𝑥𝑎𝑏 −> 𝑃𝑡𝑥𝑎𝑏 + 𝛥𝑃𝑎𝑏
to within Pmaxa > Ptxab > Pmina.
Similarly node b could adjust its transmit power by the amount ΔPba indicated by node a.
The optimal result of the exchange of information would result in the scenario depict below
Submission
Page 4
NXP, Exegin
July, 2015
ZigBee-15-0276-03
node a
node b
Power in dB(m)
Pmaxa
Ptxab
Pmaxb
Ptxba
Pminb
Pmina
Popta
Poptb
20dB Margin
Excluded Receive Band
due to min LBT CCA levels
PLBT1
PLBT2
Psensitivity
Both node a and b are transmitting at a power level such that the other node is receiving the packets at the
optimal power level.
No device tells the other device what power to use. The decision is arrived at by the each device
independently using the information available to it.
Two Stage Negotiation Approach
The active power management is done in two stages:
(1) Initial Negotiation
The initial stage takes place at the PHY/MAC layer where transparent data communication solicits easy and quick
power level negotiation and quickly establishes the medium for communication. EBR/EB communication are used
to establish a viable RF link, with defined optimal power level for the link. When using other messages not
containing the relevant power information then the default power should be used and would rely upon the next
levels to handle the power negotiation at a later stage. The Rx sensitivity is not an issue even for interoperability
between vendors as this is defined in the TRD and all devices must conform to a common range.
The joining device sends an EBR at maximum Tx power. From the Rssi value received by the coordinator it is
possible for the coordinator to calculate the optimal value that should be set at for this communication link, based on
the expected value of Popt. The coordinator sends back the delta value as a component IE of an Enhance Beacon. If
the joining device so wishes it may take note of this delta value and readjust it’s Tx power accordingly for future
communications:
A
Submission
B
Page 5
NXP, Exegin
July, 2015
Pmax
ZigBee-15-0276-03
EBR (27dBm)
|------------------------------------------------------------- |
PA = 27dBm
Rssi = -60 dBm
PA = 7dBm
Popt = -80dBm
|-------------------------------------------------------------|
EB (7dBm)
Keeping a local copy of the Rssi, LQI and Tx power in the MAC layer is useful as it gives immediate access to
important power parameters without having to involve the higher layers. Also it means that we can use the Link
Quality to assess whether the channel has no signal or a bad signal ie poor implementation or a possible interferer.
This cannot be ascertained merely from Rssi values. This may prove useful for the later implementation of the LBT
mechanism.
(2) Final Negotiation
The final stage takes place at the network layer where encryption provides added security to allow only certified
devices to communicate information about power levels and link quality to other devices. These devices use this
information to set the optimized power threshold and link characteristics.
Note: the power control must be on a LINK basis. There has to be storage for the required power levels for each link
available. This information is required at the MAC/PHY as they define, for example, the power of the ACK. It is not
sufficient to say to use the max power allowed for the channel for the ACK. The MAC/PHY has to manage the TX
level used for each individual link.
The simplicity of a system where the transmitting devices also include their power level in the transmission, is best
illustrated as the ACK may now be sent back with a power level corresponding to the difference of the RSSI from
the optimum – initially a logical choice for reliable communication. Additionally, power level negotiation derived
from the network layer can be further used to optimize the ‘link budget’.
When the power is not transmitted the MAC/PHY it is preferable to have this information available – response times
may be degraded to an unacceptable level if the Network layer and the Neighbor Table has to be interrogated to get
such information about the link.
The basic information needed at the MAC/PHY level to set the correct power etc for the link are:
Octets
2
8
1
1
Data Type
Short address
IEEE Address
TX power level
Last Known RSSI
level
This information is needed for all direct neighbors (for two hop links only the first is relevant). We assume that we
will have a limited number of devices which satisfy this criteria i.e. < 16. The TX power level should be
independent of the channel used (for the first estimation) and as such there is no channel storage requirement. The
TX power level can be negotiated directly with the EBR/EB exchange. Or may be further modified at a later stage
from the network layer. If no power level is chosen then the DEFAULT for that channel is used.
Submission
Page 6
NXP, Exegin
July, 2015
ZigBee-15-0276-03
The table has to persist over resets. The information in the table is made available by the MAC to interact with the
higher layers.
The network layer negotiation is done based on the device type. If the link is with an end device the initiator of the
power negotiation is the end device and it uses the new commands of verify link cost and link response to negotiate
the power levels.
The routers/coordinators will use the existing link status to achieve the same. The link status is formatted for both
868 and 2.4G links with the modification detailed in this document. Since there is only 1 neighbour table shared
across all the MAC interfaces the expectation is that the link status would be duplicated across the MAC interfaces
and wouldn’t be formatted differently per interface.
Table 3.40 NWK Command Frames
Submission
Command Frame Identifier
Command Name
Reference
0x01
Route request
3.4.1
0x02
Route reply
3.4.2
0x03
Network Status
3.4.3
0x04
Leave
3.4.4
0x05
Route Record
3.4.5
0x06
Rejoin request
3.4.6
0x07
Rejoin response
3.4.7
0x08
Link Status
3.4.8
0x09
Network Report
3.4.9
0x0a
Network Update
3.4.10
0x0b
End Device Timeout Request
3.4.11
0x0c
End Device Timeout
Response
3.4.12
0x0d
Verify Link Cost Request
3.4.13
0x0e
Verify Link Cost Response
3.4.14
0x0d – 0xff
Reserved
—
Page 7
NXP, Exegin
July, 2015
ZigBee-15-0276-03
Verify Link Cost Request
The Verify Link Cost is a command sent by an end device to it’s parent. That parent can be a coordinator
or a router. It is a request to evaluate the link cost of this message and return the result to the local device
immediately.
MAC Data Service Requirements
The data transmission is done using a previously negotiated power setting detailed in section
In order to transmit this command using the MAC data service, specified in reference [B1], the following
information shall be provided:

The destination address and PAN identifier shall be set to the network address and PAN identifier,
respectively, of parent.

The source MAC address and PAN identifier shall be set to the network address and PAN
identifier of the end device

The transmission options shall be set to require acknowledgement.

The address mode and intra-PAN flags shall be set to support the addressing fields described here.
NWK Header Fields
The NWK header fields of the verify link cost command frame shall be set as follows:

The source address field of the NWK header shall be set to the 16-bit network address.

The source IEEE address sub-field of the frame control field shall be set to 1, and the source IEEE
address field shall be set to the IEEE address of the device issuing the request.

The destination address field in the NWK header shall be set to the 16-bit network address of the
parent.

The destination IEEE address sub-field of the frame control field shall be set to 1, and the
destination IEEE address field shall be set to the IEEE address of the parent.

The radius field shall be set to 1.
NWK Payload Fields
Octets: 1
1
1
1
Sequence Number
Outgoing Cost
Incoming Cost
Delta Power Level
Sequence Number
Submission
Page 8
NXP, Exegin
July, 2015
ZigBee-15-0276-03
This is a number used to identify the Verify Link Cost transaction. This number is independent of the
network header sequence number.
Outgoing Cost
The local device shall find the entry in the nwkNeighborTable corresponding to the NWK destination of
this message. If not entry can be found, this message shall not be sent.
The Outgoing Cost in the message shall be copied from the Outgoing Cost in the corresponding entry in the
nwkNeighborTable.
Incoming Cost
The incoming link cost is derived from the LQI of the last received packet find the entry in the
nwkNeighborTable corresponding to the NWK destination of this message. If not found the initial value
will be 0.
Delta Power Level
The local device puts that value of the difference in dB between its optimal receive power level and the
actual received power level of the last packet received from the destination device into the Delta Power
Level field of the message.
Submission
Page 9
NXP, Exegin
July, 2015
ZigBee-15-0276-03
Verify Link Cost Response
This command is generated in response to a Verify Link Cost Request.
MAC Data Service Requirements
The data transmission is done using a previously negotiated power setting detailed in section
In order to transmit this command using the MAC data service, specified in reference [B1], the following
information shall be provided:

The destination address and PAN identifier shall be set to the network address and PAN identifier,
respectively, of the end device.

The source MAC address and PAN identifier shall be set to the network address and PAN
identifier of the device transmitting the request (i.e. The parent)

The transmission options shall be set to require acknowledgement.

The address mode and intra-PAN flags shall be set to support the addressing fields described here.
NWK Header Fields
The NWK header fields of the Verify Link cost response command frame shall be set as follows:

The source address field of the NWK header shall be set to the 16-bit network address.

The source IEEE address sub-field of the frame control field shall be set to 1, and the source IEEE
address field shall be set to the IEEE address of the device issuing the request.

The destination address field in the NWK header shall be set to the 16-bit network address of the
parent.

The destination IEEE address sub-field of the frame control field shall be set to 1, and the
destination IEEE address field shall be set to the IEEE address of the parent.

The radius field shall be set to 1.
NWK Payload Fields
Octets: 1
1
1
1
Sequence Number
Outgoing Cost
Incoming Cost
Delta Power Level
Sequence Number
The sequence number in the Verify Link Cost Response message shall be a copy of the value of the Verify
Link Cost Request.
Outgoing Cost
The local device shall find the entry in the nwkNeighborTable corresponding to the NWK destination of
this message. If not entry can be found, this message shall not be sent.
Submission
Page 10
NXP, Exegin
July, 2015
ZigBee-15-0276-03
The Outgoing Cost in the message shall be copied from the Outgoing Cost in the corresponding entry in the
nwkNeighborTable.
Incoming Cost
The incoming link cost is derived from the LQI of the last received packet find the entry in the
nwkNeighborTable corresponding to the NWK destination of this message. If not found the initial value
will be 0.
Delta Power Level
The Delta Power Level transmitted in the Verify Link Cost Response shall be the difference in dB between
the power level of the received Verify Link Cost Request and receivers optimal receive power level.
Link Status Modification
The link status command frame allows neighboring routers to communicate their incoming link costs to
each other as described in section 3.6.3.4. Link status frames are transmitted as one-hop broadcasts without
retries.
MAC Data Service Requirements
In order to transmit this command using the MAC data service, specified in IEEE 802.15.4-2003 [B1], the
following information shall be included in the MAC frame header:

The destination PAN identifier shall be set to the PAN identifier of the device sending the link
status command.

The destination address must be set to the broadcast address of 0xffff.

The source MAC address and PAN identifier shall be set to the network. address and PAN
identifier of the device sending the link status command.

The frame control field shall be set to specify that the frame is a MAC data frame with MAC
security disabled, since any secured frame originating from the NWK layer shall use NWK layer
security. Be-cause the frame is broadcast, no acknowledgment request shall be specified.

The addressing mode and intra-PAN flags shall be set to support the addressing fields described
here.
NWK Header Fields
The NWK header field of the link status command frame shall be set as follows:

The source IEEE address sub-field of the frame control field shall be set to 1 and the source IEEE
ad-dress field of the NWK header shall be present and shall contain the 64-bit IEEE address of the
origi-nator of the frame.

The destination address in the NWK header shall be set to the router-only broadcast address

The destination IEEE address sub-field of the frame control field shall have a value of 0 and the
desti-nation IEEE address field of the NWK header shall not be present.

The radius field shall be set to 1.
Submission
Page 11
NXP, Exegin
July, 2015
ZigBee-15-0276-03
Figure 3.21 Link Status Command Format
Octets: 1
Variable
0/Variable
Command options
Link status list
Power Link List
NWK command payload
Command Options Field
The format of the 8-bit command options field is shown in Figure 3.22.
Figure 3.22 Link Status Command Options Field
Bit: 0 – 4
5
6
7
Entry count
First frame
Last frame
Link Power Present
The entry count sub-field of the command options field indicates the number of link status entries present in the link
status list. The first frame sub-field is set to 1 if this is the first frame of the sender's link status. The last frame subfield is set to 1 if this is the last frame of the sender's link status. If the sender's link status fits into a single frame, the
first frame and last frame bits shall both be set to 1. The link power bit shall be set if Power Link List fields present
otherwise is zero.
Link Status List Field
Power Link List Field
Power Link Entry
1
Delta Power
Level
Delta Power Level
Submission
Page 12
NXP, Exegin
July, 2015
ZigBee-15-0276-03
The local device puts that value of the difference in dB between its optimal receive power level and the actual
received power level of the last packet received from the destination device into the Delta Power Level field of the
message.
The order of power link entries for each link is based on order of Link status list entries.
Submission
Page 13
NXP, Exegin