Skip to content
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 satellite links #545

Draft
wants to merge 61 commits into
base: master
Choose a base branch
from
Draft

Add satellite links #545

wants to merge 61 commits into from

Conversation

pfittipaldi
Copy link
Collaborator

@pfittipaldi pfittipaldi commented Feb 26, 2024

This code adds satellite links to QuISP. More information can be found in quisp/modules/Satellite/README.md.

The Free-Space links work by parsing CSV files that contain distance of the satellite and atmospheric attenuation (these files can be generated with common satellite simulation toolkits). The variable link takes into account how distance and attenuation affect loss and link delay.

Furthermore, a new module was added (PointingSystem) to check when the Free-space channel will next be up. If the channel is not available at the moment, classical messages are buffered inside the node until visibility is established again.

The last addition is a modification of the existing Queue component to add some control logic: instead of just queuing the packets up, the new GatedQueue module polls the PointingSystem for visibility before sending queued messages.

The only exception to the visibility checks are OSPF packages: if a simulation starts with a satellite out of sight, the initial routing process cannot be performed. To circumvent this issue, OSPF packages are always let through in order to allow the initial routing phase to complete. The proper, longer term solution to this problem would be some kind of additional ground node that answers for the satellite for all routing purposes, but that would require classical and quantum information to follow two distinct paths.

I had to make a slight modification to the RuleEngine code: if a TimingNotification arrives that asks it to emit photons at a time in the past, the request is discarded. This could not happen in the fiber case, but is common when the satellite goes out of visibility with a buffered TimingNotification and then comes back after one orbit and sends it.

Finally, there is a note to be made concerning MSM communication: since unlike the MIM and MM link the MSM link works continuously, there was no clean way to account for variable delay in a per-round way. The solution I came up with was setting a SatResyncDelay parameter, so that every once in a while (10 ms default) the timing notification is re-generated. In the future, I would like to experiment with a version of the MSM link that works by batches, which could be good for satellite scenarios.


This change is Reviewable

@pfittipaldi pfittipaldi marked this pull request as draft March 11, 2024 08:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant