Now, we're going to look at some of the Machine to Machine Protocols. A little bit longer distance in most cases than the ones that we reviewed in the low-level protocols. These are sometimes wired, sometimes wireless protocols that we would use for a variety of system communications, usually at the edge or to a gateway. Will look at what some of the common protocols are. We'll compare and contrast them a bit. Again, things you could consider using as you're putting together your own designs or prototypes Systems. When we start talking about these wireless protocols, we have to categorize them in terms of the types of networks that we're putting together. This goes all the way from a Wide Area Network where we're talking about the long range and the network being in terms of miles or kilometers. Alternate versions of this might be a Metropolitan or a Campus Area, but again, that would be a very wide long range network. We dropped down a little bit into a wireless LAN, which is a really intended for a building or a local area, and now we're getting down to probably 10s and 100s of meters. A Local Area Network might be even smaller, or it might be a room or two. We're really talking about 10s of meters, and a lot of times those, LANs are wired. Then we get to a Personal Area Network, we're talking about a network that's on your person, phone, ear phones, things that are directly adjacent to you at the personal level. When we look at Wired Protocols, of course the most common one probably that we would see in a wired LAN, local area network would be Ethernet. There's a lot of different flavors of Ethernet that give us different performance in terms of interference, distance, and speed. Everything from 10BASE-T to 1000BASE-T versions provide different top-end speed for those networks. The Ethernet networks we're all probably familiar with, could be bus or star topologies, usually with hubs, and switches, and repeaters supporting many devices that are using some sort of an IP addressing scheme. When we think about Ethernet, we often again think about the OSI model that shows, for instance here, an application with its presentation in the session elements using something like HTTP for presentation, TLS for encryption, etc. Then we get into the network level where we're looking at the transfer protocol, TCP or UDP datagrams, the packet transfer level of IP, the Data link layer, which is the actual Ethernet specification, and then the Physical layer where that's running, maybe again on a 10base-T cable. Another common wired protocol we run into a lot is USB, of course, we see that with computers, telephones, all sorts of devices. USB IS pretty neat, good speed, easy to set up, an interesting tiered star network topology. As we all know, the various plug formats have changed over time, but behind it all it's still pretty much the same USB protocol. A single USB hosts can handle a 127 slave devices and the distance gets to be a little longer as you start dropping in powered hubs. Communications is generally initiated by a host device, and the communications is on a bus where the host is transmitting or a device is transmitting. All the devices received the packet sent from the host, but only the device that's being talked to really accepts that data. The devices can transmit back to the host, and again, the hubs are used to repeat the data as it comes in from devices. Serial protocols other than USB aren't quite as common as they used to be, but still you'll run into devices that are using RS-232 cables, RS-422, Rs-485, especially in laboratory equipment. All the laboratory equipment you might run into as you're pulling the systems together, you might still see some of these serial protocols around. There's certainly any number of other protocols out there, Firewire, MIDI, Thunderbolt, which is really a USB variant, Industrial Control Protocols like BACnet, Modbus, the CANbus that's used in automotive communications, so many different protocols out there. When you start to look at your application, you have to consider which of these is appropriate for trying to get to the level of communication that you're trying to reach. We will talk in the next lecture more about the Low Power WANs side, which would include things like cellular conductivity, LoRaWAN and SigFox. In these cases, we're talking about things that have, again, miles and kilometers of range. There's other WAN technology is of course out there, satellite, microwave, etc, that you could consider, but when we're putting together are IoT networks, a lot of times for that longer connectivity will use something like cellular modem or LoRa radio. To make our conductivity, again at relatively low power levels. A ton of other Machine to Machine Protocols out there at the Wireless Local Area Network. The more local home networks that you might put together, Wi-Fi, Wi-Fi HaLow, Zigbee, Z-Wave, 6LoWPAN, EnOcean. There's any number of protocols in this set and more and more every day as people make variations of these protocols. Certainly, we use Wi-Fi pretty generally for most communications where we have a device that's working into an established network in the home. Zigbee and Z-Wave are often used because they're fairly easy for end-users to connect and they provide the level of connectivity that's needed for security or other home control systems. Zigbee and Z-Wave again, are very popular for home automation. Zigbee is known for its low power requirements. It can take a little bit of setup to get a device mesh network running. Z-Wave might be a little bit easier to manage. Generally, Z-Wave devices had been known for being a little more expensive. These things change though as the protocols mature and as the number of devices in the market increase. I have seen implementation issues with Zigbee and Z-Wave. They're both mesh network based, so the nodes can act as endpoints and repeaters. Zigbee uses the 2.4 gigahertz bands, which can interfere with Wi-Fi or Bluetooth. Z-wave uses the 900 megahertz bands, which gives a little longer range for less power. Again, in the early days, especially when needs were being rolled out, there was a lot of issues in interoperability, in range issues, et cetra. I think these days most of these implementation issues have been shaken out. Certainly, you'll find no end of devices out there that use these two protocols. Just as a counterpoint, there's also a lot of custom wireless protocols out there. One example is from a company called Inovonics that uses a proprietary protocol called EchoStream. That's a frequency-hopping spread spectrum protocol. It's used for custom endpoints, repeaters, and gateways in a number of different applications. Why would they use accustomed network rather than using one of the standard protocols? Well, in this particular case, the interoperability between different manufacturers' devices was needed, and the protocol lends itself to easy installation and reliability of event delivery. Again, there's certainly reasons why you might consider custom protocols for different applications as you compare their criteria of the different protocol elements. Personal Area Networks. Now I generally lump Bluetooth in here, although you certainly could have included Bluetooth these days as more of a Wider Area Network protocol. But generally speaking, these are protocols that we use within 10 meters or less, or we use them near our bodies. Bluetooth, NFC, RFID, and ANT are the popular ones that are out there. On your phones, usually, you use elements of Bluetooth and NFC. NFC is interesting because it sets up very quickly and it requires much much less power for connectivity than Bluetooth does. You could, for instance, put an application together where you use these in combination. Where you use NFC initially to establish a communication and then handed off to a Bluetooth communication. Again, your mileage will vary for what applications you're using these for. Bluetooth is very popular. Lots of good radio sets out there for it, and it's easy to work with. There's a newer version of Bluetooth, which is a mesh version that allows you to decentralize the system so there's no single failure point. The message forwarding uses a concept called a managed flood, where messages are cached. They live for a certain time within the network. Again, this mesh was designed to allow Bluetooth to be used more as a Local Area Network tool. It was interesting in listening to one of the developers talking about Bluetooth mesh. They said that 80 percent of the design work was related to security. Bluetooth mesh has fairly complete security for provisioning, blacklisting, and disposing devices, setting up different levels of security for applications and messages. Definitely a good alternative for your own mesh network devices. Quick example here of using GPIO pins with Bluetooth in an Android application. Again, if you are looking at libraries for application development, you'll run into many of them. Blueman, Bluez, Python-Bluetooth. You will fairly easily find support for what's probably one of the most popular protocols that you could include in your IOT systems.
