Research-stage platform

Vazgra QNet

Vazgra QNet is a research-stage software platform for modelling, simulating and analysing quantum communication systems and networks under realistic physical and network constraints.

QNet: channels, topology and protocol stateA conceptual quantum network with weighted channel paths, relay nodes, a source and receivers. Solid, sulphur and dashed paths distinguish schematic link states. No deployed infrastructure or measured values are shown.SourceRelayNetwork stateReceiverη(t)φ(t)Physical channelTopology + resourcesProtocol analysisQNet: a compact network viewA source, relay, network state and receiver are connected through distinct solid and dashed channel paths. This mobile composition is a conceptual architecture, not measured infrastructure.SourceRelayStateReceiverη(t)φ(t)
Conceptual quantum network architecture · Illustrative topology

It is being developed as a computational environment that connects physical channel behaviour, network state and protocol-dependent analysis.

In this overview

What is Vazgra QNet?

Vazgra QNet is an R&D software platform for the modelling, simulation and analysis of quantum communication systems and networks. Its intended role is to make the relationship between physical conditions and network behaviour explicit, so that a computational study can be interpreted in the context of its assumptions.

A link can be available in the network graph while being unsuitable for a particular protocol under the current channel conditions. A protocol can have a useful asymptotic description while producing a different outcome for a finite observation window. A static topology can also conceal the timing constraints of a satellite or free-space scenario. QNet is being designed to represent these distinctions within a coherent modelling workflow.

The proposed scope covers quantum key distribution, including twin-field QKD, physical channel modelling, temporal network state and topology-aware simulation. These are areas under exploration; the description does not imply that every protocol or scenario has been implemented.

A conceptual architecture

The architecture separates six responsibilities. Each layer needs an explicit interface to the next, so that a channel assumption, a topology change or a protocol parameter can be traced through the analysis. This is a proposed design structure for the platform under development.

  1. 01

    Physical channel model

    Represent attenuation, background conditions, geometry and relevant device assumptions. A channel model supplies physical quantities with defined units, a time reference and a stated domain of validity. Different scenarios may require different levels of detail.

  2. 02

    State / topology model

    Represent nodes, possible links, their temporal state and the rules that determine availability. Distinguish a physical connection from the conditions needed to use it. Preserve the relationship between channel evolution and network events.

  3. 03

    Protocol model

    Describe the protocol family, configuration and assumptions used to turn physical conditions into protocol-level quantities. Keep the selected security analysis, data requirements and finite-size treatment visible rather than embedding them implicitly in a network metric.

  4. 04

    Simulation engine

    Coordinate time evolution, stochastic behaviour and network events. Record the configuration and sampling choices that define a computational experiment. The appropriate execution approach depends on the timescales and interactions being represented.

  5. 05

    Security / performance analysis

    Evaluate defined quantities using the chosen protocol model and security assumptions. Distinguish sample statistics, physical link behaviour and protocol-dependent key quantities. A numerical output must retain the conditions under which it was calculated.

  6. 06

    Result interpretation

    Connect the outputs to the original research question. Identify sensitivities, unavailable links and limitations of the scenario. Make it possible to examine whether an apparent network effect comes from physical conditions, protocol choices or simulation assumptions.

Why quantum network simulation is difficult

Quantum communication software must connect several layers of behaviour that are often studied separately. The difficulty is not only computational cost: it is preserving the meaning of a result as physical, statistical and network assumptions interact.

Attenuation and physical-layer constraints

Optical loss reduces the probability that transmitted signals contribute to a usable observation. Detector behaviour, background events and the details of the optical link also matter. A network edge with a fixed weight is often too coarse to represent these dependencies. Fundamental Limits of Repeaterless Quantum Communications provides background on the relationship between channel loss and communication limits.

Stochastic channels and temporal correlations

A channel may fluctuate over time, and neighbouring observations need not be independent. A model that preserves only an average can lose information about short periods of poor conditions or persistent favourable conditions. R&D therefore needs to consider both the distribution of channel behaviour and the temporal assumptions used to generate it.

Changing topology and link availability

Free-space and satellite scenarios can involve visibility windows, changing geometry and links that appear or disappear. Availability is a time-dependent property. Network scheduling and route selection must be interpreted alongside the physical conditions and the amount of protocol data collected during each usable interval.

Finite-size effects and protocol dependencies

Protocol evaluation depends on the specific data, estimators and security analysis being used. Finite-key treatments account for limited data and statistical uncertainty; they cannot be replaced by an asymptotic expression without changing the assumptions. Tight Finite-Key Analysis for Quantum Cryptography introduces this distinction in a QKD setting.

Technical areas under exploration

QNet’s R&D scope is organised around the following connected areas. The list describes topics the platform may address, with implementation choices still subject to modelling requirements and validation.

Quantum communication protocols

Quantum key distribution, twin-field QKD, protocol evaluation and finite-key analysis. Protocol models need explicit assumptions and must remain connected to the physical quantities they consume.

Physical and temporal channels

Satellite quantum communications, free-space optical links, attenuation, temporal channel behaviour and stochastic processes. Scenario descriptions should make geometry, channel conditions and time evolution understandable.

Networked system behaviour

Network topology, network-state modelling, topology-aware simulation, link availability and performance analysis. These topics connect local link behaviour to questions about the network as a whole.

Potential research applications

The following are possible research uses of the proposed platform. They are directions for computational studies, rather than claims about completed projects or validated performance.

  • Satellite QKD studies: examine how visibility, geometry and physical channel assumptions affect the usable intervals of a scenario.
  • Network topology experiments: compare graph structures while keeping protocol and channel assumptions explicit.
  • Protocol comparison: study different protocol configurations under compatible, documented modelling conditions.
  • Sensitivity analysis: identify which uncertain parameters have the strongest influence on a defined output.
  • Dynamic quantum links: explore the effect of time-dependent availability and stochastic channel behaviour.
  • Architectural validation: examine whether a proposed modelling and software structure preserves the dependencies needed for a study.

Analysis that remains connected to its assumptions

A useful study needs more than an output table. It needs a clear question, a model specification, a protocol definition and an explanation of how the computation was performed. Reported quantities should identify their units, aggregation method and observation window. Variability between runs should be examined in the context of the sampling process.

This motivates a close relationship with mathematical modelling and scientific computing. An efficient implementation can still misrepresent a system if its abstractions discard a relevant dependency. Conversely, a detailed model can become difficult to interpret if its configuration and analysis procedures are not controlled.

For QKD, a security quantity belongs to a specified protocol and security argument. Simulation can explore the conditions and inputs associated with that argument; the model and the security assumptions need their own examination. QNet’s proposed architecture keeps those responsibilities visible.

Current status

Vazgra QNet is currently under research and development. It is a research-stage platform within the early-stage R&D of Vazgra Solutions. The architecture and applications described here explain the intended technical direction, with particular models, protocols and capabilities still subject to development and validation.

For a discussion of the scope or a possible research scenario, contact contact@vazgrasolutions.site. The quantum communications overview provides additional field context.

Let’s work through the problem.

For enquiries, research discussions and early conversations about the platforms in development.

contact@vazgrasolutions.site