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.)

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

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.

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.

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.

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 )

http://www.heatsynclabs.org/

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

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.

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).

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.

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/

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

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

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 !

http://stringphone.readthedocs.org/

* 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.

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...

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.

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

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.

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.

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!

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.