 You know, you make the sacrifice to the demo gods first thing in the morning and sometimes they forget by the end of the afternoon So we'll see how it goes But it is time to get it for us to get started here, and I'm sure that no one wants to hang around late. So Let's go ahead We're here. Hopefully if you are if you are here, I assume you're here for messaging techniques in the IOT If not, then you're in the wrong room and you can go ahead and leave now I always appreciate when they say that on the aircraft that says if you're not on your way to Denver Then you should probably consider leaving now because this flight is going to Denver. Well, that's what we're gonna be talking about We're gonna be talking about messaging techniques in the IOT now When we deal with messaging techniques, if I can get my thing this forward, there we go Just by way of introduction, my name is Mike Anderson. I am chief scientist for the PTR group The PTR group does a fair amount of not only robotics for NASA and DARPA and a few others We also do flight software for various satellite companies. We have about 35 satellites on orbit right now We were the first to put Linux in space as it turns out back in 2006 So we had a Navy satellite and the Navy was willing to take a chance on running Linux because no one had ever used Linux before Everybody was using VX works at that time So they were willing to take a chance and put Linux on the bird and the bird's still up there still working So we're really happy about that Myself I've been in the industry now 40 years this year I started out as a programmer on an 8080 and Altair back in 1977 so I have seen the industry change quite a bit and When you take a look at the devices that are available today raspberry pies beagle bone blacks and things of that sort you just go I can't imagine You know when in my day when I first got started my first embedded system was an IBM 360 mod 30 Which would have taken most of the broom here So today we have quite a bit faster machines and of course that leads us to this whole issue That we're all here to talk about and that is the internet of things Which is a terrible name? Unfortunately, it is the moniker that's been stuck with us by the individual marketing people We'll talk about connectivity in that we'll deal with some of the messaging models that are being used in the IOT And then we'll talk about the different implementations of different messaging techniques We will also compare those in terms of efficiency for the individual Techniques that are going to be using for wireless and connectivity so that you'll have a pretty good idea of okay If I do this it's going to cost me that when I get ready to actually put this across the wireless interface And then we'll hit a quick summary there So in the world of the IOT of course depending on who you believe We could have anywhere from 20 billion to 80 billion devices attached to the internet by the year 2020 Well, that's only three years away the reality is that if you think about the amount of power that 70 billion devices would require it far outstrips the entire power production capability of the world So somehow I suspect we're going to run into a limit long before we get to those kinds of numbers But nonetheless Suffice to say there's going to be a lot of devices attached to the internet We have to deal with several different things when we're trying to design a system for use in the IOT We have to understand a what the system supposed to do obviously What our say size weight and power requirements are and more importantly these days how we're going to connect it if We are dealing with the internet of things We're really talking about things that are connected to the internet or at least connected to each other So how do we handle that connectivity given that we're not going to be running say fiber optic lines or ethernet cables Across an open field out in the middle of the San Joaquin Valley some place So when we're dealing with a lot of the individual applications for the IOT We're really in some cases their solutions looking for problems But nonetheless we have to come with some as a designer It's our responsibility to come up with an approach that allows us to be able to actually make that concept a reality We'll talk about several different topics in this particular presentation. We'll deal with the communications media itself Addressability the individual protocols that are used a little bit of security and of course a couple of other things as we go along the path So in terms of IOT connectivity models, we need to really consider one of a couple of different approaches The first one is what's referred to generally as the cloud model in the cloud model devices are directly Connected to the internet that is my little temperature sensor out in the middle of a field somewhere is actually connected to the internet And it's going to be uploading its raw data to a cloud server some place that is supposed to be doing something with that data Now that particular model on the plus side the data grubbers the data analysts people Want to get all that raw data because they are concerned that somewhere squirreled away in that raw data Is that nugget that they're been looking for that's going to change the entire market? Whether you believe that or not is a different issue They certainly believe it and therefore they put a requirement on those of us who are designing systems To actually try to get them the raw data Now the reality is by having our device directly connected to the internet We are exposing ourselves to all of the black hats that are out there and people who have nothing else better to do with their time Than to try and hack into your system and cause you trouble So that's probably not the general model that we would want to consider There is an alternative approach and that alternative approach is known as the fog model In the fog model the individual sensors and the devices that are out Doing their work in the network Are actually never directly attached to the internet They're attached to a border gateway or a border router and the border router is responsible for taking all of the data Doing some collation of it throwing out bad samples and then sending the cooked data up to the cloud So that the data grubbers then get the cooked data not the raw data Now what this does is this Removes the possibility that there's going to be some hidden piece some hidden gem in the raw data They're not going to see the raw data and therefore they may not be able to find the hidden gem but on the other hand from a security perspective it also limits your attack surface Because now I can focus on making sure that I've got say a Linux device or some other type of device that is Protected hardened hardened kernel remove all the individual You know non-essential services Maybe I'm going to run it in a container who knows but I want to try and eliminate as much of the attack surfaces I can and make sure that the devices that are behind the border gateway are never exposed to anybody from the outside That's the general idea and there are some ways of doing that that Guarantees that no one is going to be able to talk to those things directly from the outside If I'm using wonky protocols on the inside of my little network here That don't route If they don't route it's awful tough for me to be able to get access to them from the outside world Not impossible Nothing is impossible given enough time and money anything is possible but In terms of just trying to eliminate as much of the attack surface as possible The fog model is one that a lot of the individual Corporations that are focusing on the IOT are really trying to hone in on because it's the one that Proposes at least exposes the least amount of attack surface to the outside world Now let's see here. I went the wrong way. I guess there we go Of course in order for us to be able to do anything with the Internet of things We have to think about how we're going to be connecting these devices And there are lots of communications techniques that are out there, of course, we have you know anything from ethernet Of course, we have RS422 RS485 Those are pretty old techniques, but it's remarkable that a lot of the industrial world, especially water purification plants power production plants things along those lines are still Using devices that are 20 milliamp current loop RS485, RS422, RS423 old standards that many of us here in the room probably have never had to deal with Mercifully on your part those of us who have to deal with things like RS485 and RS422 They become the bane of our existence Just simply because of the the nasty the nasty cabling and everything that goes along with it On the other hand what we're really seeing and what we're trying to see in terms of a focus for a lot of the IOT is wireless connectivity and Whether that's traditional Wi-Fi whether that's 80215 for whether that's some of the new modes of LTE cellular We'll talk about those as we go along here But definitely the emphasis for the IOT is wireless connectivity Now understand that in the wireless world if we were to take a look at the entire wireless spectrum From DC to daylight There's not that much that's available to us in terms of available frequencies We do have the ISM bands the industrial and scientific Medical machine bands of course the 2.4 gigahertz band is the one that's kind of universal across the entire globe at this point But there are many many others here in the United States. We have the 5 gigahertz band. There's a 1.2 gigahertz band And where we see a lot of the IOT starting to focus is sub gigahertz Now when we say sub gigahertz here in the United States, that's the 915 megahertz band in Europe That's like 868 megahertz or something along those lines 800 something megahertz in China 700 something megahertz There's also a 432 megahertz band. So it just depends on what part of the world you're in As to exactly why you would be focusing on particular frequency ranges The advantage of sub gigahertz is its distance When we take a look at 2.4 gigahertz and 5 gigahertz especially 5 gigahertz 5 gigahertz has a real problem about penetrating walls and if I have Rebar in the building walls that becomes a major problem for 5 gigahertz 2.4 gigahertz it kind of goes all right, but you'll notice that in most of these rooms. There's a little Repeater that tries to get the Wi-Fi down here because Wi-Fi by itself would not normally go through all these walls So when we start switching to the sub gigahertz bands Then we start talking about being able to do a kilometer or more In terms of the in terms of the range for this particular type of frequency bands So most of us are familiar with the standard 802 11 flavors a b g in a c, etc But there's a new one coming out and this new one is called Wi-Fi halo Otherwise known as 802 11 a h Wi-Fi halo is sub gigahertz It runs in the 900 megahertz band here in the United States It is low power Wi-Fi and its sole purpose is for you to be able to connect up to thousands of devices to a single access point and have those Thousands of devices be able to communicate with the access point was it which will then translate it from Wi-Fi halo into normal Wi-Fi or into Ethernet or some other technology the thing about Wi-Fi halo It's IP based communications In the 20 to 40 megabit per second range So not horribly fast. We're not talking 100 megabit or gigabit kinds of speeds But certainly fast enough that you can actually get a lot of data through at 20 megabits per second The special access points of course then have to be set up to deal with this There's also a variant of this that does mesh topology. So you can actually have a Wi-Fi mesh interstate Network setup. So Wi-Fi halo definitely something that is coming on at this point They have now they've got an official logo So that of course is always a positive sign when they actually go to the trouble of doing the artwork for an official logo And we'll start seeing these sometime this year It's not too far off But because they are running sub gigahertz Without having to do anything particularly magic in terms of antennas We should be able to get a kilometer out of the individual in individual components There's another one out there called Laura. It was originally called Laura now called Laura WAN and Laura is a sub gigahertz, but it's a star of stars So rather than being a wireless mesh or a loosely coupled mesh This is a star of stars topology. It uses a ES 128 for its encryption and Runs in the various bands the EU 868 the 433 megahertz bands and so forth It's based on a proprietary radio technology from a company called sim tech According to the Documentation from sim tech. This is supposed to be a symmetric connection Something less than a hundred kilobits per second The reality is that most of the links I've seen for Laura ran are actually running at thirty eight point four kilobits per second So thirty eight point four K range is about two clicks about two kilometers and urban settings about 22 kilometers in rural settings It is not IP based however so it depends on Concentrators that are then going to take the transmission on Laura WAN and convert it into IP so you can then send it up to the cloud The radios that they have Most of this stuff is available from multiple manufacturers except for the concentrators Once you start getting to the concentrators, then the folks at sim tech still control that they haven't licensed that silicon to anybody else So you pretty much are at their individual mercy In terms of being able to get any additional information out of them So that's a but that's certainly one It has seen a lot of deployment, especially in Africa We're starting to see it deployed much more widely here in the United States and of course in Asia as well Europe has had Laura WAN for a while and We're Expecting to see that probably expand in a certain in a certain extent, but it really is Very much proprietary and because it doesn't use IP as its transport mechanism It means that you're going to have to have some other Messaging technology to get the data across Again, it's supposed to be symmetric. We've seen some cases where it's not quite so symmetric As a matter of fact very asymmetric in terms of the upload speeds versus download speeds But that's usually a factor of the radio itself When we start getting into a situation where we're not getting very good bit error rates They start narrowing the band down to try and do a little bit better in terms of this The signal-to-noise ratio so they can actually get the signal through There's another one out there called SIGFOX SIGFOX is a proprietary cellular like communication service also in the sub gigahertz bands This targets really throw low throughput devices typically remote sensor type devices up to a hundred and forty Messages a day from these devices and the payload is only 12 bytes So you're definitely not going to be running IP across something like this But and the throughput is a whopping hundred bits per second But for very low power type of use SIGFOX is a definitely definitely a viable option Range is about 10 clicks in urban settings about 50 clicks in rural applications So it really focuses on very low power consumption for sensors that just want to wake up squirt a number like a Temperature or something humidity something along those lines Up through the network and then shut back down again Again like we had with Laura Wain. We have a gateway requirement We have to have a gateway in order to convert it from Whatever the internal SIGFOX format is into something that can be routed across the internet Then we have we have the kind of venerable 802 15 for 802 15 4 has been around for a while and It is typically going to be found in the 2.4 gigahertz band But there is quite a few examples of 802 15 4 there are several examples that are running in the sub gigahertz bands and These are typically going to be different manufacturers Technologies that set on top of 802 15 4 802 15 4 defines like six or seven different max In different frequency ranges, so they actually support the Chinese medical band and several others But 802 15 4 actually only defines up through layer 2 Then layer 3 through layer 7 are up to individual manufacturers to set on top of that 802 15 4 is a wireless mesh topology. It is self healing If something if a node goes down, then it'll simply find another way around that failed node and keep communicating Those of us here in the United States We actually see this network in in very broad deployment in advanced metering infrastructure so AMI applications Itron and Cisco have teamed together to create meters that now have the ability to use the 802 15 4 in the 900 megahertz band and Set up a wireless mesh so they can then report information up to the individual monopoly the utility The interesting thing about this particular approach in the way it's being used in advanced metering infrastructure Is that they don't tell you that it's actually a bidirectional communications So the the folks who are reading your meters They used to drive around in a truck and read the meter off of a 900 megahertz radio Then I have to do that anymore now it reports to a cellular link Which is a little gray box typically on side of a on a light pole someplace and that cellular link will then report back to the utility Interesting thing is the utility can now if you don't pay your bill they used to have to send a truck out to shut your power off They don't have to do that anymore now. They can just send a signal from the main service facility and shut your power off automatically Which raises some interesting questions about security, but we'll deal with that a little bit later In terms of the the typical protocols we see on top of 802 15 4 of course Zigbee is probably the one that's the most widely known There's also z-wave The Thread Alliance has their thread System that sits on top of that the Thread Alliance actually only defines up through layer 4 and Then it's up to individual manufacturers to put their layer 5 through layer 7 on top of that One of the interesting things is of course Zigbee IP which came out about three years ago Didn't really catch on Because it was too confusing for the people who were in the members of the Zigbee Alliance What are we using? Are we using IP or are we using Zigbee? But they've cut a deal the Zigbee Alliance has cut a deal with the Thread Alliance Of course the Thread Alliance are the people who are Google Nest and big-ass fans and a whole bunch of other companies There's about 230 or so of them that are members of the Thread Alliance They have cut a deal so that they're going to have the Zigbee libraries available on top of thread So if you can't beat them join them cut a deal and low and hold low and behold We will now see Zigbee layer 4 actually layer 5 through 7 sitting on top of Thread which sets on top of 802 15 4 So the layering of protocols gets to be a little wonky at times But the advantage of 802 15 4 is Linux already supports it We see lots of implementations of it that can be done in relatively lightweight radios and you can get decent performance out of it typically Two clicks with a halfway decent antenna Without having to do a whole lot of extra stuff and it is particularly targeted at low power operation As far as the individual internet of things devices are concerned 802 15 4 looks like a UART So it's very simple You don't really have to have any particular Implementation of the protocol the radios typically implement the protocol and the radios also implement AES 128 encryption So it does have link encryption if you want to go beyond that and you want to go to end-to-end encryption Then typically they'll be using DTLS The datagram transport layer security There is of course one of the big issues that has come about because of where our good friends the telcos are these days Here in the United States. We have reached a hundred and four percent saturation on smartphone usage That is over a hundred percent of everyone who would ever buy a smartphone has one and We say more than a hundred percent because many people have more than one device They have tablets. They have extra phones, etc So they at this point It means that the only way for the carriers the telcos to actually be able to gain more revenue share more market share is By stealing customers from somebody else And we see that's all the time the advertisements come to T-Mobile. We are you know, we're a hundred percent Unlimited data. Oh screw those T-Mobile guys come to Verizon. We have the best signal ever And now everybody now sprain is saying they're within 1% whatever The issue is the only way for them to increase market share is to steal market from somebody else Except when it now comes to the Internet of Things and This has got the telcos really excited because they see this as a whole new market of potentially Billions of devices that are now going to start using their cellular system So in order to support that the cellular communications folks have come up with LTE evolution and With LTE evolution we actually see three new flavors that are targeting low power wide area networks And that is LTE cat one cat M dot one or excuse me dot cat dot M one and Cat dot in B one Cat one is you know, of course one of the major issues with the Telcos they have been focusing on faster and faster and faster networks. They want to be able to deliver 60 megabits per second to your phone But you don't need 60 megabits per second in a device. It's only going to send out a temperature and a humidity once every half hour That's major overkill and of course that radio because it is such a fast radio is very expensive from a power consumption perspective So they've targeted these new variants of LTE One of them a cat dot one is less than 10 megabits per second on the download less than five megabits per second on the upload So most of these are going to be asymmetric That's fine because in most cases we really want to be able to download for instance an update But we really don't care to have the same kind of bandwidth coming back up from the sensor Because the sensor doesn't have that much data to have a report in the first place Cat M one is One megabit per second and that's a symmetric one that's upload and download at one megabit per second We then see cat in B one which is narrow band one and that's 170 kilobits per second on the download 250 kilobits per second on the upload side These all work like normal cellular so you can run IP across them IPv4 IPv6 doesn't matter They behave like cellular they use the cellular infrastructure It's just a new mode for the radios So if you have cellular coverage Then you should be able to see these new standards become available for you in the not too distant future But they the key thing here is that these will be billed as data usage So it does count against your data, and they are counting every single byte you transfer And they are billing you for that which comes into play when we start talking about which messaging techniques We should be using in the IOT Of course the old standards ones like Bluetooth. They've been around for a while We see Bluetooth classic and Bluetooth smart when is Bluetooth not Bluetooth. It's when it's Bluetooth low energy BLE or Bluetooth smart is a completely different standard. It just happens to have Bluetooth as its logo It uses a different radio modulation technique It does happen to sit in the same 2.4 gigahertz band But Bluetooth low energy and Bluetooth classic are really not very well related to each other at all They're completely separate libraries everything else So either one of these however could be running IP or they could run PPP for instance But classic is typically better targeted at this kind of thing because classic is more Connection oriented whereas Bluetooth Bluetooth low energy is like I happen to be walking through the room And there's something that tells me what the temperature is It's going to say what the temperature is whether I asked it to or not I just happen to be close enough by that I could receive that what the temperature is So Bluetooth low energy targeted much more at sensors The problem with Bluetooth if you have a class one Bluetooth device it can actually do a hundred meters I have yet to encounter more than half dozen or so Bluetooth class one category one devices Most of them are cat three, which means we see about 30 meters out of them if we're lucky For those of you who actually use Bluetooth headsets you realize that the range on Bluetooth is actually about three feet Not not by design, but just According to the spec. It's supposed to be much better than that, but unfortunately the spec in reality often differ That's right. So the question is do we want IP or not? And that's an interesting question in and of itself because if we want to be able to say we have a cloud model the cloud model only works if our devices speak IP All the way from our device up to the cloud where we're going to be recording all this data If we're using the fog model then that limitation disappears Because we can speak anything we want to you on the local network segment The only thing that has to speak actual IP is the border gateway So if I'm going to be running in the fog model Then the restriction of having to have IP implemented on my device pretty much goes away But there are a lot of wireless standards that don't support IP as we saw Sigfox for instance that a whopping 12 bytes worth of payload is not going to support IP very well So when we start deciding whether we're going to do IP or not That then drives the decision for which one of those messaging which one of those Communications techniques we use and of course will also drive the decision on the actual messaging model that we use Now the messaging patterns themselves break out into three basic categories We see something called publish subscribe also known as pub sub Publish subscribe basically the sensors are going to publish their data to a broker and the broker will then have the data in It's hands and if someone who has subscribed to the data Will be informed that there's new data available or they can actually go and either it can either be push data Or it can be pull data depending on how we want to set that model up The one that is probably the best example of pub sub is MQTT We'll talk about MQT in some detail in just a moment Another one of the models is client server With client server that's kind of our traditional web service kind of thing I've got a web server setting out there my data gets public you get sent by the client It connects to the server transfers the data and then disconnects We see a couple of different implementations of that restful protocols and a protocol called co-app We'll talk about all of these coming up and then the last one is peer-to-peer the peer-to-peer is now have a point-to-point connection Client server is a modification of that But I might actually have peer-to-peer do relays for me Which is going to be a slightly different model than what we would see typically with traditional client server So these messaging patterns are then represented in various types of messaging protocols The first one we'll take a look at here is message queue telemetry transport otherwise known as MQTT That was originally developed by IBM back in 1999 Long before the Internet of Things was even somebody's You know imagination It is now an ISO standard and has also been standardized by the OASIS folks Which is another standards organization for information interchange It's designed as a lightweight messaging protocol and the interesting thing about the way MQTT works There's really no specific format being placed on the actual payload There's an MQTT header and we have the published subscribe There has to be a broker someplace that's going to be the central repository. There may be more than one broker available to us But it is a pub sub messaging model and there because there's no particular format on the payload It means that we have to kind of figure out ahead of time. I'm going to send this data It's going to be a floating point followed by two decimals followed by a string Everybody has to know that that's going to be the format of the data before you send it Otherwise the people who are subscribing to that data are not going to be able to figure out what the data is The broker has to interpret that puts it into its individual data stores And then the subscribers come along later and grab that information out of the data store MQTT has five basic methods. We have a connect to disconnect subscribe and unsubscribed and then a publish method This one happens to be used by a couple of relatively large vendors Of course IBM's blue mix and the Amazon IOT platform also use MQTT But one of the distinct advantages of MQTT is that most of the IOT frameworks that are out there today all understand MQTT Whether it's Iotivity all seen Alliance You've got of course the folks at Thingworks all these individual major suppliers of or want to be suppliers of Individual IOT solutions all support MQTT. That's kind of the one universal that we have Of course, there are some open source implementations of both the MQTT protocol itself as well as the message brokers Probably the one that's most well-known is the eclipse mosquito But it also turns out that OpenStack in my QTT also do it OpenStack actually does it as kind of a side effect of what OpenStack is supposed to do in terms of virtualization And cloud service providers They just happen to use MQTT as some of the protocols that are being used to exchange information on OpenStack Another one of the messaging protocols is DDS. That's the data distribution service This originally started as a military protocol used in distributed simulations. This is back in the 1990s and It turned out that it had a lot of applicability to many many different applications It's used for instance an Aegis Missile Cruisers. It's used a lot by the military But they've kind of now broken out of that mold and said look what we really we're just a messaging We're just middleware. It doesn't matter if it's a military or a commercial application Let's go ahead and kind of break this out as a separate protocol and kind of distinguish ourselves from the government Applications it is a pub sub protocol, but unlike what we see with MQTT There's no broker in this particular case for for DDS DDS actually does point-to-point It is using multicast so it uses a multicast protocol There's two different levels of interfaces here. We have the data-centric published subscribe Which is focused on the delivery and with DDS you can say that this is just a broadcast of data You can say that it requires an acknowledgement You can say that it requires a security tag so there's different levels of security and different levels of communications with hashes and things of that sort that you can set on every type of data in DDS There's also a version of DDS or a layer that sets on top of DDS called lightweight Corba component model And for those of you who are in the data business, you're probably familiar with Corba This is they do have an implementation of it for DDS it also supports unified modeling language UML profiles and a lot of platform specific modeling So there's a lot of data modeling tools that are available for DDS In terms of where we see DDS right now Most of the DDS stuff is happening in the commercial world where companies like real-time innovations RTI and several others are competing with each other to sell DDS stacks There is an open DDS that has been implemented. So there is an open source version of this How but the open DDS is as I understand it and I could be wrong Is playing catch-up right now with the commercial implementation? So the commercial implementations have been out there for 20 years 20 plus years now The open DDS version is just now coming kind of into its own We have another one XMPP. This is the extensible messaging presence protocol This is actually used by Jabber and Facebook This one all the messages are in XML and it can be sent using TCP and HTTP transports So with XMPP, it's a client server. You can actually use it client server You can use it pub sub or you can use peer-to-peer with XMPP There are multiple open source implementations of this And of course because it's being used by Facebook There are a lot of people who are familiar with it and they've already created applications that take advantage of XMPP Kind of moving along that line that we see rest which is representation representational state transfer This is basically a protocol that just simply uses HTTP verbs. So get post put delete etc Everything looks like a web Service I mean this is none of those classic if I'm an IT guy and I understand how web servers work Then I'm going to design an IOT protocol that work like web servers that's what they've done and The implementation any implementation any protocol a transport mechanism that uses HTTP Could be thought of as restful restful protocol So because it uses standard web service web type transfer verbs Basically, there are lots of open source implementations of restful type protocols Now if we were to take the restful protocol the HTTP get input verbs and Remove all the XML and JSON and all the rest of the stuff and just condense it down to binary That's where we have co-app Co-app is a constrained application protocol. It's essentially a binary version of rest The advantage is that this has been specifically tuned for use in low resource Type devices so very small memory footprints very low data rates It is it sits on top of UDP. It takes advantage of data trans a datagram transfer Excuse me datagram Transport layer securities to DTLS It's compatible with six low pan compatible with IPv4 as well It does have support for resource discovery So we can actually send out what effectively looks like a multicast message that says hey Where's the border router and there may be more than one of them that answer and then it just simply says Oh, well you're closer. I'll start sending my data to you So co-app is a definitely an interesting protocol Can be used typically either in client server or peer-to-peer modes, but the advantage is of that binary transfer It's not using HTML or XML or JSON to do all of its transfers And that of course is a major win when we start talking about where the carriers are right now Of course, there are some other messaging protocols some of the proprietary ones like Zigbee's eWave and wireless heart These are all proprietary. There is no open source implementation of these Whereas with co-app you have an open source implementation. There's several of the others that have open source implementations but For instance with Zigbee if you're not a member of the Zigbee Alliance, then sorry for you You can't do anything you can't design anything that uses Zigbee. You can be a consumer of Zigbee You can be a consumer of wireless heart But if you're going to be producing products that use those standards You have to be a member of their respective alliances in order to be able to get access to the standards and the radios that go along with them Of course the lack of IP here is going to limit our options if we're using something like Zigbee or wireless heart or z-wave They don't speak IP, which means I'm not going to be able to use an 80215 for Six low-pan type of transport mechanism nor am I going to be able to use standard IP So the cases of being able to use halo Wi-Fi halo That's uses IP. So if you're using Zigbee, you're not going to be using halo as your transport mechanism So this also is going to limit your ability to debug the connection because if you don't have the ability to start up Wireshark and watch the track packets go back and forth. How are you going to debug the protocol? You have to buy proprietary tools to debug the protocol which of course can get rather expensive after a while Transmission issues of course sell your carriers love rest and XMPP Because they use XML JSON and HTTP oriented messages, which means lots of more bytes get transferred And since they bill you by the byte they really want you to use these other Protocols that spend a lot of time being very verbose with lots of XML formatting. They love that Of course if you really want to think in terms of HTTP verbs, then co-app is your answer It works like HTTP. It just doesn't use ASCII to send the data back and forth. It uses binary encoded stuff Now cybersecurity, of course, you can't do anything these days without having to worry about cybersecurity Lots of bad actors out there. Of course, we saw last October a Significant denial of service attack against the east coast of the United States Against the DNS servers, which pretty much shut down the east coast At a minimum when we're dealing with any of these radio standards We have to make sure that our links are encrypted If our links are not encrypted then anybody with a receiver can pick them up and start decoding them That might give them some information for instance what? Personaria network what pan ID you happen to be or what kind of other characteristics you have this this guy is a temperature sensor, but this guy controls the motors that actually run the Individual mining equipment so those are the kinds of things that we need to try and protect So at a minimum we're going to want to encrypt the links, but the reality is that simply encrypting the links is usually not enough we need to think in terms of end-to-end encryption and end-to-end encryption means from application to application and When we start talking about application to application encryption now We're talking about either TLS if we're using TCP or DTLS if we're using UDP as our transport mechanisms Of course code signing certificates all that sort of business. We have to take that into account I'm sure you're probably tired of hearing about that kind of stuff after several days of IOT here at this conference But the bottom line is that the fog model makes it a lot easier to secure Because I don't need to worry about each individual sensor being able to get all the way to the internet and get its Acknowledgements back So which messaging API should you use? Well, of course it depends If you're looking for the broadest support you want to have you don't want to tie yourself down to a particular radio Technology or a particular transport mechanism then the best one available to you is probably MQTT. It's the most flexible It's the one that's most widely supported by the most different vendors out there So if you go with MQTT, you're probably not going to go wrong if the transport mechanism is in fact IP If it's not IP then MQTT can still be used We just have to make sure that we understand the mechanisms for doing publish and subscribe when we have a Communications model it's asymmetric and doesn't necessarily support published subscribe kinds of models If on the other hand you want a web-like model Then I would not use rest unless I was talking from the border gateway to the cloud server That you've connected to the internet knock yourself out use whatever technique you want But if I'm going to be going from a low-performance device such as a Cortex M zero plus Cortex M three or in four Out in the field. I don't want to put too much Burden on it. I'm going to allow the radio to do the IP. I'm going to allow the radio to do the communications and the encryption I Want to do as little as little as possible inside of the actual device itself So in that case co-op probably is a better model for you if you like the idea of HTTP get input kind of things Of course, there are a lot of wireless options. Most of them support IP. So we do have a lot of flexibility there MQTT co-op both of those work reasonably well on resource constrained devices Now the internet of things and of course it's brethren the industrial internet of things Which you'll start seeing that one pop up more and more over the next couple of years There has no shortage of offerings whether we're dealing with standard radio communications traffic Unfortunately a big issue with the wireless communications is a limitation in the amount of available bandwidth If you're not running in one of the ISM bands You got to have a license There was a recent licensing that happened with the FCC and I think they paid 18 billion dollars for a frequency band You know trying to get your own personal license for a section of the frequency spectrum Not an easy or cheap thing to do So this really pushes a lot of manufacturers and builders into one of the ISM bands 900 megahertz 868 You know 2.4 gigahertz or 5 gigahertz bands Of course wireless standards like Bluetooth low-energy Wi-Fi 802 15 for they help deal with a physical connectivity They are in many cases very resilient especially 802 15 for or Wi-Fi. Halo Another one that is looks to be very resilient. We don't have enough information about it at this point We haven't seen enough of it to be able to tell but They should be able to provide us that kind of universal connectivity that we're looking for especially if our focus is trying to do things with IP or IP related services like six low-pan You have to consider the attack surface. You have to consider whether or not open source availability is an important thing to you I mean you're here at the Linux conference. We assume I assume at least that you're here because you think open source is a valuable product in a valuable tool So going with a completely proprietary solution for your IOT communications may not necessarily be the right thing to do Certainly, that's my personal opinion, but you know, it's worth what you paid for it. I guess so Consider your attack surfaces when you're getting ready to do your message decisions I have just a couple minutes here and what I want to do is I want to show you an actual IOT thing using MQTT and For those of you who don't really care one way or the other Let's see if I can bring it up here That would be this guy here and Oh, that's right. I need to need to do one more thing. I need to communicate with ADB in Order to kick off the VNC server that I'm using to communicate Because the whole thing is set up to to talk over my cell phone here and Of course, it says send to try again So let me try and do my ADB devices. Ah, there it sees it and Now I'm going to launch the VNC server That should be there That says my server has stopped of course You know, it's a question of up. There we go. Now it says the server is running That's a hopeful thing Let me go ahead and try and launch this now. Oh How about that? Okay, so for whatever reason it's now decided to run in some horribly off-sized mode but that's okay, we'll do the best we can with that and Let's go ahead and launch the tool and Would also help if I turn on the device wouldn't it? This is a TI sensor tag. So this is a cc-25 2650 I think and What it does is it identifies itself as a sensor tag in this little Sampling thing here and I whoops helps if I don't do that. How does it? Simple link starter. Come on Bluetooth Scan there we go center tag. Yay So now it's discovering services and of course you can't see that Soon as it finishes there, we should be able to then scroll up And let me see if I can get that to scroll here But we see the amp the ambient temperature data Come on There we go. Ah All right, so now So it has accelerometers. It has magnetometers. It has Little switches you can push the buttons and these I think these are like 20 bucks But it uses Bluetooth low energy and it uses MQTT to talk from this device to the cell phone and there's actually even a mechanism if you were to scroll back up here There is a mechanism to push it to the cloud So it understands So it does IBM blue mix and you'll be able to actually use MQTT push it up to the cloud and then pull the data out with Node.js and node red and then you can create your own little dashboard It's a great little way and this is actually originally targeted for use on Beaglebone black and a Raspberry Pi So it communicates from this to the Raspberry Pi Where the Beaglebone black and then that links it up to blue mix and then you can get a free 30-day trial of blue mix Play around with the dashboards play around with Node.js node red and be able to pull the data off of it and say Oh, this is really cool. What can I do with this? So if you're interested in doing a little bit of experimentation For 20 bucks and a Raspberry Pi you have the ability to start pushing data up to the cloud. Yeah Yeah, so, you know, so absolutely this one just happens to be the 2650 the 3310s the 3320s the 3200 series Texas Instruments has a lot of different parts that work in different frequency bands and do different things I happen to like this one because it's like I say it's 20 bucks and you can do Bluetooth You can do six low-pan and you can do Zigbee off the same little unit. You just have to load a different firmware to it But absolutely there's lots of opportunities out there lots of alternatives But it kind of gives you a way of being able to kind of get your foot wet with a Technology like MQTT Node red being able to get the data up to the cloud read it bring it back see exactly what that's like Before you make your decisions about how much you're going to commit on a radio or messaging technology Any other questions? Mercifully, no, okay in that case. Thank you very much