Take the Fast Track to Bluetooth 5 Mesh Networking

Contributed By Digi-Key's North American Editors

With the availability of mesh networking capability for Bluetooth 5, developers can enhance the range and network availability of wirelessly connected systems, such as IoT devices. However, mesh networking has layers of complexity between low-power wireless hardware design and mesh networking software development that can quickly entangle developers and jeopardize project schedules.

As Bluetooth 5-enabled smartphones and other mobile platforms emerge, time becomes a critical factor as developers will need to respond rapidly to an expected explosion in demand for Bluetooth mesh networking capability across almost every industry segment and application. In response, silicon and software vendors are introducing solutions to simplify and accelerate the development process.

This article will outline the rationale for Bluetooth mesh networking, and then step through the process of development using a specific device from Silicon Labs’ mesh capable Bluetooth 5 module line. Using such an integrated Bluetooth 5 solution, developers can quickly deploy connected devices and applications able to take full advantage of Bluetooth mesh networking.

The article concludes with a description of the Silicon Labs Bluetooth mesh software development package, including a detailed look at the event-driven model demonstrated using sample mesh application code.

The need for Bluetooth mesh

Bluetooth mesh goes beyond the point-to-point connection capability of traditional Bluetooth technology. By relaying messages through neighboring connected devices, Bluetooth mesh extends the effective reach of low-power devices beyond the actual range afforded by their transmitter power output and receiver sensitivity. Most importantly, Bluetooth mesh leverages the widespread familiarity with Bluetooth-enabled apps on smartphones and other mobile devices, providing a natural progression for more sophisticated mesh connected applications.

With mesh support, developers using Bluetooth now have a powerful ability to easily connect large numbers of devices for home automation, building management, and any number of IoT applications.

How Bluetooth mesh works

Bluetooth mesh uses a conceptually simple model of interaction among nodes in a network (Figure 1). Specialized node types provide additional capabilities needed to relay messages between nodes, extending the effective range of a network that interacts through a proxy node with a Bluetooth enabled mobile device.

Image of Bluetooth mesh networkFigure 1: Along with basic edge nodes, a Bluetooth mesh network can use special node types to pass messages for other nodes (relay), serve as a cache (friend) for low-power nodes, or connect the network (proxy) to a Bluetooth enabled mobile device. (Image source: Silicon Labs)

Other specialized node types address requirements for reduced power, using friend nodes to cache messages that low-power nodes periodically poll between extended sleep states. Even with this added functionality, Bluetooth mesh devices can nevertheless use Generic Attribute Profile (GATT) services to connect with legacy devices using earlier versions of Bluetooth. Thus, mesh devices can take full advantage of existing Bluetooth low energy (BLE) capabilities such as beacons for generating area specific messages to smartphones, or identifying themselves to asset management applications.

Bluetooth mesh also addresses growing concerns for security in protected networks needed in building automation or other IoT applications. Unlike BLE where security is optional to protect a single device, Bluetooth mesh imposes security in an attempt to protect the mesh network as a whole.

Bluetooth’s approach to mesh security is particularly interesting. Its security scheme introduces the concept of separation of concerns to mesh networking, using separate security measures for each device, the network, and the overall application. A private device key (DevKey) associated with each device provides security for operations such as configuration and provisioning that involve that node alone. Each device needs a network key (NetKey) to communicate with other nodes in a network or subnet. Finally, application level interactions, such as sending a message to turn on a light, require an application key (AppKey). Other security measures guard against common threats such as man-in-the-middle or replay attacks. In combination, the security mechanisms in Bluetooth mesh provide a critical foundation of trust needed for more sophisticated IoT applications.

Implementing a Bluetooth mesh connected application nevertheless presents significant difficulties for developers. Most applications using mesh networking build on power limited devices, relying on the mesh network to extend the effective reach of low-power radio subsystems. The challenges involved in creating suitable mesh ready low-power hardware devices can stall even the most experienced hardware developer. Even after completing their custom Bluetooth designs, developers can face significant costs and protracted delays in meeting national certification requirements. Software developers face their own delays in finding compatible Bluetooth mesh stacks and using them to build software layers able to support their own applications. With Bluetooth hardware and software from Silicon Laboratories, however, developers can rapidly deploy Bluetooth mesh functionality in low-power devices for their own applications.

