IoT: A Comprehensive Introduction To Connectivity 2.0

So you’ve heard the term ‘IoT’. You know that its something to do with technology. Unless you are a DIY builder or an active tech practitioner, chances are that you probably don’t know much more. The proliferation of connectivity in our lives today is quite simply astonishing, and it continues to grow at an ever increasing pace as multinationals and governments pour capital into connecting ‘things’. Imagine this. You finish a hard day of work at 6 pm. You step out of your office to see your car waiting to take you home. You step in, switch the auto-drive function, and then take a nap as the connected car plans the path to your connected home. It then autonomously works its way through a network of connected roads, and informs you when you finally reach. You then step into the shine of your connected home lights, to find a connected kettle that was perhaps programmed for a hot drink at 7 pm. As you drink and make a meal, the television swifts through your past viewings to see if there is something relevant to show you. As you relax and eat, you are informed by your connected speakers that the weather might be bad tomorrow. But that’s fine because your connected car already knows this, and programs the human-centric lighting in your bedroom to wake you up earlier tomorrow. After the meal, you ready yourself for the night. The connected blanket sets the heat for a comfortable sleep, and as you put your head on the pillow, you drift into deep sleep, knowing the difference that technology has made to your life that day. Okay, that was perhaps too idealistic. But this seems to be where we are heading today. Everything is connecting. Everyone is also connecting. Human comfort, maximized via a flow of information and conditional logic across devices and everyday items. This article will provide a broad overview of the IoT revolution, its common architecture, and latest technologies. We start off with a brief overview of the core concept before delving into infrastructures, networks and finally the major protocols in existence today. To understand what it means to be ‘connected’, let’s start by looking at an omnipresent connectivity solution, one that exists all around us in the modern world: the internet. THE INTERNET (OF COMPUTERS) The internet is merely a . Everything you do ‘online’ refers to active manipulation of data from another machine somewhere in the world. In layman’s terms, this means: network of computers a) When you access your email, you request a centralized computer — also called a ‘server’ (Gmail, Yahoo etc.) — to send email data to your machine. b) When you make a payment online, an intermediary program (PayPal, Stripe etc.) initiates the process of deducting the amount from your bank’s server and adding to the recipient’s server. Note that this process can be fairly long depending on the nature of the counterparties involved. A footprint of this process is then sent to your email server as a receipt of the transaction. c) When you stream on Youtube, you are requesting Youtube’s servers to send across video data in a timely fashion (incidentally, that’s why the buffer bar loads a bit, then stays still, then starts loading again). So whatever you do online, you are either data for others to access (think of your Facebook profile picture that your friend can access) via a machine-to-machine (M2M) communication. If one were to be precise, the ‘internet’ is actually an abbreviation of the more accurate ‘internet of computers’. accessing data or uploading Replace the ‘C’ with ‘T’, and you get to the Internet of Things. THE INTERNET (OF THINGS) The genius here is that the set of ‘things’ . So rather than two computers talking to each other, a computer can now talk to a thermostat (NEST) or a light bulb (Phillips Hue) directly. Two traditional ‘things’ can me made to talk: a door sensor can now talk to a camera when someone enters the house (IoT based surveillance). The fact is that any combination of computers and tangible objects can interact with each other as many times as needed, and these devices can interact with further devices down the chain. includes computers, servers as well as everyday items Combine this with global economic trends and you get a feel for the scale of this operation. With each passing year, the emerging ‘third’ world continues to lift in excess of 25 million people above the poverty line. Fishermen, farmers, shoe repairers, toddy tappers, the traditionally underprivileged and the disadvantaged, are all emerging consumers of a pivotal 21st century technology: the cellphone. In fact, this empowerment of the underclass is so rapid that Gartner predicts a total of 50 billion connected devices by 2020. That’s 3 years from now. But take it a step further: who is to say that these systems are to act alone? If you visit the streets of Trivandrum (my home city in India) today, you will find a raft of cars, carts, trucks, rickshaws, lorrys and people moving every which way in a haphazard attempt to reach their points of destination. The only rule is that there are no rules. If you visit the same street in 2070, it’s more than likely that you will find an integrated system of transport— one that regulates itself, one that sources information across surveillance, weather systems, underground subway lines, airports and other local systems, to feed a diet of pertinent and timely information to the future consumer class. Intelligent systems are already paving the way for intelligent systems of systems and everything is connected to everything else. That seems to be the likely result of the information age we all live in today. Who knows, maybe we will soon be talking about an internet of ‘X’ where the X is literally everything imaginable — computers, things, human thoughts, behaviors, and so on… The internet of literally everything imaginable sounds rather odd though, so the next Kevin Ashton is going to have to be more creative with words :). But that’s all in the future. For now, let’s go deeper into the architectural elements of such a system. THE IOT ARCHITECTURE Every IoT system is characterized by a combination of edge devices (called nodes), a cloud (back end servers) and a possible gateway. My (rather horrendous) drawing above captures the conceptual framework behind most IoT systems. Edge devices generally fall into two categories, namely bulbs, radiators etc., which act on a command, and door sensors, thermostats, sensor cameras etc., which sense from their environment. Information about the state of each device is relayed to a central cloud server via one of two duplex communication methods — (a camera pushes an image of an intruder into a cloud database), or (the cloud server periodically pulls house temperature data every half hour). In any case, the user maintains full control of all devices via a network interface on their phone/iPad/another device. actuators — sensors — push pull Note that all devices depicted above use to communicate with the Cloud. This happens when the communication standard native to the device network is different to that of the cloud server. We will return to this concept later on, but the primary purpose of a gateway is to act as a ‘translator’ of sorts. gateways Having looked at the architectural elements of IoT, let’s now try to understand how these things ‘talk’ with one another. We will first review the OSI model — the holy grail of all connectivity solutions — and then move on to look at the major protocols and standards of today. THE OSI MODEL The pen ystems nterconnections model is a framework for sending data across devices. See the layered structure below: O S I The OSI Stack ( Note that the application, transport, network and physical layers are the most important ones to know; hence the variation in color) To understand what the figure means, let’s consider an event we are all familiar with: the transfer of a file from one phone to another. When you choose your file and hit ‘Send’, your phone has to first figure out the . The payload is a string of bits (ones and zeroes), whose length depends on the type of file (image, video etc.) and its respective features (pixel color, brightness, frame rate, compression etc.). Similar to how humans exchange information in the form of alphabets and words, machines exchange information via bits and bytes (combination of bits which mean something). The simplest IoT use case for this concept is . core payload 1 = ‘Turn light bulb on’ and 0 = ‘Turn light bulb off’ The payload data then works its way through each layer of the OSI model, after which it is routed to its destination via telecommunications networks. You might ask what ‘working its way through each layer’ means. Two words: and . encapsulation decapsulation Encapsulation is the first phase and this can be compared to a production process. Take your laptop as an example. It started life as a generic circuit board/PCB at the start of a production chain. A whole host of electronic devices —sockets, slots, power connectors, clock generators etc. — were added to transform the PCB into your alpha motherboard. We then had memory components (ROM, RAM modules), processing units (microcontrollers, chip sets) and other control structures added to produce the modern day CPU. After this, we added the main HDD (hard disk) and video card interfaces. On top of all this, we added a screen, surrounding casing and few ports so that the final structure — your laptop — looks appealing to use. Now think of our payload as the initial PCB. The job of each layer then, is to ‘add’ bits to the payload to make it ready for transmission. In other words, the payload is ‘encapsulated’ at each layer by layer specific information as seen below. Payload Encapsulation The output from the last layer becomes the ‘payload’ for the next layer, which proceeds to add its own (TH = Transport header, NH = Network header, DLH = Data Link header) to whatever it is provided with. overhead The benefit of such an approach is that each layer can be made to serve very specific functions. In an IoT context, the most important layer is the as it is key to (the extent to which devices can talk to a variety of other devices). If device A has a different application layer to device B, they cannot directly communicate with each other. As we shall soon see, this is the reason why consumers of ZigBee devices for example, often experience difficulty in inter-vendor device communication. Moving on, the network and transport headers include message source/destination addresses, forwarding and routing information etc. Data Link headers include MAC addresses, LLC multiplexing, frame synchronizations and other information related to local delivery. A full description of functions is beyond the scope of this article, but the general idea is that each layer is independent of the one above and below it, making its functions exclusive and unique to the overall OSI operation. application layer interoperability The (PHY) defines how the data is to be transmitted. Several methods exist from varying a signal’s frequency/phase/amplitude (F/P/A shift keying) in a multitude of ways (binary, quadrature etc.). We don’t need to know about these in detail, but note that the difference between well known transfer protocols (WiFi, Bluetooth) can be due to the formal definitions at this layer. physical layer Now enter the final stage: modern telecommunications. Beyond the physical layer, the message (payload plus all overheads) is routed towards its destination via a combination of hops (over other devices) and telecommunication channels (wires, phone lines, cables etc.). There is of course, always a chance that the message or parts of it will be lost during transmission. However, under little interference and ubiquitous telecom networks, your message should arrive at the other phone’s physical layer. What happens now? Decapsulation. Each OSI layer at the receiver end removes its respective overhead, until the core payload is exposed. This payload is then stored as a file (e.g. ‘transferredphoto.jpg’) on the phone’s memory, which can be accessed via a respective user application. That’s Telco 101 finished; let’s now relate this to IoT and its protocols. PROTOCOLS A ‘protocol’ is just a we met earlier. Some IoT protocols define all the layers, and others define only a few. Regardless, the underlying OSI structure is the bedrock for all M2M (machine-to-machine) communication methods. permutation of the OSI stack Like the early days of the internet, the IoT space at the moment is a warzone between various protocols. The most significant contenders in the connectivity race are WiFi, Z-Wave, ZigBee, Thread, and Bluetooth along with a few trailing proprietary solutions. We do not know which one will win, but we can be fairly certain that one among the aforementioned ones will emerge victorious. Let’s see which one we should bet upon… WiFi As a classic connectivity solution, and as per the WiFi alliance, carrying through a ubiquitous network of phones, tablets, laptops and other electronic devices, WiFi should by all means, have outstripped its competition by every yardstick in the world. Unfortunately (for WiFi), this has not been the case. half of all global Internet traffic From an OSI standpoint, WiFi technology is defined by the standard for the physical and data link layers. It then uses well known TCP/UDP and IP standards for transport and network layers, and leaves the . IEEE 802.11 application layer undefined WiFi OSI Stack What this implies is that WiFi devices cannot communicate with each other, at least not directly. Now, you might then wonder how WhatsApp calls or email exchanges work. They work because you (or another human) acts as the de-facto application layer. You know that to initiate a call, you have to download the app, create an account, add the contact, tell them to be online during the time of call, and then finally hit the call button. Remember, a protocol is just an OSI permutation defined by layer functions. In WiFi’s case, you perform the duties of the application layer. ‘Things’ in the Internet of Things require hard coded logic, and are (fortunately) not as clever as us. As such, WiFi is . non-interoperable WiFi infrastructures are also based off a . This means that device to device communication is achieved only via a . Thus, if the router fails, all further communication attempts fail. This single point of failure might not matter in home environments, but can cause a problem in enterprise grade IoT (e.g. commercial lighting, smart street lights etc.) star topology mediating router Star Networks Moreover, WiFi was invented for devices needing requirements. Depending on the PHY type (b/g/n), this equates to an impressive . So using good ol’ WiFi allows us to stream a Youtube movie involving the transfer of millions of bits. To facilitate such a transfer, WiFi is extremely , and this overcapacity is actually an overkill in resource-constrained IoT environments. To take an earlier example, we just want to tell our bulb to ‘turn on’ ( ) and ‘turn off’ ( ) — the payload can be fully represented by a single bit. The IoT vision involves a world where globally deployed sensors and nodes feed us data, and in this world, we cannot use solutions that gorge on electricity, or frequent battery changes for that matter. high data rates and bandwidth 10–100 megabytes per second power hungry represented by a 1 represented by a 0 WiFi does however have one major strength to offer: its . Every mainstream consumer electronic device today comes with a WiFi module built in; the only other protocol with this benefit is Bluetooth. If we require every device to communicate with every other device on Connected Earth 2.0, wouldn’t it be cost effective to start with something that is already built in to as many existing devices as possible? Perhaps. But when you imagine powering billions of sensors and items with considerable amounts of electricity and these devices cannot talk to each other, you might think twice before adjudicating in WiFi’s favor. Another issue is the growing global consumer market, causing WiFi’s to become somewhat overcrowded. I certainly wouldn’t be impressed if I trigger a command to turn my bulb off, and the signal gets ‘delayed’ due to the band being . existing network infrastructure 2.4 GHz ISM band prone to interference What we need are solutions. And sadly, WiFi’s current state cannot achieve this. low power, interoperable Let’s now look at the next standard on our race, Z-Wave. Z-Wave Z-Wave was introduced by Zensys in 2003 as an official standard, which was later acquired by Sigma Designs. While WiFi’s strength is its strong network, Z-Wave’s strength is its IoT penetration. The United States is leading the world in consumer home automation, and Z-Wave is the most prominent standard in terms of market position. Abundant anecdotal evidence points to over in active circulation. For manufacturers and vendors in home automation, these figures equate to a potential goldmine. Take a look at the Z-Wave OSI stack: 1700 existing devices in the market and several millions of compatible units Z-Wave OSI Stack There are certain interesting contrasts when you compare Z-Wave with WiFi. As you probably figured out from the figure above, Z-Wave covers the full technology stack and therefore, is an solution. Any Z-Wave device can communicate with any other Z-Wave device, even if they are from separate vendors. This is perhaps a major reason why Z-Wave has garnered the positive attention that it has. Secondly, Z-Wave’s electronics are more in line with what is expected in a constrained environment. Depending on the particular module, you can choose between , which certainly cover most smart home applications and perhaps even enterprise grade IoT solutions. Energy consumption and transmission band tick the box too, as the module uses power in a relatively unused band. Lastly, Z-Wave’s topology is different to WiFi’s star topology that we met earlier. Two devices in a Z-Wave network can communicate with each other without the help of a mediator, whereas in WiFi’s case, this can only happen via a router. Let’s take a more detailed look at how this works. interoperable cross vendor interoperability 9.6, 40 and 100 kilo bits per second very little 868–910 MHz The key point is as follows: each device in a ‘Z-network’ acts as a of messages. This comes in handy if say, the destination is far away and not directly accessible to the source. Think of the message starting at point A and hopping across several other points until it reaches point B. Even before initiating any message transfer, Z-Wave arranges a hypothetical path to the destination via a bunch of other Z-Wave devices. The protocol therefore uses to facilitate a . Other standards like ZigBee are also mesh networks, but as we shall soon see, they rely on different routing techniques. sender, receiver, and transmitter source-based routing mesh network Mesh Networks There are pros and cons to this approach. The obvious benefit coming from the arrangement above is the improvement in communication distance. The mesh network increases the protocol’s from (line of sight) to easily around twice that. Assuming your environment can be contained within an area of a football pitch, Z-Wave should be able to do all the device talking for you. However, there is a central problem. Due to the source based routing procedure, the transmission will fail if any node in the planned path breaks down (e.g. a broken fuse). While the source has mechanisms to attempt other routes ( ) in this case, the healing procedure can cause unacceptable delays in transmission. You know how you are used to pressing a switch and your appliance turning off instantly? How weird would it be if you had to wait 10 seconds after ‘pressing’ off, before the thing actually turns off?!? Latency surely is abnormal UX, right? maximum range 100 m LOS explorer frames The last thing worth mentioning about this protocol is the requirement of a for communicating from devices external to the network. Say you wanted your phone to command your Z-kettle to boil some water in the morning. Assuming your phone is connected to either local WiFi or a 3G/4G network, the command has to be routed through a gateway before reaching the kettle. Why? Because a WiFi stack is different to a Z-Wave stack (see earlier). Your phone sends a ‘WiFi data packet’ which is different to a ‘Z-Wave data packet’, and as such, someone needs to translate for the kettle to understand the message. Internet based control of any Z-device can only be granted through a gateway that is paired to a local home router. As such, every Z-Wave network has to include one of these things. gateway Overall, a pretty good standard with the right idea and definitely a potential race winner. ZigBee ZigBee started life during the 90s, but it wasn’t until 2004 that the ZigBee alliance first published an official standard. Ever since the early 2000s, ZigBee and Z-Wave have been battling it out for domination in the smart space. They both facilitat . ZigBee’s data rate tops off at around , and the power consumption is less than in typical applications certainly favorable numbers in the IoT scene. Let’s look at ZigBee in relation to the OSI model. e low power, low bandwidth, mesh based networks 250 kilo bits per second 1 W — ZigBee OSI Stack This protocol only defines the upper layers of the OSI stack, and delegates the lower layer functions to the well known radio. Note that unlike 802.11 which is only used by WiFi, the 802.15.4 can be used by other proprietary solutions too. IEEE 802.15.4 Unlike any protocol so far, ZigBee has — Light Link, Home Automation, Smart Energy etc. — defined. Additionally if they wished to, a manufacturer could adopt a proprietary application layer of their own. This seems reasonable at first glance: vendors could choose between delivering products that (a) work within standardized ZigBee ecosystems, or (b) only work within their own ecosystems. So depending on whether their manufacturers implanted similar application profiles, two ZigBee devices may or may not be able to communicate with each other. The standard is meant to provide complete backward compatibility towards both LightLink and Home Automation profiles, but it remains to be seen whether this will make the protocol fully interoperable. As it stands, the protocol’s current state is . several standard application layers incoming ZigBee 3.0 a blur between interoperable and non-interoperable Some features are worth comparing between the two ‘Z’ protocols. Both require for reasons outlined earlier. However, while Z-Wave has a limit of devices per network, ZigBee, as per the ZigBee alliance, can supposedly deal with over devices. No conclusive evidence exists for this claim, but if true, ZigBee is perhaps the best placed protocol to support a large scaled IoT application (e.g. smart city). However, caution has to still be exercised: devices sending messages will undoubtedly clog the network, and this is made worse by the fact that ZigBee operates on the same ISM band as WiFi’s . Communication gurus among you should also recognize how the higher frequency band implies around common obstacles (walls, furniture etc.) In contrast to Z-Wave, ZigBee uses routing. Should any node on a given transmission path fail, the self healing process reroutes the message towards its destination fairly fast. ZigBee also supports , which involves the ability to send messages simultaneously to several devices in the same transmission. As of now, Z-Wave does not support this feature. gateways for global device control 232 60,000 60,000 interference prone 2.4 GHz lower penetration power destination-based multicasting ZigBee is certainly ahead of WiFi in our race, but it’s unclear where it stands in comparison to Z-Wave. ZigBee has perhaps had slightly more success in enterprise IoT as it gives manufacturers a greater ability to customize, but who is to say that consumers wont trump enterprises? On to the baby contender in the race: Thread. Thread You’ve probably figured out by now that the connectivity market is highly competitive. With a myriad of established players and proprietary solutions, it would be fair to rank this market at the lower end of your business ventures. But Thread thinks different. The Thread group, started in 2014, is the newest contender in our race. Launched with the sole aim of focusing on the smart home segment and capable of only supporting nodes at maximal usage, this standard promised to specifically address the consumer space. But has it delivered? 250 Not yet. 2016 came to a close without a single Thread certified mass product in the market, and so far, 2017 has witnessed only minor adoption rates (NXP software stacks, Samsung ARTIK & IoTivity etc.). Contrast this with the number of ZigBee certified products and you get a feel for what Thread is up against. One could say that it takes a while before any new technology establishes itself. This is certainly true if you look at ZWave and ZigBee, which have together accumulated over 15 years since birth. So it might not be Thread’s fault that it’s behind as of now, but we do expect a lot from it in future. Thread OSI Stack Take a look at the software stack above. Given that it’s radio is the same as ZigBee’s, the protocol delivers a similar data rate of on It should also be clear by now that that Thread is . 250 kilo bits per second 2.4 GHz. not interoperable Thread’s major strength perhaps, is the way it defines what it does define. Thread, like several others, is a . Moreover, as their names suggest, the network and transport layers deal with accurate message routing and Thread specifies these with the largest scale of devices in mind. Using the 6LowPAN framework underneath UDP (a transport layer technology) , Thread is currently the only protocol with the ability to receive IPv6 data packets over the 802.15.4 radio. That makes Thread networks . Similar to how your laptop has an IP address in a network setting, Thread products can be reached directly if an authorized router sends information straight to the Thread product. If you wanted to do that in a ZigBee setting, you would need a secondary gateway. However, one thing to bear in mind is that as we saw with WiFi’s case, IP connectivity still requires a human to mastermind the OSI procedure. Thread also claims to have no single point of failure, and this is partially true. Certain nodes such as (router-eligible end device), have the capability to downgrade and upgrade their functionalities under specific instances of network disruption. If for example, the assigned leader fails, another node takes its place autonomously. However, as you can probably imagine, in networks with one router and several ‘sleepy end devices’, the failure of the router would still equate to a failure of the network. So this argument also has to be taken with a pinch of salt. mesh network IP addressable routers and REEDs Having said that the group does have . CES 2017 in Las Vegas showcased several major firms — Google, NEST, Samsung, OSRAM, Texas Instruments etc. to name a few — developing proprietary solutions using aspects derived from the Thread protocol. We have an evolutionary tendency to do what others do and so who knows; maybe Thread might gain massive adoption piggybacking the success of existing multi nationals. support from a variety of major corporations To me, what makes this standard interesting is its striking resemblance in technicality to ZigBee. The radio, bandwidth, topology, frequency band, are all the roughly the same. Even power consumption is pretty similar. The Thread stack is more complex than ZigBee’s with its incorporation of 6LowPAN and therefore might consume more power (and bigger microcontrollers), but it remains to be seen if this difference is anything more than marginal. In many ways, Thread looks almost like a successor to ZigBee — its suave, polished offspring — and it should not come as a surprise that the groups have agreed to collaborate on cluster agreements. Parents and children often quibble, but probably don’t mean any inconspicuous harm to one another, right? Well…maybe :) Let’s move on to our final major protocol, the cosmopolitan Bluetooth. Bluetooth Cosmopolitan in the sense that like WiFi, Bluetooth is found in every major electronic device of today. Used mainly for between two devices, Bluetooth is known by many. Staunch supporters include the SIG (Bluetooth’s Special Interest Group), as well as software manufacturers like Windows and Apple iOS. direct and initiated duplex communication This ubiquity is a major strength for Bluetooth. The concept of ‘just connecting and sending data between any two devices’ is alien to ZigBee, ZWave and Thread, but not to Bluetooth. Any modern phone can connect to any other phone, laptop, or Bluetooth enabled peripheral and start exchanging data packets. Excluding WiFi, this is the only other protocol with this feature. However, it is important to realize that the strength of this argument rests only partially on Bluetooth’s competence as a standard, because as you might know, it was invented all the way back in 1994 by Ericcson. With a 23 year history and a timing that coincided almost perfectly with the 90s spike in mass technology adoption, Bluetooth was literally at the right place at the right time to free ride. So, has it really got the legs to lead IoT now? It’s model is depicted below: Bluetooth OSI Stack . To be more precise, the stack shown above is Bluetooth 4.0, also known as Bluetooth Smart. The original classic Bluetooth was meant to be a data heavy solution clocking in an impressive data rate of with a and (the local Bluetooth network). Interoperability and full stack? Check 3 megabits per second, range of 10–100 m maximum of 7 devices per piconet Bluetooth Smart has modified these to be more ‘IoT relevant’. Its theoretical range is more than the classic version, but its data rate has been reduced to a power saving . Why is this important? Because full scale IoT dictates that devices have , meaning they wake up only to perform their functions and go to sleep immediately after. This saves power. When expressed as a ratio between wake and sleep times, Bluetooth, due to its high data rate, records a lower duty cycle than other protocols. Think of sending a lot of information in a very small time (so you don’t have to be ‘awake’ very long), rather than sending smaller data components across a longer duration. But bear in mind that nearly all protocols satisfy this criteria somewhat well — Z-Wave for instance has a minor duty cycle of , even though its PHY transmission mechanism is different to Bluetooth. Moreover, unless your IoT use case is large scale, there probably isn’t much data to be transferred anyway. Even then, devices with lower duty cycles should theoretically last longer on small scale coin batteries. 1 mega bit per second low duty cycles 1% Both versions also feature the technique of hopping. Whereas all the IoT standards so far are frequency bound, Bluetooth dynamically hops between specified channels to ensure fastest message delivery and avoid noisy interference. adaptive frequency Bluetooth’s integration capabilities are also worth accentuating. We have already seen that the technology is built into most electronic products today. In addition to this large ecosystem, the availability of paves the way for . Think of location based services for instance. Your car can quite literally be ‘led’ to an open parking space if an iBeacon is attached to it. Another example: take well being. South Korean trains in Busan use iBeacons to assist pregnant women to find empty seats. Several digital food brands are embracing similar technology to provide customized meal plans to shoppers. All this is on top of extensive beacon use in streamlined inventory management and supply chain tracking. You can see how distinct transmitters capable of passing identifier information to other devices, have the effect of multiplying the potential use cases by a staggering amount. Bluetooth is the only technology with this advantage. iBeacons (Apple) and Eddystones (Google) enormous value based services It is a bit of a shame that Bluetooth currently capability. Devices still have to be within range to communicate via Bluetooth. The SIG’s Working Group in 2016 announced to add mesh capabilities to the existing Bluetooth Smart protocol; we are yet to see how this will pan out post the recent release. does not have mesh networking That roughly covers everything we set out to do. Let’s now wrap this gig up. FINAL THOUGHTS As IoT continues to penetrate our daily lives, the journey towards standardization will prove to be a major challenge. As we saw above, each protocol has its pros and cons, and we can’t predict the eventual victor easily. Interestingly, most manufacturers avoid having to deal with this question by leaving it to their customers, and as such, every vendor and reseller is betting on what they think will win. The truth is this: no one knows who will win. One other thing we have not covered are business related concerns. It’s not just enough for a product to be ‘cool’; it also has to sell. Additionally, what about the roadmap? How do individual products fit into the wider vision in IoT? These are all questions that fundamentally relate to the value proposition for any IoT system. Unfortunately most exhibitions so far, including the most recent HKES in Hong Kong, featured plenty of gimmicky technology without any compelling use cases whatsoever. Finding IoT tech with adequate value potential is another major challenge today, and one that has to be dealt with. In any case, I am quite convinced that connected devices are the future. The vision for IoT is very real and we are likely to attain the level of comfort described at the start of this article. Time will tell more, but for now, the uncertainty is what makes the space extremely fun to observe. To borrow a quote from my man Pliny the Elder (23 AD), ‘The only certainty is that everything is uncertain’. Thank you for reading.