अंतराळ संप्रेषण मानकांबद्दल थोडेसे

उल्का M1 उपग्रह
स्रोत: vladtime.ru

परिचय

स्पेस टेक्नॉलॉजीचे ऑपरेशन रेडिओ संप्रेषणाशिवाय अशक्य आहे आणि या लेखात मी इंटरनॅशनल अॅडव्हायझरी कमिटी फॉर स्पेस डेटा सिस्टम्स (CCSDS) ने विकसित केलेल्या मानकांचा आधार बनवलेल्या मुख्य कल्पना स्पष्ट करण्याचा प्रयत्न करेन. हे संक्षेप खाली वापरले जाईल. .

हे पोस्ट प्रामुख्याने डेटा लिंक लेयरवर लक्ष केंद्रित करेल, परंतु इतर स्तरांसाठी मूलभूत संकल्पना देखील सादर केल्या जातील. हा लेख कोणत्याही प्रकारे मानकांचे सखोल आणि संपूर्ण वर्णन असल्याचा अभिप्रेत नाही. तुम्ही ते येथे पाहू शकता साइट CCSDS. तथापि, ते समजणे खूप कठीण आहे, आणि आम्ही त्यांना समजून घेण्याच्या प्रयत्नात बराच वेळ घालवला, म्हणून मी येथे मूलभूत माहिती देऊ इच्छितो, ज्याने इतर सर्व काही समजून घेणे खूप सोपे होईल. तर, चला सुरुवात करूया.

CCDS चे नोबल मिशन

कदाचित एखाद्याला प्रश्न असेल: जर तुम्ही तुमचा स्वतःचा मालकीचा रेडिओ प्रोटोकॉल स्टॅक (किंवा तुमचे स्वतःचे मानक, ब्लॅकजॅक आणि नवीन वैशिष्ट्यांसह) विकसित करू शकत असाल तर प्रत्येकाने मानकांचे पालन का करावे, ज्यामुळे सिस्टमची सुरक्षा वाढते?

सराव दर्शविल्याप्रमाणे, खालील कारणांमुळे CCSDS मानकांचे पालन करणे अधिक फायदेशीर आहे:

1. मानके प्रकाशित करण्यासाठी जबाबदार असलेल्या समितीमध्ये जगातील प्रत्येक प्रमुख एरोस्पेस एजन्सीच्या प्रतिनिधींचा समावेश आहे, ज्यांनी अनेक वर्षांच्या डिझाइन आणि विविध मोहिमांच्या ऑपरेशनचा अनमोल अनुभव मिळवला आहे. या अनुभवाकडे दुर्लक्ष करून पुन्हा त्यांच्या रेकवर पाऊल टाकणे अत्यंत मूर्खपणाचे ठरेल.
2. ही मानके आधीच बाजारात उपलब्ध असलेल्या ग्राउंड स्टेशन उपकरणांद्वारे समर्थित आहेत.
3. कोणत्याही समस्यांचे निवारण करताना, तुम्ही नेहमी इतर एजन्सींमधील सहकार्यांकडून मदत घेऊ शकता जेणेकरून ते त्यांच्या ग्राउंड स्टेशनवरून डिव्हाइससह संप्रेषण सत्र आयोजित करू शकतील. जसे आपण पाहू शकता, मानके ही एक अत्यंत उपयुक्त गोष्ट आहे, म्हणून त्यांचे मुख्य मुद्दे पाहू.

आर्किटेक्चर

मानके हे सर्वात सामान्य OSI (ओपन सिस्टम इंटरकनेक्शन) मॉडेल प्रतिबिंबित करणार्‍या दस्तऐवजांचा एक संच आहे, डेटा लिंक स्तरावरील समानता ही टेलीमेट्री (डाउनलिंक - स्पेस - अर्थ) आणि टेलिकमंड्स (अपलिंक) मध्ये विभागण्यापुरती मर्यादित आहे.

चला काही स्तर अधिक तपशीलाने पाहू या, भौतिकापासून सुरुवात करून आणि वर जाऊ. अधिक स्पष्टतेसाठी, आम्ही प्राप्त केलेल्या बाजूच्या आर्किटेक्चरचा विचार करू. प्रसारित करणारी त्याची आरशातील प्रतिमा आहे.

भौतिक स्तर

