One key advantage of Bluetooth® Low Energy (LE) is the long battery life it gives to portable devices that are always-on, but still light-weight and miniature in form-factor, such as asset and personnel tags for Real Time Location Services (RTLS).
Bluetooth mesh profiles provide the basic infrastructure protocol to support the relay of messages from tags over a network of mesh relay nodes, which are typically line-powered devices. The location of tags are most commonly determined using received signal strength (RSSI) at three or more nodes, the position of which are known and allows tag position to be calculated using geometrical trilateration techniques. Location-accuracy is dependent on individual silicon implementation of RSSI measurement, as well as the sophistication of post-processing algorithms applied to the calculation. Commercial products, such as the WiSilica patient tracking system, can typically resolve down to one-meter accuracy.
Bluetooth Mesh Lighting Controls
The Bluetooth mesh profile, together with Bluetooth mesh model specification, has primarily focused on the support for lighting controls, and many Bluetooth LE based networked lighting products are expected to be deployed in the near future, especially in the enterprise market. It will be convenient and cost-effective for such lighting fixtures to be used as connectivity nodes, enabling location-awareness for low-power IoT devices throughout the enterprise environments.
The Bluetooth mesh model specification has defined procedures for location setting and reporting by individual fixture locations, for example, which can be directly useful for defining the reference node locations to be used for trilateration. The Bluetooth mesh profile also supports the use of advertising packets so that short asynchronous broadcast ADV packets from the tags can be relayed efficiently on time. Also, unlike many simple tracking products in the market today where the tags simply transmit fixed ADV beacon packets, the Bluetooth mesh profile has strong security procedures where, for example, each message is encrypted using a sequence number and keys to protect against message replay attacks. As a result, a tag is not easily cloned or its location tracked by rogue receivers as would happen to the simple beacon tags.
Bluetooth in Smart Environments
Currently, there is no Bluetooth profile strictly defined for RTLS, although some activities are beginning in the smart environment working groups with initial effort around an FRD that predicates the use of the Bluetooth mesh profile. In any case, as an application layer protocol, the Bluetooth mesh profile can coexist with other applications that allow the complete RTLS system to be built even when not all application profiles are standardized yet. Compatibility at the core Bluetooth LE stack layers is maintained so that integration with the mobile device ecosystem is possible. This is an essential advantage of Bluetooth LE over many competing short-range wireless standards, just as the Bluetooth mesh profile also alludes to the use of a smart or even legacy phones as the provisioner to add a device securely to a Bluetooth mesh network.
Meeting Demanding Applications
In general, RTLS is a much more demanding application than lighting control due to the number of tags and the amount of traffic generated per tag in a typical enterprise deployment. Patient tags and asset tags would need to transmit at least once per second or more for position updates to be real-time. In a typical healthcare environment, there could be hundreds of patient tags and asset tags, all within a small area.
The Bluetooth mesh profile, being a flooding mesh, would typically be impacted in throughput if applied without due consideration of such traffic engineering issues. However, there are provisions within the profile, such as the different type of nodes being just passive nodes, relay nodes, and low power nodes, so that individual vendors may incorporate additional application-layer optimization that would achieve higher overall channel utilization and traffic throughput.
Finally, the system would typically require gateway devices where the mesh network interfaces to Wi-Fi or some other LAN and eventually to the cloud server that provides the accumulation of all received ADV packets and their RSSI and perform the location calculations. It is entirely conceivable that standardization effort would eventually define an RTLS profile that standardizes on protocol right up to the gateway, and also makes use of new features provided by Bluetooth 5, such as the extended advertising packets and large number of secondary advertising channels. This will enable the full potential of the Bluetooth mesh profile to be utilized with RTLS services ubiquitously provided from the cloud by any RTLS service providers, to any IoT devices connected to a Bluetooth mesh network. Location services will become a key function of every IoT object, as is connectivity to the Internet.