Cloud Protocol Gateway - operated by a customer
The device connectivity layer - Bosch IoT Hub - allows you to connect devices to IoT applications in an easy and secure manner.
In general, the communication between device and the device connectivity layer is established through standard protocols such as MQTT, AMQP, CoAP, and HTTPS. In some cases, however, devices or field gateways can only communicate using proprietary protocols or protocols that are not supported by the device connectivity layer. This is where the Cloud Protocol Gateway approach comes in. It allows customers to connect devices using their individual protocols to establish communication.
The Cloud Protocol Gateway is a custom component that must be implemented and operated by customers. It is connected to the device connectivity layer as a gateway device. The main function of the Cloud Protocol Gateway is to transfer the device’s proprietary protocol into the protocol used by the the device connectivity layer protocol adapter.
Find an example implementation of a Cloud Protocol Gateway connecting to the standard AMQP protocol adapter in the Eclipse Hono project.
Communication flow
The diagram below shows, that only the Cloud Protocol Gateway communicates with the physical devices.
For the device-to-cloud communication, it forwards received messages (telemetry and events) from the physical devices to the AMQP protocol adapter, provided by the device connectivity layer.
For the cloud-to-device communication, the Cloud Protocol Gateway receives the incoming commands from the northbound application and forwards them to the specific device addressed.
Usage of other protocol adapters:
The AMQP 1.0 protocol adapter is recommended for this approach, but this in not mandatory.
The Cloud Protocol Gateway can also be connected to other supported protocol adapters, e.g. the MQTT protocol adapter.
The basics requirements in a nutshell
In order to keep the communication flow safe, please consider the following rules:
The Cloud Protocol Gateway needs to be registered in the device connectivity layer and the digital twin layer.
The physical devices need to additionally be registered in the device connectivity layer and the digital twin layer.
The credentials of Cloud Protocol Gateway registered as a gateway device need to be managed in the Device Registry of the device connectivity layer.
The credentials of the physical devices can be managed in the Device Registry of the device connectivity layer, but this is not mandatory.
The physical devices are linked to the Cloud Protocol Gateway using the via property.
The physical devices communicate only with the Cloud Protocol Gateway.
The Cloud Protocol Gateway is responsible for authenticating the physical devices.
Authentication
The device connectivity layer relies on protocol adapters to establish a device’s identity before it is allowed to publish telemetry data or to send events.
Conceptually, the device connectivity layer distinguishes between two identities:
Authentication credentials – associated to the authentication identity or auth-id, and
Identity to act as the device identity or device-id.
In this particular case, the Cloud Protocol Gateway is authenticated by the device connectivity layer as a (virtual gateway) device, which has an own device-id and auth-id.
The physical devices in turn, have only a device-id, and can be authenticated by the Cloud Protocol Gateway.
In case the devices connected via the Cloud Protocol Gateway prefer to store their own credentials in the device connectivity layer, please consider that the credential registration is only supported via HTTP API at the moment.
Multiple Cloud Protocol Gateways
In scaling scenarios, with thousands of devices, the Cloud Protocol Gateway needs to be scaled to multiple instances and the devices can be connected to the device connectivity layer via many Cloud Protocol Gateways as outlined in the graphic below.
Each instance of the Cloud Protocol Gateway must be registered as a separate gateway device in the device connectivity layer.
Further, the device connectivity layer offers the possibility to group gateway devices. Such a group will have an own device-id and auth-id. The physical devices need to be linked to this Cloud Protocol Gateway-group. To achieve this, the via property must be set to the gateway-group-id (i.e. the device-id of the group) on device registration.
By linking the devices to a group, the existing devices will not need to be updated, when a new instance of a Cloud Protocol Gateway is launched.
Find an example of how you will need to provision such structures at Cloud Protocol Gateway example.