या स्तरावर, मॉड्युलेटेड रेडिओ सिग्नल बिट स्ट्रीममध्ये रूपांतरित केला जातो. येथे मानके प्रामुख्याने सल्लागार आहेत, कारण या स्तरावर हार्डवेअरच्या विशिष्ट अंमलबजावणीपासून अमूर्त करणे कठीण आहे. येथे, CCSDS ची महत्त्वाची भूमिका स्वीकार्य मॉड्युलेशन (BPSK, QPSK, 8-QAM, इ.) परिभाषित करणे आणि प्रतीक सिंक्रोनायझेशन यंत्रणा, डॉप्लर भरपाई इ.च्या अंमलबजावणीवर काही शिफारसी देणे आहे.

सिंक्रोनाइझेशन आणि एन्कोडिंग पातळी

औपचारिकपणे, हा डेटा लिंक लेयरचा एक सबलेयर आहे, परंतु CCSDS मानकांमध्ये त्याच्या महत्त्वामुळे ते अनेकदा वेगळ्या लेयरमध्ये विभक्त केले जाते. हा स्तर बिट स्ट्रीमला तथाकथित फ्रेम्स (टेलिमेट्री किंवा टेलिकमंड्स) मध्ये रूपांतरित करतो, ज्याबद्दल आपण नंतर बोलू. फिजिकल लेयरवर चिन्ह सिंक्रोनाइझेशनच्या विपरीत, जे तुम्हाला योग्य बिट प्रवाह प्राप्त करण्यास अनुमती देते, फ्रेम सिंक्रोनाइझेशन येथे केले जाते. या स्तरावर डेटा घेत असलेल्या मार्गाचा विचार करा (खालपासून वरपर्यंत):

तथापि, त्यापूर्वी, कोडिंगबद्दल काही शब्द बोलणे योग्य आहे. रेडिओ चॅनेलवर डेटा पाठवताना अपरिहार्यपणे उद्भवणाऱ्या बिट त्रुटी शोधण्यासाठी आणि/किंवा दुरुस्त करण्यासाठी ही प्रक्रिया आवश्यक आहे. येथे आम्ही डीकोडिंग प्रक्रियेचा विचार करणार नाही, परंतु केवळ पातळीचे पुढील तर्क समजून घेण्यासाठी आवश्यक माहिती प्राप्त करू.

कोड ब्लॉक किंवा सतत असू शकतात. मानके विशिष्ट प्रकारच्या एन्कोडिंगचा वापर करण्यास भाग पाडत नाहीत, परंतु ते तसे उपस्थित असणे आवश्यक आहे. सततच्या कोडमध्ये कन्व्होल्युशनल कोड्सचा समावेश होतो. ते सतत बिट प्रवाह एन्कोड करण्यासाठी वापरले जातात. हे ब्लॉक कोडच्या विरुद्ध आहे, जिथे डेटा कोडब्लॉकमध्ये विभागला जातो आणि केवळ पूर्ण ब्लॉक्समध्येच डीकोड केला जाऊ शकतो. कोड ब्लॉक हस्तांतरित डेटा आणि प्राप्त डेटाची शुद्धता सत्यापित करण्यासाठी आणि संभाव्य त्रुटी सुधारण्यासाठी आवश्यक असलेली अनावश्यक माहिती दर्शवते. ब्लॉक कोडमध्ये प्रसिद्ध रीड-सोलोमन कोड समाविष्ट आहेत.

जर कन्व्होल्युशनल एन्कोडिंग वापरले असेल, तर बिटस्ट्रीम सुरुवातीपासून डीकोडरमध्ये प्रवेश करते. त्याच्या कार्याचा परिणाम (हे सर्व, अर्थातच, सतत घडते) CADU (चॅनेल ऍक्सेस डेटा युनिट) डेटा ब्लॉक्स आहेत. फ्रेम सिंक्रोनाइझेशनसाठी ही रचना आवश्यक आहे. प्रत्येक CADU च्या शेवटी एक संलग्न सिंक मेकर (ASM) असतो. हे 4 बाइट्स अगोदर ओळखले जातात, ज्याद्वारे सिंक्रोनायझर CADU ची सुरुवात आणि शेवट शोधतो. अशा प्रकारे फ्रेम सिंक्रोनाइझेशन साध्य केले जाते.

