The future of single-channel gateways

Gateways [obsolete] SCPF
1

Background

A single-channel gateway is a LoRa device that acts as a gateway by forwarding LoRa packets to the network. As it’s usually built using a SX1272/SX1276 instead of SX1301/SX1257, it’s a lot cheaper than a full gateway, making it a favorite choice for people to start with LoRaWAN. However, single-channel gateways are very limited compared to a real gateway. Using a single-channel gateways often leads to undesired design choices for device implementations, but also cause a lot of issues in the network as a whole.

As a reminder: Single-Channel gateways are not LoRaWAN compliant and are currently not officially supported by The Things Network.

Problems of SCGs

Single-channel gateways can only receive on one channel and one spreading factor at the same time, whereas a full gateway can receive on eight channels and six spreading factors at the same time. Some single-channel gateways can “hop” between frequencies and spreading factors to simulate a real gateway, but they still have less than 2% of the capacity of a real gateway. As mentioned in another thread by @kersing, single channel gateways project a false coverage image. Putting single-channel gateways on the map confuses many people (“why is my LoRaWAN compliant node not working when there is a gateway 60 meters away?”). Furthermore, we need multiple channels to make the network scale (using Adaptive Data Rate).

Many single-channel gateways do not have downlink support. This may lead to lost downlink messages if the network tries to schedule a downlink on such gateway, confusing people even more (“the gateway that is 60 meters away receives my message with great signal, a downlink is sent, but never received?”). Furthermore, downlink support is required for OTAA (“why does my LoRaWAN compliant device say “join denied” when I’m 60 meters from the gateway?”) and for using Adaptive Data Rate (ADR). Without downlink support, devices close to the single-channel gateway will not go to more efficient spreading factors, but instead, pollute the spectrum with unnecessary SF12 transmissions.

What I think we need to do

  1. Add Downlink Support to all SCGs: In my opinion, the biggest problem is the fact that many single-channel gateways do not support downlink. Although the hardware supports downlink just fine, the forwarder that is used, does not. As far as I know, @JBraam’s ESP8266 based single-channel gateway and the LoPy are the only ones that do support downlink. If we eventually want to support other single-channel gateways, these projects should also add downlink support.
  2. Define Single-Channel Frequency Plans: I think we should define a single-channel frequency plan (per region) outside the existing frequency plan, and use that for all single-channel gateways. Currently, most SCGs in EU are fixed to 868.1, which is one of the 3 join frequencies that are used by all LoRaWAN networks, putting significantly more load on this one channel than on the 7 other channels, which is harmful for the entire network. If we would define a completely separate frequency that will exclusively be used by single-channel gateways, we won’t harm the rest of the (LoRaWAN compliant) network anymore.

Let’s start the discussion with that.

14 Likes
2

**

Can this topic be free from how to’s and which bits and pieces one is experimenting with?

** try and keep on topic.
And if one has “thoughts” (be they ever so jumbled) one can also just reuse a post that one has, by editing it (like I do with this one)

Decreasing costs and availability of Real GW’s: may mean some issues disappear.

False hopes of coverage by “coverage” on the TTN Map: The map should only show “the real thing” as defined by core team

Pollution of the RF: where pollution is the generic term of a byproduct of what one wishes to achieve
If there is one GW in the area (and maybe only ever be one) why not a directional antenna on a device so that the RF is kept clear in other directions to avoid pollution.

Collision domain and physical limits:
node, repeater, bridge and router (Ethernet LAN: the old yellow stuff)
in relation to
device, missing1, missing2 and GW (TTN type LowPowerWideAreaNetwork)
missing1: a “thing” to allow line of site to a missing2 or GW (missing1 does not necessarily have to support many devices as it is “filling a hole”)
missing2: a “thing” that is a full blown GW without Internet connection to connect to a GW with Internet Connection. Internet is sometimes “hard” in an area with many devices that do not have LoS to a GW.

In respect to capacity (single channel “GW”): missing1 can be “interesting”.

