This is the #4 post of the IoT series that I am writing, in this article I will talk about IoT protocols & architecture, explain them, how they work and give examples of some conventions of architecture.
The architecture is a fundamental part of any system, regardless if it's IoT, web, desktop, without IoT we cannot build a good, reliable and scalable application. So to become a good IoT engineer is mandatory to know about network architecture, IoT architecture and embedded systems architecture.
IoT systems architecure
There is no single consensus on architecture for IoT, which is agreed universally. There are many types of architectures that can be used for IoT, the simplified ones, the complex ones, it happens because IoT is a growing field in the tech area, too new and recent, so the conventions are not so clear so far.
In this article we will cover the 3 main IoT architectures, they are: 5 layer architecture, fog architecture and 3 layer architecture. They are similar in many aspects, but they have their differences in layers, specifications and implementations.
3 Layer Architecture
The 3 Layer Architecture, as the name and the image show, has three layers, each one with a different function.
5 Layer Architecture
The 5 Layer Architecture, as the name and the image show, has five layers, each one with a different function. The 5 Layer Architecture is considered a more detailed version of the 3 Layer Architecture, because it has more layers, so more details and specification.
The Fog Architecture, has five layers, but with some sub-layers, that are located between transport and perception layers. These sub-layers work like a middleware, that intercept data, treat it and pass to next layer.
Fog Architecture is the most complete and specific IoT architecture, it is very adopted in big projects that have integration with cloud providers and its services. Your purpose is to maintain the security of the data and devices.
Now let's describe the function of each of the layers present in the Fog Architecture:
Perception Layer - Sensors, hardware level. This layer is responsible for collecting data and broadcast it.
Security Layer - Sub-layer between Perception and Transport. Responsible for ensure security of the data, and maybe(depends on the business rule) encrypt data.
Monitoring Layer - Sub-layer between Perception and Transport. Its function is to monitor the sensors activity and operation to ensure that are no failures and defects.
Temporary Store Layer - Sub-layer between Perception and Transport. Its function is to store the data produced by the Perception Layer temporarily, very similar to cache.
Transport Layer - It is and important role in IoT architecture. The transport layer is for transmitting and processing the sensor data.
Processing Layer - Big Data, Machine Learning, databases. This layer takes the raw data, and turns it into something presentable by processing and analyzing.
Application Layer - Websites, apps, smartphones, smartwatches. This layer is to deliver the specific application to the end-user, this application always contain the processed and organized data.
Business Layer - Admin panels, system management, graphics and analytics. This layer is on top of the IoT system, if it was an employee in a company, it would be a CEO, a Manager.
Embedded systems architecture
Embedded systems are more limited in hardware capacity and functionality than a personal computer, so this leads us to the conclusion that on a limited hardware, software is also limited. In situations like this, architecture and design are twice as important, so that we can use the full capacity of what we have at hand, and with a good performance.
But the embedded systems architecture is different between microcontrollers and microprocessors because of their differences in hardware and operation. They have different layers and different organizations, and we need to know the difference.
In this section I will not approach the devices and components of a microsservice or a microcontroller, they are part of the architecture, but they were explained in the last post, so to not repeat things, I will simplify them as "Hardware" layer.
The architecture of an embedded system for a microcontroller is very simple and has only 3 layers: Hardware, Firmware and Software, in this order from the bottom to the top.
Hardware - It is the physical part of the micros/computers, that is, parts and equipment that make the computer work.
Firmware - It is the embedded system itself, firmwares are the built-in programs in the micro, they perform specific tasks, and are generally not re-programmable.
Software - It is the logical part of the system, the programmable part, it is where we can input programs that will be converted to machine code and control the hardware.
The architecture of an embedded system for a microprocessor is a little bit more complex. It has 4 layers: Hardware, Firmware, OS(Operating System) and Software, in this order from the bottom to the top.
The 3rd layer is the OS layer, it is present on this architecture, because unlike microcontrollers, microprocessors run an operating system. The operating system layer doesn't need to be separated from the software layer, but by doing this we isolate responsibilities, turning the software the main responsibility of the programmer.
Maintaining a clean embedded architecture is very good and effective for your product's long term health, it will avoid problems in the future and it will definitely save you a lot of time.
Before we dive in the specific IoT protocols, let's remind some concepts of network organization, network protocols. Specifically about TCP/IP model, that is the base of the most of the network protocols, including IoT protocols.
It is essential that we understand the concept of TCP/IP, as this model is the basis for almost everything on the internet. The biggest part of the IoT protocols are built on top of TCP/IP, using its model and specification, also, not only IoT protocols, but the other protocols too.
I will not explain all about TCP/IP because it's not the purpose of the post, but if you want to be a great Iot engineer, you must learn more about it. You don't need to be a Cisco certified CCNA, but is interesting to know about TCP/IP, OSI and all this network detailed stuff, so then you will be a better engineer.
Transmission Control Protocol (TCP) is connection-oriented, once a connection has been established, data can be transmitted in two directions. TCP has built-in systems to check for errors and to guarantee data will be delivered in the order it was sent, making it the perfect protocol for transferring information like still images, data files, and web pages.
For example, let's suppose you have a server that sends messages to another one, the destination server will threat the received data and register them in a database. For this you need a confirmation that messages are being sent and received, and TCP do this by establishing a connection between the points.
User Datagram Protocol (UDP) is a simpler, connection-less Internet protocol wherein error-checking and recovery services are not required. With UDP, there is no overhead for opening a connection, maintaining a connection, or terminating a connection; data is continuously sent to the recipient, whether or not they receive it.
For example, let's suppose you have a server that multicasts/broadcasts messages in a determined frequency, in this case a connection will not be established between points, your server will just send the data without caring if it was successful delivered.
TCP vs UDP
I think learning with memes and images is much easier, in some cases it can be clearer than building a table that compares UDP and TCP. So enjoy this meme:
The image shows the TCP protocol "concern" with package delivery, to minimize loss of information, and record it if it happens. But it also shows the UDP protocol sending the information "anyway", without concerns.
IoT protocols are the base of the IoT technology stack, hardware and the data collection made by software would be useless without the IoT protocols. IoT protocols allows the exchange of data in a structured and meaningful way between two devices don't matter the distance, they only need to be connected and active.
What enables all this smart stuff present in the smart devices and sensors to talk and interact, are the IoT protocols which can be seen as languages that the IoT gear uses in order to communicate.
MQTT, short for Message Queuing Telemetry Transport, is a lightweight messaging protocol for sensors and small mobile devices optimized for TCP/IP networks. The scheme is based on the Publish-Subscribe model, which is extremely simple and lightweight. Its architecture aims to minimize the use of network bandwidth and use of equipment resources. This protocol was built by IBM in 1990 to be used on oil platforms.
MQTT is very versatile and lightweight, is widely adopted by technology companies, but it also has some limitations, they are:
Maximum message size of 260MB
The network can only scale according to the broker's capacity
It doesn't come with a security layer out of the box like HTTPS, but you can easily implement with TLS
Despite having only 2 bytes in size in its header, this can still be too much for some old controllers
It does not have confirmation of receipt of messages by default (but it is possible to implement manually)
Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was designed for communication between web browsers and web servers, but it can also be used for other purposes like IoT. HTTP follows a classical client-server model, with a client opening a connection to make a request, then waiting until it receives a response.
HTTP is not so used on IoT because it is not efficient, HTTP closes the connection, so you will always need to be reopen it, and also because HTTP needs a good connection and consumes much energy from the device. But on the other hand HTTP is easier to implement, error messages are more clear and you can use HTTPS to maintain the data safe.
Created by the IETF Constrained RESTful Environments working group and launched in 2013, Constrained Application Protocol (CoAP) was designed to translate the HTTP model so that it could be used in restrictive device and network environments.
Designed to address the needs of HTTP-based IoT systems, CoAP relies on the User Datagram Protocol (UDP) for establishing secure communication between endpoints. By allowing for broadcasting and multicasting, UDP is able to transmit data to multiple hosts while retaining communication speed and low bandwidth usage.
There are also some disadvantages to CoAP:
- Message unreliability, because UDP does not guarantee the delivery of datagrams.
- CoAP is still evolving, although there is a lot of market momentum behind it.
- CoAP can have problems communicating with devices behind a NAT since the IP can be dynamic over time.
- CoAP is unencrypted and hasn't a built-in security layer.
WiFi uses radio waves that broadcast information on specific frequencies, such as 2.4 GHz or 5 GHz channels. Both frequency ranges have a number of channels through which different wireless devices can work, which helps to distribute the load so that the individual connections of the devices are not interrupted.
A range of 100 meters is the typical range of a standard WiFi connection. The most common range, however, is limited to 10-35 meters, because as far as you are from the router, poorest is your connection. IoT systems usually implement connections through Wi-fi when the devices are in a LAN (Local Area Network) and not so distant one from each other.
Bluetooth is a technology that allows wireless connection of various electronic devices, such as a telephone, keyboard, computer, laptop, mouse, printer, headset, and more. Wi-fi and Bluetooth are somewhat similar, but they are completely different protocols.
In Bluetooth technology, data is sent in the form of packets to one of 79 channels (in the case of the oldest Bluetooth 1.0 standard) with a bandwidth of 1 Mhz which ensures a maximum transfer speed of 721 kbit/s. In the case of the latest Bluetooth 4.0 standard, there are 40 channels with a bandwidth of 2 Mhz, which guarantees a maximum data transfer of up to 3 Mb/s.
It is a good technology, very easy to establish a connection between devices, but is too slow and limited by distance, if the devices are in a distance bigger than 10 meters the connection will start to fail.
We have reached the end of our article, this was a very long post, probably the longest in the series so far, but it is also one of the most important in terms of theory, concepts and fundamentals of networks and architecture.
Obviously this post doesn't contain everything you need to know, because it's a very dense subject, but I tried to summarize as best I could, to make the information clear and allow you to go deeper into the subject.
Top comments (3)
Found this while searching for articles on protocols and can't stop reading! Guess I will have to read the other posts from this series. Thanks!
Can't wait for the rest of the series! :)
i am writing the #5 and I will drop it on Sunday, it's about C/C++ programming for microcontrollers, do you have any suggestions?