सिंक्रोनाइझेशन आणि एन्कोडिंग लेयरचा पुढील पर्यायी टप्पा भौतिक स्तराच्या वैशिष्ट्यांशी संबंधित आहे. हे विकृतीकरण आहे. वस्तुस्थिती अशी आहे की प्रतीक सिंक्रोनाइझेशन साध्य करण्यासाठी, चिन्हांमध्ये वारंवार स्विच करणे आवश्यक आहे. म्हणून, जर आपण संपूर्णपणे एक किलोबाइट डेटा प्रसारित केला, तर सिंक्रोनाइझेशन नष्ट होईल. म्हणून, ट्रान्समिशन दरम्यान, इनपुट डेटा नियतकालिक छद्म-यादृच्छिक क्रमाने मिसळला जातो जेणेकरून शून्य आणि एकसमान घनता असेल.

पुढे, ब्लॉक कोड डीकोड केले जातात आणि जे शिल्लक आहे ते सिंक्रोनाइझेशन आणि एन्कोडिंग पातळीचे अंतिम उत्पादन आहे - एक फ्रेम.

डेटा लिंक स्तर

एका बाजूला, लिंक लेयर प्रोसेसर फ्रेम्स प्राप्त करतो आणि दुसऱ्या बाजूला ते पॅकेट जारी करते. पॅकेट्सचा आकार औपचारिकपणे मर्यादित नसल्यामुळे, त्यांच्या विश्वासार्ह प्रसारणासाठी त्यांना लहान संरचना - फ्रेममध्ये तोडणे आवश्यक आहे. येथे आपण दोन उपविभाग पाहू: टेलिमेट्री (TM) आणि दूरसंचार (TC) साठी स्वतंत्रपणे.

टेलीमेट्री

सोप्या भाषेत सांगायचे तर हा डेटा आहे जो ग्राउंड स्टेशनला अवकाशयानाकडून प्राप्त होतो. सर्व प्रसारित माहिती एका निश्चित लांबीच्या लहान तुकड्यांमध्ये विभागली जाते - फ्रेम्स ज्यामध्ये प्रसारित डेटा आणि सेवा फील्ड असतात. चला फ्रेम स्ट्रक्चर जवळून पाहू:

आणि टेलीमेट्री फ्रेमच्या मुख्य शीर्षलेखासह आपला विचार सुरू करूया. पुढे, मार्गात काही स्पष्टीकरणे देऊन, मी स्वतःला काही ठिकाणी मानकांचे फक्त भाषांतर करण्याची परवानगी देईन.

मास्टर चॅनल आयडी फील्डमध्ये फ्रेम आवृत्ती क्रमांक आणि डिव्हाइस अभिज्ञापक असणे आवश्यक आहे.

सीसीएसडीएस मानकांनुसार, प्रत्येक अंतराळ यानाकडे स्वतःचे अद्वितीय अभिज्ञापक असणे आवश्यक आहे, ज्याद्वारे, फ्रेम असल्यास, ते कोणत्या डिव्हाइसचे आहे हे निर्धारित करू शकते. औपचारिकरित्या, डिव्हाइसची नोंदणी करण्यासाठी अर्ज सबमिट करणे आवश्यक आहे आणि त्याचे नाव, त्याच्या ओळखकर्त्यासह, मुक्त स्त्रोतांमध्ये प्रकाशित केले जाईल. तथापि, रशियन उत्पादक अनेकदा या प्रक्रियेकडे दुर्लक्ष करतात, डिव्हाइसला एक अनियंत्रित अभिज्ञापक नियुक्त करतात. फ्रेम आवृत्ती क्रमांक फ्रेम योग्यरित्या वाचण्यासाठी मानकांची कोणती आवृत्ती वापरली जाते हे निर्धारित करण्यात मदत करते. येथे आम्ही "0" आवृत्तीसह केवळ सर्वात पुराणमतवादी मानकांचा विचार करू.

व्हर्च्युअल चॅनल आयडी फील्डमध्ये ज्या चॅनेलमधून पॅकेट आले त्याचा व्हीसीआयडी असणे आवश्यक आहे. VCID च्या निवडीवर कोणतेही निर्बंध नाहीत; विशेषतः, आभासी चॅनेल अनुक्रमे क्रमांकित केलेले नाहीत.

