In the last article, I wrote about converting Data to Dollars. We discussed how you can overcome key challenges of data interoperability to turn IoT investments into revenue generators. But what about saving dollars?
When you transmit data from your IoT device to the cloud via a service provider, of course, you pay for the cost of data transmission. However, what you might not have realized is that you also pay that same service provider to encrypt your data. And therein lies a known “hidden cost” of IoT security.
In the “IoT world”, data is transmitted more often than in the consumer world, resulting in additional transactions. If you add security headers - frames of data that are required to encrypt & decrypt data - to those transactions, you could unintentionally increase your costs to the point where your business case is invalid.
In this article, I cover how you can employ strategies to save dollars on IoT data costs. Saving dollars can sometimes be the difference between having a valid business proposition and being dead in the water.
Why is IoT security cost so expensive?
Publish and Subscribe, or Pub/Sub, as it is often called, is a communication pattern for device to device communication. The pub/sub model decouples the client that sends a message (the publisher) from the client or clients that receive the messages (the subscribers). Traditionally, technologies that involve publish/subscribe methods, such as the very common MQTT protocol, use MQTT/ TLS to provide security. There are several existing pub/sub protocols seeing heavy use in IoT applications, MQTT is perhaps one of the most notable.
Technologies involving Publish / Subscribe methods have traditionally used MQTT / TLS to provide security. When establishing a data handshake from an IoT device to the cloud the bulky TLS package adds additional “security headers” to the data packet. That means less “useful valuable data” is sent per packet, but your data packets are secure - a tradeoff and ultimately the true cost of security.
In the IoT world, data packets are usually much much smaller, but sent much more frequently than in the consumer world. Let’s illustrate with an example:
Let’s say you only downloaded a single 150GB movie while roaming on a 5G network - and nothing else that month. At the end of your month you check your phone bill and Voila! You get charged for about 150GB plus a few not noticeable bytes for security data. It's such a small difference that you probably would not even notice it - maybe a penny of overages.
Now imagine, instead of transmitting 150GB of movie data, we need to transmit 1MB of IoT data. In the world of IoT, the data we choose to send might just be temperature & pressure values every 5 minutes.
Okay, so now let’s say we have to slice that 1MB of data up into packets that are sent every 1.5 minutes over the course of a single day. For the sake of example that conveniently translates to roughly 1000 X 1kB IoT data packets.
To ensure we are sending that data securely, we need to add security headers to each packet. That now multiplies the total quantity of security-related data by 1000; one equivalent sized header for each message that is securely sent!
But now, instead of a single penny of overages, it's 1000 pennies of overages (€10.00). In some cases, that €10 extra on a common €40 / month bill multiplied times the number of IoT enabled machines a customer owns, is the difference between a profitable venture and going bankrupt.
And that’s just the data transmission on a good day with reasonable connectivity. Let’s take a look at what happens when you have the dreaded “intermittent connectivity” scenario. Reception is okay but fading in and out. You connect …..Nope. You Connect…..Nope. You CONNECT……Nope.
We’ve all been in this scenario before, but what you might not have been aware of, is that some data is still transmitted (just not enough to be useful). Rest assured - someone is paying for that data - and it is NOT your mobile service provider.
The problem is that IoT devices are often deployed in scenarios where connectivity is exactly that - intermittent. That means, in those cases you could easily add a multiplier of 2 times to 10 times on data transmission costs for this overhead before you even get your valuable useful data. How is that happening? Each time I start transacting data, I send billable, but not meaningful data. Before enough valuable data is sent, the connection gets interrupted, for example 256kB the way through a 1024kB message. The result with 3 retries might be 3x256kB + the successful 1024kB with an overall overhead to value ratio nearing 70%. That means in this example, you pay for about 1.7Mb of data, but you only had about 1Mb of user relevant data.
The 9 Strategies
You may be wondering, what strategies can you use to help reduce your data costs? Here are a few strategies to consider:
- Send Less Data
Send insights and gradients instead of data. Do more processing to power your IoT Edge. An example insight might be sending an “alarm flag” instead of sending your raw temperature data and calculating an alarm in the cloud. An example gradient might be anonymizing data and sending only parameters which can be decoded by a central server - which then sends updates back to the decentralized nodes - as in the case of Federated Learning. Check out Fraunhofer who is doing some great work on this topic at their Smart FactoryOWL facility in Lemgo.
- Batch & Match Shifts
If you are generating a daily report, then match that with daily batches (offset by a couple of hours). If you have (3) shifts in a business day - send data in 3 batches. This will make sure you’re not sending too frequently. Be sure to offset the data sending to make sure if there are any technical problems, that it will get there in time.
- Configurable Batching Profiles
You can have a set of configurable static batching profiles that leverage extremely simple - low overhead calculations. Those profiles can include a variety of parameters such as “choose the longer of every X Minutes or if X MB of data are exceeded”. The profile can be customized per customer situation. You can even include other basic rules, alerts or triggers.
- Set a retry limit
Easier said than done, but you will need to set a threshold for the number of retries that finds the balance of guaranteeing the data is sent in a reasonable time frame and optimizing unwanted data costs. Not to mention, you also need to consider the myriad of IoT asynchronous errors (errors that IoT devices create with the cloud that cannot guarantee to be resolved at the same time the error is created).
- Use different Priority Channels
It’s possible to find clever ways to process data in batches. For example, you can send priority data via another channel, such as SMS or perhaps another port. This allows you the ability to collect the less important data at longer intervals and save data costs on the lower priority data.
- ML Batching Profiles
It’s essentially the same as configurable batching profiles, but this time leveraging Machine Learning (ML). Through ML, you can train ML models in the cloud and send those dynamic “when do I send data for my situation” profiles back down to your constrained devices. The usual issue with this approach is that your devices are too constrained to be able to process ML algorithms. If they are not, you might want to check out what companies like GaussML are doing for parameter optimization.
- Reconsider your architecture
I know what you’re thinking - But Marc - I can’t send less data, I’m using IoT Class 2 constrained devices. Ask yourself, instead of going from IoT to Cloud, is it possible to network a series of less constrained processing nodes to your IoT devices? The up-front infrastructure changes might save your entire business proposal.
- Ditch Security
I am not advising to remove all of your security. There are cases where having a smaller encryption block size than necessary can save a business case. In other use cases, the data being sent is useless without intelligent decoding on the other end, in which case moving away from a secure protocol could be the answer. Usually not, but it is possible.
- Use our Patent: Reduce Size of Security Headers
We cannot remove those security headers entirely, but we can reduce their size. This in turn reduces the total overall data packet sent. We found that MQTT/TLS is too bulky and we wanted a more graceful solution so we came up with an embedded method of encryption for pub/sub communicating protocols that enhance savings for TCP/IP most notably for MQTTs.
Finally, if you cannot truly reduce your data costs, you might want to consider abstracting away the costs entirely by moving away from usage based models to a subscription model.
There is a lot to consider with this method. More and more carriers are offering services and APIs that allow you to do this; Vodafone comes to mind - with their NBIoT /LTE-M offering and Melita.Io with their LoRa offering. These providers allow you to offer new business models which focus your offering on value-added services rather than a one off product transaction, or leasing equipment with a single fixed cost (no variable usage cost). These models are great because you can finally answer your customer's questions about how many CAN signals (IoT Telemetry data) they can send for €40 per month?
In conclusion, In the IoT world, data packets are usually much smaller, but sent more frequently than in the consumer world. The problem is that IoT devices are often deployed in scenarios where connectivity is intermittent which could easily add a multiplier of 2 times to 10 times on data transmission costs. To save dollars on IoT data costs, I discussed nine strategies that you can employ. If you cannot reduce your data costs, you can consider switching from a usage based model to a subscription model.
Author: Marc Cyr