Remember: newbie alert (with experience) but no knowledge of previous thoughts as to how to fill the holes of LoS with “GW”'s for few device, lack of easy Internet connectivity, for many devices

Ethernet yellow cable:
Based on CSMA/CD:
Carrier-sense multiple access with collision detection
LoraWAN? (which I “Like”)
Carrier-sense: not sure, transmit and pray
Multiple access: yep
Collision detection: almost, just throw the packets and hope for reception, or try again (which is also fine)

Collection of links as time goes by
https://www.thethingsnetwork.org/forum/t/single-channel-gateway-part-1/798
And if one is hungry, make some food: https://www.buzzfeed.com/alvinzhou/chicken-alfredo-lasagna

Original first post

Edit the edit
htadvisser kindly added more information later https://www.thethingsnetwork.org/forum/t/the-future-of-single-channel-gateways/6590/31?u=owenbrotherwood

So, what is the minimum channels to be a full GW, and why the “some even ten” in some context
Edit
I answer, my own question, 8 but the 10 is confusing.
As a newbie, I presume 6 spreading factors is a constant and is in the specs (I don’t need to read as such: just comply when purchasing a GW)

https://www.thethingsnetwork.org/wiki/Hardware/Gateways/Single-Channel-Gateway

  • needs revision: has the 10 and no mention of band

Edit
Latter in the topic, I read that there are systems with even more channels, which puts the original first posts 10 in context https://www.thethingsnetwork.org/forum/t/the-future-of-single-channel-gateways/6590/19
“LoraWAN has the concept of bands”
So maybe, one day, there will be a discussion on GW’s that only support single bands …???
“What is the future of Gateways”
and
“What is the effects for Devices”

3

’ a completely separate frequency that will exclusively be used by single-channel gateways ’ -

perfect !

5 Likes
4

Removed that to avoid confusion.

2 Likes
5

If the frequency in not one of the join frequencies there won’t be an opportunity for the node to join the network and receive a NewChannelReq to set the new frequency.

This will break many nodes which don’t allow changing the default frequencies (most using Semtech/Stackforce stack?)

Is the density of single channels gateways so high that this is a real problem? I expect most will be indoors anyway, so with a short range.

1 Like
6

+1 to that. SCG are test systems, so it’s perfectly valid imo to exclude them from the default network environment and into its own isolated freq plan. Anyway, nodes already need to be adjusted to work with SCGs, so, makes a lot of sense to go this route.

4 Likes
7

In my area, there are two full gateways within a 2 km range. But I cannot get an OTAA node to join the network using those gateways. After my node has been activated via my single channel gateway, messages sent by the node are also received by the two full gateways. So single channel gateways that support OTAA can be useful to help nodes getting activated. Activation may take longer because only one of three join channels is monitored, but a slow activation is better than no activation at all.

The ‘negative’ scenario’s of single channel gateways only apply when there are no full gateways in range. In that scenario full gateways would also occasionally receive messages send by a node in that area, quite comparable to a single channel gateway receiving only one in eight messages.

When there are full gateways in range, messages sent on all frequencies will be received by the full gateways in the neighborhood. Occasionally the messages will also be received by the single channel gateway. When the network decides to schedule a downlink using the single channel gateway (triggered by the reception of the message on that single channel gateway) it will just work. Downlinks on other channels will be scheduled to be sent by the full gateways. So in my opinion there is no drawback on also having some single channel gateways in an area with good full gateway coverage. In fact: this is the reason I started developing the single channel gateway. My idea was that if there were more gateways receiving (some) messages that would help in getting better geolocation via LoRaWan.

I agree that it is not desirable to ‘cripple’ nodes to use only one channel. People should be aware that LoRaWan is ‘send and hopfully it will be received’. So if there is no gateway in close range, it should be expected that some (most?) messages will not be received. Having only a single channel gateway in your area will at least have some messages received by the network, mimicking an area with no gateway in close range.

Maybe not showing single channel gateways on the map will avoid confusion. Using another icon clearly stating the channel the SCG is listening to is another option. BTW when I started with LoRaWan it took me a while to find out that ‘planned gateways’ weren’t there (yet); very confusing.