बर्‍याचदा मल्टीप्लेक्स ट्रान्समिटेड डेटाची आवश्यकता असते. या उद्देशासाठी, आभासी चॅनेलची यंत्रणा आहे. उदाहरणार्थ, Meteor-M2 उपग्रह दृश्यमान श्रेणीमध्ये एक रंग प्रतिमा प्रसारित करतो, त्यास तीन काळ्या आणि पांढर्‍या रंगांमध्ये विभाजित करतो - प्रत्येक रंग त्याच्या स्वतःच्या आभासी चॅनेलमध्ये वेगळ्या पॅकेटमध्ये प्रसारित केला जातो, जरी त्यात मानकांपासून काही विचलन आहे. त्याच्या फ्रेम्सची रचना.

ऑपरेशनल कंट्रोल फ्लॅग फील्ड हे टेलीमेट्री फ्रेममध्ये ऑपरेशनल कंट्रोल फील्डची उपस्थिती किंवा अनुपस्थितीचे सूचक असेल. फ्रेमच्या शेवटी असलेले हे 4 बाइट टेलीकॉमंड फ्रेम्सचे वितरण नियंत्रित करताना फीडबॅक प्रदान करतात. आम्ही त्यांच्याबद्दल थोड्या वेळाने बोलू.

मुख्य आणि व्हर्च्युअल चॅनल फ्रेम काउंटर हे फील्ड आहेत जे प्रत्येक वेळी फ्रेम पाठवताना एकाने वाढवले ​​जातात. एकही फ्रेम हरवली नाही याचे सूचक म्हणून काम करा.

टेलीमेट्री फ्रेम डेटा स्टेटस हे ध्वज आणि डेटाचे आणखी दोन बाइट्स आहेत, ज्यापैकी आपण फक्त काही पाहू.

दुय्यम शीर्षलेख ध्वज फील्ड हे टेलीमेट्री फ्रेममध्ये दुय्यम शीर्षलेखाची उपस्थिती किंवा अनुपस्थितीचे सूचक असणे आवश्यक आहे.

तुमची इच्छा असल्यास, तुम्ही प्रत्येक फ्रेममध्ये अतिरिक्त शीर्षलेख जोडू शकता आणि तुमच्या विवेकबुद्धीनुसार कोणताही डेटा तेथे ठेवू शकता.

फर्स्ट हेडर पॉइंटर फील्ड, जेव्हा सिंक्रोनाइझेशन ध्वज "1" वर सेट केला जातो, तेव्हा टेलीमेट्री फ्रेमच्या डेटा फील्डमध्ये पहिल्या पॅकेटच्या पहिल्या ऑक्टेटच्या स्थानाचे बायनरी प्रतिनिधित्व असेल. डेटा फील्डच्या सुरुवातीपासून चढत्या क्रमाने स्थिती 0 वरून मोजली जाते. टेलीमेट्री फ्रेमच्या डेटा फील्डमध्ये पॅकेटची सुरूवात नसल्यास, पहिल्या शीर्षलेख फील्डच्या पॉइंटरमध्ये बायनरी प्रतिनिधित्व "11111111111" मधील मूल्य असणे आवश्यक आहे (एक लांब पॅकेट एकापेक्षा जास्त फ्रेमवर पसरल्यास हे होऊ शकते. ).

डेटा फील्डमध्ये रिकामे पॅकेट (निष्क्रिय डेटा) असल्यास, पहिल्या शीर्षलेखाच्या पॉइंटरमध्ये बायनरी प्रतिनिधित्व "11111111110" मधील मूल्य असावे. हे फील्ड वापरून, प्राप्तकर्त्याने प्रवाह समक्रमित करणे आवश्यक आहे. हे फील्ड हे सुनिश्चित करते की फ्रेम्स सोडल्या गेल्या तरीही सिंक्रोनाइझेशन पुनर्संचयित केले जाते.

म्हणजेच, एक पॅकेट, म्हणा, चौथ्या फ्रेमच्या मध्यभागी सुरू होऊ शकते आणि 4 व्या सुरूवातीस समाप्त होऊ शकते. हे फील्ड त्याची सुरुवात शोधण्यासाठी वापरले जाते. पॅकेट्समध्ये एक शीर्षलेख देखील असतो जो त्याची लांबी निर्दिष्ट करतो, म्हणून जेव्हा पहिल्या शीर्षलेखासाठी एक पॉइंटर आढळतो, तेव्हा लिंक-लेयर प्रोसेसरने ते वाचले पाहिजे, ज्यामुळे पॅकेट कुठे समाप्त होईल हे निर्धारित केले जाते.
त्रुटी नियंत्रण फील्ड उपस्थित असल्यास, संपूर्ण मिशनमध्ये विशिष्ट भौतिक चॅनेलसाठी प्रत्येक टेलीमेट्री फ्रेममध्ये समाविष्ट करणे आवश्यक आहे.

