Usambazaji wa funguo za quantum huwawezesha sehemu mbili zilizo mbali kushiriki funguo za usimbaji fiche wa symmetric kwa kutumia sifa za fizikia ya quantum. Hata hivyo, umbali na kasi ya uzalishaji wa funguo za siri katika mifumo ya QKD inayopatikana kibiashara leo ni mdogo. Inapotakiwa kuunda quantum key kati ya watumiaji walio mbali sana, key lazima ipitishwe kupitia trusted intermediate nodes kadhaa. Shughuli za encryption, decryption na key management katika kila intermediate node zinaweza kuchelewesha kuanza kwa huduma.

Katika utafiti huu, watafiti wanapendekeza proactive quantum key relay algorithm inayotayarisha funguo kwa node pairs fulani kabla ya kuwasili kwa ombi la quantum-secured service. Algorithm inatathmini pamoja urefu wa relay path, idadi ya keys zilizopo kati ya nodes na remaining lifetime ya keys zilizopo. Mchakato unaendeshwa katika hatua mbili: kwanza 1-hop keys hutayarishwa kwa neighboring service points katika user network, kisha n-hop keys hutayarishwa kwa points zilizo mbali zaidi.

Method ilisomwa kwa simulation katika quantum-key-distribution networks mbili zilizotokana na NSFNET na COST 266 topologies. Katika scenario ya NSFNET, average key-response delay ya traditional on-demand relay ilikuwa 607,7 milliseconds; ikashuka hadi 91,3 milliseconds kwa 1-hop proactive relay pekee na hadi 65,6 milliseconds wakati 1-hop na n-hop stages zilitumika pamoja. Thamani hii ya mwisho inalingana na delay iliyo takribani %89,2 chini ya traditional method. Katika condition ile ile, idadi ya quantum-secured services zilizohudumiwa ilishuka kutoka 31.665 hadi 27.911; total relative loss ilikuwa takribani %11,9.

Katika scenario ya COST 266, delay ilishuka kutoka 505,4 milliseconds hadi 109,1 milliseconds, punguzo la takribani %78,4. Kwa upande mwingine, idadi ya served services ilipungua kutoka 33.533 hadi 28.156 na takribani %16 loss ikatokea. Results zinaonyesha kwamba kutayarisha keys mapema kunaweza kuharakisha huduma; lakini keys zinazotumiwa kabla ya demand na zinazomaliza lifetime bila kutumika zinaweza kupunguza total service capacity.

Utafiti hautumii physical QKD test environment. Delays zimekokotolewa kutoka fixed node-processing times, key generation imewakilishwa na probabilistic model, na simulation imeendeshwa kwa time slots 1000 tu zinazolingana na sekunde moja. Kwa hiyo, kabla ya proposed method kuhamishwa kwenye real networks, inapaswa kuthibitishwa kwa physical QKD devices, real traffic na long-duration experiments.

Usambazaji wa funguo za quantum hulinda nini?

Quantum key distribution au QKD inalenga kushiriki secret keys zitakazotumika katika symmetric encryption kati ya parties mbili. Kwa kuwa quantum states hubadilika wakati wa measurement, jaribio la kusikiliza quantum channel linaweza, kimsingi, kugunduliwa.

QKD haisafirishi moja kwa moja user data yote kupitia quantum channel. System kwanza huzalisha shared secret key kati ya endpoints mbili. Key hii inaweza baadaye kutumika katika one-time encryption au symmetric cryptographic methods kama AES. Security ya communication haitegemei QKD protocol pekee; pia inategemea security ya endpoint devices, authentication, key managers, classical communication channel na relay nodes.

Layered network architecture iliyotumika katika utafiti

Figure 1 kwenye page 2 inaonyesha quantum-secured network architecture iliyofafanuliwa na ITU-T katika layers nne:

Katika study, key manager iliyopo location moja na QKD module iliyounganishwa nayo kwa pamoja huitwa “QKD node”. Kila sehemu ilipo user application ina QKD node; lakini katika long-distance connections, additional QKD nodes zinazotumika kwa key relay pekee huwekwa kati yake.

