Reception paths listening to the right frequency

[non-det-alle]

Where do you check if reception paths of gateways are listening to the right channel frequency? In the implementation of SimpleGatewayLoraPhy::StartReceive it doesn't seem to happen.

[renzoe]

Hi @non-det-alle (;)),

I think each reception path will be fixed to a single frequency here, when the GW object is created : https://github.com/signetlabdei/lorawan/blob/develop/helper/lorawan-mac-helper.cc#L270

( I am still learning the code, I have to check the dependency with this other part of code: https://github.com/signetlabdei/lorawan/blob/develop/helper/lora-phy-helper.cc#L81)

I think that following the "simple-network-example" logs at the time helped me to understand (though I forgot what I've learned), also the "examples/parallel-reception-example" seems good to follow the flow and see where the GW set ups this.

My 2 cents.

EDIT: Correction. Your observation is correct, I do not see where each Reception Path is fixed to a single frequency, I am gonna keep digging (as this also concerns/interest me too)

[DvdMgr]

What @renzoe says is correct - the frequencies of reception paths were set at configuration time.

We recently merged the rxpaths-new branch into develop, the commit where things changed is ee716fd5735ebe6e7ba3e04cbbf80caf07c6ae19. This is the result of us reading the SX1301 datasheet more thoroughly, and seeing no explicit mention that a demodulator should be locked on a single frequency (Section 3.6 is the one that's relevant to this discussion). This commit changed the model slightly, removing the fact that a demodulator is locked on a frequency and cannot be used to decode packets on other frequencies, which we think is the correct interpretation of what the datasheet says. In turn, the probability of a packet being lost due to unavailability of demodulators is expected to drop compared to the previous version (although not by much for networks that are experiencing a normal traffic load).

Still, I think the terminology we currently use in the ns-3 model is imprecise at best, and probably incorrect: in reality, a reception path is the component that is scanning the bandwidth at a certain frequency, which is distinct from the demodulator (of which there 8, too, and are what we are currently calling reception paths in the ns-3 model).

If you have any insight on how the GW chips work, please don't hesitate to share them! Every contribution will improve the model and we will all gain from it.

[renzoe]

Hi Davide! Thanks for the reply! And the precise pointers (for the Section of the semtech SX1301).

Reading the spec/block diagram, even if the examples they gave could have been clearer , I think your current assesement is correct. There are totally 8 Demodulators, and as long as you recognize a preamble in any SF (for any of the defined IF/frequencies) you are good to demodulate. What I have my doubts, and I think that is not possible is same SF and same IF, even if you have available demodulators (this I will check with a partner that currently has access to real GW hardware); and my understanding is that in this current ns-3 model this is possible. With a real GW will be relatively easy to test, at least set up 4-8 ED that all emit at same frequency and SF12 (long time) synchonous, and see if the GW can demodulate all in parallel.

( Small backgound; I worked with LoRa gateways/networks some years ago, when the LoRaWAN alliance yet did not exist. I am network/software person, but I was developing at relatively lower level. And I had access and configured GWs. In short, this is how you configured (and yet is the case I believe for many..) a lora GW: https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/global_conf.json#L34 .)

TL;DR: I will come soon with more insight about this issue.

[brunocitoni]

Hi everyone, I believe I was part of the "discovery" last year and as far as I remember I did run some tests at the time. I can confirm that with the updates provided in rxpaths-new you now get a configurable amount of reception paths and they no longer are locking onto a single frequency. This means you are currently able to lock on and receive up to 8 (configurable) packets with the same SF and the same IF.

As far as I am aware, I don't remember reading anything that would stop this from happening at the gateway level, though what is going to happen is that those packets should interfere & collide so they may get lost that way instead.

This said I do have a gateway handy and some nodes so I might try to run a quick test with a couple of them transmitting at the same time with the same SF and check what the gateway thinks of that.

[DvdMgr]

Yep, @brunocitoni was the one that pointed this out while conducting some comparisons with other LoRaWAN simulators, his work was key for this change. Bruno, we're glad to see that you are still monitoring the repository ;)

What I have my doubts, and I think that is not possible is same SF and same IF, even if you have available demodulators (this I will check with a partner that currently has access to real GW hardware); and my understanding is that in this current ns-3 model this is possible.

@renzoe This is only possible if the colliding packet is 6 dB below the desired packet (i.e., all cases corresponding to the diagonal in the interference matrix). In the current model, we assume this situation will trigger capture effect, but of course any insight coming from observation of actual devices is welcome and could be used to improve the model.

Let me take this chance to point something else out! Unfortunately, the first few years of life of this repository we had a lot of 'shallow' interest (i.e., coming from people that were interested in using the simulator), but could not find any long-term contributors, people that were willing to delve deeper into the code, or people that had a hands-on experience with LoRaWAN devices (aside from @peggyopal, who completed a huge and very much needed refactoring work). The focus of my research has now moved on to other topics, and the other maintainer from my old institution (@MartCp) will finish her PhD soon, too. I will of course keep maintaining the project, and we are currently working on some additional publications, but I believe that in order to keep things moving at a fast pace we need external contributors. On the development side there are lots of missing features that I think would considerably improve the module, and I think I also have a few interesting ideas to conduct some original research. If you are interested in working on this, please let me know - you can open new issues to discuss publicly, or contact me directly via email if you'd like to collaborate on original research.

[non-det-alle]

Thank you all for the interesting discussion and for taking the time to write down the clarifications! This helped me a lot. :) I will close the issue for now.

EDIT: I reopened it in case @renzoe and @brunocitoni discover something new and want to continue the discussion. I'll live to @DvdMgr the decision to eventually close it if he thinks it is the case.

[renzoe]

HI All! Sorry for the delay in responding. Thanks @brunocitoni , and great! From my part I did not activated with my colleague with what I said (testing in real GW), yet (mea culpa).

@DvdMgr Indeed Davide, this is conveyed in the diagonal; my "feeling" was empirical, I mean I sniffed a lot of packets on real GWs but I never saw (...) frames overlapping in time from same IF and SF... but I never tested on pourpose, so I am still really curious to see what happens in real hardware. Maybe we can have a nice surprise. Indeed, the model captures this theoretical "capture effect" --as you properly define--, all things being equal but power, whenever two (or more) signal/frames will overlap in time, only one will survive: the strongest. We know reality is more complicated than any model (e.g., If you can not "lock-on" a frame during the short LoRa preamble, it will not be demodulated, even if the total SNR would have been sufficient). But I am very happy with the model we have here.

[Collaboration] And I link the last last sentence with what you said about collaboration. Indeed, I am aware that all this is mostly done one good-will, at this point in time, at least for you and others originally involved. Of course, we all have/had motivations (papers, or whatever), but it would have been easier for you to either not share originally (as sadly still most computer science is done, but, in my opinion, weaker science) or not maintain the code once you achieved your original goals (still, better than not sharing :) ). So if something in the model does not suit me, I will modify from my part, and share. I do not intend to be a leecher, but I like discussing. In this particular case, thanks to this discussion, I am convinced more than this model is quite correct. Even if personally I may use another interference matrix.

To try to round up: I am currently on a project that will last for 8 or more months. In which I decided I will use this model for my purposes (I will implement ADR algorithms, using Reinforcement Learning). And I plan on sharing all my contributions, publicly, and here to the source model. So I will try to be active and open here. So far, I am still digesting ns-3 in general, and this module. So I will be involved with the ADR part: whatever I find, I will contribute. E.g., I know that ADR NS-side there is no standard, and here you use TTN's ADR . Anyway, just a to say I will be around at least in for some months :). Have a good day.

[DvdMgr]

I'd like to thank everyone involved in this discussion for their contributions. I'm doing a bit of housekeeping, so I'm closing this for now - feel free to let me know if you'd like me to re-open this and continue this discussion.