Philippe Vibien • Iridium SBD DirectIP Broker

Currently the Short Burst Data (SBD) service from Iridium only offers DirectIP and email as a means to communicate with remote terminals. While DirectIP offers a considerable speed and volume advantage over email, it uses a custom binary protocol and requires a static IP address registration with Iridium, which can lead to additional complexity when operating multiple independent applications.

This broker is designed to act a middle man between the Iridium SBD Gateway and your various independent applications that each want to send messages or access received messages from remote terminals. Rather than have each application manage a connection with the gateway using the binary protocol, they speak a simpler text based protocol to the broker which handles all the DirectIP complexity, reducing development time and costs.

The broker accepts JSON formatted requests over STOMP or HTTP REST endpoints and converts them into DirectIP format and forwards them to the Iridium SBD Gateway. The central nature of the broker allows for easy logging and audit trail generation. Furthermore, it reduces setup costs by allowing several applications to share one static IP registration.

Currently the broker allows you to access all features of Direct IP and more including:

• Sending messages

• Receiving messages

• Viewing previously sent and received messages

• Status of queued messages at the gateway

• Automatic message retry if the SBD Gateway is down

• Notification of received messages

The broker is a .Net application which runs as a Windows Service or Linux daemon. It is designed to be run on premises, but can be remotely hosted if this is of interest. The goal of this broker was to lower the complexity of using DirectIP Iridium SBD. If you are interested in trying or licensing the broker, please send me an email.

Example Parameters

Sending a MT message or reciving a MO message is as simple as publishing a JSON formated request to the STOMP broker which will then return a JSON formated result.

An example of sending a message to a remote terminal:

Request:

{

"imei": 300434010008270,

"command": "sendMT",

"message": {

"type": "textual",

"content": "This is a test message!"

}

"Unique-Client-Message-ID": "Msg1"

}

Response:

{

"imei": 300434010008270,

"command": "sendMT",

"status": 3

}

When sending, some of the fields are optional such as the MT-Disposition flag or the Unique-Client-Message-ID. Some fields support multiple entries as well, such as the IMEI to send a message to multiple remote terminals.

An example of checking if a remote terminal has sent a message:

Request:

{

"imei": 300434010008270,

"command": "checkMO",

"detail": "all"

}

Response:

{

"imei": 300434010008270,

"command": "checkMO",

"message": {

"type": "textual",

"content": "Sent from a 9603!"

}

"Time": 1445487318,

"MOMSN": 12,

"MTMSN": 36,

"CDR-Reference": 563812

}

When checking for recived messages, the level of detail in the response can be specified, ranging from just the message content to all the session data including the approximate location of the remote terminal if available.