Azure IoT Edge now enables to better prioritize how your devices use bandwidth. This is particularly useful when your IoT Edge devices are going through a metered or constrained connection. You can now decide which messages are sent first to the cloud and when they should be discarded.
Since releasing Microsoft Azure IoT Edge, we have seen many customers using IoT Edge over metered connections like cellular or satellite connections. For these customers, overall bandwidth consumption is a first concern but prioritizing how this limited connection is used is another one. For the first concern, IoT Edge automatically balances the needs for using as little bandwidth as possible to keep operating costs down while remaining reachable from the cloud whenever possible. However even with a low overall bandwidth consumption, companies operating devices on limited bandwidth must not miss critical data such as alarms due to temporary saturation of their bandwidth with lower priority or expired messages.
Route priority and time-to-live are new features in IoT Edge (version 1.0.10 and above) that address this need by letting customers choose which data should be sent first and when it should be discarded. These features expand the existing message routing features of IoT Edge that declares how messages are passed between IoT Edge modules and to the cloud. Let’s take the example of a ship connected over a satellite connection that sends two types of messages: telemetry messages to provide regular updates on the status of its engines and alert messages when something goes wrong. Those messages used to be sent as part of the same queue before, so when the bandwidth was limited, alert messages were sent only once all telemetry messages in front in the queue were processed and thus risked being received too late by operators. With route priority, customers can now define a priority setting for each route. For instance, they can specify that they want to receive their alert messages first, with a priority set to 0, and telemetry messages second, with a priority set to 1. With route time-to-live, they can now also define a time-to-live setting for each route to discard messages after a certain period. For instance, they can decide to discard telemetry messages that are more than an hour old and haven’t been sent yet but keep alert messages for 24 hours.
Here is an example of how to declare routes in the deployment manifest and define priority and time to live:
"$edgeHub": {
"properties.desired": {
"schemaVersion": "1.1.0",
"routes": {
"alerts": {
"route": "FROM /messages/modules/EngineMonitoringModule/outputs/P0_Alerts INTO $upstream",
"priority": 0
},
"telemetry": {
"route": "FROM /messages/modules/EngineMonitoringModule/outputs/P1_Data INTO $upstream",
"priority": 1,
"timeToLiveSecs": 3600
},
"upstream": "FROM /messages/* INTO $upstream"
},
"storeAndForwardConfiguration": {
"timeToLiveSecs": 86400
}
}
}
Note that IoT Edge deployment schema version 1.1.0 or above needs to be used to define these new settings. For more details, you can look at this documentation.
Now that you've seen how you can configure your IoT Edge device to prioritize specific telemetry messages over others and define time to live for messages that are no longer useful after a specified amount of time, you might be wondering how you can address the other data flows such as file uploads. We are preparing a follow up article that will provide guidance and best practices on how to leverage Linux Kernel capabilities to have a broader control over bandwidth usage by your IoT Edge devices. Don't miss it by subscribing to the IoT Blog!
