Uplink unconfirmed frames should be transmitted "NbTrans" times?

[JacoTuks]

Expected Behavior

Uplink unconfirmed frames should be transmitted "NbTrans" times except if a valid downlink is received following one of the transmissions.

LoRaWAN specification 1.1 states on page 21 in lines 595 and 596 that this is the expected behaviour.

Actual Behavior

Uplink unconfirmed frames are only transmitted once even in NbTrans is > 1.

EndDeviceLorawanMac::DoSend() does save confirmed uplink messages and will resend those.

Am I misinterpreting the specification or misreading the code?

Steps to Reproduce the Problem

1. Enable logging of EndDeviceLorawanMac
2. Run sim with unconfirmed only traffic
3. Note that no "Retransmitting an old packet." will be in the output

Specifications

• ns-3 version: 3.30
• lorawan module version: latest (4 May 2021 159cc5e)
• Platform: Ubuntu 20.04.02
• Compiler:

[DvdMgr]

You are right - repetition of unconfirmed packets is not supported currently. If you are interested in working on this, I can help out! As a starting point, we could add a counter for re-transmissions of unconfirmed packets, and schedule a new send event if this counter is < NbTrans. Upon successful reception of a downlink packet, it would be enough to reset the counter to zero, and cancel the next send event. We should also take care of resetting everything if a new packet is given to us by the application layer (that is, unless you are interested in implementing a queue).

[JacoTuks]

I'm currently working on this and I wanted to confirm the simulator's behaviour with you because I think some additional comments might now be needed when NbTrans is supported fully.

Currently, MacTransmissionCallback() saves a copy of a packet in m_macPacketTracker upon its first transmission. What happens to this first transmission in terms of PHY is stored in m_packetTracker. Retransmissions of a packet will not update its status in m_packetTracker as it already exists thus insert() fails. In addition to m_packetTracker, a packet's reception will be logged in m_reTransmissionTracker (if confirmed) and/or in m_macPacketTracker.

As a result, if a packet is sent four times (NbTrans = 4) with the end results being lost due to Tx, interfered, received, interfered the packet will be seen as successful by CountMacPacketsGlobally() as it examines m_macPacketTracker and will be recorded as Lost due to Tx from PrintPhyPacketsPerGw()'s perspective as it uses m_packetTracker.

As a result, simulation results might be confusing at first glance as this behaviour isn't explained in comments:

Legend for Print: SENT, RECEIVED, INTERFERED, NO MORE RECEIVERS, UNDER S, LOST T TX

NbTrans = 5 for dev branch which does not resend unconfirmed
CountMacPacketsGlobally
6000.000000 5348.000000
PrintPhyPacketsPerGw
6000 5348 652 0 0 0

NbTrans = 5 for new version which resends unconfirmed
CountMacPacketsGlobally
6000.000000 5415.000000
PrintPhyPacketsPerGw
6000 3671 1805 524 0 0

CountMacPacketsGlobally() shows an improvement in PDR even though RECEIVED from PrintPhy() shows that fewer packets were received. Fewer of the first attempt's were received due to the additional traffic, but due to the retransmissions, more application packets were received.

I think this can be solved by just expanding the comment on PrintPhyPacketsPerGw() to explain that this will occur. I don't think that updating a packet's status in m_packetTracker is the way to go as it then becomes a question of what outcome do you pick if different outcomes occurred.

Does this make sense + do you agree a comment is the way to go?

[DvdMgr]

I think the fact that m_packetTracker, the PHY layer packet tracker, is not updated for re-transmissions of the same MAC layer packet should be considered as a bug. I would expect the PHY layer to treat two re-transmissions of the same MAC layer packet as different packets (and thus insert a new packet for each MAC layer re-transmission).

So for instance, if you were using unconfirmed traffic and NbTrans = 5, and you had 100 EDs each sending 1 packet, you would have 100 packets at the MAC layer, and 500 at the PHY layer, each with its outcome.

I think implementing this change would also solve the confusion - do you agree?

[DvdMgr]

Closing - let's move this discussion to pull request #114.