या फील्डची गणना CRC पद्धतीने केली जाते. प्रक्रियेने टेलीमेट्री फ्रेमचे n-16 बिट्स घेणे आवश्यक आहे आणि शेवटच्या 16 बिट्समध्ये गणनाचा परिणाम समाविष्ट करणे आवश्यक आहे.

टीव्ही संघ

टीव्ही कमांड फ्रेममध्ये अनेक महत्त्वपूर्ण फरक आहेत. त्यापैकी:

1. भिन्न शीर्षक रचना
2. डायनॅमिक लांबी. याचा अर्थ टेलीमेट्रीमध्ये केल्याप्रमाणे फ्रेमची लांबी कठोरपणे सेट केलेली नाही, परंतु प्रसारित पॅकेट्सवर अवलंबून बदलू शकते.
3. पॅकेट वितरण हमी यंत्रणा. म्हणजेच, अंतराळयानाने, ते प्राप्त केल्यानंतर, फ्रेम रिसेप्शनच्या अचूकतेची पुष्टी करणे आवश्यक आहे किंवा असुधारित त्रुटीसह प्राप्त झालेल्या फ्रेममधून अग्रेषित करण्याची विनंती करणे आवश्यक आहे.

टेलीमेट्री फ्रेम हेडरवरून अनेक फील्ड्स आम्हाला आधीच परिचित आहेत. त्यांचा एकच उद्देश आहे, म्हणून आम्ही येथे फक्त नवीन फील्डचा विचार करू.

बायपास ध्वजाचा एक बिट रिसीव्हरवर फ्रेम तपासणी नियंत्रित करण्यासाठी वापरला जाणे आवश्यक आहे. या ध्वजासाठी "0" चे मूल्य सूचित करेल की फ्रेम एक प्रकार A फ्रेम आहे आणि FARM नुसार सत्यापित करणे आवश्यक आहे. या ध्वजासाठी "1" चे मूल्य प्राप्तकर्त्याला सूचित केले पाहिजे की फ्रेम एक प्रकार B फ्रेम आहे आणि FARM तपासणीला बायपास केली पाहिजे.

हा ध्वज प्राप्तकर्त्याला FARM - फ्रेम स्वीकृती आणि अहवाल यंत्रणा नावाची फ्रेम वितरण पावती यंत्रणा वापरायची की नाही हे सूचित करते.

डेटा फील्ड कमांड किंवा डेटा ट्रान्सपोर्ट करते की नाही हे समजून घेण्यासाठी कंट्रोल कमांड फ्लॅग वापरणे आवश्यक आहे. ध्वज "0" असल्यास, डेटा फील्डमध्ये डेटा असणे आवश्यक आहे. ध्वज "1" असल्यास, डेटा फील्डमध्ये FARM साठी नियंत्रण माहिती असणे आवश्यक आहे.
FARM एक मर्यादित राज्य मशीन आहे ज्याचे पॅरामीटर्स कॉन्फिगर केले जाऊ शकतात.

RSVD. स्पेअर - आरक्षित बिट्स.

असे दिसते की सीसीएसडीएसने त्यांच्यासाठी भविष्यात योजना आखल्या आहेत आणि प्रोटोकॉल आवृत्त्यांच्या मागास अनुकूलतेसाठी त्यांनी हे बिट आधीच मानकांच्या वर्तमान आवृत्त्यांमध्ये राखून ठेवले आहेत.

फ्रेम लांबी फील्डमध्ये बिट प्रतिनिधित्वामध्ये एक संख्या असणे आवश्यक आहे जी ऑक्टेट वजा एक मधील फ्रेम लांबीच्या समान आहे.

फ्रेम डेटा फील्डने रिक्त स्थानांशिवाय शीर्षलेखाचे अनुसरण करणे आवश्यक आहे आणि त्यात ऑक्टेटची पूर्णांक संख्या असणे आवश्यक आहे, ज्याची लांबी कमाल 1019 ऑक्टेट असू शकते. या फील्डमध्ये फ्रेम डेटा ब्लॉक किंवा कंट्रोल कमांड माहिती असणे आवश्यक आहे. फ्रेम डेटा ब्लॉकमध्ये हे असणे आवश्यक आहे:

