SemBeacon: A Semantic Proximity Beacon Solution for Discovering and Detecting the Position of Physical Things

Maxim Van de Wynckel, Beat Signer

Web & Information Systems Engineering Lab
Vrije Universiteit Brussel

Overview

"A Physical Thing is an abstraction of a physical entity that provides interactions to and participates in the Web of Things"
- W3C Web of Things (WoT) Thing Description 1.1

Problem Statement

"How to discover and track Physical Things indoors?"

"How to provide context to Physical Things?"

"How to get this context to the user?"

- HP CoolTown Beacon (2000) [26]

- Location-based service using ontology-based semantic queries (2017) [18]

If we look at existing solutions to this problem in the scope of the Web of Things we often found solutions that rely on a predefined method of centralisation such as a web service or knowledge database. But even then, tracking its location within an complex environment such as indoors is not fully discussed. If we look back at the early 2000's, Hewelett Packard started the CoolTown project. Part of this project was the creation of URI beacons which were infrared transmitters of uniform resource identifiers. This URI would then lead to an XML description of the location or place or "Thing". Despite the hardware limitations back in the day, this solution tries to solve our problem by putting the description online and transmitting this to the user. However, the XML vocabulary was specific to the CoolTown project and only one URI was used to describe the place. Other examples that more closely resemble the problem we are trying to solve use an object relational database system on the web that can be accessed by mobile clients. These clients can query the database to retrieve geospatial information about the environment which can be used to offer indoor positioning. While these solutions offer the ability to create interoperable applications, especially when used with common vocabularies -- it still requires knowledge on the location of the server. If we would make an open world assumption where these geometry and topology models are decentralised, we would require large semantic queries over unknown multiple servers, which is currently a huge bottleneck in linked data.

- Manfred Sneps-Sneppe, Dmitry Namiot, "On Physical Web models" (2016)

In 2014, Google introduced the Physical Web. The general idea behind the physical web was that Bluetooth transmitters could send out an URL that you can access when nearby the beacon. The Physical Web was mainly focused on broadcasting user-browserable and interactable websites and was implemented in Google Chrome as notifications that would appear when near a beacon. Use cases ranged from getting notifications for posters and events that you pass by, so that you could open the URL in the notification rather than scanning a QR code on the poster. Interactions with devices such as parking meters or smart lights and even on moveable objects such as pets, so their owners could update the website whenever their pet was missing. The project was shortlived and was removed from iOS and Android in 2017 after the concept was use too much for advertising and marketing, rather than providing seamless interactions.

Bluetooth Low Energy (BLE)

Bluetooth Low Energy (BLE) Positioning

BLE Specifications UriBeacon

Encoded URI to fit within 17 bytes
One flag implemented for invisible hint
Discontinued in favor of Eddystone-URL

BLE Specifications Eddystone

BLE Specifications iBeacon & AltBeacon

Other specifications used for proximity estimation, positioning and tracking include iBeacon and AltBeacon which are two popular specifications that are commonly used in indoor positioning systems. Instead of advertising a service, the use manufacturer specific data to include the required information. This includes the calibrated signal strength at 1m distance that can be used to determine the distance, a 128 bit proximity unique identifier and major and minor classification. Invented by Apple, the iBeacon specification recommends that companies use the same UUID per application and the major minor classification to indicate the spatial region. In iOS it is even impossible to detect iBeacons without providing an UUID within the application, which limits the use of iBeacon to applications that are aware of the used identifier within a building. To solve this particular issue, AltBeacon was created by Radius Networks which does not require to use the Apple manufacturer identifier, has an extra 1 byte that can be implemented by manufacturers for more specific data and officially has a 20 byte beacon identifier. However, due to backwards compatibility this 20 byte identifier is usually implemented similarly to iBeacon with a proximity uuid and major and minor classification.

BLE Specifications Bluetooth IPS

Bit (MSB)	Description
0	Presence of coordinates in advertising packet
1	Coordinate system used (WGS84 or local)
2	Presence of TX Power field in advertising packet
3	Presence of Altitude field in advertising packet
4	Presence of Floor Number in advertising packet
5	Presence of Uncertainty in advertising packet
6	Location Name avaiable in GATT database

SemBeacon

The basic principle of our semantic beacon solution called SemBeacon is a Bluetooth Low Energy beacon that advertises two identifiers and a set of flags. Compatible applications can then ask to retrieve an additional URI that redirects to semantic linked data on the Web containing more information about the beacon, its position and environment. In our semantic data we can make use of existing and extended vocabularies such as the generic positioning system ontology, Geosparql, sensors and observations ontology and the IoT-lite ontology. Our solution and contribution includes both the bluetooth adveritsement protocol, the semantic description and vocabulary and how the semantic data, identifiers and flags contribute to the usability of the SemBeacons for indoor positioning, device discovery and eventually the interaction with the device.

