This document discusses best practices for topic namespaces in MQTT applications for M2M communication. It recommends separating data and control topics, with data topics pushing sensor data and metrics, and control topics for dynamic request/response interactions between clients. Control topics should use verbs like GET, POST, PUT, DELETE, and EXEC for requests, and REPLY for responses. A example flow shows a requester sending a GET request on a control topic, and the responder handling the request and sending a response back on the reply topic. Response codes and optional exception messages are also discussed. Finally, the document introduces the Kura Cloudlet for building applications using these patterns with the Kura Cloud Client to handle MQTT connections and routing messages to applications.

1. Advanced MQTT and Kura
Best Practices for Topic Namespaces in M2M
Applications
EclipseCon 2014, March 19th

2. IOT MQTT System Topology
Sensors
Actuators
Legacy
Systems
Smart
Machines
M2M
Multi
Services
Gateway
Human /
Machine
Interfaces
Meters
Console/Port
al
APIs
Business
Logic

3. Request and Response in MQTT
Use cases
• Device Firmware/Software Updates
– Did the device get the update? When? Was it valid & installed?
• Configuration Updates
– Same Questions…
• Remote Resource Control/Interaction
– Device management/Backend business logic needs to
start/stop/interact with a device side service
• Control of actuators
• Dynamic status requests
• Remote Command execution
• Remote Service Control/Interaction
• Other considerations
– Extensibility, mutitenancy, client addressing, multiple applications,
resource management…

4. MQTT Topic Space
Considerations
• Data Topics
– Used for push of sensor data, metrics, or other data
– Example: [account_id]/[client_id]/...
• Control Topics
– Used for dynamic request/response interactions between clients
– Example: CTL/[account_id]/[client_id]/[app_id]/…
• Separate data from control topics
– Provides increased granularity on ACLs
– Allows for segregation of persistent and transient data

5. MQTT Request Verbs
• Request
– CTL/[account_id]/[client_id]/[app_id]/GET/[resource_id]
– CTL/[account_id]/[client_id]/[app_id]/POST/[resource_id]
– CTL/[account_id]/[client_id]/[app_id]/PUT/[resource_id]
– CTL/[account_id]/[client_id]/[app_id]/DEL/[resource_id]
– CTL/[account_id]/[client_id]/[app_id]/EXEC/[resource_id]
• Response
– CTL/[account_id]/[requester_client_id]/[app_id]/REPLY/[req_id]
REST Like

6. Request/Response Example Flow
Responder
(device1)
Requester
(manager1)
Responder
Subscribes on request topic:
CTL/kura/device1/CONF-V1/GET/configurations
Requester
Generates request metadata (for request payload):
request_id: 1363603920892
request_client_id: manager1
Subscribes on reply topic:
CTL/kura/manager1/CONF-V1/REPLY/1363603920892
Requester
Sends MQTT request
CTL/kura/device1/CONF-V1/GET/configurations
Responder
Handles request and generates response using request
specific parameters in the payload of the request
• [request_id] and [request_client_id] included in
request payload
• Manditory response code
• Optional application specific parameters
• Optional logs, exceptions, stacktraces, etc
Responder
Sends response to requesting client
CTL/kura/manager1/CONF-V1/REPLY/1363603920892

7. Response Codes
• response_code
– 200 (RESPONSE_CODE_OK)
– 400 (RESPONSE_CODE_BAD_REQUEST)
– 404 (RESPONSE_CODE_NOTFOUND)
– 500 (RESPONSE_CODE_ERROR)
• response_exception_message
– Optional and contains error message if an error occurred
• response_stacktrace_message
– Optional and contains a stacktrace
HTTP Like

8. Kura Cloudlet
• Uses Kura Cloud Client
– Allows for one MQTT connection across many applications
– Built in configurable store/forward of messages on device
– Handles callback routing to applications based on [app_id]
• Offers simple overrides for request/response operations

9. Kura Cloudlet

10. Thank You