NLC Overview

NLC: Lighting and the Mesh

What is NLC?

When you design a new Bluetooth™ Mesh device, you want to make sure that it will work with every other device on your Bluetooth Mesh (e.g., Lights, Sensors, Fire system, Burglar alarms, etc.).  This is especially important for lighting, since you want to know that the light switch you purchased from company A will turn on/off/dim the lights you purchased from company B.

This is the reason that the NLC – Networked Lighting Control profiles were created.  They are specifications that define the minimum requirements for Bluetooth Mesh Lighting devices to ensure interoperability. discusses NLC here and here – this website is the primary source of the information for this blog post.

Why did we need NLC (or did we)?

If you are familiar with the various Bluetooth Mesh Lighting Models, you may wonder why the NLC profiles are needed.  I have implemented lots of Mesh switches, and they work great with all of the different Mesh luminaires.  After all, we know the Bluetooth Mesh team specifically designed the models to be interoperable in the first place, right?

Well, yes, that is true; the lighting models were specifically designed to allow various Mesh clients to work with the various Mesh servers.  But, when you read through the Bluetooth Mesh specifications [1][2], you will see that some things are required, but there are also optional features.  When one company implements a device, they make design decisions and feature tradeoffs in the implementation (e.g., because of cost, memory constraints, etc.) that could potentially make it difficult for another Mesh device to completely work (especially if the company making that device made a different set of feature tradeoffs).

Example: Company Z makes a Mesh switch with buttons to turn on/off 4 different zones.  There are 3 different rooms to control, and each room is assigned a button (buttons 1-3).  Button 4 is then configured to be the button to turn on/off the lights in the whole building.  This requires that each light has two available subscription entries: 1) to listen to the button for the whole building, 2) to listen to the button for the room.
Unfortunately, after all of the various sensors and other devices are configured, they find that Company A’s Mesh light’s subscription list has only one available entry left.  So the user is disappointed, unable to control the rooms independently for the whole building.

It turns out, there is a minimum set of features that all Mesh lighting devices need to support to ensure that they can all work reliably together.   These are embodied in the NLC profiles.

What Does NLC Actually Specify?

There are many details in each of the profiles – some of the highlights are mentioned below – more gory details are in the “Details” section below.

There are currently several NLC profiles defined:

  • ALS: Ambient Light Sensor -This is a sensor device that detects and reports ambient light levels (brightness).  That reported light level can be used by a sensor client or a lighting controller.  An ALS NLC device must:
    • implement the Bluetooth Mesh Sensor Server model [2] and must report the Present Ambient Light Level.
    • implement calibration (calibrating a light sensor assures that the light level reported is a viable and usable value).  The implementation must allow a Sensor client to send a command to set either the Present Ambient Light Level or the Sensor Gain.  See section 3.5 of [3]
  • BLC: Basic Lightness Controller –
    This is a device that acts as a lighting controller (known as an LC server).  Each LC server can change the luminaire’s brightness based the amount of ambient light, any detected occupancy/motion, various on/off/dimming/scene commands (e.g., from a switch), or elapsed time.  A BLC NLC device must:
    • implement the Light LC Server model with at least one scene server model (which must be able to contain the Light Lightness server model element) [2].
    • assure that additional models (other lighting models such as CTL/HSL or additional scene server models) are on higher element addresses (i.e., so they will not interfere with the other elements).
  • BSS: Basic Scene Selector
    This is a device that allows a user to pick a Scene (user preset for lighting levels) – this is often a wall switch with some number of buttons corresponding to multiple scenes.  A BSS NLC device must:
    • implement a Scene Client model [2].
    • implement the Scene Recall Unacknowledged command supporting at least 1 scene.  This allows a switch to tell lights to restore a specific set of lighting values.
  • DIC: Dimmer controller
    This is a device that controls the brightening or dimming of the luminaire’s light level.  This is often a wall mounted switch with a button or rocker switch to brighten/dim.  A DIC NLC device must:
    •  implement the Generic Level Client model [2].
    • implement the Generic Delta or Generic Move Set Unacknowledged command.
  • ENM: Energy Monitor
    This is a sensor device that detects and reports energy consumption.  A ENM NLC device must:
    •  implement the Sensor Server model [2] and report the Precise Total Device Energy Use.
  • OCS: Occupancy Sensor
    This is a sensor device that detects if anyone is in the area.  This allows for saving energy by turning down/off lighting levels when no one is around.  Different detection methods can be used: motion, presence, or counting the number of occupants.  A OCS NLC device must:
    • implement the Sensor Server model with only one of the sensing methods (motion, presence, counting).
    • allow the writing of the Motion Threshold if the device allows the sensitivity to be set.