SemBeacon Bluetooth Specification

BLE 4.X

SemBeacon specification for BLE v4.x

SemBeacon Bluetooth Specification

Flags

Based on UriBeacon, Bluetooth IPS and Eddystone frames

Bit (MSB)	Description	Example
0	Indicates if the beacon has a position.	0 = Unsure, 1 = Yes
1	Indicates if the beacon is private.	0 = Public, 1 = Private
2	Indicates if the beacon is attached to a moving object.	0 = No, 1 = Yes
3	Indicates if the beacon has a positioning system.	0 = No, 1 = Yes
4	Indicates if the beacon has telemetry data.	0 = No, 1 = Yes
5 - 7	Reserved for future use.

Our flags are based on the invisibility flag of UriBeacon and its use cases, the flags and data of the Bluetooth IPS service and finally the use cases of the Eddystone frames. These flags should be configured when setting up a device and do not offer any dynamic information. For example, the position flag would be set to 1 when, during the installation it is clear the beacon will have a fixed position, which would be the case when mounted on wall. Similarly we have other flags that can be decided on during initial setup based on the use case for the SemBeacon. We introduced these flags in order to still provide applications with context on the type of beacon without requiring them to perform an HTTP request. For example, an application that only aims to navigate within a building should not access moveable objects without a position, as these will not be useful.

SemBeacon Bluetooth Specification

BLE 5.X (Work in Progress)

SemBeacon specification for BLE v5.x

In addition to our backwards compatible BLE 4 advertisement we also have a work in progress BLE 5 advertisement specification. With the increased payload size for BLE 5 advertisements we can include both the namespace and instance identifiers and uri within a single advertisement. As we no longer have to ensure Eddystone-URL compatibility, we also extended the encoding for the the URI to enable a smaller payload for common linked data URIs, versioning, and a larger URI in general which could negate the need for URL shorteners. BLE 5 advertisements offer better range compared to legacy BLE 4 advertisements which is useful for positioning. Our arduino library already offers the capabilities to use this new service on newer BLE 5 compatible ESP32 hardware for both scanning and advertising. However, our mobile application currently does not scan for BLE 5 advertisements yet.

SemBeacon Namespace and Instance

SemBeacon POSO Extension

SemBeacon Device Interactions

M. Bermudez-Edo, T. Elsaleh et al. "IoT-Lite Ontology", November 2015

SemBeacon Method of Discovery

:pl9_3 a ssn:Deployment ;
    rdfs:label "PL9.3"@en ;
    sembeacon:namespaceId "77f340dbac0d..."^^xsd:hexBinary .

:BEACON_08 a sembeacon:SemBeacon ;
    sembeacon:namespace :pl9_3 ;
    sembeacon:instanceId "c187d748"^^xsd:hexBinary ;
    poso:hasPosition [ a ogc:Geometry ;
        ogc:asWKT "POINT Z(...)"^^ogc:wktLiteral ] .

:BEACON_07 a sembeacon:SemBeacon ;
    sembeacon:namespace :pl9_3 ;
    sembeacon:instanceId "00cc38e7"^^xsd:hexBinary ;
    poso:hasPosition [ a ogc:Geometry ;
        ogc:asWKT "POINT Z(...)"^^ogc:wktLiteral ] .

:BEACON_02 a posoc:iBeacon ;
    sembeacon:namespace :pl9_3 ;
    posoc:proximityUUID "77f340dbac0d..."^^xsd:hexBinary ;
    posoc:major 50174 ; posoc:minor 64267 ;
    poso:hasPosition [ a ogc:Geometry ;
        ogc:asWKT "POINT Z(...)"^^ogc:wktLiteral ] .

Demonstrator Dataset & Recreation

- M. Van de Wynckel & B. Signer, OpenHPS Single Floor Dataset (2021)

In order to test and demonstrate the capabilities of SemBeacon we tested it in a real world scenario. For our test we based ourselves on a previously recorded indoor positioning dataset from 2021 that we recorded in the building of our lab. Back then, indoor positioning using the deployed beacons required an internal database within the application in order to perform multilateration. The primary focus of our dataset transformation consisted of transforming the geojson descriptors of the environment as well as the information of beacons. We first converted the dataset to semantic data using the POSO ontology after which we repositioned the beacons in the same building. However, this time around we also added two SemBeacons near the entrance of the floor that would provide all the contextual information about the floor.

