Notes IoT provider. Propriety

Continuing the cycle of articles. Start:

I would like to devote my fourth article to one important thought. I was prompted to it by numerous comments and messages in a personal.

The Internet of Things is still very young. He slowly takes over all new areas and finds application in more and more areas. However, like any new technology, now IoT is just getting on its feet. In fact, the first rules and recommendations barely appear, how and on which technology to deploy networks. And no one knows the exact answer to the question of which standard will “fly up” and which one will sink into oblivion. And I do not know. I can only assume, based on an analysis of the market, the advantages or disadvantages of individual technologies.

So why all the same LoRaWAN?

In my first article, I cited the arguments for: there is unlicensed spectrum, and battery savings, and high noise immunity. But, in one way or another, other standards have it. They also know how to live a long time on the battery, they also work in 868. Maybe we don’t even look there, the star topology will not take root and it will be replaced by mesh networks?

Everything's possible. However, LoRa has an important advantage that not everyone is aware of. This is not a proprietary standard. That is, it is not focused on one firm, on one vendor. It is more or less open, and it is produced by many manufacturers.

Let's not be cunning, the ball is still ruled by the developer, the French company Semtech. Only she makes crystals for chips. And its influence is felt in the LoRa Alliance. However, the French have chosen a successful business model. The production of chips is at the mercy of several other companies, the specification is publicly available and now it is almost possible to start the production of a LoRa terminus almost in the basement.

And most importantly, everything that honestly supports LoRaWAN is compatible with each other.
Why is it important?

Any standard closed to a single manufacturer-developer carries an obvious risk. The manufacturer may disappear and you will have a pile of purchased but useless iron on your hands. This threat will be squared if software is deployed not on your servers, but in the manufacturer’s cloud. That is why we immediately shallow, for example, "Swift". It can be ten times better in terms of performance, I will not even argue on this topic. Simply, it is proprietary from start to finish. If you choose it as a technology, you associate yourself with quite tangible bonds with Swift-Telematics. The company is wonderful, their director is quite a pleasant and extremely enthusiastic engineer. However, to depend on his decisions is somehow short-sighted.

Similar to Waviot with its NB-Fi. There is already more interesting, Waviot decided to open and publishes the source on the GitHub. Immediately, many noticed that it is suspiciously similar to SigFox, only slightly doped, but not the essence. As soon as several independent companies will take on the production of NB-Fi, it can already be considered for real projects. Of course, with NB-Fi, the security situation is completely sad, because there really is a replay attack. But we are discussing the concept, not the details.

I think the moment with a single vendor is obvious to many. However, there is one more thing that not everyone understands. Because of her open source solutions are so popular. When a developer opens and uploads documentation for everyone to see, when he donates production to dozens of companies, and hundreds of companies deploy networks without him, that's when bugs really get out. A huge community under the microscope is studying technology, someone on enthusiasm, someone from working considerations. All these people think differently, speak different languages, have a different level of qualification. And they will find. Find everything you can.

LoRaWAN is often called the leaky standard for numerous flaws. Here the session keys can live for several months (we will talk about this in the topic about security), this is not the most efficient use of the spectrum, there are tricks on how to enter the end into a stupor.

Yes, it is, it is foolish to deny. But we know all this just because LoRa is very well studied by the very people who got access to it.
Other standards have exactly the same problems. Only we do not always know about them. Perhaps someone will say: closeness is also a defense. Partly so. But, according to Murphy's law, if trouble is possible, then it will happen somewhere.

With LoRaWAN, we at least know where to look and what to fear. With proprietary workers this will not work. Their problems will come out at the most inopportune moment. And we, by virtue of our ignorance, do not even understand what happened.

And LoRa has a whole Alliance, which continues to develop. In October, specification 1.1 was released. It is still little used in practice, in any case, I have not met devices with the support of new items. But if you dig into it, it becomes clear - among other things, many bugs have been fixed. Engineers, when they got to work, already knew that they needed to work first.

How will proprietary workers develop their standard (if at all)? Obviously, to modify and improve, without noticing that the critical error migrated to the updated version.

Let's do it again. There are no dogmas on the Internet of Things, we are writing its history here and now. I bring you my arguments, and they are not even so much for LoRa, as for the open source as a whole. The article was a little philosophical, but I want to clarify the position on the question: “Why don’t you use it, is it better?”. It may be better, but it will be seriously considered only in the case of openness, compatibility and multi-vendor. In the next issue of "Notes" let's talk about security and again plunge into the technique. I am not a supporter of lengthy arguments, but it is better to designate the position immediately and as a whole, than in pieces in the comments.

PS When I talked about the compatibility of devices from different manufacturers, I meant that on our server you can hang different base stations, and put the end of different manufacturers in the network. But if the first is implemented by us (now the BS of three vendors are working in the network), then the second seemed to me to be a very distant future. A year, maybe two, before customers come to us with their equipment.

But the future came faster. We were approached by the customer with his tip, in fact, he is renting a network from us. It took a little time to tailor the package format and it all worked.

C. Compatibility.

PPS I will be consistent and to the whole article I will add the forgotten term IMHO.