Week 2: Internet of Things > 2a Networks for IoT 1 > 2a Video 1
- When we talk about that, we really need to distinguish between three different kinds of networks.
- While a sensor networks are primarily focused on low energy, low complexity type of devices.
- Networks are designed to be interoperable, because IoT networks often combine multiple systems in one big system.
- Cyber physical systems, because of a real time guarantees value, predictability, and because of their life safety properties, often need redundancy.
- While the sensor networks, which one can see also as a predecessor in some way of the internet of things, because they are so focused on energy efficiency, they try to minimize network communication.
- Network communication tends to be one of the most expensive parts of running a wireless sensor network.
- So we typically use either local or personal area networks, which means from a frequency perspective, we can extensively reuse the same frequency band, simply because each band, each communication relationship, is such a short-range one.
- They are using a relatively low load inside of a network except if video.
- All the other ones are going to be relatively low network bandwidth usage.
- For security systems, you do want to make sure that they continue to function if somebody cuts the landline, or if we have an outage in one of the cell networks.
- So hubs and gateways often provide multiple network modalities- wireless network, a wired network at the same time, primarily for reliability.
- As a third and final category, we have the direct connection of things to the internet, typically via either classical cellular networks, TV white space networks, TVWS, where they reuse frequencies that were initially assigned to TV stations, or low power wide area networks.
- For those networks, what matters is that the bandwidth that is available has low cost, but is universally available.
- Potentially that lifetime of the device may actually be longer than the network itself.
- Typical networks for cellular network generations may only last 10, 15 years.
- So depending on when you deploy the device into a network in its network lifecycle, the network may run out on you before the device runs out on you.
- We try to on an axis show the huge diversity of communication needs devices tend to have.
- We have devices that have roughly an hourly communication need.
- Then we have devices such as video cameras that might send 10, 20, 50 frames a second and that.
- What has emerged over the years that we’ve had a number of local network technologies that have all established their own kind of benefits and tradeoffs.
- While Bluetooth provides you an extremely low cost chipsets, often very low power.
- So they have found their niches primarily in in-home and building type of networks.
- We have near field communication, chip card type of networks, that are designed for extremely low cost, offer no battery devices or devices where the communication range is intentionally short, simply because it prevents security problems, or makes it very easy to associate the device, the communication modality, and the communication channel all with each other.
- So let’s look at below power wide area networks as another modality is much more recently than these local area networks.
- So we start out with Sigfox, which is a low complexity network used for extremely infrequent communication.
- Then LTE has the technology which is typically used for carrier networks is now being extended into even narrow band IoT version, or [INAUDIBLE] version, the low complexity version, for LTE for devices as well.
- As one of metrics that is used to characterize these different networks is the maximum coupling loss between the transmitter and the receiver in the network.
- The higher that number, the higher the decibel number is, for the same power that you have, or the same interference that you have, the longer range you can support, meaning fewer cell towers you have to deploy to build a nationwide network.
- So if the bandwidth that you might have is only like 100 Hertz type of bandwidth on the channel itself, and that leads then to very low data rates as well.
- So the more devices you have, the lower of a per device communication bandwidth is.
- They will send a burst of traffic into the network, and then be quiet and listen possibly for commands coming back, if they have a sensor.
- An important consideration that has driven a lot of the interest in these low power wide area networks is how much it costs to deploy the network.
- Like I mentioned earlier, in these networks, it’s not performance that matters.
- If you want to deploy an IoT network, you want to be assured that wherever you are that you can get network connectivity.
- They don’t want to have to worry about the cell network isn’t available in one part of the territory versus another.
- They don’t want to have several different network operators.
- So they’re going to flock to a network that can pretty much promise both outdoor and indoor coverage across a reasonably large area or country, at least a state or maybe a metropolitan area.
- So if you compare the network costs, at least for comparison provided here, it’s all estimates, LoRa and Sigfox are actually somewhat higher because we have to build a new network, new towers, new radio transmitters.
- While the others are either software upgrades, or they are going to be in the 5G K is included into the network design.
- This comparison has to be taken a bit with a grain of salt, because often the business models that are behind the carrier model makes it somewhat more expensive to actually support IoT applications than a custom built network, simply because of the plans that they can offer to IoT systems may well turn out to be more expensive, since it’s part of a larger system than a dedicated network would offer.
Week 2: Internet of Things > 2b Networks for IoT 2 > 2b Video
- There is no perfect network on all of those, which likely means we’re going to see both cellular, type of low power wide area networks of dedicated kind, as well as a short range networks of Bluetooth and ZigBee kind.
- The questions that we should ask when we pick networks include how much is the device going to consume in power.
- Because many of these devices are going to be sensitive to bill of material cost, how much does it cost to add a modem as a chip or add on on a board, or can you integrate it into a system on a chip, an SOC? A non-trivial component of many of these device costs is actually not the cost of silicone or production.
- You need to make sure that the latency that you can operate, which is often much larger than what you’re used to from a traditional cellular network, multiple seconds, is supportable for that application.
- I mentioned earlier that an important consideration is network lifetime.
- When you build one of these networks, can you go out and replace the device once it’s deployed? That may be difficult if a device is attached to a tower or a bridge and you don’t want to go in five, 10 years from now to replace your whole network.
- How easy is it to deploy? Can you deploy it easily into some or Wi-Fi type network, city type network.
- For example there are now multiple lower city networks in many European cities, or do you need a national network? And finally as I mentioned, how does your business model correspond to the needs of the applications.
- We probably also need longer antenna, simply because they have longer wavelengths, to support those, which may not be feasible for small embedded devices.
- Assume we have now picked a suitable network that allows us to meet both the technical and business needs of the application.
- The unlicensed band, one of the prime challenges is that the model for many of these unlicensed bands- Bluetooth and Wi-Fi in particular- was designed for a world where human manned, staffed devices were the norm, where you had a keyboard on your laptop that you connected to your Wi-Fi. How do you that in a device that doesn’t typically come with a keyboard, such as an electric meter? You’re not going to attach an electric meter to a keyboard each time you want to install it or need to change your home Wi-Fi password.
- How do you convey credentials to the device as well as to the network in those cases? For a licensed one, we have mechanisms such as SIMs or very recent eSIM proposal to allow remote insulation.
- So networks may not be universally available in the territory of interest.
- In general, authentication becomes a surprisingly difficult challenge for IoT applications, simply because the classical model of one device, one person, at a time at least, no longer holds.
- Devices are often shared in somewhat non-obvious ways.
- If you don’t know what the thing is called, how are you going to enter it into a policy table, give it rights, remove it from a network, or write programs? We tend to focus on the network interface naming because that’s what we’re familiar with.
- So the two choices there are the traditional MAC address, which is called the 64 address [INAUDIBLE], extended version of it, or in the future IPv6 addresses, 128-bit network addresses.
- Those are plenty of addresses to address any conceivable number of network interfaces that might exist on both classical devices, computing devices, as well as on IoT type of devices.
- You don’t want to have to reprogram your device if you swap out your network interface, or if it switches network interfaces from, say, a cellular network to a Bluetooth network.
- So we want to name devices independently of a network as a physical entity.
- If you change network providers, do you have to reprogram your home security system? Not great.
- In some cases, we want to name devices not by hardware- because we might need to replace them- and we don’t want to do it by network interface, because we might want to use multiple network interfaces, but by function.
- We want to address a particular lighting fixture in a particular room, not caring particularly if somebody replaces the light bulb or maybe even swaps out the fixture, because what I care about is turning on the light in a room, not a particular device.
- Thus it’s important in designing systems not just to think about network interfaces, but to think about devices and higher level constructs as well.
- So let’s take a look at one potential way of addressing devices, namely simply giving them phone numbers.
- The number of devices that we would want to tag isn’t all that large.
- Those would be the kind of likely devices that you’d want to name by a telephone number.
- Indeed it’s already becoming common that cars have telephone numbers built in simply because they’re now becoming network addressable devices.
- I’m distinguishing the owned ones that are owned by a particular provider, a network provider for example, the one that you get from somebody else, from a provider of a service- Gmail example, or your local exchange carrier, think telephone company- a phone number, I mentioned a minute ago, and possibly service specific identities that are directly assigned and managed by the service provider.
- So if I own my own my URL here for example, then I can move them to a different service provider without worrying about changing my whole IoT program and readdressing all my devices.
- So I wanted to be naming not just a single device, but a group of devices.
- Thus we currently really don’t have a good higher level abstraction name for these devices.
Week 2: Internet of Things > 2c Securing IoT Networks 1 > 2c Video
- Thus, we are in a period of immense transition where we really need to think about how we’re going to live with these devices that are in many ways much more personal than some of the computing devices that we’ve had- personal in a sense that they might be on our body or they might be able to do physical damage to where we live or to high sensitivity installations, chemical plants, nuclear power plants, transportation system than traditional business oriented computing systems might do.
- When we think of IoT networks, we often tend to think of only private devices, devices that are installed in a home or installed on our bodies, a fitness detector type of devices, where the data is at least meant to be private.
- The picture showing an example of a bus arrival display where the data itself is meant to be public, possibly used by multiple applications and sensing and possibly the actuating data should indeed be public, maybe authenticated, but it’s not meant to be private data.
- All of these cases will have a mix of device characteristics.
- There have been relatively famous examples where companies have disclosed data which they thought was anonymous and aggregate.
- It happened for an online service at some point where you had a well intentioned disclosure of data but it turned out somebody else was a bit smarter than the disclosure had anticipated and were able to de-anonymize at least part of the data where suddenly it was possible with the help of external sources often to figure out who that was that was meant to be just an anonymous entity.
- In some cases, it might help you if you do clever cryptography which allows operations on encrypted data to do less raw data and more encrypted data possibly protecting you against unexpected de-anonymization attacks.
- How do we do software upgrades? How do we reconfigure applications, meaning what do we do about the back end structure of a service not just the built in one that we have? What happens if the company that ran that service is no longer around because they went belly up somewhere along the way? All of this needs to happen and plan for well in advance much more than say a cellular device with an expected lifetime of two years, three years, or so.
- Think of cameras or microphones such as some of these in-home devices that now take voice commands.
- If somebody can break into those devices and essentially has a high quality microphone, they can listen in on any conversation.
- A repeated problem has been that these devices offer new entry points into corporate or home networks.
- So if one is not careful, you can suddenly turn a thermostat or a controller for lighting into an entry point that allows an attacker to have a presence, long live presence, on a corporate or home network, often again because these devices can then either be prevented from being updated or they never updated to begin with.
- A recurring problem in home devices but also enterprise devices is that they combine many software components that are not written by the manufacturer itself.
- Since many of these IoT devices have built in small web servers for configuration or that’s how they interact with the outside world, you now have to worry about SQL injection even though there is no real big database on the device.
- There is a small simple SQL storage engine on the device and is just as subject to various type of attacks as a traditional web portal might be.
- If such checking does not take place, then anybody who can redirect the software update to some other website can now install any software they want on the device, typically the software systems are not signed unlike on cell phones, and can make that device run anything they want whatsoever.
- So checking for all the possible certificate chains, making sure that certificates when they expire get replaced so you don’t have dead devices out there, all of that is something we have not gotten terribly good at yet.
- As I mentioned, in many cases devices will suddenly become inoperative simply because the vendor decided to quit that line of business or not being interested in it at all, and assume that people would just stop running the device which they usually obviously won’t because it works just fine at least initially.
- A final category what is assuming the increasing importance, we’d like to talk about billions and billions of devices, but once you have these billions of devices that also now means you have billions of amplifiers for denial of service attacks.
- Any single one of these devices is probably connected to one or more relative high speed networks, leaving aside the low power wide area network devices- so in a home network, office network.
- So the CPU power of these device is actually quite high.
- So if you’re able as a bad guy to take on these devices as part of your denial of service botnet, you’ve got it made.
- You don’t have to worry about just having a few PCs. You now have these millions of devices of a certain manufacturer, for example, that can all be drafted into your botnet army to launch denial service attacks and that.
- It may not even be visible because the device will often continue to function just fine.
Week 2: Internet of Things > 2d Securing IoT Networks 2 > 2d Video
- One particular challenge that is unique to IoT is what’s known as the enrollment challenge, namely taking a device purchased or delivered as part of a building build out installation and making it part of a network.
- You now want to put in all your smart building configuration devices, sensors, actuators, valves, thermostats, light bulbs, etc.
- All of these in the building you could easily have thousands of these devices.
- You really don’t want to go to each device, hook up a laptop to that device with a USB cable and program the credentials of your network.
- So the current model that we have even at home is that we typically have just one app for each of these IoT devices.
- So you have typically a company that might offer a device class or the device itself.
- Also what happens if you want to change your Wi-Fi password? You want to go around and remember to change every single light bulb device or thermostat, every microwave, every refrigerator? That makes seemingly the daylight savings time changes where you have to now run around and change all the clocks you didn’t know you had an easy one.
- Again, likely to scale only for relatively small device counts, not so useful for commercial buildings.
- So another possibility would be to actually turn around the classical model of device introduction, namely where instead of you giving a password to the device, the device comes to you and says, hi, I’m the new device here.
- If I’m discarding a device or if I’m selling an appliance, I want to make sure that the old appliance doesn’t have my network password in there.
- So we’re exploring as part of my lab research, for example, how we can offer these type of challenge response based models as well as introduction based models that allows you to explicitly admit devices.
- So what you might do is you might use sound or light to convey that in a safe manner simply because the propagation characteristics make it easy to limit the propagation of your password credentials to that device.
- So a number of companies have started to explore using non-radial means to introduce the credential content into devices.
- Almost all IoT devices now have more than enough CPU power to do encryption.
- A common source of vulnerability is that these devices often get set up with a default password, either a fixed password which is in the manual and anybody can find out, or a algorithmically determined password which the attacker by knowing a few pieces of data often discoverable can discover the password itself.
- An important consideration that plays back to the software update one is that the device should not trust any network data just because typically it would be provided by a trusted entity.
- So input validation is just as important for IoT devices as it is for regular web application.
- The second good piece of advice that applies to kindergartners as well as IoT devices is do not talk to strangers, meaning before you connect to an access point or a server for updates or API usage, make sure cryptographically in that case you know who you’re talking to.
- Once you are able to spoof an access point even if it provides internet access and even if you’re using encrypted communication, you suddenly have much greater opportunity to, for example, spoof a DNS resolver and redirect the device to a malicious server of your choice.
- So any flaw invalidation then becomes a fundamental break into device trust.
- Finally, because of a long lifetime that we have in these devices, one should plan what happens if a device can no longer find its mother ship.
- Designing in a fail safe mode that essentially allows the device to function is a minimal functionality may be enough to alert the user that their smoke detector is no longer fully functioning, still perform the minimal necessary function, but not accept network commands in that case so that it can be safely replaced as opposed to becoming an attack target because of its inability to be securely updated.
- How do you credential your IoT system if you, for example, wanted to place a warning call if your basement is flooded? Very useful, but it raises again additional security and programming challenges which will define what we need to do to make IoT more useful than simply a legacy device with a color screen and a few special features that allow you to control things remotely via your smartphone.
Week 2: Internet of Things > 2e Networking: IoT – 6LoWPAN > 2e Video
- In this lecture we’re going to focus on a 6LoWPAN, a practical developed for resource constrained IP based systems suitable for Internet of Things.
- The difference between IPv4 and IPv6 is essentially in the amount of bits allocated for purposes of addressing.
- We’re going to talk now about the link layer for 6LoWPAN.
- Key features required of a link layer of any arbitrary link layer to be able to support internet protocol are framing, addressing, error checking, length indication, and the features of broadcast and unicast.
- One example of all in clear protocol is a ethernet, the other name is media access control layer.
- For purposes of wireless communications at a low power, the IEEE standardization came up with a 802.15.4 protocol which is an important standard for home networking industrial control and building automation.
- It has three physical layer modes, able to transmit at 20, 40, and 250 kilobits per second.
- The way it is used is it is partitioned into 802.15.4 media access control and physical layer with in 800 megahertz, 900 megahertz band, or 2.4 gigahertz band, both of which are overlaid with an upper layer stack.
- One should realize that the adding of the header created a fairly large amount of overhead. So how do we deploy IPV6 over resource constrained nodes? The main features of 6LoWPAN and how it does it is that it supports 64 bit or 16-bit addressing.
- A minimal 6LoWPAN protocol stack is shown on the right hand side in comparison to a traditional TCP/IP protocol stack.
- So we see that primary means of transport layer is UDP for 6LoWPAN.
- That 6LoWPAN uses 15.4 media access control and physical layers.
- The next one is simple LoWPAN where a number of devices configured into one LoWPAN have a single edge router and that single edge router connects to the internet routers.
- It runs protocols which facilitate the changes required for traditional IP protocols to ran towards the 6LoWPAN nodes.
- 6LoWPAN addressing is different from the ordinary IPv6 addressing.
- Essentially IPv6 addresses are compressed for purposes of 6LoWPAN.
- So the compression of IPv6 addresses is done by eliding the IPv prefix, compressing the IID, and by compression of multicast addresses.
- Essentially the global prefix is known by all nodes in the network and the link layer prefix is indicated by the header compression formant.
- We have a core IPv6 internet network connected through a router and through an edge router which supports 6LoWPAN.
- From this point on we are dealing with network addressing specific to this 6LoWPAN network.
- So header is changed in 6LoWPAN based on the definition in 15.4 standard.
- So if there is one fragment that is lost, that means that the whole packet will be lost and then the whole packet will have to be transmitted where the packet is referred to MTU of IP. While the channels have relatively low bandwidth and fairly large delay, that’s an issue itself.
- First the link layer connectivity is established between nodes.
- After which the network layer addressing is configured.
- Neighbor discovery used for IPv6 protocols is not appropriate for 6LoWPAN.
- The other assumption is that all nodes are always on, which may not be true in 6LoWPAN.
- Heavy use of multicast traffic in IPv6 is not entirely easy to support by 6LoWPAN.
- Finally multihop is not efficiently supported over 15.4 which is used for 6LoWPAN.
- Which is used in 6LoWPAN, provides appropriate link and subnet model for all power wireless.
- It provides for node registration and node confirmation, recognition of duplicate addresses and recovery from such, and it supports extended edge router infrastructure.
- 6LoWPAN supports security which is increasingly important for Internet of Things systems.
- All of those are supported in 6LoWPAN essentially through 3 different layers.
- At the application layer, at the media access layer, and at the network layer.
- A layer 2 although we think that internet security is usually thought of just end to end, in wireless networks the wireless channel itself is very vulnerable.
- So at the data link layer we attempt to protect wireless network against attackers and increase the robustness against attacks.
- 15.4 standard provides for a built in encryption using 128-bit AES and it’s own encryption and integrity check.
- One of them called authentication header and the second one called encapsulating security payload. So the authentication header is only concerned with integrity protection and authentication.
- A particular version of ESP is suitable for 6LoWPAN nodes.
- The same hardware engine used for layer 2 in 15.4 can be also utilized for purposes of layer 3 security.
- So this concludes a short presentation on 6LoWPAN, a protocol that deals with constraint issues in Internet of Things systems.
Week 2: Internet of Things > 2f Networking: IoT – CoAP 1 > 2f Video
- This lecture is devoted to the constrained application protocol.
- So internet of things implies devices and networks which are severely constrained at several levels.
- So if we look at the traditional web application set of protocols, here we illustrate the amount of bandwidth that may be taken, and the number of bytes that would have to be transmitted for various layers of protocols.
- IP, TCP transport layer, HTTP protocol, and for objects that carry data.
- Essentially the idea is that with any design specialized protocols, we’re going to notably reduce the number of bytes that have to be transmitted.
- So for internet of things purposes, we talk about 6LoWPAN protocol using UDP, on top which will be layered is the quiet protocol.
- A short illustration of the evolution of a protocol stack.
- What we see is that for purposes of internet of things, we are using specialized physical and media access layer that come from the standardization efforts of the IEEE, the so-called family of 802 dot protocols.
- At the transport layer, we mostly use UDP unreliable data protocol instead of the reliable test mission control protocol requires lots of acknowledgements.
- Before we talk about CoAP, let’s say a few words about REST protocol.
- Every single thing or a resource has to have an ID. The purpose of REST is to link things together using some standardized methods and having resources which might have multiple representations.
- Constrained application protocol is an application which is resource-oriented.
- In IoT devices or nodes, may be powered off just occasionally to wake up and send us small amounts of data.
- Other relevant protocols are different layers for the local area network, again, developed by IETF, is 6LoWPAN or ZigBee, or Bluetooth, Bluetooth Low Energy, and so on.
- How do different segments of URI map into particular protocols.
- So this is a REST request that lies on top of a protocol.
- So constraint application protocol, the most important features of it are that it is an embedded web transfer protocol, and is used for constraint usages.
- It uses an unreliable data protocol as opposed to TCP, for which the availability is not implicit, is not implied.
- So the end point of a CoAP is the source or destination of a CoAP message.
- The end point is always identified by an IP address and a port for termination of a UDP protocol.
- Messages over CoAP are exchanged asynchronously between two endpoints.
- Because we are using UDP as the transport layer, messages from CoAP can come out of order.
- So some additional mechanism for reliability is needed on top of CoAP messages.
- These are the types of CoAP messages- CON, NON, Ack, and Reset.
- The CON message is a message that is confirmable, which means that it has to be acknowledged either by a message type of Ack or Reset.
- A NON message is not confirmed of a message, which will not require acknowledgment.
- This is useful for messages that are repeated regularly, such as coming from sensors where eventual success is sufficient.
- Ack message carry acknowledgements to specific CON messages.
- Reset message indicates that there is a specific message, CON or NON, which was received.
- A reset message is initialized usually by the receiving node that had rebooted, or has forgotten some state, which would be necessary to interpret the message.
- So then a receiver node would provoke a reset message by sending an empty confirmable message.
- So CON message and NON message- one has to be acknowledged.
- Whenever there is a message, a response has to match a token that was used by the original message.
- The same token is used for an acknowledgement message.
- You can observe here that the message on the backwards is not found.
- A GET message would require a separate response for each of the GETS.
- So both client to server and server to client messages are NON messages.
Week 2: Internet of Things > 2g Networking: IoT – CoAP 2 > 2g Video
- CoAP protocol has been designed with requirements that are suitable for constrained environments that internet of things imposes on us.
- The communication between servers, clients that lie inside the traditional network and the constrained network occurs through a CoAP protocol.
- Either directly between clients on the side of a constrained network and the ordinary network, or through a proxy.
- All of the clients on the CoAP side or the internet of things side typically have to be able to support sleeping and wake up.
- A critical feature of CoAP is that the latency is low enough such that machine-to-machine communications can be supported.
- Some mechanism for reliability needs to exist, although CoAP [? PANs ?] on top of UDP.
- So CoAP is a very efficient transport protocol made suitably for constrained devices and constrained networks.
- It is easy to proxy messages coming from HTTP towards CoAP and the other way around.
- One should note that CoAP cannot replace HTTP in general.
- The usage of CoAP are restricted to isolated automation networks.
- Because CoAP uses UDP at the transport layer, the issue of reliability is not inherently handled.
- These are the transmission parameters of CoAP messages.
- Essentially, the message transmission is controlled by the ACK TIMEOUT, with a default value of 2 seconds with ACK RANDOM FACTOR 1.5, with MAX RETRANSMIT times here indicated as 4, with DEFAULT LEISURE of 5 seconds, NSTARTS 1, and PROBING RATE of 1 byte per second.
- Essentially, the endpoints in CoAP may cache responses in order to reduce the response time and network bandwidth when we have future equivalent requests.
- This goes over the HTTP. In the proxy, that gets converted into a CoAP message- get lights- that gets acknowledged, potentially carrying the value with it.
- If a client makes a new request to get lights, and if there were no more recent values that come from the server, then we can reuse the cached value to reply once again to the client.
- So a recap for the CoAP. The main goal of the CoAP is to reduce the size or the number of bytes necessary to execute the transmission of data in cases of constraint applications such as an IoT.
- So whereas a traditional web application may have to use thousands of bytes, the combination of CoAP 6LoWPAN provides for reduction of the total number of required bytes from thousands all the way to tens.
- So this is the last slide talking about the CoAP protocol.
Week 2: Internet of Things > 2h Networking: IoT – MQTT 1 > 2h Video
- Today we’ll talk about a Message Queue Telemetry Transport Protocol, the so-called MQTT. For purposes of Internet of Things, all the layers of communications, as well as all of the components involved in IOT, have to be optimized.
- Essentially, MQTT enables massive scalability and deployment for many different solutions for which IOT’s suitable.
- It’s essentially a messaging protocol, and it services devices with limited computational and communication capabilities, and has a low bandwidth, relatively high latency, and it is designed for low bandwidth, high latency, and unreliable networks.
- So MQTT will minimize the network bandwidth for transmission of data, it will minimize memory and computation requirements, it will provide for and it has the ability to assure some degree of delivery- assurance of delivery.
- So we have publishers and subscribers, which are essentially devices, and all of them, each individually, can be protected by their own firewalls.
- In between publishers and subscribers resides a broker, again it is a device.
- If we do have a common message broker, then the boundaries of firewalls can be crossed as long as everybody else acts as a client to a common message broker.
- The broker lies outside of all of the firewalls and that being so, it is accessible to everybody.
- On the publish/subscribe pattern, we have three different types of actors- publisher, subscriber, and a message broker.
- So the role of a publisher is to connect to a message broker and publish its content on the message broker.
- A subscriber has to connect to the same message broker and it subscribes to content- only that content that a subscriber is interested in.
- Finally, the message broker makes it possible that published content can be relayed to all of those subscribers who are interested in particular content.
- Whatever messages are published to a particular topic are being transmitted, conveyed, to all of the clients who have subscribed to that topic.
- So on one side, we have clients who are subscribed, on the other side we have clients who are publishing, and clients can do both, as well.
- Once you publish a message, it can be available to anybody who is interested in it.
- So the last message is saved on the server and even if a particular subscriber joins later, it will still get a message, and it will get the last message at the moment, or immediately after the moment, of subscription.
- On the other hand- so this is Sensor who’s publishing- on the other hand, we have a subscriber and this particular subscriber is subscribed to Temperature.
- It was subscribed, actually, to all sub-branches of the Sensor class that start with Clayster, then any subtopic which in turn have a Sensor slash subtopic.
- So the lowest level is unacknowledged service, which means that any one message gets delivered no more than once, at most once, to each subscriber.
- That means that that makes sure that any content is delivered once and only once to each subscriber.
- Server can keep messages even before it sends it to all current subscribers.
- So if a new subscription is submitted for the same topic that existed before, then all the retained messages are sent to a new subscribing client.
- So all the retained messages are sending to somebody new who subscribes later.
- Initially, when an MQTT client connects to the server, it sets the clean session flag and it has a choice of setting the flag to true or false.
- So subsequent messages that arrive carrying a high QoS designation are stored for later delivery after the connection is re-established.
- This is a message that should be published to a specific topic or topics in case that there is unexpected disconnection of that client to that server.
Week 2: Internet of Things > 2i Networking: IoT – MQTT 2 > 2i Video
- Support for user authentication in MQTT is weak, because plaintext, username, and password authentication provide obvious risks- especially if the server is not hosted in a controlled environment.
- So the most obvious problems can be circumvented if MQTT is used over an encrypted connection using secure services there, or TLS. Other methods in support of security, which are not defined by MQTT itself, are use of client side certificates, or pre-shared keys to identify individual clients, instead of using username and passwords as options which are provided by the protocol.
- The stack of MQTT sits on top of TCP, whether it’s secure or non-secure, and which sits on top of IP, Local Area Networks, and the Physical layer.
- This table illustrates the differences between the MQTT protocol and HTTP protocol, with which we are all familiar.
- Whereas HTTP protocol is really oriented toward documents, MQTT is all about carrying data, and actually carrying fairly small amounts of data.
- HTTP protocol uses a request/response method, whereas MQTT protocol, as we saw, uses publish/subscribe methodology.
- Another scenario is location awareness and safety examples in chemical and petroleum industry, energy utilities, homeland defense.
- Another scenario in industrial tracking and visibility, industrial manufacturing, aerospace and defense, for managing the inventory to improve the management of stock and production.
- So Edge Server lies in the remote location, together with the remote devices, on the other side of far and far away from the Enterprise Server.
- So we have business applications and enterprise integration layer.
- Business applications want to send messages and receive messages from some remote devices, so it connects to the server in the integration layer.
- That layer is using supported transport protocols, one example being MQTT. The enterprise integration layer, the server acts as a center concentrator that remote devices connect to And the activities that the server has to support are, it acts as a service bus for business applications, it serves for purposes of message exchange, it’s capable of storing events and notifications for later delivery, if the connectivity was not available at the first attempt.
- It’s capable of mediating, filtering, and aggregating messages, such as to reduce the volume of messages.
- It is capable of applying application logic, such as event correlation, used to merge, or map, the event or alarm between the devices and integration layer.
- So let’s take a look at packet formats for MQTT. A number of bits is allocated for different purposes.
- Publishing- publish- which goes from client to server, or server to client, to publish a message.
- Publish received- indicated either from client to server, or server to client.
- Thereby, it is used for constrained devices which are low-bandwidth, high-latency and run over unreliable networks.
- So the design principles are based on minimizing the network bandwidth, minimizing the device resource requirements- such as memory and computation- with purposes of ensuring reliability.
