Managing the downlink RX windows

[brocaar]

Managing the downlink RX windows

[brocaar]

@gzwsc2007 yes, I do realise that now. A nice project would be to build a packet forwarder which directly forwards over MQTT, so that the LoRa Semtech Bridge isn't needed anymore 😉

Side-note: I just tagged 0.6.0: http://loraserver.readthedocs.org/en/latest/changelog/#060. Thanks for your feedback!

[brocaar]

Regarding your first point, you're right! I overlooked this and somewhere in the process made the assumption that the two receive windows were for redundancy. Thanks for pointing this out! For reference, these snippets from the specs are mentioning this:

3.3.5 Network sending a message to an end-device
If the network intends to transmit a downlink to an end-device, it will always initiate the
transmission precisely at the beginning of one of those two receive windows.

6.2.5 Join-accept message
The network server will respond to the join-request message with a join-accept message if
the end-device is permitted to join a network. The join-accept message is sent like a normal
downlink but uses delays JOIN_ACCEPT_DELAY1 or JOIN_ACCEPT_DELAY2

Regarding your second point, I have to validate this, but you might be right. Initially, I've only tested with the RN2483 which doesn't give any "debug" info. On an IM880A-L node, I only see incoming packets for the second rx window (in WiMOD LoRaWAN EndNode Studio). Which confirms what you're saying:

I was expecting that the packet_forwarder would build up a queue since this is what is put into the logs (when compiled with debug output):

INFO: [down] a packet will be sent on timestamp value 332621236
59.20.0.13.d3.5f.d8.9.0.99.c.10.0.8.0.0.60.50.0.8e.6.20.0.0.fb.f7.dc.71.end
INFO: [down] PULL_RESP received :)
INFO: [down] a packet will be sent on timestamp value 333621236
59.61.99.13.e2.a2.18.9.0.9c.c.18.0.8.0.0.60.50.0.8e.6.20.0.0.fb.f7.dc.71.end

Putting this logic into the Semtech Bridge domain feels wrong to me, since this queue is really in the packet_forwarder domain. When implementing this into the Semtech Bridge, I would have to take into account the network latency to the gateway as well, making it really tricky to time.

[Mehradzie]

emmm... can't believe how much stuff came our of this simple conversation. good thinking @gzwsc2007. i am glad we had this chat.
@brocaar, I am very-very new to Go and years worth of developing on C# left me with lots of old habits (which die hard as we know :D still put semicolons on every line; however, I am happy to kick-start a new packet-forwarder project with the MQTT and encryption etc, etc.
But most importantly would like to know you guys' opinion on the fact that:
Now that Semtech is working on a superior packet forwarder and Lora-Semtech-Bridge is quite matured by now, is it worth the effort to develop such a packet forwarder?

I mean I am looking for the smallest excuse to get even more involved in this even if you think it remotely worth it :D

[brocaar]

It was removed since the code was outdated after the lorawan/band cleanup, not because I'm not planning to support receive window 2 in the future 😄

[brocaar]

The new packet forwarder has been released (with just-in-time scheduling)! https://github.com/Lora-net/packet_forwarder/releases/tag/v3.0.0

I think before we can use the new packet forwarder, I need to make some changes to the Semtech Bridge because of the protocol changes. I'll look into that this Friday.

[gzwsc2007]

@brocaar Thanks for the update! Regarding the packet_forwarder log, the messages only meant that the packets have been shoved into the SX1301, not that they were actually sent out. In the case of the example, the first packet is likely to have been lost.

@Mehradzie As far as I know, at this stage custom gateway binaries are preferred over the semtech packet_forwarder. For example, Loriot.io provides their own implementation of gateway binaries for different gateway platforms. I guess the Semtech one is just too basic for real-world usage?? (e.g. It uses UDP; no encryption for server communication; and it does not queue downlink messages..)

[nestorayuso]

Hi, to know the new packet_forwarder, see commits in the experimental branch: Lora-net/packet_forwarder@0a4413a
Yes, they implemented a queue for inmediate downlink and/or timed downlink.