I think the idea to use a different frequency for single channel gateways is a bad idea, because it targets the wrong problem. If there is enough coverage by full gateways there is no problem, while if there are not enough full gateways they will help to ‘fill the gaps’ (handeling OTAA and some downlinks). If there are no full gateways SCG’s will provide some connectivity for LoRaWan compliant nodes, which in my opinion is better than no connectivity at all.

I think the only part of the network that should take SCG’s into account is the ADR algorithm: it is probably best not to use single channel gateway measurements to determine optimal datarates.

3 Likes
9

You are halfway there. Let me share my dodgy ideas.

First, every single person who makes a single channel gateway should be encouraged to make a network scanner, that allows them to visualize at least one sub band, with all 8 channels. Thanks to a friends help, I created a Lora frequency scanner & visualiser. It’s absolutely brilliant, allowing you to confirm precisely what channels your radio broadcasts on, and when. You can see interference, and you can see what the spectrum is like - whether it is flooded with traffic, moderately used, or completely empty (48 hours of scanning shows that sub bands 1 & 2 are completely empty of traffic in my part of the world…). It shows detail precisely, allowing you to instantly distinguish between received and transmitted packets and confirm if your packets are within spec, frequency wise. Refer SDR - software defined radio, using rtl-sdr and gqrx SDR (on Linux - in my case, a Pine64 SBC / Ubuntu 16 LTS & Mate, so I can make the scanner easily portable). Cost about $20 to $30 Australian, using entirely free software. Every gateway and node operator should make or buy one of these - it should be official policy for the things network.

Second, people who make single channel gateways should be encouraged to use and try different versions of the Arduino Lmic libraries. They are strange, you see… so far, I have 5 different versions that I pull into my scripts for different reasons. I have two Australian versions, both a bit broken but basically functional, even one locally made which has a repair on the DB output issue that affects all using RFM95s, allowing us to use full 20 dBm output and lower it if we like. This experimentation gives you a good idea of the complexities of the scripts that make up a Lora gateway and modifying them each time you change leads to insight. Here in Australia our frequency is 915 to 928. There is NO spare spectrum for isolating single channel gateways. Also, there is no recommended Lmic for Arduino that has Australian support. So AFAIK we have no choice but to recode and modify, and sit our DIY gateways in your spectrum.

Third, rapid hardware and software development will define this industry, the leaders will be those who carry out this rapid change. As I understand it we have single channel gateways, then hybrid gateways (two radios over 8 channels or one sub band monitored) and full gateways (16 channels or two sub bands monitored). The single channel ones cost as much as a $15 RFM-95, and can use an old raspberry pi or Arduino lying around. Essentially, they cost nothing. A hybrid gateway is about Australian $500 to $1500. A full gateway, well here, if I want one today, I have to pay over $2500. Now, it’s all well and good to say ‘single channel gateways are rubbish’ but when you are comparing $15 to $1500 or more, you aren’t really saying anything. I’ll wager that before too long we will be able to bond together three RFM-95 modules and have a basic non-compliant gateway that is functional, for under $50. Note, this is still a bit less than $1500. In other words, you will never get rid of single channel gateways, but they will improve, somewhat, as time passes. Any attempt to cut them off will simply drive people off the things network, onto competition, or even onto private networks.

Fourth, What you want is a temporary, short term solution, until some genius bonds together three RFM95s for $50 and calls it a gateway. The question that should be asked is “how do we best manage single channel gateways right now given that they are either substantially crippled or barely functional?” I suggest the best way is to slightly modify your existing systems. You could probably do it all in a few days given a couple of people.
A) Use the ‘DIY single channel gateway’ flag to change the icon of the mapped node, to visually show it is a single channel gateway, it must say ‘untested channel 0 sub band 1, SF 7’.
B) Have the gateway require a single successful note pass an OTAA test through it, prior to this the icon of the mapped gateway must show ‘untested OTAA joins’.
C) Have the gateway require a single successful ‘confirmed uplink’ and a single ‘confirmed downlink’, from a node through to TTN - prior to this the icon of the mapped gateway must show ‘untested unconfirmed nodes’