Kwa nini trusted relay node inahitajika?

Katika commercial BB84-based QKD systems, umbali unaoweza kufikiwa na quantum link moja ni mdogo. Ikiwa application nodes mbili ziko mbali sana kuweza kuzalisha QKD key moja kwa moja, trusted nodes huwekwa katikati.

Figure 2 kwenye page 5 inaonyesha relay methods mbili. Katika method ya kwanza, key moja kati ya keys zinazozalishwa baina ya neighboring QKD nodes husafirishwa kama service key kwa endpoints za mbali. Katika method ya pili, starting node hutengeneza independent random key kutoka quantum random-number generator na kuipitisha kupitia intermediate nodes kwa kutumia XOR operation na QKD key ya kila link.

Kwa mfano, kwa nodes a, b na c, ikiwa hakuna direct QKD link kati ya a na c, a–b key inaweza kuonyeshwa kama \(k_{a,b}\), na b–c key kama \(k_{b,c}\). Random service key \(k_r\) kwanza husimbwa katika node a kwa \(k_{a,b}\). Node b huisimbua key hii, kisha kuisimba tena kwa \(k_{b,c}\) na kuituma kwa node c.

Sharti muhimu la security katika method hii ni kwamba node b iwe trusted. Kwa sababu intermediate node inaweza kufikia service key katika clear form, compromise yake inaweza kuvunja end-to-end confidentiality. Study inasema measurement-device-independent au device-independent QKD approaches zinaweza kupunguza assumption hii, lakini simulation inayopendekezwa inatumia commercial BB84 na trusted-node model.

Kwa nini key lifetime ni muhimu?

Key manager huipa kila quantum key lifetime fulani. Key ambayo lifetime yake imekwisha huondolewa kutoka pool hata kama haikutumika. Wakati keys kadhaa zinatumiwa kuunda key mpya kati ya nodes mbili za mbali, remaining lifetime ya key mpya huwekwa sawa na shortest remaining lifetime ya keys zilizotumika.

Kwa mfano, ikiwa remaining lifetimes za \(k_{a,b}\), \(k_{b,c}\) na \(k_r\) ni \(l_{a,b}\), \(l_{b,c}\) na \(l_r\) mtawalia, remaining lifetime ya key inayotengenezwa mwishoni mwa relay ni:

\[ l_{\mathrm{yeni}}=\min(l_{a,b},l_{b,c},l_r) \]

Kanuni hii inaweza kusababisha long-distance keys zilizotengenezwa mapema ku-expire haraka. Kwa hiyo proactive relay inapopunguza delay inaweza kutumia scarce key resources kabla demand haijafika.

Quantum key response delay imefafanuliwaje?

Figure 3 kwenye page 7 inaonyesha five-step key-provisioning process inayotegemea ITU-T Y.3807 standard:

1. Application node a huomba key kutoka QKDN kwa service kati ya a na c.
2. QKDN hutoa key na key identifier kwa node a.
3. Application a hujulisha application c key identifier.
4. Application c huomba key kutoka QKDN kwa identifier ile ile.
5. QKDN hutoa corresponding key kwa application c.

Quantum key response delay au KRD hufafanuliwa kama muda kutoka mwanzo wa hatua ya kwanza hadi mwisho wa hatua ya tano:

\[ KRD(r_{sd}^{t,i})=\tau_{21}(r_{sd}^{t,i})+\tau_{32}(r_{sd}^{t,i})+\tau_{43}(r_{sd}^{t,i})+\tau_{54}(r_{sd}^{t,i}) \]

Hapa \(r_{sd}^{t,i}\) ni ombi la i-th quantum-secured service linalotokea wakati t kati ya nodes s na d. \(\tau_{mn}\) inawakilisha muda kati ya hatua husika za key provisioning.

Katika traditional on-demand method, key relay hufanywa kati ya hatua ya kwanza na ya pili:

\[ \tau_{21}(r)=\tau_{21\setminus relay}(r)+t_{\mathrm{relay}}\{p(r)\} \]

