Repository navigation
Radio: concurrent transmissions and receptions (off by default) - #1300
Open
torokati44 wants to merge 3 commits into
Open
torokati44 wants to merge 3 commits into
torokati44 wants to merge 3 commits into
Conversation
IRadio answers for one transmission and one attempted reception in
progress, getTransmissionInProgress() and getReceptionInProgress(). Code
that asks whether a given signal is the one in progress, such as
ReceiverBase deciding whether to attempt a reception and the canvas
visualizers linking a figure to a signal, cannot work with a radio that
has several in progress at once, which a later commit of this series
("Radio: concurrent transmissions and receptions") lets Radio have.
IRadio gains getTransmissionsInProgress() and getReceptionsInProgress(),
which return every one in progress. Radio, NoiseSource and ShortcutRadio,
which have at most one in each direction, implement them from their
singular getters. The callers switch to them: ReceiverBase attempts a
reception when nothing is being attempted or the reception is among the
attempted ones, and not when a preceding interferer is among them.
RadioCanvasVisualizer links the reception or transmission state figure to
a signal only when it is the only one in progress in that direction.
MediumCanvasVisualizer shows a signal in its spectrum figures only when
neither direction has several in progress; otherwise they show the
medium, as with none. With at most one in progress every answer is the
same as before.
The two methods are pure virtual rather than defaulted to the singular
getters: a radio that has several signals in progress and inherited such
a default would silently report one of them. C++ API change, stated in
WHATSNEW: an IRadio implementation must implement both.
Test: Radio_InProgressGetters (halfway through the only signal, the
plural getters hold exactly the transmission and the reception that the
singular ones answer; after it, nothing).
A reconfiguration of the radio (bitrate, bandwidth, and the IEEE 802.11 mode set, mode, band and channel) stops attempting the reception in progress by resetting the receptionTimer member, and a newly attempted reception replaces the one in progress the same way. Neither is logged: the log shows a reception "attempting" and later "ignoring", with nothing between to say why. The new abandonAttemptedReceptions() does this for the seven setters and startReception(), and logs "Reception abandoned" for the reception, in the format of the other reception lines. The timer stays scheduled, owned by allReceptionTimers, and the reception is ignored when it ends, as before; the reception state and the received signal part are still updated only by the next reception event. The call also gives the subclasses one place that drops the attempt, which the next commit needs when the single member becomes a vector. Test: Radio_AbandonedReception (the receiving radio's bandwidth is set halfway through the only signal: attempting, abandoned, ignoring, nothing sent up).
Radio held one transmission timer and one attempted-reception timer, so it could transmit one signal and attempt one reception at a time. Both become vectors: transmissionTimers (a pool: idle timers are reused, so a radio that never transmits concurrently still allocates exactly one) and attemptedReceptionTimers. Two new parameters, both default(false), keep today's behavior: - allowConcurrentTransmissions: without it, a packet from above while transmitting is still an error; - allowConcurrentReceptions: without it, a newly attempted reception replaces the one in progress, as the single member did. The receivers shipped with INET attempt one reception at a time, except Ieee802154UwbIrReceiver, which attempts every one and relies on that replacement. Radio's getTransmissionsInProgress() and getReceptionsInProgress() return every transmission and attempted reception in progress. Its getTransmissionInProgress(), getReceptionInProgress(), getTransmittedSignalPart() and getReceivedSignalPart() answer for the one signal in progress in their direction, nullptr or SIGNAL_PART_NONE when there is none, and throw an error when there are several: then there is no one transmission, reception or signal part. The two signal parts, and the signals emitted when they change, are only updated while at most one is in progress; when one of two attempted receptions ends, the received part becomes the other one's. A model that relies on the parts, such as the StateBasedEpEnergyConsumer and StateBasedCcEnergyConsumer energy consumers, therefore cannot be used with a radio that has several signals in progress at once. The callers in INET that must see every signal already ask for all of them, and abandonAttemptedReceptions() now drops every attempted reception. C++ API change for Radio subclasses: receptionTimer/transmissionTimer are gone, continueTransmission(), endTransmission() and abortTransmission() take the timer, and a subclass that dropped the attempted reception by resetting receptionTimer calls abandonAttemptedReceptions(). Tests: ConcurrentRadio_1 (both enabled: two overlapping transmissions from one radio, both attempted and sent up at the receiver; halfway through, 2 transmissions and 2 receptions in progress, and the singular and part getters throw), _2 (the default transmission guard), _3 (the default replacement), _4 (on a dimensional medium, three senders at once, two sharing a band and one on another, all attempted by a receiver that takes any signal within its listening band: the pair collides, the third is decoded; 3 receptions in progress), _5 (with nothing in progress the singular getters answer nullptr and the part getters NONE, with and without concurrency) and _6 (separate reception parts: with two attempted receptions the received part getter throws; when the earlier one ends, the part is the header of the other one).
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Split out from #1281.
Radiocan transmit only one signal and attempt only one reception at a time. A cellular base station needs several of each: it serves many users at once, each on its own part of the band. This PR letsRadiodo that behind two new parameters, bothdefault(false). With the defaults, behaviour is unchanged.Each commit builds and makes sense on its own, so it's easiest to review them in order:
getTransmissionsInProgress()andgetReceptionsInProgress().ReceiverBaseand the canvas visualizers use them instead of the singular getters. With at most one signal in progress, every answer is the same as before. I made them pure virtual on purpose: a default built on the singular getters would silently report just one signal for a radio that has several.abandonAttemptedReceptions()logs "Reception abandoned". It also gives the next commit one place where the attempt is dropped.allowConcurrentTransmissionsandallowConcurrentReceptionsturn the feature on. The singular getters keep working while at most one signal is in progress in their direction, and throw when there are several.Compatibility, described in two WHATSNEW entries:
IRadioimplementation that doesn't derive fromRadiomust implement the two new methods. In INET,NoiseSourceandShortcutRadioare updated.Radiosubclasses losereceptionTimerandtransmissionTimer.continueTransmission(),endTransmission()andabortTransmission()now take the timer as an argument.StateBasedEpEnergyConsumerandStateBasedCcEnergyConsumer, can't be used with a radio that actually has several signals in progress.Ieee802154UwbIrReceiverattempts every reception and relies on the newest one replacing the current one. That still happens with the defaultallowConcurrentReceptions = false.Tests (in
tests/module):Radio_InProgressGettersandRadio_AbandonedReceptioncover commits 1 and 2.ConcurrentRadio_1–_6cover commit 3: