Discovery

We've always been troubled with the fact that when you start the old CSR Bluetooth SmartMesh application on your smartphone, you see, well.... nothing! 

The app, e.g. Feit HomeBrite, or CSR's demo app, always wants to associate a new smart mesh device first. Before that you can't see anything. But, what about devices you own, and you have already associated with another smartphone or web app, or with a so called "Provisioner".

As mentioned before, we use the notion of a "status", a message to the "status channel" to scan the air and see what devices are available. With that implemented, your smartphone app, newly installed, will show all devices it can recognize (have the same network/app key) and identify it.

Here in this post I want to share the protocol we use the enable this functionality. Mesh packets in the current implementation look like this. The SIG packet format contains a bit more in the beginning such as the network ID and application ID selecting the right decryption key. Also the MIC is calculated with CMAC instead of HMAC, but that is just a technicality.

• sequence number (used as seed for encryption)

• source address (who am I)

• destination address (that would be the status channel)

• packet type (or opcode)

• transaction id (TID) and parameters

• message integrity code MIC

• time to live (for relaying data through the mesh)

The specific packet we are looking at are status packets. For now those are called PING packets, opcode 0x82. We defined the first one (TID 0x01, ping response) as a standard packet containing:

• mesh product identifier (just like the USB IF product identifier)

• company identifier (again the USB IF Vendor ID)

• number of groups the device supports

• battery voltage (important only if battery powered)

• the duty cycle, the amount of time the device listens to mesh packets (again for battery powered devices)

• internal temperature

Several secondary packets contain a user friendly readable name of the device, configureable and other information (see Configuration below).

Once the smart phone app receives those packets, it knows, what device it is and how to interpret the following status data. Now we can immediately display all devices we know on the screen of a newly installed smart mesh controller application. Here is an example how an app would display devices you may own.

Source Address

"Who Am I?" That is a unique address each device gets, or has, when you make one your own, it is called the virtual address. The Bluetooth SIG acknowledges that network key and application key which are calculated from a pass phrases are not a great idea. In many cases, when hackers try to break into a network system, guessing passwords can be possible. Take Feit's HomeBrite. Their application allows a 4 digit code to use as a pass phrase. This means you have just 10k possible network keys you can possibly generate.

It takes about 100ms to check a network key if it decrypts the packet. That means we can find the correct one within good 15 minutes. Not great. So, the SIG specifies that all keys are generated random, and all direct used keys, e.g. the network key or the application key, are derived from that main device key. Great idea.

The Bluetooth SIG also specifies that the unique address of each device to be derived from the device's UUID. We too implemented, that all devices you make your own (associate to a network, provision) will get a derived device id, or the "virtual address" used in each packet. The previously described discover process will reveal that, and you don't need to take care of that unique number. With that we avoid collisions that are common with these mentions early mesh apps when devices are provisioned.

Another set of addresses are used for grouping and broadcasting. The Bluetooth SIG defines unicast and group addresses for subaddressing components and channels. Allocation is 0x0001 to 0x7FFF for unicast, 0x8000 to 0xBFFF for source addresses, 0xC000 to 0xFFFE for groups, 0x0000 for unallocated and 0xFFFF for the common broadcast address.

Configuration

The second type of standardized packet, should be used for configuration of a device. Certainly every device is unique, but there are standard configs that every device should have. 

• user readable name

• duty cycle

• density

• time

The duty cycle is the amount of time each device is listening for mesh packets. Listening means that the Bluetooth receiver is turned on. Surprisingly, receive microwaves with an LNA (low noise amplifier) is a pretty power hungry operation. Density is the number of packets that are repeated on the bearer to provide redundancy on an unreliable broadcast channel. And time is the device’s internal time, some can use epoch time here.