Comment by blhack | Hacker News Reader

Comment by blhack | Hacker News Reader

Parent Full thread

This is un. fucking. real. I work in the IoT space (specifically on health devices), and something like this would be absolutely a GOD SEND for the things that we're doing.

The current "hottness" in our space is bluetooth low energy (BLE). This is super low power (or, rather: chips that are really good at going to deep sleep, and then coming online very quickly to burst some data out), but the range on BLE isn't great.

Some companies use general purpose radios (these guys: http://www.glowcaps.com/ are basically an couple of atmega 328s and some 433mhz radios) for range, but it seems like everything is moving towards BLE because you can use your cellphone/tablet as a base station.

If LORA can seriously get this sort of range (I'm skeptical, honestly), then that is a total game-changer for IoT.

A friend of mine at a chip manufacturer in town was telling me about some radio thing they were doing that had range like this about a year ago, but I didn't believe him. That little of power, for that long of range seems like straight-up magic.

Super cool stuff! Very excited to see this really happening!

Not to get too silly, but this about sums up how this makes me feel with regards to IoT: https://media.giphy.com/media/rl0FOxdz7CcxO/giphy.gif

Glad you agree. :)

We're putting up a LoRa network here in SF, and plan to publish a bunch of our test data, including link error rates and throughput. Urban deployments are new so more data will help us all understand what's doable. (There are a few rural deployments in production; less uncertainty there.)

We (Amerihub) craft custom data transit solutions and manage the networks and tech assets for a lot of medical and manufacturing clients in the Chicago area. This could have HUGE applications in those spaces.

I signed up for your beta via your site. We want in asap.

Anything similar going on in Europe? London specifically? I would love to create some pocketable hardware that never needs recharging and sends text and (compact) vector-based graphical market updates to people.

Yes, on the Continent, at least! I'm not sure about the UK.

Both LoRa and Sigfox came out of French companies, and several wireless carriers have announced plans to build networks. Also check out The Things Network guys in Amsterdam who are trying to crowdsource a network, very cool stuff.

Sigfox is being used in the roll out of smart gas/electricity meters in the north of England/Scotland. Unfortunately Telefonica won the south any they will use the GSM network.

How will you deal with device contention as the density of devices increases?

Check out my response to your other comment.

What tech are you using for the base station?

I'd love to put one in our hackerspace out here :) -- a few offices of people working on IoT would probably think that was pretty cool.

Killer -- where's your hackerspace?

LoRa basestation gateways are available off-the-shelf for from Kerlink, Multitech, and Link Labs. The gateways are actually quite simple, they just forward packets to the cloud network server, and back to the clients.

Hey, is there any chance for us putting something like this to the Taipei Hackerspace (Taiwan)? https://taipeihack.org

I've been checking LoRa for months to do some projects, but all got to some bottlenecks. (E.g. here are some notes on a USB-stick LoRa communicator plans: https://hackpad.com/LoRa-USB-Communication-Stick-xKGgChuwbzL )

Mesa, AZ.

http://www.heatsynclabs.org/

nice, hit me up, daniel@

Can I run my own server?

+1 Bangalore, India.

Compromise is you'll get a few bits to 1kbps at best over a few Km of range. It would work for some applications but not for all of them.

This is all that IoT needs, though. It's not about streaming video or music or something, it's about a sensor that goes high when somebody is sitting in a chair, or that sends an integer value once every few minutes.

Is bandwidth realistically at least in the high hundreds/low thousands of bps? Or are we literally talking a couple of bytes per minute?

... so why not do it over WiFi? You use less power/bit and you get the data delivered to where it matters, local network.

LoRa only makes sense (and I've seen it used) in large infrastructure type uses like sensors that monitor roads or bridges.

I think you answered your own question -- of course WiFi makes sense for small/short range networks. Its cheap and fast.

These technologies are more exciting because you are talking about realistic coverage areas of square kilometers with inexpensive, unlicensed radios. Think of something like a large natural gas pumping field -- there are tons of industrial sensors and controls spread out over a fairly large area that don't need to send much data. I work in the radio industry, and these technologies, if they live up to their hype, will be industry disrupting.

Maybe -- throughput depends on which radio tech we're talking about, and the networks need to get built with density appropriate for the task.

LoRa radios that are close to a gateway can dynamically shift to a 300 Kbps mode, or down to a long-range mode that's ~10Kbps (but yes could also be degraded further by error rate if at edge-of-range).

Is that 1kbps shared between all devices in range?

Great question. It depends on the technology. For example with LoRa, in the US there are 64 usable channels. In addition there are 5 available "spreading factors" per channel that are orthogonal to each other. A lower spreading factor device may communicate at twice the data rate of the one above it (but with worse range). So for example one device may communicate at 1kbps at SF12, another may communicate at SF11 at 2kpbs at the same time. This means you can have 31 devices communicating 1kb within a 1 second window, on a single channel.

Other technologies can have many more simultaneously communicating devices. In the case of OnRamp/Ingenu, a factor of 1600 more due to their encoding scheme.

Narrowband technologies like SigFox (based on TI radios), have way more than 64 channels available in the US, I believe in the range of 1000, but are more susceptible to interference.

Forgot to add that Sigfox isn't based on TI radios, but is hardware-agnostic. Basically, most sub-GHz radio transceivers are compatible, and it's all about adding the soft stack. Current HW partners include TI, SiLabs, Atmel, Axsem, ..

We'll be using TI HW (Launchpad dev kit) on our SF event on Nov 20 (https://www.eventbrite.com/e/smart-city-iot-hackathon-connec...), but we're fully open on the hardware side.

Full list here : http://makers.sigfox.com/

Sigfox doesn't have channels per se. Each Sigfox message is concentrated on ~100Hz, with the base stations listening to a 200KHz part of the available spectrum. Regarding interferors, the Ultra Narrow Band technology offers a great resistence: energy concentrated on a tiny width, plus the "random frequency" effect of the sigfox protocol.

If you're skeptical about LPWAN range claims .. better thing to do is to test :)

We (Sigfox) are running a hackathon in SF on Nov 20th, in partnership with the City. Good occasion to test the live network, and get your hands on a dev kit

https://www.eventbrite.com/e/smart-city-iot-hackathon-connec...

More info about Sigfox on http://makers.sigfox.com

Oh man... Unfortunately I'm going to be out of the country during that or I would be ALL OVER IT.

Those dev kits are pricey... Is this the one? http://snootlab.com/shields-snootlab/829-.html

In the SF event we'll hand out TI dev kits, Launchpad + CC1120 boosterpack (~ http://www.ti.com/tool/boostxl-cc1120-90)

The Akeru board is still quite expensive (€100), as it's a full Arduino/Genuino board + sigfox module + subscription. And the guy is producing them himself, with small batches. This one is not FCC-ready yet anyway.

Keep in touch for future US-based events !

Cool stuff, sure. But, in my opinion, IoT will be slow to take off until the security aspect is solved - and it is a tough one.

That's exactly my problem too, and I decided to develop a prototype protocol for it. I wrote a reference implementation in python, feedback very much desired:

http://stringphone.readthedocs.org/

* The weaknesses you outline in the introduction are pretty serious.

* How to exchange the topic key is described as out of scope, but totally critical since you also propose renewing the topic key as a way of attaining forward secrecy.

* You totally hand-waved away the exchange of participant keys.

* I'm pretty sure you've exposed some cryptographic weaknesses in the core protocol but I'm not going to spend the time to keep analyzing.

So in short, your protocol is not very useful. Sorry.

The biggest problems in IoT space are key agreement and machine trust among a hugely heterogeneous population. Solutions will come in the form of standards adoption, hegemony, government regulation, and probably a combination of all three. Multicast security is somewhat of a solved problem (e.g. wifi.)

Communications security between actual people is an entirely different and more easily solved problem.

> The weaknesses you outline in the introduction are pretty serious.

There's no weakness there that's not fixable. Replay protection can be easily added in the layer above, and rolling the topic key can also be done. The nonce problem can go away with using the wider Salsa variant.

> How to exchange the topic key is described as out of scope, but totally critical since you also propose renewing the topic key as a way of attaining forward secrecy.

Where did you see that? I go into a lot of detail here: https://stringphone.readthedocs.org/en/latest/protocol.html#...

> You totally hand-waved away the exchange of participant keys.

See the previous point.

> I'm pretty sure you've exposed some cryptographic weaknesses in the core protocol but I'm not going to spend the time to keep analyzing.

Hmm.

> Solutions will come in the form of standards adoption, hegemony, government regulation, and probably a combination of all three.

"Don't bother working on it" doesn't sound like very useful advice...

Are you going after people or machines as your target? It matters which, because machines can't do human trust, so then the issue of how you exchange keys and establish trust is forced.

What's the stop a MITM between a client and any other client from intercepting the conversation? In your protocol, nothing, except that if the MITM isn't there at the start, they can't join in right away. This is not a very useful assurance. So please, keep working on it, but I think your challenges are pretty serious. If the problems are fixable, then go ahead and fix them. I'd be happy to take another look - after that.

Link encryption and authentication is pretty much "solved" in that we have the components we need already. Then there's the issue of code bugs and lack of updates - I think this should be solved in most cases by devices exclusively talking over a filtered API via a trusted gateway to prevent exploit attempts from succeeding.

I can't think of any other technologies that have waited for the security aspect to be solved, can you?

Solving security aspect will mean much less hackability, which means slowing down its development.

Security in the LoRaWAN standard is well thought-through, you might be surprised.

Googling this did not lead to joy. Do you have a direct link?

https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Spec...

Would love to hear thoughts on it. Email address in my profile.

Just curious – why is range limited by a protocol? Why couldn't you send Bluetooth over hundreds of miles with a big enough antenna, for example?

You can amplify a signal and send it far. But due to FCC regulation in the 900MHz band for example you can only instantaneously transmit at 30W.

Another way to make a signal go further is to transmit at a lower data rate (thus spreading your signal out over time so that in effect you have more power in the signal). The FCC limits "dwell time" in a single channel to .4s in the 900MHz band.

Yet another way to increase range is to increase your receive sensitivity. Lora's Chirp Spread Spectrum coding actually allows signals to be received below the noise floor. You can liken this to decrypting data: to an observer the signal looks like noise, but if you know how to look within the noise you can pull the actual coded information out.

All of these LPWAN technologies use different forms of coding and signal spreading over time to get long range. Note how spreading your signal over time means your throughput goes down.

It's important to realise that - at least if I'm understanding spread spectrum technology correctly - there's no such thing as a free lunch, or free receive sensitivity. If you take an ordinary narrowband signal and convert it to spread-spectrum, you can indeed make it disappear beneath the noise floor by spreading it out, and a receiver that knows where to look can despread it and pull a signal out from what looks like noise, but the effective received signal strength and signal to noise ratio after despreading is still exactly the same as it was with the narrowband signal. You haven't gained anything, you're just moving your signal around a bit. The only advantage of this spread-spectrum technique is that other signals that don't use the same spreading code are spread out by the despreading process and look like wideband noise to the receiver.

> But due to FCC regulation in the 900MHz band for example you can only instantaneously transmit at 30W.

The limit is actually 4W ERP (1 watt transmit + 6dB antenna gain) per CFR 15.247: https://www.law.cornell.edu/cfr/text/47/15.247

If you are aware of an exception to this, I would be very interested.

Any MU-MIMO technology in sight for these radio protocols? Would be a great way to potentially extend range and throughout if multiple spatial channels could be used on each frequency / radio channel for every pair of connected devices. If it could be done efficiently enough, it could also reduce congestion even in tight crowds for things like wearables by reducing interference.

I haven't seen anything using MIMO yet. Not sure how that would affect power usage. The closest thing now is that a key aspect of Ingenu's solution is receive diversity. All of their client radios require two antennas.

Not limited by the protocol per se, but limited by the design requirements of BLE.

BLE; you're talking about power requirements of ~10mA transmit (current consumption), and averages in the <10μA range. That's the whole point of the tech. It's stuff that can run for years on a watch battery.

Now: how LORA is accomplishing such crazy long ranges when supposedly consuming similar amounts of current goes a little beyond my understanding of RF. There are a few people commenting in this thread that seem to have the knowledge, though!

They're achieving those ranges by being very, very slow.

It's probably easiest to explain how this works with conventional narrowband digital modulation schemes. For a typical modulation scheme, the bandwidth of the modulated signal is proportional to the bitrate. There's also some minimum signal-to-noise ratio below which the receiver can't decode it. By sending more slowly, you get a narrower signal, which means that the receiver can listen to a narrower slice of spectrum. Even though the received signal's no more powerful than before, because the receiver is no longer hearing all the noise outside of that narrower band the SNR improves and it can decode much weaker signals.

LORA appears to use direct-sequence spread spectrum, which basically means that the transmitter applies a spreading code to convert the narrow signal to a very wide one and the receiver uses the same code to despread it again and pick out the signal. Its range improvement is still based on the exact same principle of speaking very slowly to improve your SNR though.

Reply on news.ycombinator.com