• वापरकर्ता डेटा ऑक्टेटची पूर्णांक संख्या
• सेगमेंट हेडर त्यानंतर वापरकर्ता डेटा ऑक्टेटची पूर्णांक संख्या

शीर्षलेख उपस्थित असल्यास, डेटा ब्लॉकमध्ये पॅकेट, पॅकेटचा संच किंवा पॅकेटचा भाग असणे आवश्यक आहे. हेडरशिवाय डेटा ब्लॉकमध्ये पॅकेटचे भाग असू शकत नाहीत, परंतु खाजगी स्वरूप डेटा ब्लॉक असू शकतात. यावरून असे दिसून येते की जेव्हा प्रसारित डेटा ब्लॉक एका फ्रेममध्ये बसत नाही तेव्हा शीर्षलेख आवश्यक असतो. हेडर असलेल्या डेटाच्या ब्लॉकला सेगमेंट म्हणतात

दोन-बिट ध्वज फील्डमध्ये हे असणे आवश्यक आहे:

• "01" - जर डेटाचा पहिला भाग डेटा ब्लॉकमध्ये असेल
• "00" - जर डेटाचा मधला भाग डेटा ब्लॉकमध्ये असेल
• "10" - जर डेटाचा शेवटचा भाग डेटा ब्लॉकमध्ये असेल
• "11" - जर कोणतेही विभाजन नसेल आणि एक किंवा अधिक पॅकेट डेटा ब्लॉकमध्ये पूर्णपणे फिट असतील.

MAP चॅनेल वापरले नसल्यास MAP ID फील्डमध्ये शून्य असणे आवश्यक आहे.
कधीकधी व्हर्च्युअल चॅनेलसाठी वाटप केलेले 6 बिट पुरेसे नसतात. आणि मोठ्या संख्येने चॅनेलवर डेटा मल्टीप्लेक्स करणे आवश्यक असल्यास, सेगमेंट शीर्षलेखातील आणखी 6 बिट वापरले जातात.

फार्म

कर्मचारी वितरण नियंत्रण प्रणालीच्या कार्यप्रणालीकडे बारकाईने नजर टाकूया. ही प्रणाली केवळ टेलीकमंड्सच्या फ्रेम्ससह त्यांच्या महत्त्वामुळे काम करण्याची तरतूद करते (टेलिमेट्रीची नेहमी पुन्हा विनंती केली जाऊ शकते आणि अंतराळ यानाने ग्राउंड स्टेशन स्पष्टपणे ऐकले पाहिजे आणि नेहमी त्याच्या आज्ञांचे पालन केले पाहिजे). तर, समजा आपण आपला उपग्रह रिफ्लॅश करण्याचा निर्णय घेतला आणि त्यावर 10 किलोबाइट आकाराची बायनरी फाइल पाठवायची. लिंक स्तरावर, फाइल 10 फ्रेम्स (0, 1, ..., 9) मध्ये विभागली गेली आहे, जी एकामागून एक वर पाठवली जाते. ट्रान्समिशन पूर्ण झाल्यावर, सॅटेलाइटने पॅकेट रिसेप्शनच्या अचूकतेची पुष्टी करणे आवश्यक आहे किंवा कोणत्या फ्रेमवर त्रुटी आली आहे याचा अहवाल देणे आवश्यक आहे. ही माहिती जवळच्या टेलीमेट्री फ्रेममधील ऑपरेशनल कंट्रोल फील्डमध्ये पाठविली जाते (किंवा स्पेसक्राफ्टमध्ये काही सांगण्यासारखे नसल्यास ते निष्क्रिय फ्रेमचे प्रसारण सुरू करू शकते). प्राप्त झालेल्या टेलिमेट्रीच्या आधारावर, आम्ही एकतर सर्वकाही ठीक असल्याची खात्री करतो किंवा संदेश पुन्हा पाठवण्यास पुढे जाऊ. उपग्रहाने फ्रेम # 7 ऐकले नाही असे गृहीत धरू. याचा अर्थ आम्ही त्याला 7, 8, 9 फ्रेम्स पाठवतो. जर कोणताही प्रतिसाद नसेल, तर संपूर्ण पॅकेट पुन्हा पाठवले जाईल (आणि असेच प्रयत्न व्यर्थ आहेत हे लक्षात येईपर्यंत अनेक वेळा).

