Introduction

Wirepas Mesh operates on the same physical layer as BLE. Hence, it is possible to send and receive BLE non-connectable BLE advertisements packets with a Wirepas Mesh device. Wirepas Mesh utilizes all of the 40 BLE channels and it has its own timing requirements. BLE advertisement packets are using only the 3 BLE advertisement channels all of the time. For this reason some restriction are present when using BLE Advertisement together with Wirepas Mesh and are described in this document.

This document describes the different BLE advertising and scanning (transmit and receive) which are supported; the typical use cases associated with them; and the limitations in order to ensure proper product operation.

What you’ll learn

• The different BLE advertising and scanning modes supported by Wirepas Mesh.
• The typical use cases.
• The limitations.

What you’ll need

• Basic knowledge of Wirepas Mesh [1].

Wirepas Mesh BLE advertising and scanning support

The Wirepas Mesh stack supports concurrent operation of the Wirepas stack and BLE advertising and scanning operation both in transmission and reception. This feature can be used to send and receive messages between a Wirepas device and smartphones, tablets, or laptops.

BLE advertisement packets are sent on the BLE advertisement channel:

• On the transmit side: BLE advertiser / BLE advertising are devices that transmit advertising packets on the advertising PHY channels are referred to as advertisers.
• On the Receive side: BLE scanner / BLE scanning are devices that receive advertising packets on the advertising channels without the intention to connect to the advertising device are referred to as scanners.

Advertisement packets have some specificity, namely: 

• They are asynchronous but typically sent at a regular interval.
• Advertisements are not acknowledged after a packet has been received. 
• Advertisements use only three BLE channels: 37, 38, and 39.

Wirepas Mesh stack supports the capability to:

• BLE Advertising: Send non-connectable BLE advertisement packets on one or multiple BLE advertisement channels at a regular interval (in example Eddystone or iBeacons)
• BLE Scanning: Receive advertisements on one of the BLE radio channels.

For sake of clarity, the BLE support is limited to advertisement packets. This means connected states and GATT profiles are not supported concurrently with Wirepas Mesh stack execution.

The next sections explain how to transmit and receive BLE advertisements with Wirepas Mesh.

BLE Advertising

Wirepas Mesh stack allows BLE Advertising in parallel with Wirepas Mesh stack execution. Because the Wirepas Mesh stack execution is time-synchronized, it is quite easy for the stack to send BLE Advertising packets outside of the synchronized activity. So even if the BLE Advertising transmission and synchronized operations are using the same radio resource, they can be run on separate time slots. That’s why the BLE Advertising won’t drastically affect the overall performance of the Wirepas Mesh stack.

BLE Advertising description

Wirepas Mesh offers an API to support the broadcasting of non-connectable BLE advertisement packets. The API offers a complete configuration for the advertisement interval and flexibility on the advertisement payload. This allows support for example for Eddystone or iBeacons types. The application is responsible for defining the payload. 

The beacon API allows to set the following parameters:

• Payload: up to 37 bytes as per the BLE advertisement.
• Interval: the sending period of the advertisement packet (from 100 ms to 60 sec). Note: the Wirepas Mesh stack real-time operations always have a higher priority compared to the advertisement packet transmission. This means that the BLE Advertisement interval might be impacted (delayed) by the Wirepas Mesh stack operations.
• Channel: Advertisement packets can be transmitted on the three available channels (37, 38, and 39). To ensure reception, it is recommended to transmit the BLE Advertisement on all three channels.
• Power TX: Transmit power of the BLE Advertisement . This parameter is independent of the Wirepas Mesh stack transmit power.

The picture below describes the BLE Advertising operation versus the Wirepas Mesh stack operation. The BLE Advertising being a very seldom transmission it is automatically scheduled depending on the stack operation on the selected channel.

Wirepas Nodes roles and mode of operations with BLE Advertising

The Wirepas Mesh stack supports BLE Advertising in Low-Energy and Low-Latency modes. Also both router and non-router nodes can send BLE Advertising. 

The following points should be taken into account when BLE Advertising are transmitted:

