Europe Union

GAP GATT REST API: Tool for BLE Data Provisioning

Meet GAP GATT REST API – DAC.Digital's tech marvel! It's the secret sauce in our onboarding toolchain, effortlessly marrying Bluetooth Low Energy with Service-oriented Architecture. Whether you're on Linux or a desktop, this tool makes BLE communication a breeze and plays well with the modern Arrowhead framework. Get ready for a smoother, smarter tech journey!

System Prototype Demonstrated in Operational Environment.

GAP GATT REST API is a tool developed by DAC.digital as a part of the onboarding toolchain developed in the use case 11 (UC11) of Arrowhead Tools: Configuration tool for autonomous provisioning of local clouds. The motivation behind the development of this tool was to incorporate the Bluetooth Low Energy (BLE) based data provisioning in the Service-oriented Architecture (SOA) ecosystem. 

The tool is mainly designed to work on linux-based embedded devices, although it should work also on desktop computers with linux-based systems and bluetooth chips. It consists of two parts – Generic Access Profile (GAP), for the management of BLE connections and their parameters, and Generic Attribute Profile (GATT) for exchanging the data which are described in terms of their functionalities below.

Linux Solutions

Generic Access Profile: GAP REST API provides endpoints, among others, for: Passive and active scanning of the nodes, connecting to a node GAP is stateless, and supports a gateway operating as central and observer roles. The Hyper Text Transfer Protocol (HTTP) method GET is translated to Bluetooth’s READ, while PUT – to WRITE. Additionally to PUT and GET, the EventSource method is used to handle a stream of notifications and indications.

Generic Attribute Profile: GATT supports, among other, the following functionalities: – Service discovery (as well primary services and filtering by Universal Unique Identity (UUID)) – Characteristics discovery (by UUID as well) – Subscribing to notifications and indications – Reading and writing characteristics – Handling notifications and indication on the server side – Reading/writing descriptors of characteristics

Wireless Home Solutions

State of the art.

New developments and recent trends in wireless sensor networking technologies have sparked the creation of inexpensive, low-power, multipurpose sensor nodes. Data processing and environment sensing are made possible by sensor nodes. Different surroundings may be monitored with the use of sensors that can detect volatile compounds, temperature, and humidity. They can communicate via networks with other sensor devices and share data with outside users.

Remote Home Control Solutions

The evolution of the Web as we know it has been influenced by the Representational State Transfer (REST) architectural style, which outlines a set of guidelines for the design of networked hypermedia systems. RESTful Web services are web services that adhere to the REST architectural style, and REST APIs are the programmatic interfaces for these services. The architectural decisions made by the Web to support the scalability and stability of networked, resource-oriented systems based on HTTP have greatly influenced the design concepts for REST APIs. The core principles are: Resource addressability, resource representations, uniform interface, statelessness, hypermedia as the engine state.

REST Web Service

The use of GATT REST API and GAP REST API for Bluetooth low energy devices was introduced back in 2013. Since there they have been seen in several applications. GAP defines the general topology of the BLE network stack. GATT describes in detail how attributes (data) are transferred once devices have a dedicated connection. 

In this context, one of the main motivations of this solution was that Legacy data exchange technologies are not supported by modern SOA/microservices architectures. Moreover, the deployment of complex sensor networks, their management, diagnosis, decommissioning, and evolution of the sensor network, required specialised knowledge and tools. Hence to overcome this limitation, an onboarding tool was developed, of which GAP GATT REST API was a part. 

The Solution: How does it work?

The tool is implemented according to Bluetooth Special Interest Group (Bluetooth SIG) specifications (GAP REST API V10r01 and GATT REST API V10r01) and is a natural proxy/translator between BLE communication interfaces and REST API (used by Eclipse Arrowhead). 

BLE Communication REST API
  • After gateway receives a list of nodes from the backend and there’s an unpaired sensor, it sends the request to GGRA to connect to this node along with the payload (desired configuration)
  • When they are connected, the Bluetooth characteristics are being registered as REST services in Service Registry
  • The Authorization and Orchestration rules are dynamically set for the data provisioning service, and it’s orchestrated to the gateway’s main service
  • The data are passed to the backend for further processing, or are available on the gateway
BLE Communication REST API

Arrowhead Compatibility: To make the tool compatible with Arrowhead, a specially designed Attribute Table is used to differentiate measurements (with value characteristics) and metadata about the device. Both measurement service and metadata service are registered in Arrowhead Service Registry as soon as they are connected to the gateway (in UC11 there’s a tool responsible for automated connection with the BLE nodes). At the same time, the authorization and orchestration rules are created, and the gateway that requested the connection can consume the incoming data from the provider.

Arrowhead Compatibiliy.

To make the tool compatible with Arrowhead, a specially designed Attribute Table is used to differentiate measurements (with value characteristics) and metadata about the device. Both measurement service and metadata service are registered in Arrowhead Service Registry as soon as they are connected to the gateway (in UC11 there’s a tool responsible for automated connection with the BLE nodes). At the same time, the authorization and orchestration rules are created, and the gateway that requested the connection can consume the incoming data from the provider.

More of Our Case Studies