MQTT data usage

This section describes details about the amount of data used when using the MQTT interface to communicate with the deviceWISE Cloud .  Generally there are a few considerations, first is the actual payload being transmitted.  

The payload varies depending on:

• If you are using the TR50 interface or the server topics interface.  
• The second is the MQTT protocol overhead, this is the actual MQTT protocol frames that wrapper the payload. 
• And lastly, the TCP overhead that is used to communicate with the hosted systems.

TCP protocol overhead

• Detailed information on the TCP protocol: here
• TCP connection uses approximately 96 bytes (SYN, SYN-ACK, ACK)
• On sending and receiving data, each transmission uses approximately 64 bytes of overhead (PSH, ACK).
• In a send and reply scenario (API calls from devices to the deviceWISE Cloud):
  • If the reply is quick (<1 ms), it is possible the transaction will use 96 bytes of overhead (PSH, PSH-ACK, ACK)
  • If the reply is slow, the transaction will use 128 bytes of overhead (PSH, ACK, PSH, ACK)

MQTT protocol overhead

• Protocol specification available from IBM: here
• MQTT connection uses approximately 86 bytes of data (CONN and CONNACK)
• In a send and reply scenario (ie an API call from the device to the cloud):
  • There will be a PUBLISH from the device to the cloud that will use 15 bytes of overhead (PUBLISH).
  • There will also be a PUBLISH from the cloud to the device with the reply that uses another 15 bytes of overhead (PUBLISH).
• In a server topic scenario of pushing data:
  • There will be a PUBLISH from the device to the cloud that will use 15 bytes of overhead (PUBLISH).
  • If the QOS is set to 1, there will be a PUBACK from the cloud to the device with 2 bytes of overhead (PUBACK).
• MQTT defines a heartbeat interval, and at this interval, the client will send a PINGREQ packet to the server, the server will, in turn send a PINGRSP, each of these packets is 2 bytes of overhead.  The interval for the heartbeats is configurable and affects the delay after a network outage that the client and server detect that there is a communication error.
  • If you set a heartbeat interval of 24 hours, you will only send 1 heartbeat per day, but in the event of a network outage, the client and server will not recognize the outage until the heartbeat message is sent.  This may or may not be acceptable based on your application design.

TR50 protocol overhead

• TR50 uses JSON encoded messages (ASCII protocol).
• TR50 messages can optionally be compressed with zlib to reduce consumption.
• Refer to the API guide for sample API messages to use when sizing: here
• Use the API tester in the Management Portal to see the sizes of different requests raw and compressed
•  When you are using the deviceWISE Asset Gateway, there are two features that you can use to further reduce your data consumption:
  • Command Aggregator
    The Command Aggregator will group many API calls issued within a time window together and build one larger packet (which compresses with high efficiency).  You can specify the time window for grouping to shape your traffic.  Some trial and error will be needed to find the optimal setting for your use case.  In certain test scenarios, aggregation can increase compression from 25% reduction in data without aggregation, to 90% compression with aggregation.
  • Batching
    When using the Command Aggregator, some commands will automatically "batch" themselves to improve performance.  For example, when sending properties, they will be grouped using the property.batch API to reduce overhead when transmitting.  This behavior is automatic if you are using the Command Aggregator.