Browse Prior Art Database

Configurable MQTT Message Subscriptions via MQTT Proxy

IP.com Disclosure Number: IPCOM000239596D
Publication Date: 2014-Nov-18
Document File: 6 page(s) / 57K

Publishing Venue

The IP.com Prior Art Database

Abstract

This proposal presents a solution to a problem where a device manager wants to control MQTT Subscriptions so that applications can only read messages from devices that are relevant to the application (as determined by the device manager). The solution described utilises an MQTT 'Proxy' for applications to connect to and that can manipulate the subscription made by the application (potentially making multiple subscriptions on their behalf) and the messages that are sent to them.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 20% of the total text.

Page 01 of 6

Configurable MQTT Message Subscriptions via MQTT Proxy

This proposal presents a solution to a problem where a device manager wants to control MQTT Subscriptions so that applications can only read messages from devices that are relevant to the application (as determined by the device manager). Components

- Device - A computer connected to the Internet, able to connect to an MQTT Broker and to send MQTT messages.

- Proxy - An MQTT proxy that can act as an intermediate between an MQTT Client and the MQTT Broker. This proxy is capable of changing the Topic of MQTT messages depending on the configuration. The MQTT Proxy will appear to be a MQTT Server to any MQTT Client.

- Broker
- An MQTT Server

- Application Developer - A developer that would want to subscribe to the messages sent from devices (for example, to perform analytics or to monitor devices).

- Device Manager - Somebody that manages access to the device messages, so that only trusted application developers can access relevant devices.

Scenario

    A device manufacturer would like to produce a number of small electronic devices that send data (for example, device health or sensor readings) to a known server. The Manufacturer decides to use MQTT as the protocol to transmit device messages.

    For this scenario, we assume that devices are not powerful (may be limited by battery or a small processor) and are difficult to update (may require a recall of sold units).

    This scenario can be expected in an Internet of Things service with a large number of devices that should be observed by multiple applications (each requiring different access).

    For this scenario, we will assume all devices have been set up to use a unique 'device ID' and will publish to:
/device/

/event/
(where

is the unique device ID)

    Application developers would like to subscribe to the messages of devices, however there is currently no restriction on what they can access (they may be able to read from any of the devices).

    Device managers would like to restrict access to devices so that: 1) Devices' messages can only be seen by application developers they trust. 2) Application developers can only see messages from 'relevant' devices (as decided by the device manager).

    The first requirement can be resolved by forcing application developers to specify a username and password when connecting to the MQTT Server.

The second requirement is the subject of this document.

    Ultimately, application developers would like to subscribe to messages under: /troupe/

/


Page 02 of 6

    The problem does not need to be restricted to devices and applications, any scenario that has the three components;

- a collection of entities that publish messages (that may not be easy to change)

  - a collection of entities that subscribe to published messages
- an entity that decides who can read the messages of what
may be able to use the proposed solution - this document will use devices as an example (as it matches the use-case very well).

    A possible solution to t...