Bluetooth Mesh, Commercial Lighting and the Distributed Sensor Problem


The Bluetooth Mesh specification was recently been published which enables standards based interoperability for lighting systems.

The design point for this specification is a discrete sensor such as a manual switch or occupancy sensor on the wall or ceiling sending information to a group of fixtures; however, in commercial lighting the trend has been to integrate controls directly into fixtures. This sensor integration creates a new set of stresses on the network in coordinating the various sensors and thus challenges the 1,000 node scalability Bluetooth Mesh claims.

Discrete vs. Embedded Sensor Lighting Systems

Discrete Sensors

A discrete sensor lighting system has one set of sensors per group – typical sensors would include an occupancy sensor, an ambient light sensor for daylight harvesting and a manual switch for dimming and over-ride. The sensors may line driven or battery operated and thus need to conserve energy. Fixtures are treated only as actuators – simply receiving commands which tell them to change output levels or colors. Data flows uni-directionally from sensors to fixtures.

Distributed Sensors

Increasingly, lighting fixtures are being produced with embedded sensors and communications combining the sensors and actuator into a single product. Examples would increase the Cree Smartcast and Philips Spacewise families of fixtures which include PIR occupancy sensors, ambient light sensors, energy measurement and wireless communications.

Embedding the sensors in the fixtures decreases installation cost and simplifies the installation process. However, it greatly increases the demands on the lighting network in synchronizing group occupancy:

Transition from Vacant to Occupied State – a fixture in a vacant state senses movement

  • Fixture sends a broadcast of occupancy, all other fixtures in the group respond
  • No material change from discrete Sensor use case

Transition from Occupied to Vacant State – this occurs a “timeout” after the last fixture in a group sees motion

  • User expects all fixtures in a group to synchronize transition
  • Fixtures need to reach a Group Consensus
  • Group thus needs to coordinate, ie reach a Group Consensus, on when a vacancy transition occurs

When coordinating vacancy synchronization, the fixture that saw the motion first is not necessarily the fixture that sees the motion last – especially in a large group such as an open office configuration. The fixtures thus need to come to a Group Consensus on what the occupancy state of a group is. This requires orders of magnitude more bandwidth than the discrete sensor case.

How much Bandwidth do Discrete and Distributed Sensor Networks Require?

In this example lets assume we have 500 fixtures with an average group size of 10 (50 groups) and an occupancy timeout of 5 minutes creating 20 occupancy/vacancy events per day per group over 12 hours, 50% occupancy.

Discrete Sensor Use case

  • Occupancy – 20 events per sensor per day – 2 bytes
  • Vacancy – 20 events per sensor per day – 2 bytes
  • Ambient Light Adjustment – one event per 5s per sensor – 2 bytes

Integrated Sensor Use Case

Assume Ambient Light Sensing is not synchronized and each fixture responds to its own sensor.

  • Occupancy – 20 events per day per group – 2 bytes
  • Vacancy – simplistic case – each fixture sends occupancy data to reset timeout 1x per second

Could compression schemes be used to reduce data flow – certainly, but the point remains that Integrated Sensors dramatically increase demands on the lighting network to synchronize vacancy.

How much Data can a BLE Mesh Move – the “Managed Flood” approach

Bluetooth Mesh starts out with a 2Mbps PHY and unlike older mesh network standards like Zigbee, Bluetooth Mesh does not attempt to build and maintain mesh routing tables but rather uses a “Managed Flood” approach move data around the mesh. The managed flood approach has the advantage of being simple to implement, but the disadvantage of requiring some very thoughtful provisioning balance reliability and bandwidth efficiency.

Silabs developed a short video which explains the Managed Flood Approach here quite well.

Bluetooth Mesh devices with AC power (ie, lighting fixtures) can either be relays or nodes. When a relay hears a message, the relay retransmits it once. Nodes do not retransmit messages.

The Rub – Bluetooth Mesh Commissioning is Critical

Getting the right mix of relays and nodes in a Bluetooth Mesh is everything – too few relays and messages are not delivered reliably, too many relays and messages echo the mesh wasting bandwidth for far too long.

In fact, too many Relays in a Bluetooth Mesh can mean even personal Bluetooth devices may stop working in the space as the advertising channels get so congested your mouse or headset may not be able to find its partner.

Ericcson did an excellent whitepaper on this phenomena that I recommend,

The conclusion of this whitepaper is that in an indoor office environment, the optimal configuration is to have six relays for every 1,000m2 (equal to one for every 1,800 sq ft or about one out of every 18 lighting fixtures). Too few relays and messages don’t propagate, too many and messages get lost in the noise.

In the optimal mesh configuration, available bandwidth is 3 kbps which is <1% of the starting Bluetooth Mesh PHY Bandwidth of 2 Mbps.

To generalize, the available application bandwidth in a Bluetooth Mesh for a given Quality of Service (QoS) level falls inversely with the number of relays as shown below.

How to achieve and sustain optimal Bluetooth Mesh Commissioning at a site

Absent some tools or guidance to installers, the default would be to make all fixtures Bluetooth Mesh Relays. As detailed in the Ericsson whitepaper above, this would severely limit the scalability of a Bluetooth Mesh network to less than 49 fixtures!

This begs some key questions that have not yet been addressed in the commissioning process:

  • How does an installer decide which fixture should be Relays and which should be Nodes?
  • Commissioning of Relay vs. Node is vendor proprietary – how would an installer address this in a mixed install of different vendors’ fixtures?
  • Who maintains this Bluetooth Mesh network after the installer goes home? Walls and fixture move over time and circuits get turned on/off; sources of interference come and go in a commercial environment.

No standard provisions to support commissioning are provided in the current version of the Bluetooth Mesh Spec thus interoperability is challenged.

Leave a Reply

Your email address will not be published. Required fields are marked *