Getting IoT-ready – So, you want to get connected?
Overcoming IoT connectivity & data challenges PART 2
The Internet of Things (IoT) is defined as the development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data. It seems easy right? Wrong. The actual process of connecting ‘things’ to the Internet can be a challenge, but it is required to ultimately derive relevant business insights. Businesses who are already collecting sensor data, are at an advantage. In this case, most of the effort is directed towards making data available to analytic engines. However, many traditional, non-IoT businesses are faced with a bigger challenge – How do I get IoT-ready?
For businesses with no, or limited IoT experience, it is not always obvious where to start. Should I build everything in house or should I partner for specific parts of the value chain? Should I outsource to a third party altogether? Before making a decision, product makers first have to face the IoT learning curve. Businesses might consider external expertise and connectivity services/integrators to design, integrate, install and operate their IoT systems.
The following blog series will focus on the challenges product makers face when defining a connectivity strategy and architecture. Topics will cover the following:
- Battle of the protocols – protocols, physical layer and connectivity platform/module selection (part 1)
- Restructuring the company organization to be IoT ready
- Integration and Interoperability – the “Tower of Babel” of platforms and protocols
- Safeguarding the data – privacy and security considerations
- Proving the business case and measuring ROI
1. Protocols, physical layer and connectivity platform
Today’s internet supports hundreds of protocols and the growth of IoT will result in several more. But with so many options to chose from, how can I determine which one is right for me? When evaluating which protocol to leverage, here are some critical considerations:
- Security: Levels vary between IoT applications. Several options to consider: TLS, DTLS, HTTPS, SASL, SSL, Oauth, etc.
- Communication Protocol: Options to consider: HTTP/REST, CoAP, MQTT, XMPP, AMQP, DDS, Thread
- Desired Quality of Service: For mission critical applications, QoS is an option to ensure delivery of the sensor event in unreliable networks
- Request/Response vs. Pub/Sub: MQTT, based on a publish/subscribe scheme, has lower message overhead. It is garnering a lot of traction for IoT data collection
- Websockets: Full-duplex, bidirectional, single-socket connection, low latency/bandwidth
Working through the protocol soup – new IoT connectivity standards continue to surface (such as LPWAN, Lora, Sigfox, Ingenu, NB-IoT, LTE-M, 5G, Wifi Halow, etc). Furthermore there are a number of options available for the physical layer (such as Zigbee, Z-Wave, Wifi, Bluetooth, 2G/3G/4G, LTE, wired Ethernet, etc). Before investing in a physical layer, product makers should consider the following:
- Protocol meets Module: Once protocols and physical layer have been addressed, then comes the connectivity module(s). There are hundreds of different modules and manufacturers available. In the end, it will be a tradeoff between cost, range, reach, features, power consumption, bandwidth, support, reliability, compatibility, network coverage and security capabilities.
- Future-proof vs. Flavor of the Month: With an abundance of IoT connectivity standards it is easy for an IoT ‘first timer’ to get confused. With companies becoming more and more agile, there is a strong desire to be future-proof and not get left behind when something better (and more powerful) comes along.
- Bandwidth and Range: Connectivity and IoT traffic is another point to consider. As more and more products connect to the internet, network operators will try to get a bigger share of the IoT traffic, promoting IoT connectivity anywhere, anytime. Although Wifi, Zigbee, Bluetooth, etc, currently dominates the IoT connectivity market in non-industrial applications they are typically limited to proximity of an internet connection. On the other hand cellular-based IoT applications, have cost and bandwidth limitations.
- Power: Energy used by wireless modules often account for a large portion of power consumption. Wireless protocols and technologies optimized for low power consumption and low data rates are an important factor.
- Serviceability: Businesses will want to choose modules/platforms that allow serviceability (e.g. remote upgrades/patches). Predictive analytics will help targeted servicing of IoT devices to fix bugs, security holes, add new functionalities, etc. In many cases, IoT devices once deployed will never be patched/updated.
Finally, when it comes to processing data, there are a number of alternatives to consider. Whether you do processing on the device, on the company server or in an analytics platform, will depend on the power consumption and cost savings of each alternative (cheaper modules provide limited CPU capabilities). In some cases, product makers will face further constraints of size and power consumption.
Stay tuned for my second post, where we will dive into corporate structures, interoperability, data privacy and proving the IoT business case.
To find out how mnubo can help with your IoT data strategy, request a free consultation today!