Devices using non-IP based protocols

Some devices use non-IP based protocols, e.g. WPAN (wireless personal area network) based protocols like Bluetooth®, ZigBee or Z-Wave for reasons such as power or cost-savings. However, the transport protocol to communicate with the device connectivity layer needs to be IP-based. To implement such scenarios, IoT solution developers need to utilize some sort of gateway that translates non-IP based protocols to IP-based protocols. These gateways need to be able to send device data on behalf of the actual devices as outlined in the graphic below.

Integration with third-party network provider

Devices with limited battery capacity using LPWAN (low power wide area network) based technologies like SigFox or LoRa. Network providers of such technologies provide a backend system to interact with LPWAN devices. To transfer the data from such devices to the Cloud the integration with third-party network provider is required. For this purpose the third-party network server, e.g. LoRa network server acting as a gateway device in the device connectivity layer and the actual LoRa devices communicate via this gateway. Registering credentials for the actual LoRa-devices is not required - authentication will be performed using the credentials of the LoRa Network Server Gateway. The device connectivity layer supports forwarding of telemetry messages received from a LoRa Network Server Gateway to a business application as well as sending back messages from the business application to the LoRa Network Server Gateway.

Devices using proprietary or unsupported protocols and connecting via cloud protocol gateway

For various reasons, there are devices that cannot communicate via standard protocols and therefore they use proprietary protocols and proprietary protocol adapters. Such proprietary protocol adapter serves as a gateway that translates proprietary protocols to standard protocols like HTTP, AMQP1.0, MQTT and CoAP. The device connectivity layer supports the integration with such cloud protocol gateways.

The device connectivity layer supports the scenarios listed above in two modes: single gateway mode and multiple gateways mode.

Single gateway mode

In this mode all devices communicate only via one gateway as outlined in the graphic below.

To operate devices in single gateway mode, the actual device needs to be linked to its gateway. To achieve this, the via property must be set to the device-id of the gateway on device registration.

See Suite API Docs: Bosch IoT Hub - Management API for details. The linked gateway is an ordinary device with credentials within the Management API.

Multiple gateways mode

In this mode all devices can be connected to the device connectivity layer via many gateways as outlined in the graphic below. This mode can be used in case a protocol gateway is scaled to multiple instances and each instance of the protocol gateway is modeled in the device connectivity layer as a separate gateway device or when the actual devices are connected via different gateways (e.g. eBike is connected via Bluetooth with Smartphones of different family members and each Smartphone is modeled in the device connectivity layer as a separate gateway).

To operate devices in Multiple Gateway Mode, all gateways need to be grouped and the actual device needs to be linked to this gateway-group. To achieve this the via property must be set to the gateway-group-id on device registration. More details can be found in the sub-chapter below.