Bluetooth module

Silicon Labs’ Bluetooth mesh solution builds on its low-power Bluetooth BGM13P hardware module, which combines a wireless processor and a full Bluetooth stack to provide a complete, certified Bluetooth system in a 12.9 × 15.0 × 2.2 mm package. At the heart of the module, an EFR32BG13 Blue Gecko wireless system-on-chip (SoC) provides the core functionality. The EFR32BG13 SoC combines a 32-bit Arm® Cortex®-M4 core, a 2.4 GHz radio subsystem, 512 Kbytes of flash, 64 Kbytes of RAM, and an extensive complement of analog and digital peripherals. Along with an on-chip hardware crypto accelerator, the SoC supports the growing demand for tighter security with a security management unit that provides the same kind of granular access control to peripherals as the memory protection unit provides to memory.

The EFR32BG13 SoC can serve as the foundation for custom Bluetooth hardware designs. In using the SoC, developers take on responsibility not only for design requirements such as SoC support circuitry, but also for required certification on the completed design. The module delivers a fully certified design that includes the EFR32BG13 with the required support circuits including several oscillator sources, two crystals, and port drivers. At the same time, the module provides a range of power saving features that let developers respond to continual demand for lower power devices.

The module consumes only 87 microamps (µA)/MHz in active mode and 1.4 μA in deep sleep mode with full RAM retention. To help maximize time spent in that low-power deep sleep mode, engineers can take advantage of features including a low energy sensor interface and low energy timer, among others. Using the low energy sensor interface, engineers can program the module’s integrated finite state machine and analog peripherals to acquire and process sensor signals while the processor remains in deep sleep mode. Similarly, the low energy timer lets engineers output simple waveforms and monitor the real-time clock/counter to perform actions at designated periods without processor involvement.

Of course, power consumption in wireless devices generally depends on the efficiency of the radio subsystem. In this case, the module’s 2.4 GHz radio subsystem consumes only 9.9 milliamps (mA) in receive mode and 8.5 mA in transmit mode at 0 dBm output power. Even so, the module provides an additional feature for power savings through RF control. Developers can program an RF sense feature in the module to wake the processor when wideband RF energy is detected. Using this approach, developers can keep the module in deep sleep during periods of inactivity without loss of communications. As noted earlier, however, developers can also configure a device to act as a Bluetooth 5 low-power node that simply wakes periodically from deep sleep to poll a friend node for cached messages.

System development

For all its features, the module presents little difficulty in implementation. Developers can simply drop the module into a design with an existing processor for use as a Bluetooth network coprocessor (Figure 2A). Alternatively, developers can use the module as a complete system solution (Figure 2B). In this standalone mode, developers can run their application code on the module’s EFR32BG13 processor and use the EFR32BG13’s integrated analog and digital peripherals for signal acquisition in a simple IoT design.

Diagram of Silicon Labs BGM13P module as a Bluetooth coprocessor for a host CPU and aloneFigure 2: Designers can use the BGM13P module as a Bluetooth coprocessor for a host CPU (A), or use it alone (B), taking advantage of the module’s integrated EFR32BG13 SoC for application program execution and even sensor data acquisition. (Image source: Silicon Labs)

Developers can simplify their Bluetooth design further by using the BGM13P22F512GA-V2, a version of the module that includes an integrated antenna. For designs targeting a more challenging RF environment, developers can turn to the BGM13P22F512GE-V2, a version with a U.FL connector for attaching a Bluetooth-compatible flat patch antenna, such as the FXP74.07.0100A from Taoglas.

