Page tree
Skip to end of metadata
Go to start of metadata

This section describes details about the amount of data used when using the MQTT interface to communicate with the deviceWISE IoT Portal.  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 (ie an API call from a device to the cloud):
    • If the reply is "very fast" (ie <1ms), 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 by 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
  • You can 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.

Example scenarios

Below are some sample scenarios so you can see how the data is calculated.

Please note the following:

  • Scenarios outline "ideal" network conditions, ie no spurious connectivity loss that would result in a reconnection.
  • When using the Asset Gateway, after a connection, several API calls are made automatically to synchronize the agent, these API calls are not included in the below calculations.

Connect every hour and transmit 1 property

ActivityTR50MQTTTCPTotalExplanation
TCP Connect  9696 
MQTT Connect 64128192 
MQTT Heartbeat 4961001 hour heartbeat interval
TR50 Publish Property (request)1091564188 
TR50 Publish Property (reply)471564126 
      
Total data per hour   702B 
Total data per month   500KB 

Stay connected, and transmit 1 property per hour

ActivityTR50MQTTTCPTotalExplanation
TCP Connect  9696 
MQTT Connect 64128192 
MQTT Heartbeat 4961001 hour heartbeat interval
TR50 Publish Property (request)1091564188 
TR50 Publish Property (reply)471564126 
      
Total data per hour   414B Not counting connect
Total data per month   298KB 

Stay connected, and transmit 100 properties per hour

ActivityTR50MQTTTCPTotalExplanation
TCP Connect  9696 
MQTT Connect 64128192 
MQTT Heartbeat 4961001 hour heartbeat interval
TR50 Publish Property (request)163515641714 Assuming batching 100 properties with 85% compression
TR50 Publish Property (reply)471564126 
      
Total data per hour   1.9KB Not counting connect
Total data per month   1.4MB 

 

 

 

  • No labels