Vehicle Parking Management Using iBeacons

There’s new research by Chi-Fang Chien, Hui-Tzu Chen and Chi-Yi Lin of Tamkang University, New Taipei City, Taiwan on A Low-Cost On-Street Parking Management System Based on Bluetooth Beacons (pdf).

Current smart parking systems are very expensive as they rely on image recognition and wireless magnetometers. The image recognition isn’t perfect and sometimes fails to acquire the identity of vehicles under poor illumination or due to obstruction of vehicle registration number plates.

Instead, a system has been developed using low-cost Bluetooth beacons. Beacons are installed in the vehicles and receivers are deployed along the roadside parking spaces.

Vehicle Parking Management System
Vehicle Parking Management System

The system uses Raspberry Pi for receivers and gateways. The Received Signal Strength Indication (RSSI) of beacons is processed, filtered and sent to a gateway. The system detects the occupancy of parking spaces and identifies the vehicles.

Smart On-Street Parking System
Smart On-Street Parking System Using iBeacons

It’s unfortunate the researchers didn’t consider Bluetooth Mesh for the receivers and gateways. It’s ideal for situations such as this where nodes are within range of each other and the data is small in size and sporadic. The use of Bluetooth Mesh would have reduced the hardware requirement considerably.

Read about Beacons and the Bluetooth Mesh

Bluetooth Mesh Succeeds Where Thread Failed

Thread is a low power wireless protocol that competes with Bluetooth Mesh. Particle who develop Thread have made a surprise announcement that they are discontinuing development of Particle Mesh.

Mesh networking, while a compelling technology, is extremely complex, and trying to make it just work with zero configuration for all customers in all environments just wasn’t feasible

Instead, they are going to concentrate on Bluetooth Low Energy support for local communications between devices.

To understand the rationale, take a read of Szymon Slupik’s blog on Crossing the Mesh Chasms. Szymon is the Chair Mesh Working Group at Bluetooth SIG and CEO of Silvair who use Bluetooth Mesh in lighting. In his blog he explains how his company previously tried and failed, 8 years ago, to create a routed, self-healing and IP-based mesh. Bluetooth mesh has none of these because different techniques need to be used in networks that have low bandwidth. Attempting routing, self-healing and ip protocols on top of a limited throughput network causes it to saturate and collapse if there’s any significant network traffic.

Instead, Bluetooth mesh has been designed to send the original message multiple time (default is three) instead of using acknowledgements*. Multiple paths are used instead of self-healing.

As the Thread announcement says, mesh networking is complex. This is as much so for Bluetooth as it is for Thread. The Bluetooth Mesh Specification has over 700 pages. As Szymon says, Bluetooth mesh as a technology is only part of a solution. Bluetooth mesh needs software to configure the mesh for specific usecases and provision/manage nodes.

Read about Beacons and the Bluetooth Mesh

Read about SensorMesh™

* The mesh standard does allow for acknowledgements but, as has been our experience, using them in real-world scenarios floods the network with too much traffic.

Wireshark Supports Bluetooth Mesh

Wireshark has announced support for the Bluetooth Mesh Beacon, PB-ADV, Provisioning PDU and Proxy Bluetooth mesh protocols.

Wireshark is a protocol analyser that takes packets and decodes into human readable data. It’s usually used with other hardware and software as the last stage in processing captured data. For example, you can use Wireshark with the Nordic nRF sniffer, on Adafruit hardware and on Linux.

In the case of Bluetooth mesh, data packets are encrypted. In fact, data is double encrypted in that first the data is encrypted and then the packets. This means that while you can capture packets you can only see the packet types and Bluetooth mesh metadata. You won’t be able to decrypt the actual data. It’s more useful for determining the type and size of traffic for mesh traffic optimisation.

Read about Beacons and the Bluetooth Mesh

What’s Wrong with Bluetooth Mesh?

Researchers from TU Darmstadt, Germany have a new paper Toxic Friends in Your Network: Breaking the Bluetooth Mesh Friendship Concept that looks into weaknesses in the security model underlying the Bluetooth mesh friendship mechanism.

Friendship allows a low-power IoT device to go to sleep with a separate higher-power node caching packets until the lower power device wakes up. The paper provides an overview of friendship and the Friendship Security Material(FSM) unique to this type of communication.

The researchers found three flaws in the Bluetooth friendship mechanism related to:

  • The possibility of eavesdropping on communication and selectively jamming based on size of the control messages.
  • The lack of protection of the friend security keys against an insider attack.
  • The possibility of misuse of Friend Clear messages to cause a form of denial of service attack through flattening the battery.

The paper includes a reference to tools that demonstrate these problems and discusses possible mitigations.

The Bluetooth SIG responded:

Compromise of the friendship relationship results only in a compromise of the availability of the low power node to the other nodes in the subnet.

It is the conclusion of the working group that the friendship relationship between an LPN and its friend within a mesh subnet is not intended to be secured against attack by a party already in possession of the network key.

