• Version: v1.0

  • Version Date: 2023-09-12

  • Prepared By: Mesh Working Group

Version History

Version Number

Date
(yyyy-mm-dd)

Comments

v1.0

2023-09-12

Adopted by the Bluetooth SIG Board of Directors.

Acknowledgments

Name

Company

Simon Slupik

Silvair, Inc.

Omkar Kulkarni

Nordic Semiconductor ASA

Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.

Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”

Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.

Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.

Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.

Copyright © 2022–2023. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.

1. Introduction

Sensor-based control systems can increase energy savings by turning off or dimming the lights when rooms are unoccupied and/or by adjusting the temperature setpoints to prevent excessive cooling or heating. To verify the effectiveness of such systems, energy consumption is monitored.

The Energy Monitor NLC Profile specifies the requirements for a networked lighting control (NLC) product acting as an energy monitor in a Bluetooth mesh system. The Energy Monitor NLC Profile standardizes the use cases and implementation patterns of energy-monitoring devices to help improve interoperability and performance of systems based on Bluetooth mesh, such as networked lighting control systems or sensor networks.

A common use case for the Energy Monitor NLC Profile is a sensor reporting energy consumption. This energy-monitoring sensor may include a circuit that can measure the consumed energy, or the sensor may read the energy data from another device, such as an LED driver that reports energy consumption over a Digital Addressable Lighting Interface (DALI) bus (see [5]).

1.1. Language

1.1.1. Language conventions

In the development of a specification, the Bluetooth SIG has established the following conventions for use of the terms “shall”, “shall not”, “should”, “should not”, “may”, “must”, and “can”. In this Bluetooth specification, the terms in Table 1.1 have the specific meanings given in that table, irrespective of other meanings that exist.

Term

Definition

shall

—used to express what is required by the specification and is to be implemented exactly as written without deviation

shall not

—used to express what is forbidden by the specification

should

—used to express what is recommended by the specification without forbidding anything

should not

—used to indicate that something is discouraged but not forbidden by the specification

may

—used to indicate something that is permissible within the limits of the specification

must

—used to indicate either:

  1. an indisputable statement of fact that is always true regardless of the circumstances

  2. an implication or natural consequence if a separately-stated requirement is followed

can

—used to express a statement of possibility or capability
Table 1.1. Language conventions terms and definitions

1.1.1.1. Implementation alternatives

When specification content indicates that there are multiple alternatives to satisfy specification requirements, if one alternative is explained or illustrated in an example it is not intended to limit other alternatives that the specification requirements permit.

1.1.1.2. Discrepancies

It is the goal of Bluetooth SIG that specifications are clear, unambiguous, and do not contain discrepancies. However, members can report any perceived discrepancy by filing an erratum and can request a test case waiver as appropriate.

1.1.2. Reserved for Future Use

Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.

Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.

When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.

The acronym RFU is equivalent to Reserved for Future Use.

1.1.3. Prohibited

When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.

Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.

“Prohibited” is never abbreviated.

1.2. Table requirements

