Connectivity and Protocols in IoT: Thoughts on picking the right one
There’s lots of ways to move from Point A to Point B: trains, ships, and planes. We instinctively assess the logistics of travel by basing our decisions on factors like distance, cost, and urgency.
If we have to ship goods, similar logic comes into play. It is cheaper to plan in advance if you are importing goods from China to the US. If the delivery of a good is important enough, you would have your product air-shipped.
Barring specific nuances, the same approach needs to be taken for picking up IoT protocols and connectivity options.
- Range between the communicating nodes — for example between the sensor and the gateway.
- Reliability of signal between the communicating nodes — range alone is not enough.
- Latency (time it takes from one to another)
- Throughput/Bandwidth — how much usable information (not the raw rate) can you send through at a time
- Power Source: is it battery powered or not?
- Security: while security is extremely critical — it needs to work at a system level based on the rest of the parameters
- Ease of use, installation and maintenance: these translate to cost, and impact profitability
Note — ‘Node’ above implies all types of physical entities involved in interacting and communicating with each other — devices, sensors, gateways, cloud etc.
Things to keep in mind:
Don’t be myopic when making decisions! For example when addressing the cost of the solution — evaluate more than the COGS (cost of goods). Address, for example, costs associated with installation, provisioning and subscription for data network. To quote a British saying — “don’t be penny wise, pound foolish”.
Do make your decision with eyes wide open — tactical business pressures may prevent you from making a strategic decision — do make a note of the reasons and document them. For example if you are reducing requirements to meet a deadline — make a note of it. Be clear on the reasons you are making so as to adapt the architectural evolution of your IoT application.
Don’t get stuck in an analysis / paralysis. This is a counter-point to the first one. Don’t be stuck in an endless cycle of analysis. Take a decision. Ensure that your system design and development approach is in sync with decision. Make sure trials are rapid, especially in real world environments.