\(\tau_{21\setminus relay}\) ni muda usio na relay; \(t_{\mathrm{relay}}\{p(r)\}\) ni total time ya key-relay operations kwenye selected path.

Katika study, jumla ya 20 milliseconds imechukuliwa kwa key-provisioning operations zote isipokuwa relay. Kila relay operation katika intermediate node imemodeliwa kuwa 20 milliseconds, na kila relay operation katika QKD node iliyo co-located na application node kuwa 40 milliseconds:

\[ t_{\mathrm{relay}}\{p(r)\}=T_QN_Q\{p(r)\}+T_{QA}N_{QA}\{p(r)\} \]

\[ KRD(r)=20+20N_Q\{p(r)\}+40N_{QA}\{p(r)\} \]

• \(N_Q\): Idadi ya QKD nodes kwenye path zisizo na application node.
• \(N_{QA}\): Idadi ya QKD nodes zilizopo location moja na application node.
• \(T_Q=20\) ms na \(T_{QA}=40\) ms zimechukuliwa.

Katika model hii, delay huongezeka kwa namna ya linear pamoja na idadi ya relay nodes kwenye path. Lengo kuu la proactive method ni kupunguza values za \(N_Q\) na \(N_{QA}\) wakati wa request kwa kufanya relay kabla request haijafika.

Upeo wa delay model

Katika equation, transmission delay ya third message kati ya applications haijajumuishwa. Watafiti wanaeleza kwamba muda huu unategemea cryptographic application inayotumika na hauwakilishi moja kwa moja service quality ya QKDN.

Times za central controller kukusanya network state, kuhesabu path na kutuma control messages pia zimeondolewa kwenye KRD kwa assumption kwamba zinafanywa mapema. Hivyo model inapima hasa processing cost ya relay katika key managers. Real end-to-end service-start delay inaweza kuwa juu zaidi.

Wazo kuu la proactive key relay

Katika on-demand method, long-distance key huundwa baada ya user request kuwasili. Katika proactive method, keys zinazoweza kutumika baadaye hutayarishwa wakati network iko idle au resource conditions zinafaa.

Mchakato huu hubadilisha link-level key pools kuwa pre-relayed multi-hop key pools. User request ikifika na suitable pre-prepared key ikipatikana, long relay chain haitendeshwi tena na service huanza kwa muda mfupi zaidi.

Figure 5 kwenye page 10 inatenganisha proactive stages mbili:

• 1-hop proactive relay: Hutengeneza keys mapema kwa QKD nodes zilizounganishwa na directly neighboring application nodes katika user network.
• n-hop proactive relay: Hutengeneza keys kwa more distant application nodes zilizotenganishwa na multiple links katika user network.

Neno “hop” hapa halimaanishi idadi ya physical relay nodes katika QKD network, bali distance kati ya application nodes katika user network. Pair iliyo 1-hop katika user network inaweza kuwa na intermediate QKD nodes nyingi katika QKDN path.

Mpangilio wa shughuli katika kila time slot

Figure 6 kwenye page 11 inaonyesha key management katika time slot moja kwa mpangilio huu:

1. Kupunguza remaining lifetime za keys zilizopo,
2. Kufuta expired keys,
3. Kuzalisha keys mpya kwenye QKD links,
4. Kuendesha 1-hop proactive key relay,
5. Kuendesha n-hop proactive key relay,
6. Kupokea quantum-secured service requests,
7. Kutoa keys kwa requests.

Ikiwa multiple service requests zipo katika time slot ile ile, requests huchakatwa kwa first-in first-out order. Request ambayo suitable QKD key haipatikani haijakubaliwa kama quantum-secured service; badala yake inachukuliwa kwamba inaweza kushughulikiwa na njia nyingine ya ulinzi kama post-quantum cryptography.

1-hop proactive key algorithm

Algorithm 1 kwenye page 12 inatathmini node pairs zote zilizo directly adjacent katika user network. Kwa kila pair, shortest path kwenye QKDN huamuliwa.

