Bosch IoT Remote Manager

Protocols and Data Formats

RM supports OMA DM based communication over HTTP and HTTPS network protocols. The supported message content encodings are plain XML and Wireless Binary XML (WBXML).

RM URL Format

The RM URLs available for contact from OMA DM clients (devices) are as follows:

For HTTP - http://<rmhost>/syncml-dm
For HTTPS - https://<rmhost>/syncml-dm

Authentication

The OMA DM server in RM supports BASIC, MD5 and HMAC authentication. By default, the server does not require authentication from devices establishing connection.

Configuring authentication is available by means of the special authentication inheritable properties for generic OMA DM devices in the RM device management tree. Inheritable properties can be set to a group of devices, and all member devices will inherit them unless the properties are specifically set to a concrete device. Inheritable properties can be conveniently modified by using the Management Console where they are shown as node settings.

Client Authentication Schemes and Properties

The Mobile DM Manager provider the following properties for configuring client authentication to the management server:

Node Property Name	Node Property ID	Description
Required OMA DM Authentication Type	`omadm.backend.authentication.type`	The backend supports authentication from clients with the following types: None, Basic, MD5 and HMAC.
Device Username	`omadm.backend.authentication.username`	The user name that the device must use for authentication to the management server.
Device Password	`omadm.backend.authentication.password`	The password that the device must use for authentication to the management server.

Server Authentication Schemes and Properties

The Mobile DM Manager provider the following properties for configuring server authentication to the device:

Node Property Name	Node Property ID	Description
Device Require Authentication	`omadm.device.authentication.type`	Select "Yes" (i.e. true) if the device or group of devices require authentication.
Server Username	`omadm.device.authentication.username`	The username that the management server will use for authentication to the device.
Server Password	`omadm.device.authentication.password`	The password that the management server will use for authentication to the device.

Session Initiation

RM supports both models for initiation of management sessions - client-initiated and server-initiated.

Client-initiated sessions - The OMA DM device is "provisioned" with the settings for connection to RM and initiates a management session with the OMA DM server of RM.
Server-initiated sessions - The OMA DM server of RM sends an initiation notification alert to the device to commence communication in the form of a WAP Push message. Server-initiated session requires proper configuration of the settings related to WAP Push notification.
According to the way the sessions are initiated, there are:
Manually initiated sessions - The RM user explicitly requests session initiation from the Management Console.
Automatically initiated sessions - The session initiation alert is automatically sent when a new management operation have to be executed to a device, which is not currently connected.

WAP Push Notification Settings

For a single device or for a group of devices the OMA DM Manager provides the following inheritable properties for configuring OMA DM WAP Push notification:

Node Property Name

Node Property ID

Description

WAP Push Method

wap.push.method

Specifies the method to send the notification to the device. Set it to one of the following values:

SMPP Provider - WAP Push notification will be achieved by sending an SMS message through an SMPP server. Use this method for most standard OMA DM devices. You have to additionally configure the SMPP server settings.
SMS Server - WAP Push notification will be achieved by sending an SMS message according to a Bosch Digital proprietary format. Use this method if the target OMA DM server runs the OSGi stack for the purpose of testing. The SMS server requires that a mobile device is connected to the machine of the management server - the device will be used to send messages to the specified number.

Phone Number

wap.push.number

The phone number of the target OMA DM device.

SMPP Server Settings

When using an SMPP Provider for sending WAP Push SMS messages for session initiation from the backend to a device, the following inheritable properties for a device or device group are used to contact the provider:

Node Property Name	Node Property ID	Description
SMPP Host	`smpp.omadm.wap.push.host`	The host of the SMPP server.
SMPP Port	`smpp.omadm.wap.push.port`	The port on which the SMPP server is listening for requests.
User	`smpp.omadm.wap.push.user`	The SMPP server user name.
Password	`smpp.omadm.wap.push.password`	The SMPP server password associated with the user name.

Switch on Automatic Server Session Initiation

To have an OMA DM device automatically notified to open a management session when an operation is pending over it, use the following inheritable properties for a device or a group of devices:

Node Property Name

Node Property ID

Description

Try Session Initiation

session.initiation.enabled

Set it to "true" to have a WAP Push notification automatically send to the device if there is an operation pending for execution.

Session Initiation Mode

session.initiation.mode

Specifies the mode for session initiation:

background -The session will be initiated in the background transparently to the end user.
informative - The end user will be informed of the OMA DM session launch.
user interaction - The end user has to confirm the starting of the OMA DM session.

Session Maintenance Models

RM supports two models of maintenance of management sessions established by a specific device:

Transactional sessions – This is the traditional model for device management over the OMA DM protocol. The device connects, and RM refreshes the device's configuration and stores this information in its device database so that the device operator is able to view it later. If there are some commands pending on the device, on connection the devices receives them, and after the device reports the outcome of the command execution, the connection is closed. In this mode, all device manipulation actions performed by the device operator are stored in a persistent queue and executed the next time the device opens a connection.
Persistent sessions – In this extended mode, RM explicitly keeps active the session initiated by the device as long as possible, which allows direct interaction between the device and the device operator. This model allows the device operator to execute management operations on the device and receive the execution outcome immediately - it is not necessary to wait till the next time the device connects to RM. Using persistent sessions is suitable for development and debugging purposes as they provide more immediate access to the device.

You can configure RM to use the required session maintenance model for a single device or for a group of devices by using the following inheritable properties for session life cycle in the device management tree.

Node Property Name	Node Property ID	Description
Keep Persistent Sessions	`session.persistent`	If true, enables the support of long living sessions with the device(s). Otherwise, the device will connect to RM, execute the operations pending over it and then will disconnect.
Persistent Session Expire Time	`session.lifetime`	Has meaning only if "Keep Persistent Sessions" is true. This is the time in seconds to wait for the user to perform an operation on the DMT of the involved device. If this time passes and the user is still inactive, the SyncML session with the device will be closed.
Persistent Session Heartbeat Time	`session.pingtime`	Has meaning only if "Keep Persistent Sessions" is true. This is the time period in seconds over which RM sends "heartbeat" messages to the corresponding device in case the user is not actively executing operations on the device.