In part one of this series I talked about some of the differences between IoT and (I)IoT, while also summing up multiple variables that play an important role when it comes to the network involved. Throughout this post I’d like to zoom in a bit more on (big) data analytics, the triggering of workflows and where our data could, or should reside. Next to that I will highlight some of the most popular (I)IoT network types today with a main focus on LPWAN and LTE (cellular/4G) technologies including some of their main characteristics, pros and cons. And, oh yeah, I’ve also included another potentially helpful cheat sheet, for your convenience – you’ll find it near the end.
Other related (I)IoT posts:
- All ‘things’ connected, the ‘I’ in the IoT – a closer look. Part one!
- All ‘things’ connected, the ‘I’ in the IoT – a closer look. Part three!
- Defining your IoT strategy – first things first!
- IoT use-case: The Connected Cow! Yes, really
- Citrix Octoblu: an architectural breakdown
Big data and the (I)IoT platform
As briefly mentioned in part one as well, big data and data analytics can, and probably will play an important role, especially when it comes to the Industrial IoT. Before any of this can take place, the data will first need to be collected and stored, into some form of a data warehouse, for example. Here, the amount of data and number of ‘things’ from where data is collected can greatly influence the preferred location of the big data/analytics platform. Also, certain actions triggered based on specific data received might or might not be sensitive to latency etc. it will all depend. Let’s have a look at some real-world examples to see how each of these vary.
With Workspace IoT as an example, certain actions (workflows) might be triggered when a person enters a building or parks his or her car. For example, a virtual desktop might be booted, which will then be ready for login before the user even arrives at his or her desk. Or perhaps a user login will be triggered as soon as a user comes within a couple of feet of a workstation or thin client etc.
Relatively simple actions which do not produce big amounts of data and/or huge amounts of network traffic. Also, the data will probably never leave the building/datacenter. In this case, big data analytics might be somewhat beneficial, but we can take our time gathering and processing it. The same applies to in-house asset tracking, free desks to work at or even the automated booking process of a conference room, as showcased by Citrix during this year’s Synergy event.
If, as in the above example we would like to use a third party, cloud based big data/analytic and/or IoT platform, meaning the generated data would need to be send over the internet to get there (yes, there are other options, but you get my point), this wouldn’t be too big of an issue. Also, there’s no (real) need for real-time analyses, so the data can take its time to get there, so to speak. The triggering of workflows based on certain data received isn’t that big of a deal either, even if it takes multiple seconds to get the data across nobody will notice, it will al still ‘just’ work as designed.
However, when dealing with a mid-sized to large industrial environment like a plant, we are talking about thousands of censors and dozens of other industrial components (see part one for more details on this) generating GB’s of data en potentially hundreds of thousands of data packets. Especially when things like heat/cold, friction, weight etc. and milli or microseconds in delay can mean all the difference in a manufacturing process, (near) real-time processing and data analyses becomes critical – and latency is one of the biggest enemies! While not in a life-threatening way (per se), the idea behind (I)IoT is to automatically re-configure/adjust machinery based on their output as described above. Saving thousands of dollars per month, week, day or hours even. And believe me, i have seen some very real examples of this throughout the last couple of months.
In the above example, data processing and/or big data analytics should probably take place locally, meaning on the same network, within the same building etc. or at least as close to the source as possible. In most cases (not always though, it depends on the characteristics of the workload and what you are trying to achieve) a third party datacenter or cloud platform, in this type of situation would only complicate things. This is also where edge computing has found its way into our datacenters. Not necessarily a complete new concept, but it’s being pushed in new ways with the rise of IoT and (I)IoT.
Tracking and Tracing
Another example would be the use of sensors on containers or pallets, to name just a few. That’s the thing as well, with IoT, industrial or not the only limit in what you can do lies within your imagination. Make sure you understand the company’s core business, its processes etc. and figure out how IoT might help them in saving time, and thus money.
Anyway, together with the abovementioned monitoring of industrial components, tracking and tracing is probably one of the most popular forms of IoT today (and has been for years, we just didn’t call it IoT back then). GPS coordinates will be send (from/through sensors) so we have a general idea (when still in transit) of where our merchandise resides.
It’s obvious that local networks won’t do us any good. Also, (big) data analytics become less interesting as well, though over time you might gather some useful statistics. Here we need a (relatively) wide range and low power wireless network. In general, with tracking and tracing high latency isn’t that big of a deal either. I explicitly mention ‘low power’ because it is important. A high (er) powered network like LTE (cellular), for example drains the sensor’s battery too quickly – a dead battery means human intervention.
IoT Fact: Most sensors today (up to a certain size) come with their batteries and GPS modules built-in. So even if it would be possible to replace a dead battery, it’s still something a human would need to take care of.
LTE vs. LPWAN – A few pros and cons
Like always, low powered and high (er) powered networks come with their own pros and cons. LTE, a cellular type network and high (er) powered (measured in dB, by the way) has a much broader range (up to 7 times better coverage) than all low powered networks combined. Next to that, the maximum throughput in Kbps is also much higher as is the maximum number of connected devices/possible connections.
On the other hand, low powered networks, in the LPWAN (Low Power Wide Area Network) category do conserve battery power (10+ years), which can be very important, but the maximum throughput is way less, as is the overall range/coverage. Also, LPWAN networks are not available in each country or in all regions of a country, they’re still being built throughout the U.S, Europe and other parts of the world. Another drawback, for some is the lack of a standard. LTE networks have the 3GPP standard, most LPWAN network today are proprietary.
Beside the above, there are also multiple, non, or less technical reasons why companies stay away from either 3/4G, LTE and/or LPWAN type networks, which I’d like discus in one of my upcoming posts, part three.
Most popular (available) (I)IoT network types today
I’ve put ‘available’ between brackets because 5G is not available yet (2020) though could potentially play an important role when it comes to (I)IoT in the (near) future. Below I’ll highlight a couple of the most used and popular IoT networks today, including some of their most important characteristics. The primary focus will be on LTE (cellular) and LPWAN networks, I’ll leave 2, 3 and 5G out for now.
LTE (cellular) – Long Term Evolution
Is a standard for high-speed wireless communication for mobile phones and data terminals. Have a look here (Wikipedia) for some more detailed information on its history and capabilities. LTE networks are of the cellular kind and have been around for years (10+) including the well-known 4G standard. In fact, LTE and 4G are often referred to as being, or meaning the same thing. And even though there are some (technical) differences, the ITU-R organization (who set the requirements) agreed on this mainly because of the significant enhancements that LTE brought to the original 3G standard. It’s basically what we all use throughout the day.
IoT Fact: 2G and 3G are both cellular networks as well but are incompatible with the 4G interface. As such, they operate at a different radio spectrum.
I already mentioned a couple of drawbacks regarding LTE type networks, especially when it comes to (sensor) battery power consumption. Also, when dealing with smaller amounts of data being send in an irregular fashion LTE networks do not perform as well as the LPWAN competition. However, with the resurrection of Low Power networks (these have been around for multiple years as well) there have been some interesting developments within the LTE space, like LTE-M and/or NB-IOT, for example both aimed at low power and low bandwidth usage as well. Don’t worry, I’ll cover both in the cheat sheet and in more detail throughout part three of this series. So, while LTE and LPWAN networks are different, you’ll soon find out that there is an overlap as well.
LPWAN stands for Low Power Wide Area Network. It is a wireless type network with the emphasis on connecting low power, low bandwidth, also referred to as narrowband and low cost wireless devices, or ‘things’, like the sensors I keep talking about. The concept was first introduced in the early 1980’s, believe it or not. Back than networks like Alarmnet (owned by Ademco, an alarm device manufacturing company) and Ardis (owned by Motorola), were the first relatively low powered networks, specifically designed to handle low amounts of data and data rates. Alarmnet was/is used for monitoring alarm panels and is still in operation in 18 major areas throughout the U.S. Eventually 3G (cellular) was introduced and shortly after many alarm and similar systems were migrated onto the 3G network.
In 2009 Sigfox started to build the first modern LPWAN network (France), which quickly took off, especially within Europe, and continues to grow by the day. I recently spoke to some of the Dutch Sigfox representatives and their story was quite impressive, as were their numbers. And while today’s LPWAN networks have a lot in common with their pressers, one of the biggest differences is today’s online integration making it possible to apply (near) real-time monitoring, and all the benefits that come with it – the main reason why these types of networks have become so popular in such a short time frame.
Below you’ll find a compact cheat sheet highlighting the most important characteristics and features on a per network type level. Click to enlarge and sharpen the image. Download it in .PDF format here. Note that I’m still relatively new to the wonderful world of (I)IoT, so if you have any comments and/or additions, please do let me know. This is version 1.0 and thus a work in progress, just like the application layering cheat sheet which is up to version 3.0 already.
Most of the features/characteristics mentioned on the cheat sheet speak for themselves, however, there are few that might need a bit more clarification. Let’s start with ‘Standard’. Today the LTE 3GPP standard is probably the best known one. The 3rd Generation Partnership Project (3GPP) unites [Seven] telecommunications standard development organizations (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC), known as ‘Organizational Partners’ and provides their members with a stable environment to produce the Reports and Specifications that define 3GPP technologies.
The project covers cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities – including work on codecs, security, quality of service – and thus provides complete system specifications. The specifications also provide hooks for non-radio access to the core network, and for interworking with Wi-Fi networks. As stated on their website.
Proprietary (Sigfox and LoRa) is the direct opposite; a definition could be: specifications for hardware or software that are controlled by one company. When a proprietary standard such as Windows (as an example) is widely used, it becomes a “de facto” standard even though it is not governed by a standards organization. Both have pros and cons.
The second one I’d like to briefly highlight is ‘Spectrum’. It refers to the frequency being used by a network/technology. In the above cheat sheet you’ll find two types of spectrums, licensed LTE and un-licensed ISM.
With licensed bands, individual companies pay a licensing fee for the exclusive right to transmit on assigned channels within that band in a given geographic area. As an added benefit, companies will be able to apply QoS and won’t have any interference from other (nearby) signals, to name just a few advantages. Of course, the costs will be a bit higher.
Unlicensed wireless technologies, however don’t require any permission, so long as products and users comply with the rules associated with that unlicensed band (for example, the maximum transmission power). However, unlicensed wireless technologies are, by nature, vulnerable to interference. This is why your home or business WLAN can experience signal corruption caused by a neighbour’s WLAN operating on the same channel within the 2.4 or 5 GHz band.
In part three I will highlight each individual network type and talk a bit more about their history, potential future and some capabilities in general.