Silicon Labs eliminates even that level of hardware implementation with its SLWSTK6101C development kit. Designed to work with plug-in boards for its different Bluetooth devices, the SLWSTK6101C provides a representative IoT design which includes Macronix’s MX25R8035F 8 Mbit flash, Sharp Microelectronics’ LS013B7DH03 128 x 128 LCD, and Silicon Labs’ Si7021 temperature and humidity sensor. In this case, developers plug the SLWRB4306A wireless radio board which includes the BGM13P module into the SLWSTK6101C board.

Besides being a production-ready design, the completed board set provides a proven reference design that engineers can use to examine different approaches for interfacing devices such as the flash, the LCD, and the sensor.

For example, while the 8 Mbit flash and LCD connect to the module through its SPI bus, the Si7021 sensor’s I2C interface shares the bus with an external header on the development board. Silicon Labs demonstrates a method for designing a simple interface that keeps the sensor normally disabled and electrically isolated from that shared bus. When the module’s PD15 input goes high, the SENSOR_ENABLE output goes high, connecting the sensor to the 3.3 V VMCU power rail and the I2C bus (Figure 3).

Diagram of Silicon Labs Si7021 sensorFigure 3: Besides providing a hardware evaluation platform, the Silicon Labs SLWSTK6101C development kit serves as a reference design, illustrating methods for interfacing with an external device such as the Silicon Labs Si7021 sensor shown here. (Image source: Silicon Labs)

The shared I2C bus header is only one of several features designed to support development with this platform (Figure 4). Along with an on-board J-Link debugger, the board provides a packet trace interface (PTI) that lets engineers analyze packets in detail. The PTI builds on a packet and state trace unit built into the EFR32BG13 SoC to provide non-intrusive capture of all packets sent and received by the system. For analyzing complex protocols such as Bluetooth mesh, this packet trace capability provides a tool that can be critical for optimization and tuning of low-level network communications.

Diagram of Silicon Labs SLWSTK6101C kitFigure 4: The Silicon Labs SLWSTK6101C kit brings out multiple interfaces for packet trace, energy monitoring, and low-level Arm Embedded Trace Macrocell (ETM) trace, providing engineers with a rich set of tools for deep analysis of design operation and performance. (Image source: Silicon Labs)

While network experts need capabilities like the PTI for network optimization, system developers need tools able to help them identify application inefficiencies that can lead to excess power consumption. For this kind of application-level power optimization, the Silicon Labs Simplicity Studio energy profiler provides code-level analysis of power consumption.

As with the packet trace tool, the energy profiler takes advantage of underlying hardware. In this case, the board includes a dedicated energy monitor circuit comprising a current sensor resistor, a current sense amplifier, and gain stages that deliver their output to the board’s controller for access by a development host system (Figure 5). Parallel gain stages allow the energy monitor to measure current between 0.1 μA to 95 mA at two different resolution levels: 0.1 mA resolution above 250 μA; and 1 μA resolution below the 250 μA threshold.

Diagram of Silicon Labs BGM13P Bluetooth moduleFigure 5: Built into the BGM13P Bluetooth module, a dedicated energy monitor circuit and processing controller can provide non-invasive current measurement from 0.1 μA to 95 mA. (Image source: Silicon Labs)

While the energy monitor circuit generates current measurements, low-level trace mechanisms built into the EFR32BG13 can periodically sample the processor’s program counter, and output the results on the device’s serial wire output pin. By combining the results of the energy monitor and this program trace output, the energy profiler can provide a real-time display of energy consumption linked to code running on the device (Figure 6).

Image of Silicon Labs Simplicity Studio energy profilerFigure 6: The Simplicity Studio energy profiler combines energy monitor output with program trace data to provide a real-time display of current consumption linked to actual code. (Image source: Silicon Labs)

Mesh application development

While hardware engineers can use the dev kit to optimize their hardware designs, software developers can take advantage of Silicon Labs’ comprehensive software development environment to rapidly create mesh networked applications. Provided with Simplicity Studio, Silicon Labs’ Bluetooth 5 mesh stack extends the basic Bluetooth stack with specific mesh resources. As a result, developers can move easily from more conventional Bluetooth protocols, such as beacon or point-to-point communications, to full mesh topologies (Figure 7).

