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.

[DvdMgr]

Thanks for the effort! I looked at the code and tried it out, it seems to work fine! I left a couple comments throughout the code in this review. Other general comments:

• Maybe it's best to split the pull request in two: work on the packet tracker and work on re-transmissions.
• We might be able to simplify some of the code in ClassAEndDeviceLorawanMac and EndDeviceLorawanMac, but let's leave this for another time.

Unfortunately, as of now it's kind of difficult to test the correctness of the code - I will take this contribution as a sign that it's finally time for me to write some in-depth tests. I will come back to this pull request once those are done! In the meanwhile, again, thanks :)

[DvdMgr]

You can also use MakeIntegerChecker's arguments to specify minimum and maximum allowed values:

Suggested change

	MakeIntegerChecker<uint8_t> ())
	MakeIntegerChecker<uint8_t> (1, 15))

[JacoTuks]

I made this change, but no error is given when I run complete-network-example with numberOfTransmissions=17? I tried googling this checker but didn't get examples of how this should work.

[DvdMgr]

This is expected, as the integer value is checked only if the value is set through the attribute system, which is bypassed if you use the method directly!

[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++.