About Lora-Semtech-Bridge, it is intended to run into the gateway or in a server? My bet is for the gateway, to translete locally between UDP and MQTTT, encryption, autentication, remote management of the gateway...

[ivajloip]

Hi,
My bet is that lora-semtech-bridge should run on the server as it seems intended to be able to serve multiple gateways.
As for the encryption, here are some problems I see. It does not seem right to me that anybody could tell the gateway to send a packet, that's for sure. On the data up side things are also not great, Trying to impersonate a gateway could lead to some form of DoS attack. Those problems could be resolved without full message encryption (an attacker can listen to all the traffic from the gateway anyway), although full message encryption might still be useful.
My two cents.

[Mehradzie]

Well, about the first part of your comment I should say, you got it right until the part that, gateway has no way of knowing if the end-node received the data on Window 1. and the Ack could be received about the data sent on Window 1 way way later. like minutes away.

The last paragraph sounds really interesting to me. Have you looked at the Semtech Packet forwarder to acquire these info? I use a Multitech Conduit which uses a different one called Basic Packet Forwarder but I assume the Conduit also has a SX1301 and a couple of SX1257s(to enable rx and tx at the same time) so it'll be in the same boat. So I am wondering if this situation could be true in our case as well. Gotta look into it a bit more.

[ivajloip]

I agree that implementing this on Semtech Bridge will not be easy. Some antennas might be connected through very latent networks. Sometimes it will be impossible to know this in advance (maybe right now the antenna is connected through the slow backup connection), but miscalculating the latency might lead to packet loss. I would expect the packet forwarder to have a queue of a reasonable size. After all the maximum number of packets that can be send for a given period of time is limited by the duty cycle, thus a good value for the queue size can be derived.

[brocaar]

First point has been fixed in 2604fc6.

@gzwsc2007

Before coming up with a rather complex scheme of deciding which RX window to use, I think it is OK to just hard-code the server to always use RX1.

It is now hard-coded to RX1. I think the best would be to switch between RX1 / RX2 based on duty-cycle management in the end.

[brocaar]

@gzwsc2007 just heard (on TTN Slack) that the queuing will be handled better in the next version of packet_forwarder 😄

[gzwsc2007]

@Mehradzie I am still quite skeptical about how well Semtech can improve their existing packet_forwarder, so I would say it is worthwhile to develop a new one. However, my concern is that will this overlap with what TTN is doing? If I remember correctly TTN also plans to develop custom gateway software such that part of the processing can be offloaded to the gateway. (And of course, this allows more features like encryption and queuing etc.)

[brocaar]

@nestorayuso it shouldn't matter how you run it, you can:

• run one Semtech Bridge and connect multiple gateways to it
• run multiple Semtech Bridge instances and connect multiple gateways to each instance (e.g. through a loadbalancer. Make sure that the straffic of the same gateway will be forwarded to the same Semtech Bridge instance each time)
• run the Semtech Bridge on the gateway itself

Semtech Bridge will subscribe to the topic(s) for each gateway it maintains a connection for, so each of the above case should work.

[brocaar]

Given that the next packet_forwarder will solve the queueing problem, I'm closing this issue.

[Mehradzie]

Hi Orne,

I have moved to the latest release and I can see that Window 2 is fully removed now :( which was commented out in the couple of previous releases and I was manually enabling it back before making the project.

I honestly think there is a misunderstanding here. If you've based your decision on the following two sections this might be just simply misreading the standard. (Although out understanding from it is still based on an interpretation)

3.3.5 Network sending a message to an end-device
If the network intends to transmit a downlink to an end-device, it will always initiate the
transmission precisely at the beginning of *_one *_of those two receive windows.

6.2.5 Join-accept message
The network server will respond to the join-request message with a join-accept message if
the end-device is permitted to join a network. The join-accept message is sent like a normal
downlink but uses delays JOIN_ACCEPT_DELAY1 or JOIN_ACCEPT_DELAY2

This is the conclusion we came down to when this has been brought up couple of weeks ago among the team.

3.3.5 Network sending a message to an end-device
If the network intends to transmit a downlink to an end-device, it will always initiate the
transmission precisely at the beginning of one of those two receive windows.

I'd say the writer is stressing on the precise moment of transmission rather than pointing out that only one windows is to be used.

6.2.5 Join-accept message
The network server will respond to the join-request message with a join-accept message if
the end-device is permitted to join a network. The join-accept message is sent like a normal
downlink but uses delays JOIN_ACCEPT_DELAY1 or JOIN_ACCEPT_DELAY2 (instead of 17
RECEIVE_DELAY1 and RECEIVE_DELAY2, respectively).

The writer is trying to point out to the reader that the correct delay is the JOIN_ACCEPT_DELAY not the RECEIVE_DELAY.

Please let me know what do you think about this :)