Image of Silicon Labs Bluetooth mesh stackFigure 7: The Silicon Labs Bluetooth mesh stack extends earlier Bluetooth functionality (blue) with mesh layers (green), enabling developers to take advantage of the full range of Bluetooth features from beacon to full mesh configurations. (Image source: Silicon Labs)

Used with the Silicon Labs BGM13P-based SLWRB4306A and SLWSTK6101C development board, Simplicity Studio lets developers configure their environment with the appropriate software development kits (SDKs). For Bluetooth development, the Studio provides Silicon Labs’ Bluetooth mesh SDK along with pre-built demo binaries and source code. Within this environment, developers can work with sample code that implements a complete Bluetooth mesh application.

Designed to demonstrate operations in a Bluetooth mesh network, the sample applications work with the development board and a mobile app to walk the developer through typical mesh operations including provisioning, configuration, and application-related usage. To deploy the sample application, engineers run Simplicity Studio against a set of dev boards separately configured to serve as a light or a switch in a connected lighting application. By working with the sample code and hardware, engineers can gain a better understanding of each operational phase of a typical mesh application starting with device power up.

With Silicon Labs’ software architecture, Bluetooth operations proceed as a series of events, using predefined event IDs that signal the nature of the event. In the sample software package, the main() routine, which runs at power up or reset, simply calls a series of initialization routines before entering its main loop, which consists of just two lines of code in this case (Listing 1).

int main()
  /* Put the SPI flash into Deep Power Down mode for those radio boards where it is available */
  /* We must disable SPI communication */

