jpnorair

The LoRaWAN authors copied a lot from WiFi, which seems kind of dumb, but this sort of thing happens a lot when there is no security expert in the room. In addition, they needed to address that physical access to endpoints is easy in IoT, but they didn’t.

No, it's usually much less for GNSS. The secret to low power GNSS is to find a way not to have the receiver on much of the time, but that's very possible. LTE has less flexibility in overhead energy, because there's overhead enforced by the network.

Excellent post -- a rarely understood truth. For low power wireless systems, still, though, the bulk of the energy is spent in TX and RX. But realistically the quiescent power drain still needs to be in the sub 5uW range to deliver long life on a small battery. A lot of GNSS and LTE SoC's standby in the 50uW range, which is just too much. Most of the LTE devices I've surveyed (M1, NB-IoT) are expected to be attached to MCUs, but they implement internally a small linux platform. Obviously, that makes it hard to get down to 5 uW.

That's a really hard problem to solve, which is why you don't see lots of solutions. DASH7 has been around for a few years, and it addresses the technical aspects of this problem, although it still probably needs another year to mature to the point where it's easy to integrate. But if you have a high volume application, it's an option.

A few things. (1) If the payload is shorter than the key length (e.g. 128 bits) then crypto is actually really strong (and easy). For long payloads, you need to work a lot harder. (2) For doing a public key handshake, you can do it without a huge packet using one of the elliptical curve algos, but for any public key handshake you need a reasonably short duration of the handshake in order for it to be adequately secure. That's a bigger challenge than the data size. Low power LTE Cat M1 or NB-IoT systems aren't any better at practically serving low latency sessions than most LPWANs are. (3) "secure elements" should be called "insecure elements" when the items they are installed in are remotely operated in public environments. (4) Carriers tend to use TCP/IP with LTE, which is more of a limitation than a benefit, because it prevents any manner of broadcasting. There are a lot of applications that can be low power if they are broadcasted, but will never be low power (or easy) via TCP. (5) The direction LTE has gone, in my opinion, makes it undesirable for a lot of applications. It is nice for low-volume monitoring applications. So in a sense I think LTE as a LPWAN is really the great solution for niche use-cases.

It is a feature of using lower frequencies together with lower data rates and signal processing technologies. Consult with any RF engineer -- there is no magic here, just practical engineering to solve a particular set of problems.

The part of the article that addresses data interoperability and databasing on the endpoint (without cloud middleman) is important for use cases where there are ownership issues. The author would no-doubt agree that having to subscribe to a cloud-based gatekeeper middleman, to access the data on the fridge you own, is absurd and against the spirit of the internet.