an IBM blog post last month. As ReadWriteWeb's conversation with IBM software architect Andy Piper discovered, that marketing characterization may not be entirely in alignment with the actual MQTT architecture - and for good, solid reasons.The way IBM sells the concept of the "Internet of Things" is as a new, fully functional, and perhaps even separate Web for the exchange of data between devices. "It makes it possible, potentially, for every device on the network to communicate and share information with every other device," reads
Some types of real-world communications that IBM claims requires a new Web that's the stuff of dreams, are already happening on a practical level without such a Web. This is what we've learned from Alex Brisbourne, the president and COO of KORE Telematics. Since 2003, KORE has been developing wireless connectivity systems for devices that need to share data with other devices, often over limited distances, in the machine-to-machine (M2M) market space. Brisbourne is an outspoken advocate of inter-device communication, though he warns that the scale of the systems on which this communication is, and should perhaps continue to be, limited.
Brisbourne is not a naysayer. He does indeed believe in the potential for future applications on a next-generation wireless network layer for M2M, enhancing the capacity for the types of real-world applications that KORE Telematics provides - which, by the way, include cross-country shipping vehicle tracking, mobile payment processing, and industrial equipment monitoring. What he tells us, in this first of a three-part discussion (in which, fair warning, I do share my personal opinion), is that there are certain real-world applications where the Internet analogy does not, and should not, apply.
Alex Brisbourne: It's fair to say there's all sorts of terminology out in the marketplace. "Internet of Things" seems to have caught on a little, and as a result, has got many fathers with regard to who really invented the phrase - [who hail from the realms of] embedded devices, traditional devices, and obviously traditional M2M. But really when we come down to it - whether we're operating at business level or consumer level, whether it's a centralized app, whether it's sitting on a portable device or on a back-end server - we're really doing nothing more than facilitating remote data access, and then turning that into actionable information in some sort of application. So increasingly, we're seeing that the excitement is ultimately [about] how remote data collection is becoming part of mainstream business expectation over the next three, four, five, maybe ten years, as businesses look to differentiate more - clearly to save costs - by becoming more efficient.
I think up until now, a lot of what's happened in M2M has been about saving money. But I think the next generation is all about making money, in terms of inventing new services. Clearly, no matter how sexy the application is, you can't connect [devices] without reliable and broadly-based connectivity. So I think the maturation of cellular, and to a certain extent, satellite networks, to be able to play a part in this - cost-efficiently, easily deployed, and with a reasonably high degree of reliability - will be the thing that gets [M2M] onto everybody's radar screen over the past two to three years... despite the fact that we [KORE] have been doing it for almost ten, I suppose, and watched some of the growing pains that organizations have had to endure.
Scott M. Fulton, III, ReadWriteWeb: Well, you have to credit Google and IBM to some extent, even though they're really not as involved in the business as you are, with trying to popularize the concept and get it into the public conscience. For you and me trying to evangelize folks on this topic through the '80s and '90s, it was like rolling logs uphill. What they've managed to do is popularize the concept by giving it a kind of science fiction theme.
But one of the things I worry about is that characterizing basic M2M communication as this "Internet of things," as Vint Cerf puts it, may remove it from the context of usability. There's a good argument that for M2M to work, and work well, you really don't want an Internet of things. You really don't want everything communicating with everything else. But you do want sophisticated protocols that are not like the Web, if you will, that are not HTTP, but that enable machine-to-machine communication on a level that cannot be tampered with.
AB: I would generally agree. But I wouldn't totally agree, if you don't mind me saying so. If one thinks of the shorthand of the "Internet of Things," I think one can read too much into the Internet analogy, which is essentially the whole notion of peer-to-peer-based communication, as opposed to host-to-client-based communication. I would say, however, we would think of it in the context of the Internet as the whole flattening of the service delivery architecture as well as, frankly, the data management architecture.
And it's certainly fair to say that, in the world of machine-to-machine communication, particularly as it focuses on the business end of the market, the architecture looks very much more traditional, in many ways. It's typically extremely thin-client, relatively unintelligent, devices with a very highly purpose-specific element attached to them, with a significant amount of the logic and data management (value-add) taking place at the host level. So the device at the end typically manages a lot more relating to exception than it does to processing.
Now, I do believe there are emerging areas within the Internet of Things, particularly M2M, where peer-to-peer does, in fact, become highly relevant. Think of pipeline controls and monitors, for example: I want to move data peer-to-peer across a regulator valve. If I see an upstream fault flow, then I communicate with my nearest neighbors [so they can] isolate a particular part of the pipeline. So you have more intelligence at the individual device level, and have a better peer-related communication.
From that perspective, I think there are certainly some areas where the Internet analogy works quite well. I would honestly say that the majority of people who use the expression, "Internet of Things," truly think of it solely in the context of devices being ubiquitously connected, as opposed to the real architecture of the delivery mechanism.
SF3: I would venture to say that devices maybe don't need to be ubiquitously connected. In the model you just described... there's really nobody else that a segment of pipeline needs to talk to except for the segment next to it. It doesn't need to tell that to me.
AB: Right. Actually, that's also an extremely fair point. I'll use an example of a typical fleet management application, and a relatively complicated, integrated one: Let's say there are UPS trucks that have to pick up from dropboxes. There are many tens of thousands of brown trucks driving around, but the guy handling the route to the dropboxes also wants to pick up from dropboxes that something has been dropped into. So each one has a simple sensor in it that says, "Yes, come and pick something up from me." [It] only has to be able to communicate with a vehicle within a two-mile radius. I do think that... there's a much more increased level of sophistication in the apps, so perhaps as we saw in M2M as little as three or four years ago (to your point), you don't need broadly-based connectivity. A limousine dispatch service only needs to be able to know to dispatch a certain job to people who are in a certain geographic reach of this client.
Scott M. Fulton, III, ReadWriteWeb: If you had broadly-based connectivity, then it would be almost academically easy for someone or something to mess up - probably intentionally - the routing of your limousines or the directions of your delivery drivers. Someone could plant a bug, and it could say, "Guess what, I'm a package and I'm waiting to be picked up by you." People may say, "Surely there's not that much malicious intent in the world." But you know, frankly, it only takes one guy. So there doesn't have to be that much malicious intent in the world.
When I talked years ago with Microsoft about all the different security protocols that they were, at the time, building into Windows Vista, one of the things they said to me in defense of having to backtrack and bolt these things on was, "We never really had an opportunity to test things at this level in the public until we just went ahead and did [Windows XP]. And you have to go ahead and do it, and get it wrong the first time, in order to figure things out." I don't know if we have an opportunity with an M2M network that's ubiquitous, to get things wrong. It would mess everything up. Why do it that way?
Alex Brisbourne, Pres./COO, KORE Telematics: Security becomes a very interesting discussion area in and of itself. I'm more than confident that you've read some of the paranoias that exist in the utility space -
SF3: Oh, yes.
AB: - relating to this. The whole notion that somebody might break into your home meter in Indianapolis and somehow manage to shut down a power station in Texas. Some of it is pretty outlandish stuff, but the concern ultimately is - as it is with the Internet - the ingress/egress point.
Generally speaking, to your point, the level of interconnectivity that's needed for these applications is actually pretty low. They tend to be very much more point-to-point applications, and point-to-point service delivery solutions. So in many ways, that actually helps the notion of security. If your utility meter is being read by your local utility company, and it has an addressing schema that is only available to that company and it's only capable of flowing a particular type of data in one direction - and the only valid route for that data is between those particular points - you massively simplify, in many ways, the security architecture.
SF3: And it's the self-limiting nature of that network topology that provides the authentication. If you're in the network, you should be authentic because the network is so small. You can't retrofit this model to the Web. [Andy Piper at IBM] gave me an example of fishing boats in the bay. There's no other reason you would want to have a network beyond these fishing boats, communicating the weather conditions, the tide, the temperature, the depth of the waves. The security is built into that.
But the one thing the Web does make easy for developers is opening up APIs, which makes applications possible. When KORE Telematics talks about developing smart energy meters for the home, developers are thinking, "It would be great if the developer would open up the API for that, and I could develop any app I want, I could put in on my Android phone, and I could monitor my home energy usage and they wouldn't have to build it for me." That necessitates opening up a protocol; and then you have to talk about, where does that opening up begin and where does it end?
AB: I think you know, this is an area of much interest, of discussion, frankly of debate. Among some schools of thought, there is a strong desire to move towards elements of standardization. And certainly some [standardization] has to occur, noticeably around the edges, the interfaces between different types of sensors. It's easier to write APIs for them in a way that we've seen in the auto industry... sensor technology [for] environmental control, air pollution, water [pollution]. There is significant standardization that already exists because of the use of these devices in previous generations.
I think one of the relatively significant current challenges for M2M, which I think will remain for some significant period of time, is this: The devices that are going to be used towards the edge of networks are, if anything, increasingly rather than decreasingly highly specialized. [This is true] not only in terms of the application - for example, "Am I simply measuring temperature in a joint, or am I measuring air pollution or air pressure, or am I doing something relatively more complex, doing mobile resource management for a plumber?" They're also highly specific to environmental considerations, [such as] power management. A tracking tag that's going to have to run for a year on a battery on a container has a very different design requirement from one that's going to be hard-wired into a UPS vehicle in the ignition system.
Then you have the question of, "Are you wanting lots of data coming from these devices, or are you simply wanting to report exceptions to certain sets of rules?" [Take, for example, this] big piece of yellow construction equipment: Do you simply want to know when it's overheating, or when it's getting close to overheating, or when it's gone over a certain number of engine hours? Or do you want to be constantly pounded with information saying, "I'm feeling fine, thank you." It's interesting: Clearly when you have the first discussion, people think they want to have everything. But in reality, it's like, be careful what you wish for. [It's a trap that MBAs may fall into.] They suddenly realize that the only things that really matter are the events about which they need to make a decision.
We see the need to design for purpose, to manage the environmental as well as power and other related considerations. But then finally, [we also need to take into account] the optimal use of the network, because the one significant driving force behind most of these applications is that we're really talking about remote data. It's everything from miles away to maybe thousands of miles away, not cable length. Which means typically you're paying for recurring charges to a cellular carrier, a satellite provider, or something of that nature. Typically you want to minimize the amount of stuff that's flowing through those airwaves, because that's a recurring cost.
So what we actually see here, Scott, is a significant amount of local customization in the use of these devices, that are just your common, TIA-standardized [Telecommunications Industry Association] interfaces, that are sensitive to a communications device. For example, you want to use standardized IP stacks in the devices so that you know how to interrogate them. You want a standardized modem command set so that you can actually change the communications characteristics, many of which - not all of which - currently exist.
The problem, when you go from having too many alternative standards to designing to a common standard is, if you're not at all careful, you'll blow up the bulk of the edge application device. I'm going to call it "Microsoft bloat," if you're not at all careful.
In Part 2: Is mass commercialization the only way to make the next IoT happen?