The LoRa protocol (or more precise LoRaWAN: Long Range Wide Area Network) is a wireless protocol well suited for constrained devices. Due to its power saving implementation is fits well for use-cases where battery capacity is a limited resource.

The device connectivity layer supports forwarding of telemetry messages received from a LoRa Network Server Gateway to a business application, Command & control communication is not supported.

Supported LoRa networks

Network provider	Endpoint	HTTP Method
Actility Enterprise	`https://lora.bosch-iot-hub.com/actilityEnterprise`	`POST`
Actility Wireless	`https://lora.bosch-iot-hub.com/actilityWireless`	`POST`
Kerlink	`https://lora.bosch-iot-hub.com/kerlink/dataUp` `https://lora.bosch-iot-hub.com/kerlink/rxmessage`	`POST`
The Things Network (TTN)	`https://lora.bosch-iot-hub.com/ttn`	`POST`
Objenious	`https://lora.bosch-iot-hub.com/objenious`	`POST`
Everynet	`https://lora.bosch-iot-hub.com/everynet`	`POST`
Proximus	`https://lora.bosch-iot-hub.com/proximus`	`POST`
ChirpStack	`https://lora.bosch-iot-hub.com/chirpstack`	`POST`
FireFly	`https://lora.bosch-iot-hub.com/firefly`	`POST`
Loriot	`https://lora.bosch-iot-hub.com/loriot`	`POST`
Orbiwise	`https://lora.bosch-iot-hub.com/orbiwise/*`	`POST`

LoRa application properties

The following list shows the properties which are available for messages received through the LoRa adapter:

Property Name	Description
`JMS_AMQP_CONTENT_TYPE`	`application/json`
`device_id`	The identifier of the device which sent the message.
`orig_adapter`	The identifier of the LoRa protocol adapter: `hono-lora`.
`orig_address`	The relative uri path the device pushed its data to.
`orig_lora_provider`	The name of the LoRa protocol provider over which an uploaded message has originally been received.
`function_port`	The LoRa function port used by a device in an uplink message.
`meta_data`	JSON object containing adapter-specific meta data. The semantics of the meta data can be taken from the particular provider’s documentation.
`additional_data`	Additional data gathered in the context of an uplink message.

These properties can be mapped in the header mappings of the IoT Things connection.

LoRa payload format

The message body and content-type of invoking HTTP requests are LoRa provider specific and therefore vary based on the chosen endpoint. Each LoRa uplink message can contain an arbitrary payload which will be used as the outgoing AMQP message body. Potential meta information of the LoRa uplink message is put in the AMQP message application properties. The available AMQP application properties vary per LoRa provider.

How to get started using the LoRa adapter

The LoRa adapter is currently only available in the Starter and Standard Plan (see Easy and secure device connectivity for the IoT - Service plans at a glance). Therefore you need to make sure that you have subscribed to a payed service plan. Otherwise you will get a 403 FORBIDDEN error even-though the supplied credentials are correct.
Register a device and credentials for the LoRa Network Server Gateway with the device connectivity layer.
Register sensors with the device connectivity layer. The device-id must correspond with the LoRa end-device identifier DevEUI send by the sensor and the LoRa Network Server Gateway. Keep in mind to include the via property with the device-id of the previously registered LoRa Network Server Gateway. This is necessary to link the authentication. The LoRa Network Server Gateway will then be allowed to send messages on behalf of the sensors. Registering credentials for the sensors is not required - authentication will be performed using the credentials of the LoRa Network Server Gateway.
Next, setup and install the LoRa Network Server Gateway as described by the network provider. For the HTTPS endpoint and the HTTP method to use please refer to the table above. For Basic Auth the credentials of the LoRa Network Server Gateway have to be used. LoRa protocol adapter also supports authentication via client certificates. See Device authentication for more information.

Some LoRa providers don’t allow special characters (e.g. “@") in the fields used for HTTP basic authentication. In such cases the auth credentials can also be passed entirely in the username field as base64 encoded string in the form of auth-id@tenant:password. The password field has to be empty in that case.