Support for different, 'swappable' RF/timing models

[EskoDijk]

This adds support for simulation with different RF/timing models for RF frame propagation. The models can be defined as Go files and can be 'swapped' at runtime using a CLI command.

To enable this, a different event message format (V2) is defined while keeping also the V1 (default) format to communicate with OT nodes that use the default format. (TODO: consider if better to just add new event types.)

Two distinct radio models are included:

• Ideal - every packet has 1 us transmit duration and an infinite amount of packets can be transmitted at the same time by nodes, even by the same node.
• MutualInterference - more realistic frame transmit duration, and RF channel is busy if a node sends, causing other nodes to experience CCA failure. This takes into account the node's CCA ED thresholds for determining 'busy' / 'not busy'.

To use the new radiomodel features of this PR (TODO: consider to support also 'classic' OT firmwares), use this OT-NS with a firmware built with PR https://github.com/openthread/openthread/pull/7897 .

[Vinggui]

Medium is busy for all nodes when 1 node sends

Does it mean that the entire medium for all nodes is considered busy whenever one single node started transmitting? Did you consider the channel used? (I am still reading your code, but answering here can help future discussions).

[EskoDijk]

Medium is busy for all nodes when 1 node sends

Does it mean that the entire medium for all nodes is considered busy whenever one single node started transmitting? Did you consider the channel used? (I am still reading your code, but answering here can help future discussions).

Initially all nodes were seeing "channel busy", but currently the power of the signal and CCA ED threshold per node is used to calculate this. Good that you mention channel, because that still needs to be added! Currently a single channel is assumed and that was also the way OT-NS was practically used by me, so far.

[Vinggui]

Medium is busy for all nodes when 1 node sends

Does it mean that the entire medium for all nodes is considered busy whenever one single node started transmitting? Did you consider the channel used? (I am still reading your code, but answering here can help future discussions).

Initially all nodes were seeing "channel busy", but currently the power of the signal and CCA ED threshold per node is used to calculate this. Good that you mention channel, because that still needs to be added! Currently a single channel is assumed and that was also the way OT-NS was practically used by me, so far.

Thanks for clarifying. In PR #235, I made a way to verify interference per channel. I believe we could use your model system in something like the functions in sendChannelActivity and ReceivePacket. What do you think?

[EskoDijk]

Thanks for clarifying. In PR #235, I made a way to verify interference per channel. I believe we could use your model system in something like the functions in sendChannelActivity and ReceivePacket. What do you think?

Yes the radiomodels in here could be used in PR #235 , and vice versa the CHANNEL_ACTIVITY event could be introduced into the present PR. For the present PR, CHANNEL_ACTIVITY would not be strictly needed to do CCA prior to a frame transmit because the CCA is already done by OT-NS as part of the procedure for handling a "Frame Tx" event that the OT node sends. But it could be introduced as a separate event but I don't see yet if this brings any benefit.

Maybe it's more of a design philosophy what the Go code does and what the C code does. (Go tends to be faster to write) Do you see a benefit of letting the OT node (C code) handle the CCA explicitly?

The CHANNEL_ACTIVITY event is needed in the present PR, in order to do energy-sensing on different channels. Currently the "energy sensing" capability is not formally supported by the simulated radio but that could be amended easily. (Separate PR in this case - if only introduced to support energy detection as a feature.)

For ReceivePacket, the radiomodels can also be used indeed. Each radiomodel has an interface defined to query the model about e.g. RSSI, reachability or apply interference to a particular frame.

As next steps I'll fix the multi-channel issue in my radiomodel, and try to incorporate the new state events so the energy reporting should work. If that works out then we would have a more or less clean separation of the "energy reporting" feature from the rest of improvements.

[Vinggui]

For the present PR, CHANNEL_ACTIVITY would not be strictly needed to do CCA prior to a frame transmit because the CCA is already done by OT-NS as part of the procedure for handling a "Frame Tx" event that the OT node sends. But it could be introduced as a separate event but I don't see yet if this brings any benefit.

Ok, nice. IMO, CCA should still be handled by OT-NS and with the single event of "Frame Tx", as the channel change request happens in the package struct that arrives to the radio functions. However, treating channels separately should be very necessary, since the default protocol is definitely using this property to avoid collisions.

Do you see a benefit of letting the OT node (C code) handle the CCA explicitly?

I believe that RSSI and CCA values should be a model of the simulator, as you seem to have done, but the decision to say it is busy or not is definitely for the protocol in charge of it. Therefore, independently of the language (in this case C), the algorithm to handle it should be in the simulated device, imo.

As next steps I'll fix the multi-channel issue in my radiomodel, and try to incorporate the new state events so the energy reporting should work. If that works out then we would have a more or less clean separation of the "energy reporting" feature from the rest of improvements.

Since we are willing to unify our codes to do essentially the same feature, I'd ask you to avoid doing a duplicated work on that, instead, we should study each other's code.

[codecov-commenter]

Codecov Report

Merging #316 (75dbbaa) into main (c616148) will decrease coverage by 1.17%. The diff coverage is 48.53%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #316      +/-   ##
==========================================
- Coverage   49.97%   48.80%   -1.18%     
==========================================
  Files          38       43       +5     
  Lines        4608     4981     +373     
==========================================
+ Hits         2303     2431     +128     
- Misses       2123     2355     +232     
- Partials      182      195      +13     

Impacted Files	Coverage Δ
cli/ast.go	66.66% <ø> (ø)
dissectpkt/dissectpkt.go	80.00% <0.00%> (-20.00%)	:arrow_down:
radiomodel/radiomodelMutualInterference.go	0.00% <0.00%> (ø)
types/node_config.go	100.00% <ø> (ø)
web/site/bindata.go	99.00% <ø> (-0.01%)	:arrow_down:
cli/CmdRunner.go	21.93% <4.34%> (-1.21%)	:arrow_down:
radiomodel/radiomodel.go	21.27% <21.27%> (ø)
simulation/node.go	40.97% <25.00%> (-0.44%)	:arrow_down:
simulation/simulation.go	55.75% <36.36%> (-2.51%)	:arrow_down:
dispatcher/send_queue.go	85.18% <55.55%> (-14.82%)	:arrow_down:
... and 9 more

[EskoDijk]

For information,

• there is now a "radiomodel kbps" command to view/change the current PHY model data rate in kbps. To avoid more complexity in this PR it is in a separate branch to later make a PR from: https://github.com/EskoDijk/ot-ns/tree/pr-kbps-setting
• multiple RF channels are now also supported in the MutualInterference radio model. In the "ideal" models, this was already supported (due to no interference modeled there anyhow).

[EskoDijk]

Based on the feedback/suggestions on this PR and in https://github.com/openthread/openthread/pull/7897, I've made a new design for radiomodel simulation, so probably this PR can be closed and archived!

Thanks mostly to @simonlingoogle and @Vinggui for your comments and discussions that shaped this.

In the new design, the details of the radio operation (and state machine for it) are included in the OT node C code. This then allows multiple types of nodes to run in the same simulation in principle, e.g. nodes with different radio implementations alongside eachother. (Like Wi-Fi interference nodes, Thread nodes with Aloha-CCA, sub-Ghz Thread nodes, etc.)

The new design also integrates the features of the RTEA (Road To Energy Analysis) PRs.

[EskoDijk]

closing PR, now obsoleted by later developments in OTNS2 (https://github.com/EskoDijk/ot-ns) that contains different radiomodels.