Cheers,

Mehrad

[brocaar]

I still think that only one receive window must be used. Some of the ism bands have duty-cycle constraints. Through the CFlist (join-accept) it is possible to provision the node with different channels on different sub-bands. This has not been implemented yet, but in this case I think it is up to the network-server to find out which receive window can be used for transmission. E.g. based on duty-cycle limitations, the gateway is not allowed to transmit on the channel for rx1, but it is allowed to transmit on the channel used for rx2.

Letting the gateway transmit on both receive window would limit the capacity of the gateways.

[nestorayuso]

Yes, it is up to the network-server to use RX1 or RX2 per node, per group, per client or per application (but the network-server can't use use both RX1 and RX2 for a single node for the same uplink).

But why there are two receive windows? to adapt better to use case, circumstances, duty-cycle limitations or regulations.

Generally it is better to use RX1, it is more spectrum and energy efficient, if uplink uses ADR, the downlink will use ADR implicitly. Instead RX2 is stuck to slowest data rate.

In EU868, RX2 benefits for the higher duty-cycle (10% in 869.525MHz, compared to 1% or 0.1%). Other benefit depending on regulation, is the possibility to use a gateway in full-duplex mode if uplink frequencies are far away from RX2 frequency (not the case in EU but possible in US).

And remember Class-B and Class-C use and must use RX2.

[Mehradzie]

Totally agreed, but I am thinking rather than removing the Window 2 code completely, could we implement a compile time parameter or something to choose between the two? 😇

I honestly didn't mind having it there commented out so I could go enable it when I want to try the Window 2 functionality on the newly designed end-node. 😄

[Mehradzie]

Thanks
On 8 Jun 2016 10:21 pm, "Orne Brocaar" [email protected] wrote:

The new packet forwarder has been released (with just-in-time scheduling)!
https://github.com/Lora-net/packet_forwarder/releases/tag/v3.0.0

I think before we can use the new packet forwarder, I need to make some
changes to the Semtech Bridge because of the protocol changes. I'll look
into that this Friday.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHHeuCmrdoQn4OaxRk-scdIoJvg-jmtZks5qJrPigaJpZM4IQfGC
.

[Mehradzie]

Haha... didn't think the reply through my Pebble watch will end up here ⌚ 😆
That would be great Orne... This is a big limitation atm and I have been waiting for their team to publish that queue enabled edition.

[brocaar]

I've implemented the new Semtech UDP protocol v2, meaning you can update your packet_forwarder to version 3.0.0 with the just-in-time scheduling!

LoRa Semtech Bridge	Semtech UDP protocol version	Note
1.x.x	1
2.x.x	2	This protocol is used since version 3.0.0 of the packet_forwarder

https://github.com/brocaar/lora-semtech-bridge

[Mehradzie]

That's fantastic news. Thanks heaps
On 10 Jun 2016 11:42 pm, "Orne Brocaar" [email protected] wrote:

I've implemented the new Semtech UDP protocol v2, meaning you can update
your packet_forwarder to version 3.0.0 with the just-in-time scheduling!
LoRa Semtech Bridge Semtech UDP protocol version Note
1.x.x 1
2.x.x 2 This protocol is used since version 3.0.0 of the packet_forwarder

https://github.com/brocaar/lora-semtech-bridge

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHHeuNEAFEm3QCeW0QsO6XmMHiyIgoKCks5qKWnLgaJpZM4IQfGC
.

[brocaar]

I'm going to close this issue. For the management of rx1 / rx2, I've just opened a new issue to track the progress of this feature #69.