#endif /* FEATURE_SPI_FLASH */






  /* initialize LEDs and buttons. Note: some radio boards share the same GPIO for button & LED.
   * Initialization is done in this order so that default configuration will be button for those
   * radio boards with shared pins. led_init() is called later as needed to (re)initialize the LEDs
   * */


  while (1) {
    struct gecko_cmd_packet *evt = gecko_wait_event();
    handle_gecko_event(BGLIB_MSG_ID(evt->header), evt);

Listing 1: Simplicity Studio provides a comprehensive development environment including sample code such as this mesh lighting main routine, which demonstrates initialization and looping for event handling. (Code source: Silicon Labs)

In the first line of the main loop, the function gecko_wait_event() blocks while waiting for events to appear in an event queue populated by lower levels. Although developers often avoid blocking functions, this approach is particularly effective in this case because the Bluetooth stack automatically manages low-power sleep states in this blocked mode. For specific application requirements that cannot tolerate blocking waits, the SDK also provides a non-blocking function that returns the next event or NULL if the queue is empty. With this function, however, developers are left to deal with low-power sleep management on their own.

In the second line of the main loop, the handler function handle_gecko_event() processes the latest event (evt) based on its event ID (Listing 2). When a device powers up, the stack issues a system boot event (gecko_evt_system_boot_id). In turn, the event handler calls a series of initialization functions, including gecko_cmd_mesh_node_init(), which initializes the Bluetooth mesh stack. Later, the handler calls other functions to provide the functionality associated with that event type as represented by its associated event ID.

 * Handling of stack events. Both Bluetooth LE and Bluetooth mesh events are handled here.
static void handle_gecko_event(uint32_t evt_id, struct gecko_cmd_packet *evt)
  struct gecko_bgapi_mesh_node_cmd_packet *node_evt;
  struct gecko_bgapi_mesh_generic_server_cmd_packet *server_evt;
  struct gecko_msg_mesh_node_provisioning_failed_evt_t  *prov_fail_evt;

  if (NULL == evt) {

  switch (evt_id) {
    case gecko_evt_system_boot_id:
      // check pushbutton state at startup. If either PB0 or PB1 is held down then do factory reset
      } else {
        struct gecko_msg_system_get_bt_address_rsp_t *pAddr = gecko_cmd_system_get_bt_address();


        // Initialize Mesh stack in Node operation mode, wait for initialized event

        // re-initialize LEDs (needed for those radio board that share same GPIO for button/LED)
    case gecko_evt_mesh_node_initialized_id:
      printf(node initialized\r\n);

      struct gecko_msg_mesh_node_initialized_evt_t *pData = (struct gecko_msg_mesh_node_initialized_evt_t *)&(evt->data);

      if (pData->provisioned) {
      } else {
        printf(node is unprovisioned\r\n);
        LCD_write(unprovisioned, LCD_ROW_STATUS);

        printf(starting unprovisioned beaconing...\r\n);
        gecko_cmd_mesh_node_start_unprov_beaconing(0x3);   // enable ADV and GATT provisioning bearer

    case gecko_evt_mesh_node_provisioning_started_id:
      printf(Started provisioning\r\n);
      LCD_write(provisioning..., LCD_ROW_STATUS);
      // start timer for blinking LEDs to indicate which node is being provisioned
      gecko_cmd_hardware_set_soft_timer(32768 / 4, TIMER_ID_PROVISIONING, 0);

    case gecko_evt_mesh_node_provisioned_id:
      _my_index = 0;   // index of primary element hardcoded to zero in this example
      printf(node provisioned, got index=%x\r\n, _my_index);
      // stop LED blinking when provisioning complete
      gecko_cmd_hardware_set_soft_timer(0, TIMER_ID_PROVISIONING, 0);
      LCD_write(provisioned, LCD_ROW_STATUS);

    case gecko_evt_mesh_node_provisioning_failed_id:
      prov_fail_evt = (struct gecko_msg_mesh_node_provisioning_failed_evt_t  *)&(evt->data);
      printf(provisioning failed, code %x\r\n, prov_fail_evt->result);
      LCD_write(prov failed, LCD_ROW_STATUS);
      /* start a one-shot timer that will trigger soft reset after small delay */
      gecko_cmd_hardware_set_soft_timer(2 * 32768, TIMER_ID_RESTART, 1);

Listing 2: Developers can examine the Silicon Labs mesh sample code for key design patterns, such as provisioning event processing, shown in this snippet from the handle_gecko_event() event handler routine called in the mesh light main routine (see Listing 1). (Code source: Silicon Labs)

One of the key series of events in a Bluetooth mesh network relates to the provisioning process. After a device has powered up and completed its initialization sequence, it goes into beacon mode, announcing itself to the network for provisioning. While provisioning proceeds to completion (or failure), the sample code uses the dev kit LCD and LEDs to provide status. By examining the event handler’s code block for each provisioning state, developers can quickly gain an understanding of this provisioning sequence and options.

Similarly, software engineers can use the sample handler code as a guide for creating their application-level functionality. For example, a key concept in Bluetooth mesh networking is the use of a publish-subscribe model for associating nodes that share some functional relationship (Figure 8).

Image of Bluetooth’s publish-subscribe modelFigure 8: Application developers use Bluetooth’s publish-subscribe model to combine devices into functional groupings such as a group of lights controlled by one or more switches. (Image source: Silicon Labs)

With this approach, several smart bulbs could subscribe to a switch publisher. When the end user activates the switch, the switch would publish the ON/OFF event. That event would cascade through the mesh network to subscribed smart bulbs, whose event handlers would take the appropriate action. The Silicon Labs sample code demonstrates this process – first with a published on/off request in the mesh connected switch (Listing 3) and then with a corresponding response in the connected light (Listing 4).

 * This function publishes one on/off request to change the state of light(s) in the group.
 * Global variable switch_pos holds the latest desired light state, possible values are
 * switch_pos = 1 -> PB1 was pressed, turn lights on
 * switch_pos = 0 -> PB0 was pressed, turn lights off
 * This application sends multiple requests for each button press to improve reliability.
 * Parameter retrans indicates whether this is the first request or a re-transmission.
 * The transaction ID is not incremented in case of a re-transmission.
void send_onoff_request(int retrans)
  uint16 resp;
  uint16 delay;
  struct mesh_generic_request req;

  req.kind = mesh_generic_request_on_off;

  // increment transaction ID for each request, unless it's a retransmission
  if (retrans == 0) {

  /* delay for the request is calculated so that the last request will have a zero delay and each
   * of the previous request have delay that increases in 50 ms steps. For example, when using three
   * on/off requests per button press the delays are set as 100, 50, 0 ms
  delay = (request_count - 1) * 50;

  resp = gecko_cmd_mesh_generic_client_publish(
    0,     // transition
    0,     // flags
    mesh_generic_request_on_off,     // type
    1,     // param len
    &req.on_off     /// parameters data

  if (resp) {
    printf(gecko_cmd_mesh_generic_client_publish failed,code %x\r\n, resp);
  } else {
    printf(request sent, trid = %u, delay = %d\r\n, trid, delay);

Listing 3: This snippet from the Silicon Labs mesh switch sample application illustrates use of the Bluetooth 5 publish process (gecko_cmd_mesh_generic_client_publish) for requesting a change in state (on or off) in a light subscribed to this event stream. (Code source: Silicon Labs)

static void onoff_request(uint16_t model_id,
                          uint16_t element_index,
                          uint16_t client_addr,
                          uint16_t server_addr,
                          uint16_t appkey_index,
                          const struct mesh_generic_request *request,
                          uint32_t transition_ms,
                          uint16_t delay_ms,
                          uint8_t request_flags)
  printf(ON/OFF request: requested state=<%s>, transition=%u, delay=%u\r\n,
         request->on_off ? ON : OFF, transition_ms, delay_ms);

  if (lightbulb_state.onoff_current == request->on_off) {
    printf(Request for current state received; no op\n);
  } else {
    printf(Turning lightbulb <%s>\r\n, request->on_off ? ON : OFF);
    if (transition_ms == 0 && delay_ms == 0) { // Immediate change
      lightbulb_state.onoff_current = request->on_off;
      lightbulb_state.onoff_target = request->on_off;
      if (lightbulb_state.onoff_current == MESH_GENERIC_ON_OFF_STATE_OFF) {
      } else {
    } else {
      // Current state remains as is for now
      lightbulb_state.onoff_target = request->on_off;
      LED_set_state(LED_STATE_TRANS); // set LEDs to transition mode
      gecko_cmd_hardware_set_soft_timer(TIMER_MS_2_TIMERTICK(delay_ms + transition_ms), TIMER_ID_TRANSITION, 1);

    onoff_response(element_index, client_addr, appkey_index);
  } else {

Listing 4: The Silicon Labs mesh light sample includes routines for specific application-level events such as this function for turning a LED on or off in response to a published request from the switch (see Listing 3). (Code source: Silicon Labs)

Along with the Bluetooth stack and SDK for node development, Silicon Labs also provides the final piece of the Bluetooth mesh puzzle – the connection to mobile devices. Most mobile devices support Bluetooth 4, and although their radios can support Bluetooth 5 requirements, they provide no stack support for Bluetooth 5 mesh layers. Silicon Labs addresses this limitation by providing mobile app developers with an additional software stack that provides mesh functionality (Figure 9).

Image of Silicon Labs’ mesh stackFigure 9: Developers can add Silicon Labs’ mesh stack for mobile devices to their mobile apps, enabling use of Bluetooth 4 mobile devices in Bluetooth 5 mesh networks. (Image source: Silicon Labs)


Bluetooth 5 mesh networking provides a natural transition for a wide range of applications that already leverage smartphones and other mobile devices for point-to-point communications. Yet, deployment of Bluetooth 5 mesh networking presents significant challenges in both hardware and software design, particularly in power limited applications such as the IoT. In addition, hardware engineers need to meet requirements for minimal footprint and low power; software engineers need to build software that uses minimal resources to execute complex communications protocols. With the combination of the BGM13P module, SLWSTK6101C development board, and Bluetooth stacks for both nodes and mobile devices, engineers have a comprehensive platform for rapid development of applications using Bluetooth mesh networking.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this publisher

Digi-Key's North American Editors