• BLE Advertising transmission might have an impact on the Wirepas Mesh network performance in Low-Latency mode. This depends on the load in the network and the BLE Advertisement interval.
• BLE Advertising transmission will always have an impact on power consumption with low-energy devices. The impact depends on the BLE Advertisement interval and the TX power.
• BLE Advertising always has a lower priority than the Wirepas Mesh stack execution. This means that the BLE Advertising interval might be impacted due to the stack operations. 

Typical use cases

BLE Advertising is typically used to transmit “beacons” from a Wirepas device to a smartphone or a computer. The use cases can be:

• Broadcast periodical Eddystone or iBeacon to enable indoor way-finding on a smartphone.
• Broadcast a beacon when a device is outside of Wirepas Mesh network coverage. For example, detect and identify an asset tracking tag that is moving between two sites.
• Broadcast device status and installation quality in order to get immediate feedback during device installation.

Going further

Wirepas Mesh SDK offers an library for beacon TX [2]. An example application for BLE Advertisement called “ble_tx” can be found from the source/unitary_apps/ -folder of the SDK.

BLE Scanning

Wirepas Mesh stack allows Advertisement packet reception in parallel to normal Wirepas Mesh stack execution. Because the Wirepas Mesh stack execution is time-synchronized and the BLE Advertisements are fully asynchronous, the BLE Scanning adds more constraints to the stack compared to BLE advertising. 

Typical use cases for BLE Scanning are:

• Receive data from BLE sensors or light switch commands from EnOcean 2.4GHz BLE switches. 
• Inventory of iBeacons or Eddystone beacons, in addition to Wirepas enabled tags.
• Battery operated gateway or anchors that make an inventory of Beacons in their radio range.

The Wirepas SDK offers an API to receive BLE advertisement packets. The API allows to enable and control the BLE Scanning and has two key parameters:

• BLE Scanning activation: enable the BLE Scanning.
• BLE Scanning channel: set an explicit BLE channel to listen to (37, 38, or 39). The recommended way is to let the stack select the best possible BLE channel.

When enabled the BLE Scanning receives all the BLE advertisements on the selected channel and passes them to the application. It is then the responsibility of the application to filter the received packets that are meaningful for the application operation.

In a typical office environment the spectrum is usually full of BLE advertisements coming from all BLE devices. This means that all the BLE Scanning traffic cannot be transmitted to the backend but must be filtered at the receiving node. Also the more scanning devices there are in the same radio range, the more duplicate Advertisement packets will be received. To avoid duplicates, the BLE Scanning nodes should be placed so that: 

• The scanned area is covered with BLE Scanners .
• The scanned areas of different BLE Scanners overlap each other as little as possible. 

For example in the figure above, two BLE scanners (yellow dots) are placed so that they can hear the BLE advertisements from the switches. After the received switch event is received, the scanning node can spread the switch command using the Wirepas Mesh network. This way the BLE commands can be spread in the network without enabling the BLE scanner in every device. This is the recommended way because BLE scanning may affect the network performance and power consumption. These topics are covered in more details in the next chapters.

BLE Scanning with different node modes and roles

Wirepas Mesh has different modes of operation and node roles. Node mode and role set different limitations to the node’s capability to scan BLE advertisement packets. Wirepas Mesh concept document [1] describes the different roles and the mode of operation in detail. 

Low-Latency operation

In Low-Latency mode the devices are always listening to the messages from the Wirepas Mesh network. This is why a Low-Latency device can also do BLE Scanning during the idle time when the node is not transmitting or receiving other messages. However, Wirepas Mesh utilizes all of the 40 BLE channels in the communication and it automatically selects and uses the least crowded channels, but BLE Advertisement packets can only be received on 3 channels (37, 38, 39). This limits the frequency selection of a scanning device to those three crowded channels which may lead to a drastic decrease in the Wirepas network performance. For this reason, the BLE Scanning should only be used in a limited number of nodes and preferably in non-router devices. 

Node roles in Low-Latency mode

Router (either fixed or Autorole)