More Details

There are several requirements that are common to all of the NLC profiles (ALS, BLC, BSS, DIC, ENM, OCS):

  • PB-GATT provisioning is required.  This permits mobile devices (e.g., phones) to add a device into the Mesh.  Phones generally don’t natively support the Mesh protocol, so the PB-GATT provisioning allows a mobile device to do a standard BLE connection and send Mesh commands for provisioning.
  • The advertising scan response must include the Complete or shortened Local name.  The local name is a string that can help identify the device in a human-readable way.  When an advertisement is sent, a scanning device can request more information, and the response from the advertiser must provide that string .
  • Visual attention indication must be supported.  When a user wants to add a device into the Mesh, a flashing LED (or some other visual indication) allows the user to see which device they are selecting to add.
  • Advertising bearer – this is the standard Bluetooth mesh communication – via advertising packets.
  • GATT Bearer – this is the communication method used by mobile devices – using GATT.
  • Relay and Proxy features shall be supported:
    • Relay: a device that retransmits Mesh communication packets (Mesh uses a managed flood technique to communicate data across the entire mesh). 
    • Proxy: relays the messages between the advertising and GATT bearers.
  • There must be at least 2 network keys supported, as well as 3 application keys, 32 entries in the replay protection list (255 for the BLC), 8 entries in the proxy filter list, 64 entries in the network message cache.   These are the various variables/arrays that are part of the Mesh and its security.  These minimum values make it possible for Mesh nodes to be able to interact without running out of space.
  • Note that the BLC NLC profile specifies that the Light LC server model shall support a subscription list size of 32 items or more.  This allows a user to configure the LC server to listen to sensor data, scene commands, light switches, etc.

And the NLC profiles give some recommendations, e.g.:

  • If a device allows a factory reset to default settings, a manual reset should be supported (physical interaction).  There’s nothing more annoying than a confused device that needs to be factory reset to start over, and if you can’t connect to it remotely with a phone to do a reset, a physical reset on the device is a lifesaver.
  • If the device supports a power-up blinking sequence when unprovisioned, it should use the DiiA part 341 Unprovisioned Blinking Sequence (DALI). [9]. An unprovisioned power-up blinking sequence makes it obvious to the user which devices still need to be added to the mesh network.
  • Use delays to avoid the “popcorn effect” to support synchronized luminaire lighting changes.  The popcorn effect is when various lights in the Mesh turn on or off at different times based on when the on/off command is received.  Sending a series of commands with decreasing delays can help prevent this.
  • When there is a device that implements multiple NLC profiles, the overriding rule seems to be that the number of entries for replay protection, network keys, and application keys must encompass the highest number of entries required by the included NLC profiles – a superset, in essence.

And there you have it!

Well, that’s the overview (and the gory details).  Hopefully that helped give a summary of the highlights and utility of NLC in making life interoperable in the Bluetooth Mesh.  

Are you interested in developing Bluetooth Mesh Products?  Feel free to contact us here at Ambient Sensors.  We’re happy to talk about what we can do to help your company.  We provide design and development services in hardware, firmware, mobile app, and cloud design.  We also have an RF chamber and can provide FCC pre-certification testing.


  1. Mesh Protocol Specification, Version 1.1 or later
  2. Mesh Model Specification, Version 1.1 or later
  3. ALS: Ambient Light Sensors NLC Profile, Version 1.0
  4. BLC: Basic Lightness Controller NLC Profile, Version 1.0
  5. BSS: Basic Scene Selector NLC Profile, Version 1.0
  6. DIC: Dimmer controller NLC Profile, Version 1.0
  7. ENM: Energy Monitor NLC Profile, Version 1.0
  8. OCS: Occupancy Sensor NLC Profile, Version 1.
  9. Digital Illumination Interface Alliance (DiiA), “Part 341 – Bluetooth Mesh to DALI Gateway”, link 

Learn how we helped 100 top brands gain success