tl;dr: "Standard" LoRa and specifically LoRaWAN are not designed to support many densely packed independently operated networks like WiFi does (for example). And yet SEMTECH has announced they will support LoRa Picocells for home LoRa networks. How do they overcome LoRaWAN's limitations?
I have news in several places that SEMTECH is now distributing the SX1308 LoRa Picocell gateway chip. In most places I read the same press-release material, but in EDN-Europe the title of the item LoRa Picocell Gateway reference design extends LoRaWAN coverage has the additional term reference design. I haven't been able to find this gateway reference design yet, perhaps it's available only to LoRa Alliance members at this point?
I would like to know how SEMTECH plans for the LoRa Picocells – at a density of say one per household – manage to avoid the collisions, blocking each other or otherwise interfering with each other that can happen if two radios (nodes or gateways) transmit on the same combination of frequency and spreading function (SF) at times close enough that they effectively overlap.
LoRa has primarily been optimized for low power, low data rate, low update rate, and long distance applications. Currently the best way to avoid these limitations is for multiple independent users to work with one or a few gateway providing services.
A home-by-home gateway implementation with from kilometer to tens of kilometer range would certainly lead to some problems, and since power is often available in homes, if there are any externally powered nodes they would not have the practical constraint of infrequent transmission to conserve battery life.
This answer to my previous question contains a hint about one potential method, and I can imagine others, including limits on transmitted power, but I would like to know how SEMTECH's plan for Picocell implementation actually does this, and at least roughly how it is specified, or how the LoRa chips must be configured for LoRa Picocell operation.
Some reference material can be found in:
NOTE: About the bounty: I can't edit the comment in the bounty, but recognizing that there really isn't anything official out there, at this point I will gladly consider careful, reasoned speculation.
Best Answer
Better late than never, I guess.
WiFi is quite short range, that's why you're under the impression that it handles high density better. When the size of a network barely goes beyond the walls of an apartment, it's quite easy for dozens of networks to cohabitate in the same building.
In a dense urban setting, WiFi effective range is around 20m. In the same setting LoRaWAN reaches around 1km. That's 2500 times more area for a given "cell" (more on that later) and the density has to be understood relative to the surface covered. Having hundreds of LoRaWAN gateways per square-km would be equivalent to having half a dozen of WiFi APs per room... and I think LoRaWAN was designed to handle that case much better than standard WiFi was¹. ;)
Side note ².
At the MAC/LLC level, LoRaWAN, like WiFi, use variable data-rate to optimize capacity. In LoRaWAN, this essential function is called "adaptive data rate" or ADR. In both cases, when a device is "close" (in the radio sense, so when it has a good link margin) to a gateway or access point, a higher data-rate is used, with the following benefits:
At high data-rate, a LoRaWAN network can use FSK modulation instead of LoRa, so you get the same range/spectral efficiency/interference problem as with all the legacy systems.
In both LoRaWAN and WiFi it's possible to decrease RF TX power, but it's only used when data-rate has reached the max, as it's preferable, from a network/interference point of view, to transmit faster at nominal power than to transmit at lower power and nominal speed.
Like the SX1301, the SX1308 is an array of receivers. On each radio channel of a given LoRaWAN network (200kHz channel width, 125kHz LoRa modulation bandwidth) the SX130x listen for six different data-rates simultaneously. That way, a device can send a frame to the network without having to reserve a time-slot or negotiate a predetermined data-rate with the network beforehand³, a process that is quite energy consuming. The SX130x always listen on all channels, all data-rates.
One of the specificity of LoRaWAN is that the "core" of the radio network is not the gateway, but a level above, the network server. If neighboring gateways are connected to the same server, they act as a single network. If not, they act as independent networks. In my opinion, you end-up with three different scenarios:
Lots of people buy gateways with stand-alone network servers, and use them with sensors in and around their home. Each independent network uses 3-4 channels and try to pick a different set of channels than the close neighbors (like WiFi). In that scenario, most sensors use the highest data-rate. Some sensors in unfavorable environments use lower data-rates but none are stuck at minimum speed (~300 bits/s). LoRaWAN can handle tens of thousands of low duty-cycle / high data-rate per square km. Interference would be low.
Lots of people buy gateways⁴ to connect to sensors beyond their home environment (eg. car or pet trackers) and use community networks (eg. The Things Network) for coordination. In this scenario, a high density of coordinated gateways allow all sensors in the community network to minimize data-rate. Devices can roam freely on the area covered by the network. Link reliability is high due to spatial diversity provided by the many scattered gateways. Encrypted data payloads from and to devices are transported on the community network, but only the owner of the device get access to clear-text payload. Regional frequency coordination can be handled on an ad-hoc basis by community and corporate network managers. Interference would be low assuming only a small number of networks share an overlapping region.
Lots of people buy single-channels gateways (all devices stuck to the lowest data-rate), or use standard gateways after disabling ADR, or use standard gateways with stand-alone network servers to connect to a large number of distance devices. In that scenario thousands of devices are stuck at the lowest data-rate, using as much time-on-air as they're legally allowed to use, draining their battery fast and not having a great reliability. Corporate private networks would still work for the site they're designed to cover but corporate public network would be limited to application that can handle packet losses of more than 20%.
Overall, I'm quite optimistic, as the migration from stand-alone networks to coordinated network requires a low effort, no change in hardware, and is transparent for the devices. But if you combine a high density of people and/or sensors, fierce individualism (not wanting to coordinate with a community, no interest in sharing spectrum) and magical thinking (long range = I can stream audio from kilometers away) you're in a "tragedy of the commons" kind of situation.
¹: To come back to your initial statement, for WiFi, each access point is normally an independent radio network, interference is an issue, high density leads to poor data-rates, and handover between APs is not handled gracefully. In dense WiFi deployments (eg. WiFi in stadiums, or when telcos use WiFi to serve residential customers from a water tower), access points rely on using dozens of independent channels in the 5 GHz band, proprietary magic sauce, GPS coordination, proprietary seamless handover, etc, with an external "server" in charge of managing the network.
²: Semtech doesn't write protocols nor do network planning. Semtech does the PHY layer and design chips to handle the PHY layer, period. LoRaWAN was a collaborative effort from the very beginning, and it is now in the hands of the LoRa Alliance.
³: That's why so-called "single channels" LoRaWAN gateways you might see popping up here and there are an heresy. You have to have this simultaneous multi-channel and multi-data-rate capability to be able to have a robust and salable network.
⁴: Practically, it makes sense for community to group-buy gateways, as a handful of gateways per city block is enough to provide coverage and capacity for the kind of applications LoRaWAN was designed for.