The Things Network's public community network indeed has guidelines to ensure fair access for the entire community.
If you deploy a private LoRaWAN network with your own gateways and your own servers, you only need to comply with the limits imposed by local regulators for the (unlicensed) spectrum you're using. In Europe's 868MHz ISM band, transmitters are limited by a 1% duty cycle. In the US's 915MHz band, transmissions are limited to a 400ms dwell time. Other regions have similar limits.
The technology is designed to scale to tens of thousands of active end devices per gateway (base station), but for that it does assume that most traffic is from end devices to the network. Larger scale can be achieved by adding more gateways.
End devices hop over multiple channels. Most gateways can receive simultaneously on 8, 16 or up to 64 channels (using 1, 2 or up to 8 antennas). The network can dynamically adapt the channels used by each end device to distribute traffic over the available channels.
End devices will use different data rates (spreading factors) for their transmissions (depending on required range). The LoRa modulation allows gateways to receive multiple transmissions on the same channel simultaneously if those transmissions use different spreading factors (most of the time, the spreading factors are "almost orthogonal").
You can deploy more gateways to create smaller cells. The network can then tell end devices to lower their transmit power.
These base stations (we call them gateways) are owned and operated by individuals, communities or companies. The gateways demodulate transmissions and forward them to The Things Network's public community network.
Yes, transmissions that have line of sight can go extremely far, mostly limited by the curvature of the Earth, which is why these records are typically broken using helium balloons. There have also been several interesting ground-to-ground records [1] [2]
The distances are of course much lower if there are obstacles (like concrete buildings) between the transmitter and receiver.
Sorry about that, I had to shorten the title to comply with HN's title length limit, and when I saw my mistake I couldn't edit it anymore. It would be nice if a moderator could fix that.
That's a question we hear quite often. The LoRaWAN specification [1] defines three classes of devices. Class C nodes are powered on all the time, which indeed has consequences for the energy consumption. For more energy constrained devices, Class B offers some kind of scheduled rendez-vous, and Class A devices only receive downlink messages after (in response to) sending an uplink message. This allows nodes to switch of their radio when they don't need it.
For comparison, BLE always uses scheduled rendezvous (B), and Thread supports always-on, and unscheduled wake-up type devices (C and A).
The downside of scheduled rendezvous is that both devices need accurate clocks, and they have to communicate regularly (once every few seconds) to maintain synchronisation.
July 2019: https://news.ycombinator.com/item?id=20562684
September 2017: https://news.ycombinator.com/item?id=15201692