Demonstrator Transformation

https://sembeacon.org/examples/openhps2021/beacons.ttl

:BEACON_08 a sosa:FeatureOfInterest, ogc:SpatialObject, poso:RFLandmark, 
        poso:BluetoothBeacon, sembeacon:SemBeacon;
    rdfs:label "BEACON_08";
    poso:hasPosition [ a geo:Point, poso:AbsolutePosition;
        ogc:asWKT "POINT Z(4.392253994600526 50.82057562786381 93.5999999962747)"^^ogc:wktLiteral;
        ogc:coordinateDimension 3; ogc:spatialDimension 3; ogc:dimension 3;
        schema:latitude "50.82057562786"^^xsd:double; schema:longitude "4.392253994600"^^xsd:double;
        schema:elevation "93.5999999962"^^xsd:double ];
    posoc:hasReferenceRSSI [
        poso:hasRSS [ a qudt:QuantityValue;
                qudt:unit unit:DeciB_M;
                qudt:numericValue -56 ];
        poso:hasRelativeDistance [ a qudt:QuantityValue;
            qudt:unit unit:M;
            qudt:numericValue 1 ]];
    hardware:macAddress "f7:5c:38:a4:45:ec";
    ogc:sfWithin :pl9_3_corridor;
    sembeacon:namespace :pl9_3;
    sembeacon:shortResourceURI "https://bit.ly/3JsEnF9"^^xsd:anyURI;
    sembeacon:instanceId "c187d748"^^xsd:hexBinary.

Demonstrator Transformation

https://sembeacon.org/examples/openhps2021/beacons.ttl

:pl9_3 a ssn:Deployment, sosa:FeatureOfInterest, ogc:SpatialObject, schema:Accommodation, seas:Floor;
    ogc:hasGeometry [ a ogc:Geometry;
        ogc:asWKT "POLYGON Z((4.3926809491 50.82056 92, 4.3925189891 50.820491195 92, 
            4.3924384904 50.820566477 92, 4.3923227711 50.820517092 92, 4.3924032699 50.820441810 92, 
            4.3922413107 50.820372691 92, 4.3918880594 50.820703046 92, 4.3920500197 50.820772165 92, 
                ...
            4.3921796702 50.820650918 95, 4.3922953899 50.820700303 95, 4.3921657397 50.820821550 95, 
            4.3923277009 50.820890669 95, 4.3926809491 50.820560314 92))"^^ogc:wktLiteral;
        ogc:coordinateDimension 3; ogc:spatialDimension 3; ogc:dimension 3 ];
    rdfs:label "PL9.3";
    sembeacon:namespaceId "77f340dbac0d20e8aa3af656a29f236c"^^xsd:hexBinary .
:pl9_3_lobby_1 a schema:Place, ssn:Deployment, sosa:FeatureOfInterest, ogc:SpatialObject;
    ogc:hasGeometry [ a ogc:Geometry;
        ogc:asWKT "POLYGON Z((4.392281317197596 50.82061024217639 92, 
            4.39223788808538 50.82065085654958 92, 4.392153959019106 50.82061503844629 92, 
            4.392197388204323 50.8205744240731 92, 4.392281317197596 50.820610242176386 94,
            4.392237888085379 50.82065085654958 95, 4.392153959019106 50.82061503844629 95, 
            4.392197388204322 50.8205744240731 94, 
            4.392281317197596 50.82061024217639 92))"^^ogc:wktLiteral;
        ogc:coordinateDimension 3; ogc:spatialDimension 3; ogc:dimension 3 ];
    rdfs:label "Lobby #1" .

Demonstrator Mobile Application

Scans and Simulates SemBeacon, iBeacon, AltBeacon and Eddystone
Extracts and visualises SemBeacon encoded information
Implements HTTP caching and namespace mapping to environments

Supplemental Material

Android Application to scan and broadcast SemBeacons
Created using Ionic Capacitor and @sembeacon/openhps
Arduino ESP32 Library to advertise SemBeacon
Available in the Arduino IDE as "ESP32_SemBeacon"
Android library extension to identify SemBeacons
Using the AltBeacon Beacon Library
TypeScript library to create and detect SemBeacons
Using the OpenHPS framework (@sembeacon/openhps)

Conclusion and Future Work

Semantic beacon solution called SemBeacon
Describes beacons, environments and all devices within
Backwards compatible, offline identification, scalable
Expanding the vocabulary to facilitate device interactions
Expanding to Solid Pods to enable the advertising of digital twins