Orchestra: optimize channel offsets of unicast slotframes #1673
Conversation
This file contains 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
|
I have updated the PR with a change that also makes EB output to use multiple channel offsets by default. |
arurke
requested changes
Jun 5, 2022
atiselsts
force-pushed
the
optimize/orchstra-multichannel
branch
from
b5bc6e1
to
88da0a5
Compare
|
Updated the code style here. |
atiselsts
force-pushed
the
optimize/orchstra-multichannel
branch
from
88da0a5
to
90b2436
Compare
atiselsts
force-pushed
the
optimize/orchstra-multichannel
branch
from
90b2436
to
517f9e8
Compare
atiselsts
force-pushed
the
optimize/orchstra-multichannel
branch
from
517f9e8
to
5d63354
Compare
arurke
reviewed
Jul 1, 2022
arurke
reviewed
Jul 1, 2022
…sc test congfiguration to avoid collisions between EB and unicast channel offsets
atiselsts
force-pushed
the
optimize/orchstra-multichannel
branch
from
5d63354
to
2cfd7f4
Compare
|
A note for future reference: This PR changes the default channel offsets for Orchestra. An overview for cases when there are more than 2 channels in the hopping sequence (HS):
Mixed deployment will thus not work (or work poorly depending on HS) and adjustments to the different |
|
I did a quick test on FIT IoT-lab, it showed a slight improvement in PRR as expected. |
arurke
approved these changes
Jul 7, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The problem: there is an intention to logically separate the channel offsets that are used for EB packets, for broadcast packets, and for unicast packets. However, the max unicast channel offset is set to 255. The real channel is calculated as
offset % hopping_sequence_size. As typical hopping sequences are much shorter than 256 elements, in many cases unicast packet are going to use the same physical channels as EB and broadcast packets, leading to potential collisions between these types of packets.The solution: the PR makes the range of channel offsets dependent on the hopping sequence size. This will not work as intended if the hopping sequence is changed at the runtime to have a smaller number of channels. However, this is not typical for most networks.
Of course, keeping the three groups of packets is separate channels is not possible if the number of channels is less than 3. In that special case we set
ORCHESTRA_UNICAST_MIN_CHANNEL_OFFSETto 0 and allow the ranges to overlap.The practical impact of this is very small for most networks, however, it makes it easier to reason about the causes of the collisions in the networks.
This is based on work done with Cysca Technologies.