• 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 occupancy status reported by occupancy sensors can be used to turn off or dim down the lights to save energy when rooms are unoccupied.

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

The Occupancy Sensor NLC Profile supports three methods of occupancy detection and reporting:

  • Sensing motion. This is the most common method, usually based on passive infrared (PIR) sensing, in which the sensor detects the motion of an object (such as a human body). When motion is detected, the space monitored by the sensor is considered occupied for a certain time. This time is not defined by the sensor, but instead by a model receiving the sensor messages.

  • Sensing presence. This method assumes the sensor can detect both presence (occupancy) and absence (vacancy).

  • People-counting. This method assumes the sensor can count (and report) the number of occupants in the space monitored by the sensor.

An occupancy sensor may support a sensitivity setting (see Section 3.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 Occupancy Sensor NLC Profile shall be identified by the «Occupancy Sensor» mesh profile UUID (see [4]) in the Composition Data Page 2 (see [1]).

2.2. NLC profile relationships

A device implementing the Occupancy Sensor NLC Profile interacts with a device 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 Occupancy Sensor with a Basic Lightness Controller
Figure 2.1. Interaction of an Occupancy Sensor with a Basic Lightness Controller

Note

Note: See Section 6.2.2 in [2] and 9 in [6] for a broader discussion on lighting control scenarios using an occupancy 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 Occupancy 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 with only one of the following:

    • A Sensor Property ID field value referencing the Motion Sensed device property shall be included and a Sensor Property ID field value referencing the Time Since Motion Sensed device property should be included (see Section 3.7)

    • A Sensor Property ID field value referencing the People Count device property shall be included

    • A Sensor Property ID field value referencing the Presence Detected device property shall be included

    Other values for the Sensor Property ID fields for the instances of the Sensor Descriptor state shall not be included on the Sensor Server model for the Occupancy Sensor NLC Profile. See Section 4.1.1 in [2] and the Occupancy property group in [3].

  • If setting the sensitivity for occupancy detection is supported, and the Sensor Descriptor state references the Motion Sensed or the Presence Detected device property, then the Sensor Setting state with the Sensor Property ID field referencing the Motion Threshold device property and the value of the Sensor Setting Access field equal to 0x03 (read/write) shall be included. See Section 4.1.2 in [2] and the Occupancy property group in [3].

3.6. Combinations of NLC profiles

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

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

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

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

  • When the Occupancy 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.

  • If a value of the Sensor Property ID field on a Sensor Server references the Motion Sensed device property, then a value of another instance of the Sensor Property ID field on this Sensor Server should reference the Time Since Motion Sensed device property to enable the behavior defined in Section 6.5.1.7.1, “Receiving a Sensor Status message”, in [2]. See Section 4.1.1 in [2] and the Occupancy property group in [3].

4. Acronyms and abbreviations

Acronym/Abbreviation

Meaning

AD

advertising data

GATT

Generic Attribute Profile

NLC

networked lighting control

PDU

Protocol Data Unit

PIR

passive infrared

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