JIT enqueue: why difference between Class A/B/C and beacon pre_ and post_delay calculation?

[brocaar]

struct jit_node_s {
    /* API fields */
    struct lgw_pkt_tx_s pkt;        /* TX packet */
    enum jit_pkt_type_e pkt_type;   /* Packet type: Downlink, Beacon... */

    /* Internal fields */
    uint32_t pre_delay;             /* Amount of time before packet timestamp to be reserved */
    uint32_t post_delay;            /* Amount of time after packet timestamp to be reserved (time on air) */
};

    /* Compute packet pre/post delays depending on packet's type */
    switch (pkt_type) {
        case JIT_PKT_TYPE_DOWNLINK_CLASS_A:
        case JIT_PKT_TYPE_DOWNLINK_CLASS_B:
        case JIT_PKT_TYPE_DOWNLINK_CLASS_C:
            packet_pre_delay = TX_START_DELAY + TX_JIT_DELAY;
            packet_post_delay = lgw_time_on_air(packet) * 1000UL; /* in us */
            break;
        case JIT_PKT_TYPE_BEACON:
            /* As defined in LoRaWAN spec */
            packet_pre_delay = TX_START_DELAY + BEACON_GUARD + TX_JIT_DELAY;
            packet_post_delay = BEACON_RESERVED;
            break;
        default:
            break;
    }

If I understand correctly, the packet_pre_delay and packet_post_delay are used to detect potential collisions in the JIT queue.

I do not understand why there is a difference between Class A/B/C packets and beacon packets in this calculation. For the gateway, I don't think there should be any difference with regards to type. It needs to schedule a LoRa or FSK modulated frame and there shouldn't be any collision. A gateway can't transmit two packets simultaneously + it needs some margin to forward the packet to the concentrator.

I believe the /* As defined in LoRaWAN spec */ is referring to:

In my understanding, this refers to the scheduling of Class-B ping slots, which is handled by the Network Server. However, this does not mean that a gateway can't sent other downlink frames, does it?

If I understand the code above correct, then it means that when a gateway has a beacon in its queue, it doesn't allow to schedule any frame TX_START_DELAY + BEACON_GUARD + TX_JIT_DELAY before this beacon, which is roughly 3 seconds. Why would this be needed?

What would be the issue with changing this code to just:

packet_pre_delay = TX_START_DELAY + TX_JIT_DELAY;
packet_post_delay = lgw_time_on_air(packet) * 1000UL; /* in us */

[rbaldwin13]

In an effort to improve our customer support experience and in recognition that our support backlog on GitHub has historically exceeded the capacity of our engineering team, we have taken the difficult decision to focus on the most contemporary issues reported and to close all others without confirmation of resolution.

Our belief is that issues which have remained unresolved and unaltered for extended periods of time are less likely to continue to pose a significant problem to the user than when they were originally filed. More contemporary issues however may still be relevant and hence are more appropriate to prioritize.

For those users who remain interested in resolution of a reported issue that was closed, we are encouraging usage of our developer portal forums [https://forum.lora-developers.semtech.com/] and commercial support portal [https://semtech.force.com/ldp/ldp_support] as the preferred avenues to receive support. We will continue to monitor the GitHub issue trackers as well, but want to encourage all users to take advantage of the increased community presence on the developer portal. For commercial customers, we highly recommend using the commercial support portal which is uniquely tailored to service such support requests.