खाली काही फील्डच्या वर्णनासह ऑपरेशनल कंट्रोल फील्डची रचना आहे. या फील्डमध्ये असलेल्या डेटाला CLCW - कम्युनिकेशन लिंक कंट्रोल वर्ड म्हणतात.

मुख्य फील्डचा उद्देश चित्रावरून तुम्ही सहज अंदाज लावू शकता आणि इतरांना बघायला कंटाळा येत असल्याने, मी तपशीलवार वर्णन एका स्पॉयलरखाली लपवत आहे.

CLCW फील्डचे स्पष्टीकरणनियंत्रण शब्द प्रकार:
या प्रकारासाठी, नियंत्रण शब्दात 0 असणे आवश्यक आहे

कंट्रोल वर्ड आवृत्ती (CLCW आवृत्ती क्रमांक):
या प्रकारासाठी, बिट प्रस्तुतीकरणामध्ये नियंत्रण शब्द "00" च्या बरोबरीचा असणे आवश्यक आहे.

स्थिती फील्ड:
या क्षेत्राचा वापर प्रत्येक मोहिमेसाठी स्वतंत्रपणे निर्धारित केला जातो. विविध अंतराळ संस्थांद्वारे स्थानिक सुधारणांसाठी वापरला जाऊ शकतो.

आभासी चॅनल ओळख:
व्हर्च्युअल चॅनेलचा अभिज्ञापक असणे आवश्यक आहे ज्याशी हा नियंत्रण शब्द संबद्ध आहे.

भौतिक चॅनेल प्रवेश ध्वज:
ध्वज प्राप्तकर्त्याच्या भौतिक स्तराच्या तयारीबद्दल माहिती प्रदान करणे आवश्यक आहे. जर रिसीव्हरचा भौतिक स्तर फ्रेम प्राप्त करण्यासाठी तयार नसेल, तर फील्डमध्ये "1", अन्यथा "0" असणे आवश्यक आहे.

सिंक्रोनाइझेशन अयशस्वी ध्वज:
ध्वज सूचित करू शकतो की भौतिक स्तर खराब सिग्नल स्तरावर कार्यरत आहे आणि नाकारलेल्या फ्रेमची संख्या खूप जास्त आहे. या फील्डचा वापर ऐच्छिक आहे; वापरल्यास, सिंक्रोनाइझेशन उपलब्ध असल्यास त्यात "0" आणि नसल्यास "1" असणे आवश्यक आहे.

ध्वज अवरोधित करणे:
या बिटमध्ये प्रत्येक आभासी चॅनेलसाठी FARM लॉक स्थिती असेल. या फील्डमधील "1" च्या मूल्याने सूचित केले पाहिजे की FARM अक्षम आहे आणि फ्रेम प्रत्येक आभासी स्तरासाठी टाकून दिल्या जातील, अन्यथा "0".

प्रतीक्षा ध्वज:
प्राप्तकर्ता निर्दिष्ट व्हर्च्युअल चॅनेलवरील डेटावर प्रक्रिया करू शकत नाही हे सूचित करण्यासाठी हा बिट वापरला जाईल. "1" चे मूल्य सूचित करते की या आभासी चॅनेलवर सर्व फ्रेम टाकून दिल्या जातील, अन्यथा "0".

अग्रेषित ध्वज:
या ध्वजात "1" असेल जर एक किंवा अधिक प्रकारच्या A फ्रेम टाकून दिल्या गेल्या असतील किंवा अंतर आढळले असेल, त्यामुळे पुन्हा पाठवणे आवश्यक आहे. "0" ध्वज सूचित करतो की कोणत्याही फ्रेम किंवा वगळल्या गेल्या नाहीत.

प्रतिसाद मूल्य:
फ्रेम नंबर जो मिळाला नाही. टेलिकॉम फ्रेम हेडरमधील काउंटरद्वारे निर्धारित केले जाते

नेटवर्क स्तर

चला या पातळीला थोडा स्पर्श करूया. येथे दोन पर्याय आहेत: एकतर स्पेस पॅकेट प्रोटोकॉल वापरा किंवा CCSDS पॅकेटमध्ये इतर कोणताही प्रोटोकॉल एन्कॅप्स्युलेट करा.