If you can, by some means, test and display the above, you can provide a measure of verification that will go a very long way towards improving TTN, keeping us on it.

Cheers,
X

4 Likes
10

Do you have more information about the network scanner like description and build instructions?

1 Like
11

You just buy a USB tv adaptor like one mentioned here:
http://osmocom.org/projects/sdr/wiki/rtl-sdr
Cost about $20 USD
it’s a USB RTL2832U-based DVB-T dongle.

Then you take Ubuntu and use the PPA procedure here:
http://gqrx.dk/download/install-ubuntu
Cost: Free (there are windows programs that will work as well, that are also free, if you prefer)
It’s a few lines to type in, then the program and all dependencies is installed into your Gui (On Mate you can find it under the Internet folder on the start button after the PPA installation)

Lastly, you tune it to 917.9 Mhz, which here is Australian centre of Sub Band 2. You will see all packets on that entire sub band, appear, scrolling historically, as time passes. You can guess the SF by the size, you can guess if it’s a transmit or receive.

Honestly, it’s so easy to do I am kicking myself for not doing it six months ago. Of course, no one told me I could use a $30 Australian USB TV adaptor as a software defined radio to display lora packets…

4 Likes
12

I think just removing SCG from the map and gatewaylist will already solve a lot of problems. People who deploy SCG are mainly doing this for their own ‘private’ use. They know their gateway has limited capacity. If it doesn’t show up on the map, other people wont get false hopes or be confused.

It does add to the issue of unfair or unbalanced network usage though. Using non-compliant SCG may work for the use case of the owner, but doesn’t really contribute to the network as a whole.

5 Likes
13

sorry … still don’t see your point what a 7 U$ dongle and some free software has todo with improving TTN or the future of single channel gateways.

14

Ok, a single channel gateway is not compliant to the LoRaWAN standard.

The lack of having full compliant gateways has stood in the way of deploying them for a long time.
Also TTN not delivering their gateways encouraged the development of the SCG for those who invested in the kickstarter. To a certain extend TTN contributed to the existance of so many SCG and helped to created the “issue” that is topic of this thread. .

In my opinion SCG have a purpose and they satisfy the need for a simple solution that is cost effective. The nature of SCG fits the pioneering attitude of TTN particpants. Therefore rejecting SCG it not an option in my opinion.

I do acknowledge that having SCG that are non compliant in a compliant network is undesirable.
A workaround could be to have a separate (extra) channel, as suggested, for non complaint end devices and SCG that only operate one frequency. I do not see a solution (yet) for seamless integration of SCG in the existing channel plan.

