Smart, connected things are inherently "connected" and for the most connection technologies you would need some analysis to understand how much information is being exchanged between your IoT device and the cloud.  To help you sort through this we have created this guide that lays out the data components being exchanged and leads you through some typical connection scenarios.


In this guide we assume you are sending text data between your IoT device and the cloud, a smartphone/tablet application or a server you own; for simplicity we will just call these your application.  So, your device talks to your application and vice-versa. We are assuming text conversations, most likely using JSON format for the exchanged information.   JSON is the predominant format for sending information around and if you for some reason are sending pure binary data, you can pretty much convert your binary data length in bytes to the JSON text string length.


To make it easy for you to visualize the calculations below LooUQ has created an online tool, which is free to use.     IoT Bandwidth Estimator


Starting Simple

In the simplest scenario you have a direct dialog between your device and your application.  This involves no protocol such as HTTP or MQTT.  In this scenario the bandwidth is simply the size of your data per unit of time, typically one second. This scenario packs everything your system needs in the payload.  Even in this simple approach, your project can support multiple devices per application, if you provide some type of device address in your payload like below. 

  • If you remove formatting, we have about 75 characters. 
  • If sent once per minute, this would consume (assuming we can use 1,000 for K and not 1,024): 
    • 4.5 KB/hour, 
    • 108 KB/day, or 
    • 3,348 KB/month 


{
    "DeviceId":"IotqiDevice1", 
    "BatteryVoltage":3.948047, 
    "WindSpeed":5.410000
}


Transport Protocols

If you control all aspects of your communications, the above approach is reasonable.  But if your IoT project involves 3rd party providers, it is very likely that a transport protocol will be used between your device and the providers such as LooUQ iotQi, Microsoft Azure, or Amazon AWS.  The most common protocols for IoT communications are HTTP/HTTPS and MQTT, but AMQP can be found out there as well as a couple others.  In all of these protocols additional information is added to your payload data in order to make the whole thing work.  The benefits are increased reliability and scalability.


Here at LooUQ we primarily use MQTT; however HTTP, HTTPS, and AMQP all add weight to your messages in the same way.  Let see how, there are 2 ways these protocols add up to more bandwidth used:

  • Addition of a protocol header (and sometimes a footer)
  • The occasional transmission of keepalives (or sometimes referred to as heartbeats)

Headers and Properties

Headers are generally used by a protocol to describe the payload contents, this is also known as metadata. Many of the protocols out there compose a header by stringing together a list of properties. Properties are a key/value pair of data elements; the key describes the purpose of the data and the value is well the value. Let's look at an example from HTTP.




For the Accept header, the key is "Accept" and a typical value for IoT is "application/json".


Other common HTTP headers are Authorization (contains security credentials), Accept (what we would like to get back), and Content-Type (what the other party is actually returning).  For a more in-depth look at HTTP header, check out this article on Wikipedia. It would be common for somewhere around 3-6 properties to be in a IoT header for HTTP or MQTT. It should be pointed out that in some cases the values in header properties, may remove the need for some data in the actual payload. By example a device identifier is not absolutely needed in a payload, if there is a DeviceId property in the header. For our iotQi platform, we include the properties shown below.


{
    "message-id": "7d03cba5-de8c-458d-9c13-ee92b2afa259-0000015083",
    "iotqi-version": "v-1.0",
    "message-type": "telemetry",
    "event-class": "user",
    "event-name": "wind-telemetry",
    "event-value": "Wind Speed:5.41"
}



Keepalives

Keepalives are small messages sent between the device and the application (the application then responds) 

  1. To ensure each end knows the other side is "alive" (hence the name)
  2. To keep TCP happy


The first objective is straight forward enough, you would want to know if your device suddenly drops off of the face of the earth.  So periodically, usually every couple minutes, the device is going to send a keepalive message.  In the case of the MQTT implementation LooUQ uses, the message is 2-bytes (with 2 bytes coming back).  This happens every 4 minutes for Microsoft Azure MQTT. Do the math... that adds up to a little more than 43KB over the course of a month.




Note: keepalives are only sent if the conversation has be quite for the period of time known as the keepalive interval.  If you are regularly sending data more frequently than the keepalive interval, then no keepalives are needed.


How Can You Conserve Bandwidth

  • Minimize the amount of information you send from your device to your application 
    • Consider keeping as much information about your device on your application and in your server (LooUQ iotQi follows this rule).
    • Think about sending only changed data and very occasionally send a complete data picture to make certain your application knows about your device's current state.
  • If you know that your device is not going to send anything for a while and you don't expect any urgent messages from your application, consider disconnecting. By disconnecting there will be no keepalives. 
    • Make sure that you keep the connection closed long enough to truly reduce the traffic between your device and application.  When devices "connect" there are usually a couple messages sent back and forth to get the connection established.  If these add up to more bytes than the keepalives you skipped, nothing was gained.