Masharti mawili makuu hutumika ili proactive relay ifanyike:

1. Idadi ya keys kwenye kila link ya path lazima iwe kubwa kuliko idadi ya pre-prepared keys kati ya target node pair.
2. Tofauti kati ya longest na shortest remaining lifetimes za keys zitakazotumika kwenye path lazima iwe chini ya threshold \(th_1\).

Sharti la pili ni:

\[ l_{\max}-l_{\min}

Kutumia pamoja keys zenye remaining lifetimes zinazokaribiana kunalenga kupunguza hali ambapo long-lived key inakuwa invalid mapema kwa sababu ya very short-lived key.

Masharti yakitimizwa, key moja huondolewa kutoka kila link kwenye path na key mpya huongezwa kwenye pool ya target 1-hop node pair. Lifetime ya key mpya huwekwa sawa na minimum remaining lifetime ya keys zilizotumiwa kwenye path.

n-hop proactive key algorithm

Algorithm 2 kwenye page 14 hutumia output ya 1-hop stage kutayarisha keys kwa more distant node pairs. Kwa kila endpoint pair, shortest number of links katika user network hukokotolewa na weight ifuatayo hutumika:

[ w(s,d)=K(s,d)\times dist(s,d) \]

• \(K(s,d)\) ni idadi ya proactive keys zilizopo tayari kati ya s na d.
• \(dist(s,d)\) ni idadi ya links katika shortest path ya user network.

Node pairs hupangwa kutoka weight ndogo hadi kubwa. Hivyo lengo ni kutoa priority kwa pairs zenye keys chache na zilizo relatively close.

Ikiwa 1-hop pools zina keys zaidi kuliko target n-hop pair na tofauti ya key lifetimes haizidi threshold \(th_n\), relay hufanywa:

\[ l_{\max}-l_{\min}

Kwa kuwa n-hop key huzalishwa kwa kutumia several 1-hop proactive keys, resource cost ya n-hop key inayo-expire ni kubwa zaidi. Kwa sababu hiyo watafiti wanapendekeza kanuni:

[ th_n\leq th_1 \]

.

Thresholds hubadilishaje uwiano kati ya delay na capacity?

Kadiri \(th_1\) na \(th_n\) zinavyoongezeka, keys zenye remaining lifetimes tofauti zaidi huruhusiwa kutumika pamoja. Hivyo proactive relay huendeshwa mara nyingi zaidi na more distant endpoint keys hutayarishwa mapema.

Threshold kubwa:

• Hupunguza relay operations wakati wa request.
• Hupunguza average KRD.
• Hutumia link keys nyingi zaidi kabla demand haijafika.
• Inaweza kuongeza idadi ya keys zinazomaliza lifetime bila kutumika.
• Inaweza kupunguza quantum-secured service provisioning rate.

Threshold ndogo hulinda keys, lakini husababisha requests nyingi zaidi kupitishwa kwenye long on-demand relay paths.

Mitandao iliyotumika katika simulation

Figure 7 kwenye page 16 inaonyesha NSFNET na COST 266 backbone topologies. Trusted QKD relay node imeongezwa takribani kila kilomita 100 kwenye kila user-network link.

NSFNET ina user nodes chache lakini baadhi ya links zake zina paths ndefu zaidi zinazofikia kilomita 2800. COST 266 ina user nodes nyingi zaidi na denser connectivity structure. Tofauti hizi zilitumika kulinganisha tabia ya algorithm dhidi ya network scale na link density.

Simulation parameters

Ikiwa normal distribution ilitoa negative result, hakuna key iliyozalishwa katika time slot hiyo. Hata hivyo, haijaelezwa jinsi fractional results zilivyobadilishwa kuwa integer key count.

Ingawa key-pool capacity imewekwa kuwa 100.000, expected key amount katika link moja wakati wa 20-time-slot lifetime ni takribani 200. Kwa hiyo, katika reported conditions, pool capacity si binding constraint kwa vitendo. Ingawa study imeingiza fixed pool capacity kwenye model, main constraint katika results ni short key lifetime.

Matokeo ya delay ya 1-hop algorithm

Figure 8 kwenye page 18 inaonyesha kwamba KRD ilipungua katika topologies zote mbili wakati \(th_1\) iliongezeka kutoka 0 hadi 20. \(th_1=0\) inalingana na traditional on-demand method bila proactive relay.

Katika NSFNET, kwa %50 request load, average relay operations zinazohitajika wakati wa demand zilishuka kutoka 28,8 hadi 2,8. Katika COST 266, chini ya load ile ile, value ilishuka kutoka 24,4 hadi 5,5. Kwa kuwa delay katika KRD equation imeunganishwa moja kwa moja na relay count, reduction hii iliakisiwa katika results.

Loss katika service provisioning rate

Kwa sababu proactive relay hutumia keys mapema, quantum-secured request provisioning rate kwa kawaida ilipungua wakati \(th_1\) iliongezeka.

Kwa mfano, katika %50 load scenario ya NSFNET, KRD ilipungua kwa takribani %85 huku provisioning rate ikishuka kutoka %70,0 hadi %62,5. Hii ni decrease ya 7,5 percentage points au relative loss ya takribani %10,7 dhidi ya starting value. Percentage-point drop na relative loss dhidi ya baseline lazima zitenganishwe.

Ni proactive keys ngapi zili-expire bila kutumika?

Figure 9 kwenye page 20 inaonyesha kwamba katika COST 266 topology chini ya %10 request load, idadi ya proactive keys zilizozalishwa iliongezeka kwa kasi kadiri \(th_1\) ilivyoongezeka.

Katika condition ya \(th_1=20\):

• 4353 1-hop proactive keys ziliundwa.
• Takribani 3098 keys zilitumika katika services.
• Takribani 1249 keys zili-time out bila kutumika.
• Kulingana na Table 5, service-use rate ilikuwa %71 na expiration rate %29.

Wakati \(th_1=18\), expiration rate ilikuwa %9; katika \(th_1=20\) ilipanda hadi %29. Result hii inaonyesha kwamba proactive relay iliyo aggressive zaidi inapunguza delay lakini huongeza key waste kwa kasi.

Mchango wa ziada wa n-hop stage

Figure 10 kwenye page 22 inaonyesha athari ya n-hop stage tofauti kwa \(th_1=15\) na \(th_1=20\). Wakati \(th_1=15\), insufficient 1-hop keys zilitayarishwa, kwa hiyo kuongeza n-hop threshold kulibadilisha KRD kidogo sana.

Wakati \(th_1=20\), 1-hop keys nyingi zaidi zilikuwa available kwa n-hop stage:

Katika NSFNET, n-hop stage ilipunguza idadi ya served services kutoka 28.245 hadi 27.911; additional loss ilikuwa takribani %1,2. Katika COST 266, idadi ilishuka kutoka 30.321 hadi 28.156 na additional loss ya takribani %7,1 ikatokea. Kwa hiyo capacity cost ya n-hop stage hubadilika sana kulingana na topology.

Ulinganisho wa moja kwa moja wa traditional, 1-hop na n-hop methods

Figure 11 kwenye page 24 inatoa ulinganisho wa methods tatu katika selected conditions.

Katika NSFNET scenario, delay ya full proactive method ilipungua kwa takribani %89,2 dhidi ya traditional method, huku served-service count ikipungua kwa takribani %11,9. Katika COST 266 scenario, delay ilipungua kwa takribani %78,4 huku loss katika service count ikiwa takribani %16.

Results hizi mbili zinaonyesha kwamba “takribani %89 delay reduction” haitumiki kwa every topology. Highest gain ilipatikana katika selected NSFNET condition.

n-hop key utilization rate

Figure 12 kwenye page 25 inaonyesha matumizi ya proactive keys katika COST 266 topology kwa \(th_1=20\) na %10 request load.

Wakati \(th_n=20\):

• 4351 1-hop proactive keys ziliundwa.
• 2511 kati yake zilitumika kuzalisha n-hop keys.
• 1391 zilitumika moja kwa moja katika service requests.
• 447 zilifutwa kwa sababu lifetime iliisha.
• 1155 n-hop keys ziliundwa.
• 810 n-hop keys zilitumika katika services.
• 345 n-hop keys zili-expire bila kutumika.

Kulingana na Table 7, katika condition ya \(th_n=20\), %70 ya n-hop keys zilitumika katika service na %30 zilipotea kwa sababu ya expiration. Proactive key creation inapokuwa aggressive zaidi, absolute number ya keys zinazotumika huongezeka lakini amount ya wasted resource pia huongezeka.

Jinsi results zinavyopaswa kutafsiriwa

Utafiti hauonyeshi cost-free method inayohudumia all network requests kwa haraka zaidi na kwa same success rate. Result ni trade-off:

• Keys zikitayarishwa mapema, successfully served requests husubiri kwa muda mfupi.
• Keys nyingi kupita kiasi zikitayarishwa, sehemu yake hu-expire bila kutumika.
• Key pools zikitumika bila lazima, baadhi ya new requests haziwezi kupata QKD key.
• Thresholds zikiwekwa low, resource hulindwa lakini KRD huongezeka tena.

Kwa hiyo, network operator haipaswi kulenga lowest KRD pekee. Acceptable delay, request-blocking rate, key-generation capacity na service priorities vinapaswa kutathminiwa pamoja.

Nguvu za utafiti

• KRD imefafanuliwa mathematically kwa kuunganishwa na ITU-T five-step key-provisioning process.
• On-demand relay na proactive relay zimelinganishwa katika same simulation setup.
• Finite key lifetime imezingatiwa na keys zilizo-expire bila kutumika zimefuatiliwa.
• Key generation imekuwa stochastic badala ya fixed.
• Key quantity na remaining lifetime zimetumika katika same relay decision.
• 1-hop na n-hop stages zimetathminiwa separately na additional contribution ya kila stage imeonyeshwa.
• NSFNET na COST 266 topologies zenye different sizes na connectivity structures zimetumika.
• Mbali na delay, service provisioning rate na key-utilization efficiency zimeripotiwa.
• Imeonyeshwa wazi kwamba proactive relay si beneficial katika every condition.

Mapungufu makuu

• Study ni preprint ambayo haijapitia peer review.
• Hakuna physical QKD device, real key manager au field network iliyotumika.
• 20 na 40 ms per-relay times zimechukuliwa fixed; variation kwa device, processor na application haikumodeliwa.
• Propagation, queue, network-controller, path-computation na control-signaling delays zimeachwa nje ya KRD.
• Simulation inadumu 1000 ms tu; long-term equilibrium behavior haijaonyeshwa.
• Independent simulation repeats, randomness seeds, standard deviations na confidence intervals hazijaripotiwa.
• %10–%50 probability ya request kwa kila node pair katika kila millisecond haijacalibrate na real service traffic.
• Same key-generation distribution imetumika kwa kila QKD link; link distance, optical loss, error rate na device differences hazijazingatiwa.
• Bit length ya generated keys haijatajwa; “key count” haijaunganishwa na real secret-key bit rate.
• Haijaelezwa jinsi fractional key counts kutoka normal distribution zilivyobadilishwa kuwa integers.
• 100.000-key pool si effective constraint katika simulation kwa sababu ya short key lifetime.
• Average KRD imekokotolewa kutoka successfully served requests pekee; latency cost ya blocked requests imepuuzwa.
• Mean values zimetolewa; 95th au 99th percentile latency-tail values hazijaripotiwa.
• Proposed method imelinganishwa tu na conventional on-demand relay; current pre-relay na key pre-flooding methods hazikutumika kama experimental baselines.
• \(th_1\) na \(th_n\) thresholds zime-scan, lakini online adaptive threshold controller kwa traffic changes haijatengenezwa.
• Compromise ya trusted relay node, denial-of-service attacks na security ya key-management layer hazijachunguzwa.
• Maneno “%88”, “%89” na calculated approximate “%89,2” katika results yanaunda minor reporting inconsistency.
• Hakuna open-access link iliyotolewa kwa code, simulation scripts, generated event streams na randomness seeds.

Utafiti unaunga mkono nini?

Results zinaunga mkono kwamba katika QKD network inayotumia trusted relay nodes na ambako key-relay time huongezeka pamoja na node count, kutayarisha keys mapema kwa baadhi ya endpoint pairs kunaweza kupunguza kwa kiasi kikubwa average response delay ya successfully served requests.

Study pia inaonyesha kwamba proactive relay si free wakati key lifetime inazingatiwa. Kutumia keys kabla demand haijatokea na key mpya kurithi shortest remaining lifetime kunaweza kuongeza amount ya resources zinazo-expire bila kutumika.

Two-stage structure inaonyesha kwamba keys zilizotayarishwa kwa short-distance pairs zinaweza kutumiwa katika key generation ya farther pairs. Hata hivyo, additional benefit ya n-hop stage inategemea kutayarishwa kwa sufficient 1-hop keys.

Utafiti hauthibitishi nini?

Research haithibitishi kwamba katika real national QKD network delay itapungua exactly %88 au %89. Reported ratios zilipatikana chini ya selected topologies, fixed processing times, 20-millisecond key lifetime na specific traffic models.

Study pia haionyeshi kwamba proactive method huongeza security. Method inasimamia key-provisioning latency; haibadilishi security proof ya QKD protocol, trusted-relay assumption au encryption security katika application layer.

Zaidi ya hayo, highest thresholds haziwezi kusemwa kuwa best operating policy kwa every network. Highest thresholds hupunguza KRD lakini katika baadhi ya scenarios zimepunguza served-service count hadi %16.

Umuhimu unaowezekana kwa Türkiye

Approach ya study inashughulikia resource-management question inayoweza kutumika katika future QKD networks nchini Türkiye kwa quantum communications, critical-infrastructure links, public data centers, defense communications, financial networks na operator backbones.

Katika network iliyoenea katika geography kubwa kama Türkiye, trusted relay nodes zinaweza kuhitajika kwa sababu ya distance limit ya direct QKD links. Katika structure kama hii, si key-generation rate ya quantum-optical hardware pekee, bali processing delay inayoundwa na key managers kwenye long paths inaweza pia kuathiri service quality.

Ili method itumike nchini Türkiye, new topology inapaswa kujengwa kwa national fiber routes na real link losses; measured secret-key bit rates za QKD devices, key-storage policies, different service classes na physical security ya trusted centers zinapaswa kuongezwa kwenye model.

Katika critical areas kama public, defense au finance, different policies kulingana na service priority zinaweza kutumika badala ya single threshold. Aggressive proactive preparation inaweza kutumika kwa low-latency critical links, huku resource-preserving on-demand relay ikitumika kwa lower-priority services.

Mbinu na Matokeo ya Utafiti

Matokeo muhimu zaidi ya nambari

• Katika NSFNET, KRD ya traditional method katika selected condition ni 607,7 ms.
• 1-hop proactive relay pekee ilipunguza value hii hadi 91,3 ms.
• Kuongeza n-hop stage kulipunguza KRD hadi 65,6 ms.
• Total delay reduction katika NSFNET ni takribani %89,2.
• Katika same scenario, served-service count ilishuka kutoka 31.665 hadi 27.911.
• Total service loss katika NSFNET ni takribani %11,9.
• Katika COST 266, KRD ilishuka kutoka 505,4 ms hadi 109,1 ms.
• Total delay reduction katika COST 266 ni takribani %78,4.
• Service count katika COST 266 ilishuka kutoka 33.533 hadi 28.156.
• Total service loss katika COST 266 ni takribani %16.
• %29 ya 1-hop proactive keys katika \(th_1=20\) condition zili-expire bila kutumika.
• %30 ya n-hop proactive keys katika \(th_n=20\) condition zili-expire bila kutumika.

Kazi zinazohitajika kabla ya real-network deployment

1. Kujenga physical testbed kwa real QKD devices na key managers.
2. Kupima actual hardware latency ya relay operations.
3. Kutumia key-generation rates zinazotegemea distance, fiber loss, quantum bit error rate na device type.
4. Kurudia simulation kwa traffic traces za masaa au siku.
5. Kuripoti confidence intervals kwa multiple randomness seeds na independent repeats.
6. Kuchunguza 95th na 99th percentile latencies pamoja na mean KRD.
7. Kuendeleza combined latency–capacity cost function inayojumuisha blocked services.
8. Kurekebisha thresholds online na automatically kulingana na traffic load.
9. Kulinganisha na demand-prediction au reinforcement-learning methods.
10. Kutumia current pre-relay na key pre-flooding algorithms kama baselines chini ya same conditions.
11. Kujaribu trusted-node failure, attack na denial-of-service scenarios.
12. Kuchapisha openly code, parameter files na simulation event logs.

Dokezo la Chanzo na Mbinu

Jina la asili la utafiti: Proactive Quantum Key Relay for Short-latency Quantum-secured Networking

Waandishi na mpangilio sahihi: Chankyun Lee, Hyunkyo Lim, Jubong Kim, Wonhyuk Lee.

Equal contribution na joint first authorship: Chankyun Lee na Hyunkyo Lim walitoa contribution sawa.

Corresponding author: Chankyun Lee.

Institutional affiliation: Korea Institute of Science and Technology Information (KISTI), 245 Daehak-ro, Yuseong-gu, Daejeon 34141, South Korea.

DOI:10.2139/ssrn.7022019

Official study page:Official SSRN record

Publication platform: SSRN.

Platform operator: SSRN platform ndani ya Elsevier.

Publication year: 2026.

Exact upload date: Exact SSRN upload day haijatajwa katika uploaded version.

Journal: Peer-reviewed journal publication au accepted final journal version haijathibitishwa.

Peer-review status: Kila page ya study ina preprint warning kwamba haijapitia peer review.

Source type: Computational communications-engineering preprint yenye mathematical latency model, two-stage heuristic resource-management algorithm na comparative network simulations kwa quantum-key-distribution networks.

Funding: Research iliungwa mkono na Korea Institute of Science and Technology Information chini ya support number K26L1M3C5 na Institute of Information & Communications Technology Planning & Evaluation grants zinazofadhiliwa na Ministry of Science and ICT ya serikali ya South Korea, kwa numbers RS-2025-02263666 na RS-2026-25530181.

Conflict of interest: Hakuna explicit conflict-of-interest statement katika uploaded version.

Use of generative AI: Hakuna statement kuhusu generative-AI use katika study.

Data na code access: Hakuna open repository link iliyotolewa kwa simulation code, randomness seeds, event logs na complete result files.

Maelezo haya ya Kiswahili yameandaliwa baada ya kuchunguza study text, algorithms mbili, mathematical equations, tables saba, network-architecture drawings, NSFNET na COST 266 topologies pamoja na latency na key-utilization graphs zote. Hakuna new scientific finding kutoka external sources iliyoongezwa kwenye results. External verification ilitumika tu kwa bibliographic check ya title, authors, DOI, platform na official study link.

Katika abstract ya study, highest KRD reduction imeandikwa kama %88, na katika contributions section kama %89. Reduction inayokokotolewa kutoka values za 607,7 ms na 65,6 ms katika Figure 11 ni takribani %89,2. Kwa hiyo result inapaswa kutolewa kama “takribani %89 katika selected NSFNET simulation”.

Reported delays si real end-to-end field measurements. Ni model results zilizokokotolewa kutoka fixed node-processing times na selected simulation assumptions. Kabla proposed algorithm haijatumika katika real telecommunications au critical-infrastructure network, inapaswa kuthibitishwa kwa physical QKD devices, under real traffic na security tests.

Meta Tags

quantum key distribution, proactive key relay, quantum-secure networks, QKD delay, quantum communication