-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add MAC command tests and improve MAC layer implementation #183
base: develop
Are you sure you want to change the base?
Conversation
…up and modernize c++, fix printing output
… end-device, tests
… unit of measure, add tests
…ting, clarify margin code
…void name collision with ns3::Create
- add missing EU868 radio sub-bands and fix tests - downgrade SubBand from Object to SimpleRefCount - remove unused default constructor/destructor - refactor BelongsToSubBand to Contains for clarity - re-add last frequency getter
- downgrade LogicalLoraChannel from Object to SimpleRefCount - remove unused default constructor/destructor and incomplete initializer constructor - remove setters (constructor initialization only) - refactor SetEnabledForUplink to EnableForUplink (align with DisableForUplink)
- redo the channel storage model to be aligned with LoRaWAN specifications: a fixed size array of channels accessed by index - GetRawChannelArray replaces GetChannelList and GetEnabledChannelList as the only way to get channels: the MAC layer now performs its channel-related tasks (get wait time, get TX channel, change channel mask) outside of this class with just one sweep through of the array - AddChannel becomes just SetChannel at index, in line with the channel storage structure found in the LoRaWAN specifications - Similarly, discard RemoveChannel function: channels can be overwritten in the internal array with SetChannel as in specifications - downgrade LogicalLoraChannelHelper from Object to SimpleRefCount - add size initialization to constructor, remove default constructor - remove aggregated duty-cycle management (already managed by external MAC layer) - FIX duty-cycle next transmission time calculation in AddEvent - add channel validity check - add GetWaitingTime overload by frequency (that's what it is needed to get the wait time, no need to create an ad-hoc channel instance just to retrieve the wait time) - add AddEvent overload by frequency (same reason as above) - add GetTxPowerForChannel overload by frequency (same reason as above) - remove channel addition by frequency, leading to incomplete tx channel creation (i.e. default values) + param duplication. This now mandates explicit external creation of channel instances to then be passed to the helper by pointer - remove AddSubBand with init params, now only by pointer (same reason as above)
- remove unused destructors - remove setters (mandate initializer constructor use) - add missing getters for implemented commands - add implementation TODOs - improve printing and align teminology with specs - add overflow asserts for field with size < 8 bits - remove empty lines and boilerplate
- re-implement GetNextTransmissionDelay and GetChannelForTx - remove now obsolete Shuffle method - add setter and getter for transmission power - correct ChMaskCntl spelling as per specifications - remove AddSubBand and SetLogicalChannel
- better time printing using Time::As() - prefer more general Time(0) instead Seconds(0) or others when indicatign zero time - use time methods Time::IsZero(), Time::IsPositive(), etc. when working with time - prefer shorter Now() in place of Simulator::Now()
7c4edaa
to
ee04065
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #183 +/- ##
===========================================
+ Coverage 77.66% 84.56% +6.90%
===========================================
Files 66 67 +1
Lines 6831 7017 +186
===========================================
+ Hits 5305 5934 +629
+ Misses 1526 1083 -443 ☔ View full report in Codecov by Sentry. |
@pagmatt What do you think it's best for review? Ideally we should try to split this into multiple PRs, to also have more descriptive commits in the history of the develop branch. |
These changes started as an initiative to improve test coverage because the CI was failing in PR #179, with the initial objective of covering
mac-command.cc
.This has proven to be way more challenging than expected due to the numerous inconsistencies of the code with the LoRaWAN specifications, bug prone snippets and overall messy state of the MAC layer code inherited by previous contributors. Expectedly, all these aspects have arisen in full effect since I begun writing tight tests for the functionality of MAC layer commands as received by end devices. Very often, correct test implementation required a priori changes to add functions, to fix internal behaviors or even to re-design multiple classes.
Obviously, even more work will be required to reach a satisfying state of the device-side MAC layer implementation (I am talking about dubious device classes inheritance, reception window implementation full of boilerplate and duplication, unrealistic duty-cycle management #163, etc.) but at least the present changes bring code related to existing MAC commands (more commands still need to be implemented in the future) up to speed. Notable major rework also affected the devices' frequency channel management framework (
LogicalLoraChannelHelper
,LogicalChannelHelper
,SubBand
) to correctly handle configurations apported by MAC commands.I know this is a huge PR, but - aside some minor global changes (better time printing, annotating variable/functions with unit of measure of physical quantities) that can be always separated from this PR - most changes have a strong interdependence and are not trivial to break up without introducing bugged commits. I tried my best to at least have a clean organization of changes in multiple commits, to also help review. Here is the list of changes as found inside this PR's commits from oldest to most recent with some additional annotations in italics:
Let's check if CodeCov is happy with the coverage. Of course I am open to try and break up these changes in multiple PRs to help review. Although, with smaller PRs code coverage may be partial.