• 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

Lighting control systems support defining scenes, which act as user presets for the system states. Scenes define light levels for lighting zones (e.g., a normal scene, a room-cleaning scene, an overhead projection scene, etc.). Scenes may be recalled automatically (on schedule) or manually via user interaction.

The Basic Scene Selector NLC Profile specifies the requirements for a networked lighting control (NLC) product acting as a scene-selecting device in a Bluetooth mesh system. The Basic Scene Selector NLC Profile standardizes the use cases and implementation patterns of scene selectors to help improve interoperability and performance of systems based on Bluetooth mesh, such as networked lighting control systems.

A common use case for the Basic Scene Selector NLC Profile is a wall station device, which allows users to select and recall one or more scenes preconfigured in a lighting control system.

The Basic Scene Selector NLC Profile offers design flexibility with regards to the number of supported scenes: from single-scene selectors to multiple-scene selectors.

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

2.2. NLC profile relationships

A device implementing the Basic Scene Selector NLC Profile interacts with devices implementing the Basic Lightness Controller NLC Profile [4] as defined in Mesh Model [2] Section 6.5.1.3, “Scene Store and Scene Recall behavior”, and shown in Figure 2.1.

Interaction of a Basic Scene Selector with a Basic Lightness Controller
Figure 2.1. Interaction of a Basic Scene Selector with a Basic Lightness Controller

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 Basic Scene Selector 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 Scene Client model shall be supported. See Section 5.4.2 in [2].

  • The Scene Client model shall support publication of Scene Recall Unacknowledged messages with the Scene Number field set to each value in the range from 1 to N, where N shall be greater than 0 and N shall represent the total number of supported scenes by the device implementing the Basic Scene Selector NLC Profile. See Section 5.4.2.2.5 in [2].

  • The total number of supported scenes shall be included in Device Composition Data Page 2 in the Additional_Data field of the Mesh_Profile_Entry corresponding to the Basic Scene Selector NLC Profile, as defined in Table 3.1.

Field

Size
(octets)

Description

Number_Of_Scenes

2

Total number of scenes supported
Table 3.1. Format for the Additional_Data field (see section 4.2.2.6 in [1])

3.6. Combinations of NLC profiles

The following requirements are related to combinations of the Basic Scene Selector NLC Profile and combinations with other NLC profiles (see [3]):

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

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

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

  • When the Basic Scene Selector 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 [6].

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

  • When sending the Scene Client model messages, the Delay field should be used to support synchronous operation of luminaires. See Section 5.4.2.2.5 in [2] and Section 3.4 in [5].

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] Bluetooth SIG Assigned Numbers, http://www.bluetooth.com/specifications/assigned-numbers

[4] Basic Lightness Controller NLC Profile, Version 1.0

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

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