It is the position of the Mesh Working Group and the Bluetooth SIG that neither scenario provides additional security risk for a user of the Mesh profile

In other words, the risks are appropriate to the level to which the mesh is expected to be used or attacked.

We have yet to come across any devices using friendship. Friendship is an edge case that isn’t required in most instances. Also, most existing low power devices can’t be upgraded to use mesh due to the higher memory requirement of Bluetooth Mesh.

Read about Beacons and the Bluetooth Mesh

New SensorMesh™ Gateway Box

We have a new SensorMesh™ Gateway Box that takes mesh data from a USB COM port and sends it to your server, BeaconServer™ or BeaconRTLS™.

It reads data from a COM port and uploads it to a server defined by a URL in the box’s web UI:

The web UI also shows the latest data received and the response from the server

Use of the Gateway Box is optional. We also have a Windows 10 service should you wish to do a similar thing on your PC/server or you can process the COM port data yourself for a more bespoke solution.

Read more about SensorMesh™

Survey of Mesh Technologies

There’s useful new research on Wireless Mesh Networking: An IoT-Oriented Perspective Survey on Relevant Technologies by Antonio Cilfone, Luca Davoli, Laura Belli and Gianluigi Ferrari of University of Parma, Italy. It covers how various communication technologies are suitable for mesh networking.

The paper explains mesh topologies and routing protocols. It describes Bluetooth:

“BLE is presently raising more and more attention and is becoming one of the leading technologies for both IoT-oriented and industrial scenarios”

The authors provide an in-depth introduction to SIG Bluetooth Mesh. (Note that an excellent higher level overview also very recently became available from InsightSIP). The research paper also mentions other Bluetooth mesh implementations such as the draft IETF Bluetooth Mesh for IPv6.

Applications such as smart city, industrial monitoring and smart agriculture are considered and factors such as interoperability and security are mentioned. Finally, the paper compares other protocols such as Thread, ZigBee and LoRaWAN.

Read about Beacons and the Bluetooth Mesh

Bluetooth Mesh for Industrial IoT (IIoT)

There’s an informative video presentation on the Bluetooth SIG web site on Simplifying Multi-Vendor Mesh and Sensor Networks. It provides an introduction to Bluetooth mesh and explains the ways in which it can provide for Industrial IoT (IIoT).

To add to this, Bluetooth Mesh is suitable for use on the factory floor where the environment can be electrically noisy. Standard Bluetooth Mesh uses advertising on several channels rather than (GATT) connections so as to provide for more reliable communication in environments with wireless interference.

Read about Beacons in Industry and the 4th Industrial Revolution (4IR)
Read about Beacons and the Bluetooth Mesh

RTLS Locating Using Mesh

You-Wei Lin and Chi-Yi Lin of Department of Computer Science and Information Engineering, Tamkang University, New Taipei City 25137, Taiwan have a paper An Interactive Real-Time Locating System Based on Bluetooth Low-Energy Beacon Network.

Although the implementation is similar to SensorMesh™ and BeaconRTLS™ used together, their solution uses a proprietary mesh implementation and a proprietary data protocol. Consequently, their implementation suffers longer response time when used over longer physical distances. Their maximum inter-hop distance of 8 to 10 m also isn’t good due to non-optimal devices and non-optimal device positioning.

Bluetooth Mesh, Thread and Zigbee Network Performance

Silicon Labs have a useful web site, webinar and slides on “Benchmarking Bluetooth Mesh, Thread, and Zigbee Network Performance”.

The two main measures of performance are throughput, the rate data transfer that can be achieved (in bits per second) and latency, the time taken for data to cross the network.

With a typical implementation of 6+ hops, throughput converges to a similar order of magnitude for all the protocols:

In real use these protocols only support of the order of low thousands of bits (not bytes!) per sec and should therefore only be used for sending small amounts of data that don’t change very often.

For a small payload with 192 nodes, Zigbee has lowest latency and Bluetooth has greatest variation of latency of 20ms to 200ms:

For a larger payload, the Bluetooth latency has a larger range of up to 750ms:

Whether the variation of latency matters depends on your particular solution. Which technology is best depends on what you need to accomplish. For example, in a Bluetooth lighting scenario you might not want some lights to come on immediately and far ones to come on up to a second later. For sensing, the delay usually doesn’t matter.

You also need to consider other factors such as interoperability, scalability, security, reliability and ease of deployment. For example, Zigbee is less scalable and Silicon Labs recommends a maximum of seven hops otherwise the network becomes congested due to re-tries. Bluetooth has especially good interoperability because it is ubiquitous on smartphones and other devices. It also works reliably in industrial situations and has double encryption.

All protocols can be difficult to deploy due to the lack of off-the-shelf general solutions outside specific verticals such as lighting and home automation although our SensorMesh™ is a notable exception.

Silicon Labs have a more specific paper on Bluetooth Mesh Network Performance.

Read about Beacons and the Bluetooth Mesh