स्पेस पॅकेट प्रोटोकॉलचे विहंगावलोकन हा वेगळ्या लेखाचा विषय आहे. हे तथाकथित अनुप्रयोगांना डेटाची अखंडपणे देवाणघेवाण करण्याची परवानगी देण्यासाठी डिझाइन केले आहे. प्रत्येक अनुप्रयोगाचा स्वतःचा पत्ता आणि इतर अनुप्रयोगांसह डेटाची देवाणघेवाण करण्यासाठी मूलभूत कार्यक्षमता असते. मार्ग रहदारी, नियंत्रण वितरण, इत्यादी सेवा देखील आहेत.

encapsulation सह सर्वकाही सोपे आणि स्पष्ट आहे. अतिरिक्त शीर्षलेख जोडून मानके कोणत्याही प्रोटोकॉलला CCSDS पॅकेटमध्ये एन्कॅप्स्युलेट करणे शक्य करतात.

जेथे एन्कॅप्स्युलेट केलेल्या प्रोटोकॉलच्या लांबीच्या आधारावर शीर्षलेखाचे भिन्न अर्थ आहेत:

येथे मुख्य फील्ड लांबीची लांबी आहे. हे 0 ते 4 बाइट्स पर्यंत बदलू शकते. तसेच या शीर्षलेखामध्ये आपण टेबल वापरून एन्कॅप्स्युलेटेड प्रोटोकॉलचा प्रकार सूचित करणे आवश्यक आहे येथून.

IP encapsulation पॅकेटचा प्रकार निर्धारित करण्यासाठी दुसरे अॅड-ऑन वापरते.
तुम्हाला आणखी एक शीर्षलेख जोडण्याची आवश्यकता आहे, एक ऑक्टेट लांब:

जेथे पीआयडी हा दुसरा प्रोटोकॉल आयडेंटिफायर घेतला जातो येथून

निष्कर्ष

पहिल्या दृष्टीक्षेपात, असे वाटू शकते की CCSDS शीर्षलेख अत्यंत अनावश्यक आहेत आणि काही फील्ड टाकून दिल्या जाऊ शकतात. खरंच, परिणामी चॅनेलची कार्यक्षमता (नेटवर्क स्तरापर्यंत) सुमारे 40% आहे. तथापि, या मानकांची अंमलबजावणी करण्याची गरज निर्माण होताच, हे स्पष्ट होते की प्रत्येक क्षेत्राचे, प्रत्येक शीर्षकाचे स्वतःचे महत्त्वाचे कार्य आहे, ज्याकडे दुर्लक्ष करून अनेक संदिग्धता निर्माण होतात.

जर हॅब्रासोसायटीने या विषयात स्वारस्य दाखवले, तर मला अवकाश संप्रेषणाच्या सिद्धांत आणि अभ्यासासाठी समर्पित लेखांची संपूर्ण मालिका प्रकाशित करण्यात आनंद होईल. आपण लक्ष दिल्याबद्दल धन्यवाद!

स्त्रोत

CCSDS 130.0-G-3 — स्पेस कम्युनिकेशन प्रोटोकॉलचे विहंगावलोकन
CCSDS 131.0-B-2 – TM सिंक्रोनाइझेशन आणि चॅनेल कोडिंग
CCSDS 132.0-B-2 - TM स्पेस डेटा लिंक प्रोटोकॉल
CCSDS 133.0-B-1 - स्पेस पॅकेट प्रोटोकॉल
CCSDS 133.1-B-2 - एन्कॅप्सुलेशन सेवा
CCSDS 231.0-B-3 - TC सिंक्रोनाइझेशन आणि चॅनल कोडिंग
CCSDS 232.1-B-2 कम्युनिकेशन्स ऑपरेशन प्रोसिजर-1
CCSDS 401.0-B-28 रेडिओ फ्रिक्वेन्सी आणि मॉड्युलेशन सिस्टम्स - भाग 1 (पृथ्वी स्टेशन्स आणि स्पेसक्राफ्ट)
CCSDS 702.1-B-1 - IP CCSDS स्पेस लिंक्सवर

PS
तुम्हाला काही अयोग्यता आढळल्यास खूप जोरात मारू नका. त्यांचा अहवाल द्या आणि ते निश्चित केले जातील :)

स्त्रोत: www.habr.com