RFC: Re-use of Manufacturer ID by other Linux Foundation projects

[adamfowleruk]

Introduction

The Herald Project, part of Linux Foundation Public Health, has been talking to the Bluetooth SIG about becoming a member and registering service UUIDs and Manufacturer IDs for use in Bluetooth Proximity (including, but not limited to, COVID-19 Digital Contact Tracing apps). The latest suggestion to a resolution it to re-use the existing Linux Foundation manufacturer ID which is currently believed to only be used by the Zephyr project.

This RFC is to ask for feedback from the Zephyr project on this proposal from LF.

Problem description

The Herald Project needs to use a manufacturer ID area to share device information pre-connection for efficient use of an anonymous proximity protocol. We have been attempting to register one with the Bluetooth SIG.

Proposed change

Linux Foundation (via @jennydove at LFPH) has proposed that The Herald Project share the manufacturer ID for The Linux Foundation currently used by the Zephyr project. I'd like to ask for this project's feedback first, as chair of the Herald Project and Chair of the TAC for LFPH.

Detailed RFC

Current use of the Manufacturer data area is described here (Pseudo MAC Address) in the "Device discovery introspection" section here: https://heraldprox.io/specs/protocol

This is currently only use to share a 6 byte random data item, but may be modified in future for a variety of uses.

It may be worth noting that in future other LF or LFPH projects may themselves also use this sharing precedent to use the same ID for other uses and data formats.

Proposed change (Detailed)

To share use of the Manufacturer ID 0x05F1 with other LF and LFPH projects.

Dependencies

Zephyr Bluetooth Header definitions or logic, potentially? TBD.

Concerns and Unresolved Questions

I was concerned Zephyr RTOS or other Linux Foundation projects may have uses for this manufacturer ID that may be impacted by this re-use of the ID with different data.

Alternatives

We have attempted to find a way to register The Herald Project as a 'company' or 'standards definition org' so we can register our own ID, but after approx 8 months of discussion, what is described here is the proposal we have been asked to evaluate.

[jhedberg]

I don't see any obvious problems with reusing the LF manufacturer ID like this. The important thing is that the the context specific namespace is then managed somehow centrally. By context specific namespaces I'm talking about stuff like USB VID/DID pairs, Bluetooth Mesh vendor models & opcodes, etc. At least in those cases the manufacturer id acts as a namespace that then needs to be managed somehow.

[henrikbrixandersen]

Should we bring this up at the next TSC meeting?

[adamfowleruk]

Thanks for your replies on this. I'll work on the presumption that sharing the same manufacturer code is OK for now. I'll happily pop along to your TSC meeting too, if invited/required, to have a chat about it. I want to make sure this can work well. Definitely worth a chat around namespace management.

[adamfowleruk]

Hi all. Just wanted to update you all on our use of the LF manufacturer ID in The Herald Project in LFPH.

We've started creating new MESH models and have been designing them in a way to allow upstreaming into Zephyr one day, and to not make them too Herald/healthcare specific.

This work is currently ongoing on a feature branch 113:-

• The herald-mesh-relay application here: https://github.com/adamfowleruk/herald-for-cpp/tree/feature-113/herald-mesh-relay
• Herald MESH include files: https://github.com/adamfowleruk/herald-for-cpp/tree/feature-113/herald/include/herald/mesh
• Herald MESH source files: https://github.com/adamfowleruk/herald-for-cpp/tree/feature-113/herald/src/mesh
• Issue tracking: Bluetooth MESH sample apps with Herald integration theheraldproject/herald-for-cpp#113
• Somewhat related MESH CVE tracking catch-all issue: Security Report: Pre-release validation of Bluetooth MESH CVEs theheraldproject/herald-for-cpp#114

We define general LF values in mesh.h (BT_MESH_LINUX_FOUNDATION_VENDOR_COMPANY_ID, and the Op codes for get/set/status).

We also define two models at the moment, which we include _HERALD_ in the name of for now:-

• Venue Beacon (vendor model 0x2001) - Allows a central MESH administrator to set the Bluetooth LE Beacon configuration which advertises country, state, location ID, beacon ID
  • On the MESH side, this allows central programming for venue beacons in a very large facility, and renaming of wings of buildings, room, and so on from a central interface (very useful!)
  • See the location*.h files in the above include/src folders (new, not implemented yet)
  • On the LE side, Is connectable so a nearby phone (for example) can pull extended data (E.g. location URL, and other information required in New Zealand's and the UK's digital contact tracing QR code posters)
  • Has multiple uses. We're also going to use it to facilitate internal navigation. I.e. we'll 'publish' (probably online rather than over Bluetooth) a facility map with beacon locations, allowing a phone to triangulate its own position. (Thus avoiding privacy concerns as all navigation functions happen on the phone itself - the beacons just advertise their IDs and a pointer to the map and gazetteer)
• Presence sharing (vendor model 0x2002) - Allows a MESH administrator to request a MESH / LE Gateway running Herald to share at a specified internal the LE mac addresses and running mean RSSI of nearby LE devices over the mesh
  • Main use case we're concerned with is not for general LE devices, but for Herald enabled Beacons, so we can locate hospital equipment on demand.
  • Secondary use case, but the reason we're keeping the design generic for LE, is to allow determining of density of use of an area (E.g. for COVID safety) and for finding potential people via their phones in a fire emergency (E.g. evacuating a hospital, or a tower block to help address emergency situations like the Grenfell disaster in the UK)
  • See the presence*.h files in the above include/src folders

Other potential future models we are considering:-

• MESH driven software updates - Initial new software copied (E.g. to Slot 2) via BLE or direct USB connection to one MESH node, then a 'Hey node 3 you're near node 2, use an LE connection to fetch the update. Here's some crypto info for a mutual connection, and the SHA256 of the binary'
  • I really don't want to force someone in a hospital to walk around the place doing USB software updates
  • MESH is only for small data packets, but LE can be used to chunk and transfer large files, so this seemed like a good solution. I couldn't find anyone else doing this, or a standard Bluetooth SIG model for this.
  • This is potentially very useful to distribute updates to IoT devices connected to the MESH from multiple manufacturers, just temporarily using the Slot2 storage as a local data transfer cache. Not sure if its wise - please do comment.
• Replacing hospital pagers
  • Currently Pagers are a very expensive way of doing things. 5G won't help due to building shielding and the need to ensure patient details (shared for greater context in the page request) needs to stay in-network
  • A model that allows a MESH node that is a 'Modem' (i.e. one connected to a hospital server) to provide a 'Paging server' could be connected to a reliable messaging broker (E.g. RabbitMQ) in the hospital running on Kubernetes, for example, to acknowledge the page request, providing guaranteed delivery guarantees. Could include the location and details (E.g. staff ID) of the person making the page request, the room they are in, the patient ID they are talking to, and a code of the medical issue (E.g. SNOMED code) or priority (E.g. 'risk to life' or 'non urgent consult')
  • Potentially reusable outside of Healthcare anywhere in-building messaging needed to be supported.

As ever, we're always open to thoughts and comments in Herald / LFPH, so please do let me know what you think.

Also if there's any gotchas / code style issues for the C code we're creating for the models that would make it easier to upstream to Zephyr in future, do let me know. Kconfig enabling flags for the models is one that immediately occurs to me.

If you'd like a presentation on a Zephyr TSC call on what we're doing at any point just let me know. Likewise if you'd like a slot on an LFPH TAC call just let me know (I'm TAC chair this year).

Keep up the great work! I love working on apps that use Zephyr!