• 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

The light level reported by ambient light sensors can be used to turn off or dim down the lights to save energy when daylight is sufficient.

The Ambient Light Sensor NLC Profile specifies the requirements for a networked lighting control (NLC) product acting as an ambient light sensor in a Bluetooth mesh system. The Ambient Light Sensor NLC Profile standardizes the use cases and implementation patterns of ambient light sensors 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 Ambient Light Sensor NLC Profile is a sensor reporting the ambient light level in a given space.

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 Ambient Light Sensor NLC Profile shall be identified by the «Ambient Light Sensor» mesh profile UUID (see [4]) in Composition Data Page 2 (see [1]).

2.2. NLC profile relationships

A device implementing the Ambient Light Sensor NLC Profile interacts with devices implementing the Basic Lightness Controller NLC Profile [5] as defined in Mesh Model [2] Section 6.5.1.7.1, “Receiving a Sensor Status message”, and shown in Figure 2.1.

Interaction of an Ambient Light Sensor with a Basic Lightness Controller
Figure 2.1. Interaction of an Ambient Light Sensor with a Basic Lightness Controller

Note: See Section 6.2.2 in [2] and Section 9 in [6] for a broader discussion on lighting control scenarios utilizing an ambient light sensor.

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 Ambient Light Sensor 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 Present Ambient Light Level device property.

    Other values for the Sensor Property ID fields for the instances of the Sensor Descriptor state shall not be present on the Sensor Server model for the Ambient Light Sensor NLC Profile. See Section 4.1.1 in [2] and the Present Ambient Light Level property in [3].

  • The Sensor Setting state shall include Sensor Property ID fields referencing the following device properties:

    • A value referencing the Present Ambient Light Level device property and the value of the Sensor Setting Access field equal to 0x03 (read/write).

    • A value referencing the Sensor Gain device property and the value of the Sensor Setting Access field equal to 0x03 (read/write).

    See Section 4.1.2 in [2], the Present Ambient Light Level property in [3], and the Sensor Gain property in [3].

  • An ambient light sensor shall support calibration, which consists of the following prerequisites, formula, and methods:

    Prerequisites: The following prerequisites shall be supported:

    • The sensor is installed and provisioned in the target environment.

    • The ambient light level remains constant during the calibration procedure.

    • The ambient light level is measured using a reference meter.

    Formula: The Present Ambient Light Level reported by the sensor in the Sensor Status message shall be calculated using the following formula:

    [ v a l u e   r e p o r t e d   b y   t h e   s e n s o r ]   =   [ s e n s o r   g a i n ]   x   [ v a l u e   r e a d   b y   t h e   s e n s o r ]

    where:

    • [value reported by the sensor] is the value of the Present Ambient Light Level property referenced by the Sensor Property ID field of the Sensor Descriptor state;

    • [sensor gain] is the value of the Sensor Gain property referenced by the Sensor Setting Property ID field of the Sensor Setting State;

    • [value read by the sensor] is the value read internally by the sensing apparatus.

    Methods: The following two methods shall be supported:

    1. A user measures the ambient light level using a reference meter. The measured ambient light level value is written to the sensor by sending the Sensor Setting Set message or the Sensor Setting Set Unacknowledged message, setting the Sensor Property ID field to the value identifying the Present Ambient Light Level property, the Sensor Setting Property ID field to the value identifying the Present Ambient Light Level property, and the Sensor Setting Raw field to the measured ambient light level value. Upon receiving the message, the sensor shall calculate and update the [sensor gain] such that the [value reported by the sensor] matches the measured ambient light level value.

    2. The value of the [sensor gain] is written to the sensor by sending the Sensor Setting Set message or the Sensor Setting Set Unacknowledged message, with the Sensor Property ID field identifying the Present Ambient Light Level property, the Sensor Setting Property ID field identifying the Sensor Gain device property, and the Sensor Setting Raw field set to the [sensor gain] value.

3.6. Combinations of NLC profiles

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

  • When multiple instances of the Ambient Light Sensor 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 Ambient Light Sensor NLC Profile. See Section 4.2.2.1 in [1].

  • When the Ambient Light Sensor 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 Ambient Light Sensor NLC Profile are combined on a device, the device shall support at least the minimum number of network keys defined for the Ambient Light Sensor NLC Profile. See Section 3.9.6.3 in [1].

  • When the Ambient Light Sensor 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 Ambient Light Sensor NLC Profile are combined on a device, the device shall support at least the minimum number of application keys defined for the Ambient Light Sensor NLC Profile. See Section 3.9.6.2 in [1].

  • When the Ambient Light Sensor 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 [7].

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

4. Acronyms and abbreviations

Acronym/Abbreviation

Meaning

AD

advertising data

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.1 or later

[3] Device Properties

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

[5] Basic Lightness Controller NLC Profile, Version 1.0

[6] Building a Sensor-Driven Lighting Control System Based on Bluetooth Mesh – Bluetooth White Paper, Version 1.0

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