Requirements in this specification are defined as "Mandatory" (M), "Optional" (O), "Excluded" (X), “Not Applicable” (N/A), or "Conditional" (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.

1.3. Conformance

Each capability of this specification shall be supported in the specified manner. This specification may provide options for design flexibility, because, for example, some products do not implement every portion of the specification. For each implementation option that is supported, it shall be supported as specified.

2. Configuration

2.1. Identification

The Energy Monitor NLC Profile shall be identified by the «Energy Monitor» mesh profile UUID (see [4]) in Composition Data Page 2 (see [1]).

2.2. NLC profile relationships

Data produced by a device implementing the Energy Monitor NLC Profile can be consumed and processed by any device implementing the Sensor Client model as defined in Mesh Model [2] Section 4.4.1.2.12, “Receiving a Sensor Status message”, and shown in Figure 2.1.

Interaction of an Energy Monitor with a Sensor Client
Figure 2.1. Interaction of an Energy Monitor with a Sensor Client

2.3. Concurrency limitations and restrictions

There are no concurrency limitations or restrictions imposed by this specification.

2.4. Topology limitations and restrictions

There are no topology limitations or restrictions imposed by this specification.

2.5. Bluetooth specification release compatibility

This specification is compatible with Mesh Protocol Version 1.1 [1] and Mesh Model Version 1.1 [2].

2.6. Mesh Protocol dependencies

This specification requires implementation of all mandatory requirements for an unprovisioned device and a node described in the Mesh Protocol specification [1].

3. Requirements and recommendations

The Energy Monitor NLC Profile specifies the following requirements and recommendations.

3.1. Provisioning

The following requirements are related to provisioning:

  • The PB-GATT provisioning bearer shall be supported. See Section 5.2.2 in [1].

  • Either the device «Complete Local Name» advertising data (AD) type or the device «Shortened Local Name» AD type shall be included in scan response data when advertising the Mesh Provisioning Service. See Section 7.1.2.2.1 in [1].

  • Visual attention indication for all instances of the Attention Timer shall be supported. The visual attention indication may be shared among multiple instances of the Attention Timer. See Section 4.2.10 in [1].

3.2. Bearers

The following requirements are related to bearers:

  • The advertising bearer shall be supported. See Section 3.3.1 in [1].

  • The Generic Attribute Profile (GATT) bearer shall be supported in the GATT Bearer Server role. See Section 3.3.2 in [1].

3.3. Features

The following requirements are related to features:

  • The Relay feature shall be supported. See Section 3.4.6.1 in [1].

  • The Proxy feature shall be supported. See Section 3.4.6.2 in [1].

3.4. Performance

The following requirements are related to performance:

  • At least two network keys shall be supported. See Section 3.9.6.3 in [1].

  • At least three application keys shall be supported. See Section 3.9.6.2 in [1].

  • At least 32 entries in the replay protection list shall be supported. See Section 4.2.2.1 in [1].

  • At least 8 entries per connection in the proxy filter list shall be supported. See Section 6.4 in [1].

  • At least 64 entries in the network message cache shall be supported. See Section 3.4.6.5 in [1].

3.5. Models

The following requirements are related to models:

  • The Sensor Server model shall be supported. See Section 4.3.1 in [2].

  • The Sensor Descriptor state shall include a Sensor Property ID field value referencing the Precise Total Device Energy Use device property. See the Precise Total Device Energy Use device property in [3].

3.6. Combinations of NLC profiles

The following requirements are related to combinations of the Energy Monitor NLC Profile and combinations with other NLC profiles (see [4]):

  • When multiple instances of the Energy Monitor NLC Profile are combined on a device, the number of entries in the replay protection list on the device shall be at least the number of entries in the replay protection list required by the Energy Monitor NLC Profile. See Section 4.2.2.1 in [1].

  • When the Energy Monitor NLC Profile is combined with other NLC profiles on a device, the number of entries in the replay protection list on the device shall be at least the highest required minimum number of entries among the NLC profiles. See Section 4.2.2.1 in [1].

  • When multiple instances of the Energy Monitor NLC Profile are combined on a device, the device shall support at least the minimum number of network keys defined for the Energy Monitor NLC Profile. See Section 3.9.6.3 in [1].

  • When the Energy Monitor NLC Profile is combined with other NLC profiles on a device, the device shall support at least the highest minimum number of network keys defined among the NLC profiles. See Section 3.9.6.3 in [1].

  • When multiple instances of the Energy Monitor NLC Profile are combined on a device, the device shall support at least the minimum number of application keys defined for the Energy Monitor NLC Profile. See Section 3.9.6.2 in [1].

  • When the Energy Monitor NLC Profile is combined with other NLC profiles on a device, the device shall support at least the highest minimum number of application keys defined among the NLC profiles. See Section 3.9.6.2 in [1].

3.7. Recommendations

Implementers should consider the following recommendations:

  • If a blinking sequence on power-up in the unprovisioned state is supported, then it should be the Unprovisioned Blinking Sequence defined by the DiiA Part 341 specification [5].

  • If a reset to factory default settings is supported, then a manual reset (i.e., physical interaction with the device) should be supported.

  • For the Sensor Property ID fields for the instances of the Sensor Descriptor state, values other than the value referencing the Precise Total Device Energy Use should not be present on the Sensor Server model for the Energy Monitor Sensor NLC Profile. See Section 4.1.1 in [2] and the Precise Total Device Energy Use device property in [3].

4. Acronyms and abbreviations

Acronym/Abbreviation

Meaning

AD

advertising data

DALI

Digital Addressable Lighting Interface

GATT

Generic Attribute Profile

NLC

networked lighting control

PDU

Protocol Data Unit

RFU

Reserved for Future Use
Table 4.1. Acronyms and abbreviations

5. References

Bibliography

[1] Mesh Protocol Specification, Version 1.1 or later

[2] Mesh Model Specification, Version 1.0.1 or later

[3] Device Properties

[4] Bluetooth SIG Assigned Numbers, http://www.bluetooth.com/specifications/assigned-numbers

[5] Digital Illumination Interface Alliance (DiiA), “Part 341 – Bluetooth Mesh to DALI Gateway”, https://www.dali-alliance.org/specifications/download.html