5
\$\begingroup\$

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.

\$\endgroup\$
  • 4
    \$\begingroup\$ If we told you, it wouldn't be a secret anymore. \$\endgroup\$ – Olin Lathrop Feb 9 '17 at 11:55
  • 4
    \$\begingroup\$ @OlinLathrop I promise not to tell anyone, honest. \$\endgroup\$ – uhoh Feb 28 '17 at 16:55
  • 1
    \$\begingroup\$ aS YOU NOTE, THE SECRET SAUCE IS IN THE sx1308. Product page is here and says "No datasheet" under datasheet. | The find distributor" page says "Sorry none ... " for all 3 regions shown . | Many pages have various amounts of technical adumbrations. But not much useful. | Looks like "still vapourware" so far. \$\endgroup\$ – Russell McMahon Mar 2 '17 at 0:42
  • \$\begingroup\$ @RussellMcMahon ya, I'm now having a bit of regret specifying "...a citable reference or document, not just speculation". At this point would probably accept some plausible speculation that seemed well thought out. \$\endgroup\$ – uhoh Mar 4 '17 at 12:27
  • \$\begingroup\$ NOTE: 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! \$\endgroup\$ – uhoh Mar 5 '17 at 1:29
2
\$\begingroup\$

Better late than never, I guess.

"Standard" LoRa and specifically LoRaWAN are not designed to support many densely packed independently operated networks like WiFi does (for example)

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

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.

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:

  • the device can send the same amount of data using less energy
  • the device use less "air time", reducing interference

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.

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.

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:

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

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

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

\$\endgroup\$
  • \$\begingroup\$ Yippee! I will read this gem as soon as I get to a reasonable screen. In the mean time, I've just added a bounty on the other one at the same time you must have been typing this! \$\endgroup\$ – uhoh May 14 '17 at 9:36
  • \$\begingroup\$ Is it possible to include a clearly marked summary or tl;dr at the beginning or end? This is an enjoyable to read essay, but as a stack-exchange answer it would be great if there was a way for readers to have an indication of the nature of the answer without reading all the way through first. Also, is "they will use FSK" part of your answer, or just that they could, or they might? Thanks! \$\endgroup\$ – uhoh May 14 '17 at 9:58
  • 1
    \$\begingroup\$ I'll try to do a sumary. \$\endgroup\$ – Sylvain May 14 '17 at 11:18
  • 1
    \$\begingroup\$ Regarding FSK, it's part of LoRaWAN. As far as I know, it's rarely used in practice because it's not useful in "normal" density networks and it leads to a significant decrease in sensitivity for a modest gain in data-rate. Network managers in high density areas might use it for increased capacity or for special uses (RF back-haul link to gateways, link dedicated to devices firmware update, etc). \$\endgroup\$ – Sylvain May 14 '17 at 11:23
  • \$\begingroup\$ I went and dug up some LoRaWAN spec material and indeed FSK right in there in several places! It caught me by surprise - I thought it was only for some legacy reason that it was in the hardware. OK thank you for all of your helpful discussion! \$\endgroup\$ – uhoh May 17 '17 at 13:20
1
+50
\$\begingroup\$

Re-examine the assumptions behind your impression of conflict. LoRa operates on frequencies with regulatory terms that require very low temporal occupancy of a given channel, limits which sensible LoRaWAN implementations make even stricter by imposing per-node rate limits.

It doesn't matter if multiple gateways receive a transmission from a node, only those selected by a backend to reply to it should be trying to transmit a reply (and it's not even a given that a transmission from a node will elicit a reply at all - only certain types do).

Given that, there isn't any gateway-driven conflict unless gateways are randomly and improperly replying to nodes that aren't part of their particular WAN, or unless the "which gateway should reply" logic of a given WAN's backend infrastructure is broken.

There could still be conflict if the overall usage becomes too high, but that is a problem of too many nodes not a problem of too many gateways. Generally speaking it's a problem handled by retries at non-matching intervals, and by the shortness, rarity, and regulatory-required frequency hopping making the chances of transmissions colliding relatively low to begin with.

\$\endgroup\$
  • \$\begingroup\$ You make a very good point, thanks! Implicit in my thinking is that every home picocell gateway brings with it dozens of noisy little nodes the home owner has been compelled to buy to make use of the picocell gateway that they are not quite sure why they bought in the first place. Yes it's the node density, not gateway density per se, but the latter will attract the former with a multiplier of 10 to 100 (or more if you believe marketing). \$\endgroup\$ – uhoh Mar 5 '17 at 7:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.