Internet of Things protocol stack
Hello. We have been on the [censored] team (yes, we are called) for a while now we have been creating a stack for building wireless mesh networks with adaptive routing. And imagine, it turns out!
And it just so happened that the time has come to break the cover of secrecy (ta-dam) and tell us what we are doing, why, and what opportunities for developing projects in the realm of the very Internet of things and the industrial Internet opens our stack protocol.
It would be reasonable to begin this kind of story by explaining what was the impetus for the beginning of our work. Briefly, this reason can be formulated as follows: we have concluded that modern mobile networks have a number of drawbacks (incompatible with life in the future), which cannot be overcome without the introduction of technology with a fundamentally different architecture, the version of which we thought up and decided to implement.
')
At the dawn of the emergence of mobile networks, some of their architectural features had not yet turned into flaws: the concept of dividing the coverage area into separate areas looked elegant and logical, in full accordance with the “divide and conquer” strategy. But since its inception, the mobile device market has continuously expanded, requirements for the quality of the services provided have become tougher, data rates and the number of subscribers have increased hundreds of times. This growth made it possible to identify the problems of scalability and flexibility of the now classic mobile network architecture. Paraphrasing the classics, 640 Kb was not enough.
1. Mobile networks do not scale well by the number of cells. Each new cell is a simulation of the propagation of radio waves in the area of ​​interest, the calculation of the noise level, the definition of suitable settings to minimize interference (both for the new station and for others, if any), expensive equipment, permissions from supervisory services, provision of backup lines communications and food, the work of specialists in installation, configuration and maintenance ... - in general, time and money. And the more actively radio communication is used in this area, the greater the costs. First of all it concerns LPWAN networks
2. Mobile networks do not scale well by the number of subscribers. Each device supported by the base station reserves either a frequency (FDMA), or a time slot (TDMA), or a code sequence (CDMA). All these resources are limited, and when subscribers become too many, the quality of communication begins to suffer: for someone who does not have enough frequency, slot or code, the base station ceases to exist, which in many cases turns into a subscriber’s loss from the network.
At the same time, the growth of the Internet of Things market leads to an avalanche-like growth in the number of devices requiring access to the network. The number of gadgets is growing exponentially, and developers do not bother to work on communication methods, relying on existing solutions: most smart gadgets either “live” in the home router’s network or connect to the Internet through the network of mobile operators. And often we see a comical situation: devices that are in the same room communicate with each other through cloud services. And even if there are relatively few such devices now, then very soon the throughput of both communication channels and processing stations is simply not enough. Goodbye, beautiful life!
3. Modern networks are completely non-flexible. Even in everyday mode, when base conditions change, it is necessary to recalculate and reconfigure base stations, and in case of emergency and emergency situations, the “fall” of one of the stations leads to an abrupt influx of devices to the neighboring ones, which often leads to a fall in the entire network, which is fraught with problems disaster situations or other emergencies.
Just remember any New Year when it is impossible to reach anyone, and all subscribers are temporarily not served. And if the influx during the New Year ends pretty quickly and there are no special reasons to worry, during the rescue events, the presence of at least some connection is a vital factor. And about the fact that the battery of your favorite smartphone discharges even faster from the network search, you can not speak.
The root of all ills is the usual use of the topology of the "star" with a fairly rigid centralization. That's why we decided to start developing infrastructure for the rapid deployment of a decentralized network called Ad-Hoc or MESH. The idea is to exclude the “weak” link — the base station — from the network — for which the connectivity features are shifted to subscriber devices. As a result, each of them, in addition to the role of a consumer of communication services, also plays the role of their supplier for its neighbors. The devices themselves in such networks are traditionally referred to as nodes. In such networks, when new nodes appear or existing ones fail, the network automatically rebuilds the routes, keeping it working, which simplifies scaling and makes the whole system unusually flexible. The need to administer and configure such networks is minimized and can be performed remotely. That is why the maintenance of wireless MESH networks does not require expensive infrastructure, cabling, installation of base stations and their regular administration, which makes these networks very economical to operate.
Obviously, the main feature of the node of a decentralized wireless network are the algorithms that control the routing process, which should be more complex than those in familiar routers. But since the majority of subscriber devices do not have large computational resources, the applied routing algorithms must be not only highly intelligent, but also not resource-intensive. This range of tasks was accepted by us as a kind of challenge.
About a year ago, having put forward several hypotheses about what solutions need to be implemented to build a centralized wireless network, we tested them on a specially created simulation model. Since various types of MESH networks were attempted to be built before us, it was important to overcome the constraint that their developers faced before: it is difficult to combine more than a hundred, and sometimes even a dozen, subscribers in one Ad-Hoc network. However, the simulation results were encouraging, and we set about implementing.
Our first partner was a local company engaged in systems integration and management automation solutions. We were invited to participate in a project to develop a smart street lighting system, in which our protocol stack would take its rightful place - to ensure the transfer of data. The partners had to design the hardware and create applications for controlling the lanterns, which would become the “clients” of our stack. As a result of the discussion of hardware requirements, it was decided to work with NXP LPC1343 microcontrollers and Semtech SX1272 radio transmitters (RFM96) that support the LoRa standard. At that time, the resources of the selected microcontroller seemed to be enough, and in front of us were a lot of lines of code on pure C.
In the minimal implementation, the stack is represented by three levels, between which data is constantly exchanged: the interface level, the routing level, and the service level. We did not want to devote time and effort to creating our own parallel processing primitives, so it was decided to implement the stack under FreeRTOS (not without problems, but with unexpected successes). In addition, this solution provided some cross-platform, which would be useful for the further development of the project.
To fully validate the stack, we decided to create a separate, open development platform. We chose the Raspberry Pi as the basis, and made a box for it, which facilitates the installation of the necessary peripherals: LCD-display, GPS-module, board- “hats” for radio modules, etc. ... You can read how it was done in end of article.
Despite the economical use of resources of the microcontroller, it was soon discovered that the stack did not fit in a 32 KB FLASH, so the hardware requirements were raised. Today, the minimum stack version requires the following platform characteristics:
MCU: Cortex M3
OS: FreeRTOS
FLASH: 128 KB
EEPROM: 8 KB
RAM: 32 Kb
In addition, to generate pseudo-random numbers, the stack uses an ADC built into the microcontroller, however, if necessary, it can be replaced with any suitable frequency generator with the required cryptographic strength. In fact, this stack is called MOAR.
The next goal we set for ourselves is the development of the GNU / Linux version of the MOAR stack, and with the support - as far as possible - of the POSIX standards. We believe that there is no need to explain in detail the reasons for this decision in a world where the absolute majority of network devices work, if not under GNU / Linux control, then with an operating system that supports POSIX. In addition, we plan to publish the source codes of the stack under a free license.
The version for GNU / Linux, in contrast to the first, already includes five different levels: the channel level and the presentation level were added to the previously existing ones. Instead of the queues used in the first version, standard Unix sockets are now used to exchange data between levels. Each of the levels can be restarted separately from the others, which is much more useful.
The stack has an API that we try to bring closer to the familiar socket API. It seems to us that this approach will greatly facilitate the "move" to developers who will use the stack as a ready-made solution. In addition, fine-tuning the stack is possible through configuration files, using them on the fly and transferring via the network itself - the simplest implementation of this functionality is already in the first version of the stack, for GNU / Linux it will be developed and expanded.
This flexibility and modularity of the stack being developed was chosen not only for aesthetic reasons and ease of development. Future plans include the implementation of many breathtaking opportunities, such as adaptive routing, using a self-learning neural network to predict the states of its nearest neighbors and route priorities. Due to the architectural features of our solution, you can change data processing scenarios without the need to reload the entire stack or re-train the neural network. Other planned features are in the field of information security, and we will describe them in detail later.
On December 23, we will publish MOAR stack source codes under a free license and look forward to your questions, ideas, comments, and even forks!
UPD. Release
And it just so happened that the time has come to break the cover of secrecy (ta-dam) and tell us what we are doing, why, and what opportunities for developing projects in the realm of the very Internet of things and the industrial Internet opens our stack protocol.
It would be reasonable to begin this kind of story by explaining what was the impetus for the beginning of our work. Briefly, this reason can be formulated as follows: we have concluded that modern mobile networks have a number of drawbacks (incompatible with life in the future), which cannot be overcome without the introduction of technology with a fundamentally different architecture, the version of which we thought up and decided to implement.
')
Who is guilty
At the dawn of the emergence of mobile networks, some of their architectural features had not yet turned into flaws: the concept of dividing the coverage area into separate areas looked elegant and logical, in full accordance with the “divide and conquer” strategy. But since its inception, the mobile device market has continuously expanded, requirements for the quality of the services provided have become tougher, data rates and the number of subscribers have increased hundreds of times. This growth made it possible to identify the problems of scalability and flexibility of the now classic mobile network architecture. Paraphrasing the classics, 640 Kb was not enough.
1. Mobile networks do not scale well by the number of cells. Each new cell is a simulation of the propagation of radio waves in the area of ​​interest, the calculation of the noise level, the definition of suitable settings to minimize interference (both for the new station and for others, if any), expensive equipment, permissions from supervisory services, provision of backup lines communications and food, the work of specialists in installation, configuration and maintenance ... - in general, time and money. And the more actively radio communication is used in this area, the greater the costs. First of all it concerns LPWAN networks
2. Mobile networks do not scale well by the number of subscribers. Each device supported by the base station reserves either a frequency (FDMA), or a time slot (TDMA), or a code sequence (CDMA). All these resources are limited, and when subscribers become too many, the quality of communication begins to suffer: for someone who does not have enough frequency, slot or code, the base station ceases to exist, which in many cases turns into a subscriber’s loss from the network.
At the same time, the growth of the Internet of Things market leads to an avalanche-like growth in the number of devices requiring access to the network. The number of gadgets is growing exponentially, and developers do not bother to work on communication methods, relying on existing solutions: most smart gadgets either “live” in the home router’s network or connect to the Internet through the network of mobile operators. And often we see a comical situation: devices that are in the same room communicate with each other through cloud services. And even if there are relatively few such devices now, then very soon the throughput of both communication channels and processing stations is simply not enough. Goodbye, beautiful life!
3. Modern networks are completely non-flexible. Even in everyday mode, when base conditions change, it is necessary to recalculate and reconfigure base stations, and in case of emergency and emergency situations, the “fall” of one of the stations leads to an abrupt influx of devices to the neighboring ones, which often leads to a fall in the entire network, which is fraught with problems disaster situations or other emergencies.
Just remember any New Year when it is impossible to reach anyone, and all subscribers are temporarily not served. And if the influx during the New Year ends pretty quickly and there are no special reasons to worry, during the rescue events, the presence of at least some connection is a vital factor. And about the fact that the battery of your favorite smartphone discharges even faster from the network search, you can not speak.
What to do
The root of all ills is the usual use of the topology of the "star" with a fairly rigid centralization. That's why we decided to start developing infrastructure for the rapid deployment of a decentralized network called Ad-Hoc or MESH. The idea is to exclude the “weak” link — the base station — from the network — for which the connectivity features are shifted to subscriber devices. As a result, each of them, in addition to the role of a consumer of communication services, also plays the role of their supplier for its neighbors. The devices themselves in such networks are traditionally referred to as nodes. In such networks, when new nodes appear or existing ones fail, the network automatically rebuilds the routes, keeping it working, which simplifies scaling and makes the whole system unusually flexible. The need to administer and configure such networks is minimized and can be performed remotely. That is why the maintenance of wireless MESH networks does not require expensive infrastructure, cabling, installation of base stations and their regular administration, which makes these networks very economical to operate.
Obviously, the main feature of the node of a decentralized wireless network are the algorithms that control the routing process, which should be more complex than those in familiar routers. But since the majority of subscriber devices do not have large computational resources, the applied routing algorithms must be not only highly intelligent, but also not resource-intensive. This range of tasks was accepted by us as a kind of challenge.
What is done
About a year ago, having put forward several hypotheses about what solutions need to be implemented to build a centralized wireless network, we tested them on a specially created simulation model. Since various types of MESH networks were attempted to be built before us, it was important to overcome the constraint that their developers faced before: it is difficult to combine more than a hundred, and sometimes even a dozen, subscribers in one Ad-Hoc network. However, the simulation results were encouraging, and we set about implementing.
Our first partner was a local company engaged in systems integration and management automation solutions. We were invited to participate in a project to develop a smart street lighting system, in which our protocol stack would take its rightful place - to ensure the transfer of data. The partners had to design the hardware and create applications for controlling the lanterns, which would become the “clients” of our stack. As a result of the discussion of hardware requirements, it was decided to work with NXP LPC1343 microcontrollers and Semtech SX1272 radio transmitters (RFM96) that support the LoRa standard. At that time, the resources of the selected microcontroller seemed to be enough, and in front of us were a lot of lines of code on pure C.
In the minimal implementation, the stack is represented by three levels, between which data is constantly exchanged: the interface level, the routing level, and the service level. We did not want to devote time and effort to creating our own parallel processing primitives, so it was decided to implement the stack under FreeRTOS (not without problems, but with unexpected successes). In addition, this solution provided some cross-platform, which would be useful for the further development of the project.
To fully validate the stack, we decided to create a separate, open development platform. We chose the Raspberry Pi as the basis, and made a box for it, which facilitates the installation of the necessary peripherals: LCD-display, GPS-module, board- “hats” for radio modules, etc. ... You can read how it was done in end of article.
Despite the economical use of resources of the microcontroller, it was soon discovered that the stack did not fit in a 32 KB FLASH, so the hardware requirements were raised. Today, the minimum stack version requires the following platform characteristics:
MCU: Cortex M3
OS: FreeRTOS
FLASH: 128 KB
EEPROM: 8 KB
RAM: 32 Kb
In addition, to generate pseudo-random numbers, the stack uses an ADC built into the microcontroller, however, if necessary, it can be replaced with any suitable frequency generator with the required cryptographic strength. In fact, this stack is called MOAR.
What to expect next
The next goal we set for ourselves is the development of the GNU / Linux version of the MOAR stack, and with the support - as far as possible - of the POSIX standards. We believe that there is no need to explain in detail the reasons for this decision in a world where the absolute majority of network devices work, if not under GNU / Linux control, then with an operating system that supports POSIX. In addition, we plan to publish the source codes of the stack under a free license.
The version for GNU / Linux, in contrast to the first, already includes five different levels: the channel level and the presentation level were added to the previously existing ones. Instead of the queues used in the first version, standard Unix sockets are now used to exchange data between levels. Each of the levels can be restarted separately from the others, which is much more useful.
The stack has an API that we try to bring closer to the familiar socket API. It seems to us that this approach will greatly facilitate the "move" to developers who will use the stack as a ready-made solution. In addition, fine-tuning the stack is possible through configuration files, using them on the fly and transferring via the network itself - the simplest implementation of this functionality is already in the first version of the stack, for GNU / Linux it will be developed and expanded.
This flexibility and modularity of the stack being developed was chosen not only for aesthetic reasons and ease of development. Future plans include the implementation of many breathtaking opportunities, such as adaptive routing, using a self-learning neural network to predict the states of its nearest neighbors and route priorities. Due to the architectural features of our solution, you can change data processing scenarios without the need to reload the entire stack or re-train the neural network. Other planned features are in the field of information security, and we will describe them in detail later.
On December 23, we will publish MOAR stack source codes under a free license and look forward to your questions, ideas, comments, and even forks!
For those who are interested in photos
In addition to the release of Open Source DevKit, we plan to post the full information on node assembly. Under the link you can find a brief assembly instructions and a list of necessary details. If you do not know what to do in the New Year holidays and are tired of answering the question of what to give you for the new year, you can kill a couple of three birds with one volley.
UPD. Release
Source: https://habr.com/ru/post/317056/
All Articles