Improving NbTrans support for class A

[JacoTuks]

This request improves NbTrans support by causing both unconfirmed and confirmed traffic to be transmitting NbTrans times.

This code was written for class A devices and whilst NbTrans is supported fully the LinkADRReq command does not update NbTrans. I assumed that most people aren't using ADR and those that do would have noticed that this command never supported NbTrans updates and would have implemented it themselves if required.

Furthermore, the code doesn't test if you provided a NbTrans value between 1 and 15. It will simply attempt to transmit the packet's the provided number of times.

This pull request fixes issues #110 and #112

Proposed Changes

• LoraRetxParameters struct now has an additional boolean value sendingMultipleUnconfirmed.
• PhyPacketData is now a multimap to allow for the storage of duplicate packets. Each packet's PHY result is now saved and thus PrintPhyPacketsPerGw() will now indicate what happened to all of the transmitted packets.
• The default number of transmissions have been changed to the protocol's stated 1 instead of the current 8.

[JacoTuks]

I have made some of the smaller changed. I haven't split it into separate commits yet. I will wait for that once you have written more tests.

The last commit was to change numberOfTransmissions to an int complete-network-example. I noticed that when you pass a value using sem, the passed value will be different if this variable was a uint8_t.

[DvdMgr]

The last commit was to change numberOfTransmissions to an int complete-network-example. I noticed that when you pass a value using sem, the passed value will be different if this variable was a uint8_t.

Can you expand on this? Is sem/the ns-3 script distorting the value?

[JacoTuks]

The last commit was to change numberOfTransmissions to an int complete-network-example. I noticed that when you pass a value using sem, the passed value will be different if this variable was a uint8_t.

Can you expand on this? Is sem/the ns-3 script distorting the value?

This is how I understand it.

In my sem script, numberOfTransmissions is a Python int. If the ns-3 script expects an uint8_t and not an int it will receive a different value as Python doesn't have the concept of a uint8_t.

For example, if the sem script passes 3 it gives you 51 when you print with std::cout<< (unsigned) numberOfTransmissions :: std::endl;

An easy way to see the impact of this is when running a confirmed sim.

Adding the following to RequiredTransmissionsCallback() will allow the sim output to show if(reqTx > 3) std::cout<< "More than 3: " << (unsigned) reqTx << std::endl;

More than 3: 6 More than 3: 5 More than 3: 4 More than 3: 6 More than 3: 7 More than 3: 4 ... 200.000000 200.000000

Changing to an int from uint8_t allows the value to be safely passed and then the conversion from int to uin8_t happens inside the ns-3 script rather than Python -> C++.