How does LNS handle downlink messages?

ChirpStack Network Server
1

Hi, I have a few questions with regards to how LNS handles downlink messages.

  1. Does LNS have its database to buffer downlink messages separately for each end device?
  2. If answer to 1) is Yes, how does the server decide the sequence of dequeueing if there are multiple queues for multiple EDs waiting to be sent? Does it do all at the same time?
  3. What happens to the lora packet if at the moment of sending, none of the GWs are available (either due to duty cycle or is in TX mode)?
  4. How does LNS do retransmission for confirmed DL frame?
2

Let me try to answer, but I’m not sure it is 100% right.

  1. Yes, in pg database, there is a table name like device_queue, each queue item (let’s call it qi) has devEUI.

  2. I will explain it in two situations:

  • For class-A and class-C, there is the same process, every uplink will trigger a downlink chance, we can call this process as handleUplinkResponse, it pops up the qi and loads all needed mac command, set ACK(if it is confirmed up), set txInfo, and etc. Then send it (if any to send) to gateway. (normally, this will use rx1, as LoRaWAN specifying class A and C both open rx1 after uplink, but this is configurable for loraserver to force rx2 or rx1 then fallback rx2).
  • For class-C or B only, loraserver will roll poling the database, if there are any class-C or B devices which have qi to downlink, and then it handles qi for those devices, we can call this as SchedulerLoop, and each polling is a ScheduleBatch, they run in an interval, by default it is 1s and in every batch, it will try 100 devices max (if there are this much). So technically, it does not send all at the same time, but I think, for LoRaWAN, it is not possible to send that many frames at the same time actually.
  1. I think that is handled by Packet-Forwarder which is running in gateway, it will feedback the UDP packet (PULL_RESP) handling result which in protocol we call it TX_ACK, and lora-gateway-bridge will push it to MQTT, then loraserver handle it, for tx failed, it will run into retransmission (if there is chance to fallback).
  2. I will consider it has this, but recently, I found that loraserver seems to not store the confirmed qi if it is not acknowledged, see my post:
    https://forum.loraserver.io/t/can-server-store-confirmeddatadown-queue-when-there-is-no-ack-for-it/4870?u=hobairiku
2 Likes
3

Hi There

Please see my answers below.

  1. Does LNS have its database to buffer downlink messages separately for each end device?
    [Answer]
    Any GW that had heard that datagram will forward it to the LNS.
    Therefore the LNS might receive some duplications of the SAME datagram.
    Each one of the GW will send the LNS (using the backend protocol) the received packet (header, encrypted payload, CRC), as well as the corresponding Metadata.
    The Metadata has among some key info such as the RSSI it was received as well as the Time Stamp (which corresponds to the last bit received for this datagram) as well as channel, SF (spreading factor) and other relevant info.
    Based on those (multiple packets) the LNS will
  • DeDuplicate - first step is to decide which packet is the one he will respond to! and it is mainly but only RSSI driven
    Then it
  • Decode only the header using the NetworkSessionKey (it cannot decode the Payload!)
  • based on the above the LNS will process it for example
    — If it is a MAC command it will process it accordingly
    — if it is a Data packet, that needs to be forward to a specific AS (Application Server) it will do so. Mind that there could be more than one AS in a given system.
    — If the UpLink was of a Confirmed type it will create an ACK
    The LNS will send the GW the needed DownLink, again with a Metadata that includes - Which Channel to respond on, which SF to use, and the most important at what TIME to TX the DownLink
    The GW will stage the packet based on the Time Stamp from the LNS and will send it

  1. If answer to 1) is Yes, how does the server decide the sequence of dequeueing if there are multiple queues for multiple EDs waiting to be sent? Does it do all at the same time?
    [Answer]
    The queuing is done at the GW level, which has something referred to as Just In Time (JiT) mechansim, this mechanism queues the responses (again at the GW level)
    The LNS calculates the response time based on the RX1 (or RX2)

  2. What happens to the lora packet if at the moment of sending, none of the GWs are available (either due to duty cycle or is in TX mode)?
    [Answer]
    Good question!
    Please mind that the EndNode to LNS communication is not ‘really’ synchronized.
    Thus, if the GW is busy it will just NOT TX (based on its internal priorities)
    The End-Node will miss the ACK, and will just TX the same packet (same FCount) again, and again until it receives the ACK… Well, Again and Again, is really depends on the MAC that is implemented inside the EndNode. In all reality, it will try a few times, and them will assume that it lost connectivity or it is not JOINED and more, and will try to send a JoinRequest…
    If even the JoinRequest fails, again, depending on the state-machine, it will either jump to another channel block or will just wait for a ‘while’ and will try again from the top (JoinRequest)

  3. How does LNS do retransmission for confirmed DL frame?
    [Answer]
    Please see above, I beleive I did answer this

2 Likes