If a device is a router with BLE Scanning activated, it is then forced to choose its Wirepas channel from the 3 noisy advertisement channels. This means that a router's member nodes will also use one of those 3 channels to transmit Wirepas messages. This increases the traffic on these 3 channels even more and decreases the performance. At some point if multiple routers are scanning BLE Advertisement packets the network can get so congested that it basically stops working.

Therefore, the recommendation is either to enable the BLE Scanning only on a small subset of devices (i.e. 5%) in order to get a scanner coverage in a given area or to restrict the BLE Scanning reception to the non-router devices.

Non-router

A non-router node does not have to manage a cluster, in other words, it does not have to route traffic from other nodes. This is why it can use all its idle time to BLE Scanning without any performance impact. A non-router device communicates with a router node on one of the 40 channels and is able to use one of the BLE advertisement channels for BLE Scanning. For this reason, BLE Scanning on a non-router node does not impact the network performance.

Sink

Starting from Wirepas Mesh v5.2 a sink can also be used for BLE Scanning. However, the BLE Scanning is more targeted to low-energy sinks and is recommended only if it’s absolutely necessary. With low-latency sinks it’s not recommended to use the BLE Scanning at all because the sink will be forced to operate on one of the three crowded advertisement channels (which a sink typically tries to avoid).

The recommendation is to turn off the BLE Scanning on a low-latency sink.

The next picture summarizes the different cases described above:

Low-Energy operation

Starting from Wirepas Mesh v5.2 it is also possible to activate the BLE Scanning in Low Energy mode. 

In Low-Energy mode the communication between devices is periodical. The devices are sleeping most of the time and wake periodically to send and receive data via the Wirepas network. Turning on the BLE Scanning in a Low-Energy device does not force the node to communicate on the three advertisement channels. The node just listens to the BLE advertisement channel but still makes the periodic Wirepas communication on one of the 40 channels. This is why BLE Scanning does not affect the Low-Energy network performance almost at all.

However, turning on the BLE Scanning means that the radio’s receiver is on, which consumes power. This is why the BLE Scanning should only be turned on periodically. For example, if a tag is sending BLE Advertisement every 5 seconds the scanner should be turned on at least for 5 seconds to be able to receive the message. This operation should then be repeated every X minutes depending on the solution. This reception period is controlled by the application.

Wirepas Mesh traffic also affects the success rate of the BLE Scanning because the communication period, the so-called Access Cycle, is more frequent when there is more traffic in the network. The Access Cycle is either 2, 4, or 8 seconds depending on the traffic. So with a smaller access cycle it’s more probable that the devices are transmitting/receiving Wirepas Mesh messages and are thus not able to scan the Advertisement packet. This is why with a 5-second BLE advertisement period the scan time should be at least 10 seconds to be able to receive all the advertisement packets.

In conclusion, BLE Scanning in a Low-Energy device increases the node’s power consumption which limits the activation time and the use cases. BLE Scanning does not affect the Wirepas Mesh network performance.

Starting BLE Scanning and Activation Delay

Recommendation is to enable BLE Scanning statically in the Wirepas Mesh node, and activation should be done in App_init() before startStack(). Once activating BLE Scanning, there is a delay up to 8 seconds before 1^st BLE advertisement can be received.

Going Further

The Wirepas SDK contains APIs that can be used to receive BLE advertisement packets. An example application called “ble_scanner” can be found in source/unitary_apps folder of the SDK (v1.2.x) and source/example_apps/ (v1.3.x onwards). The example uses beacon_rx API [3]. 

Summary

Wirepas Mesh supports transmitting and receiving BLE advertisements on the same device which is running Wirepas Mesh. The following table summarizes how the BLE Advertising or Scanning affect a node in different modes and roles:

References

[1] Wirepas Mesh concept
[2] Wirepas Mesh SDK - BeaconTx api
[3] Wirepas Mesh SDK - BeaconRx api

Revision History

Legal Notice

Use of this document is strictly subject to Wirepas’ Terms of Use and Legal Notice.

Copyright © 2021 Wirepas Oy