With respect to the suggested options:

  1. Adding downlink to SCG is simple. RX1 window is implemeted many times. RX2 seems not. (I have not investigated all SCG versions.
  2. Having a separate channelplan for SCG seems feaseable as long as seamless integration with the compliant part of the network is not the objective.

I think these suggestions allow small deployments of nodes and gateways in micro or nano cell level. It will contribute to the handoff of traffic of the “big” network.
In my opinion a ecosystem like the LoRaWAN deriviation for SCG micro and nano networks can coexist besides the LoRaWAN compliant network while sharing the same back-end infrastructure. A win-win?

I am looking forward to the implementation.

Cu, Remko

3 Likes
15

When you can see the RF transmission, you can see your gateways and nodes communicating. You can pair this up with the logs, and without studying the code, confirm your radio is working, and confirm what frequencies you are using. It’s about transparency, confirmation, and understanding. You can see an OTAA join.

The argument seems to be that the network is too important to be damaged by single channel gateways that monopolise a frequency.

Well, until I made the Software Defined Radio and monitored Sub Band 1 & 2 for 24 hours I had no idea if my single channel gateway was creating issues or not, whether it was damaging the network.

I confirmed that over 24 hours, there was Zero observable lora traffic on sub bands 1 & 2 in my small regional city. This is using a roof mounted antenna. I conclude that locking a single channel gateway to a frequency won’t create network issues now or in the near future where I am. Rather, having a gateway that doesn’t have the metadata on what channels it works on and whether it supports OTAA and verified uplink & downlink is IMHO creating issues. Not having a gateway at all creates issues as well. Just as a cheap home made radio shows traffic letting you see if you are playing in a crowded field, having a few status indicators or icons on a map will allow single channel gateways to remain until they are replaced by budget compliant gateways.

16

I don’t understand how removing single channel gateways from the map will solve anything, as @JBraam was saying LoRa is never guaranteed, people just need to accept that.

Even when multi-channel LoRa gateways appears on the map it means nothing regarding your ability to access it and we’ll soon see the the (painful?) realisation that indoor gateways - especially where many people will place a gateway, i.e. behind the TV next to their ISP router - just won’t offer much meaningful coverage to the network.

Many people I’ve talked to started with a single channel gateway and for them getting on the map was the “badge” for their achievement. They later moved on to multi-channel gateways. To me it would be disappointing if the plan is now to “monetise” that achievement by offering it only to those who can afford the €300 up front.

4 Likes
17

Some comments:

I think it is a good idea to test the capabilities of a gateway, and only show it on the map if it has proven to have some required features (this also applies to ‘full’ gateways!) Maybe an indication of the range of the gateway can be shown, based on received messages.

I think a single channel gateway can contribute to the network because it can help getting OTAA nodes joined and downlinks delivered in areas with suboptimal coverage. In area’s with good coverage, a single channel gateway will just occasionally be seen as another gateway that received a message.

People that want to deploy a lot of nodes in an area, should make sure there is enough coverage in that area. If there is not enough capacity they can install a full gateway to fix that. (Hope is not a strategy :wink: )

If implemented correctly, the gateway is fully unaware of the RX window a downlink is sent in. The network just tells it to send these bytes on this time using this SF and frequency. The gateway doesn’t know why or what it is sending, it just does it because the network sais so…

Using a separate channelplan can result in a separate market for ‘single channel nodes’. or ‘dual’ (both multi/single channel compatible) nodes complicating things unnecessary.

It will be single channel nodes that will monopolise a frequency! Maybe it is better to ban those from the network…

3 Likes
18

Is it possible to create my own server for a single channel gateway without downlink to just scan packets? If so, can anyone give me some starter tips?

19

Just because most people on the Forum are familiar with the typical configuration of low cost gateways (8 channels), it does not mean other configurations are wrong. LoraWAN has the concept of bands with each band comprising 8 frequencies. These 8 channel gateways therefore support only a single band.

For example, Cisco’s current LoraWAN compliant gateway supports 16 channels (two bands).

1 Like
20

take a look at this: https://github.com/gotthardp/lorawan-server for a local server. So far I’ve verified it works with TTN SCG code for NodeMCU/WeMos and ABP node built from ProMini/RFM95W. Will be testing JBraam’s SCG with Multi-SF( https://github.com/JaapBraam/LoRaWanGateway ) and a ProMini/RFM95W doing OTAA tomorrow.

2 Likes
21

I think putting less effort in building compliant gateways ‘because LoraWAN is’nt reliable after all’ is a very bad and generally unsustainable attitude. LoraWAN is best effort, and so should we be doing our best effort in building a capable and compliant network.

That’s why I’ll stick to my point: non-compliant gateways shouldn’t be on the map. It is very frustrating for new users not being able to do OTAA or test a downlink, just because the owner of the nearby gateway decided no-one needs this. Being on the map should be a badge of merit for investing time and some money in a compliant gateway.

As a middle ground, maybe SCG that do support OTAA and downlink can still be on the map, but with a different icon.

I for one don’t fear coverage issues. There are a lot of tools already to track real coverage, e.g. ttnmapper. You can’t expect gateways to reach their full theoretical coverage, but you can expect gateways to provide the basics like OTAA and downlink.

2 Likes