अंतरिक्ष संचार मानकों के बारे में थोड़ा सा

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

परिचय

रेडियो संचार के बिना अंतरिक्ष प्रौद्योगिकी का संचालन असंभव है, और इस लेख में मैं उन बुनियादी विचारों की व्याख्या करने की कोशिश करूंगा, जिन्होंने अंतरिक्ष डेटा सिस्टम के लिए परामर्शदात्री समिति - सीसीएसडीएस द्वारा विकसित मानकों की नींव बनाई थी। इस संक्षिप्त नाम का उपयोग नीचे किया जाएगा।

यह प्रकाशन मुख्य रूप से चैनल स्तर के लिए समर्पित होगा, हालांकि, अन्य स्तरों के लिए बुनियादी अवधारणाओं को भी पेश किया जाएगा। किसी भी तरह से मानकों के पूर्ण और पूर्ण विवरण का दावा नहीं करना। आप इसे CCSDS वेबसाइट पर पा सकते हैं। हालांकि, उन्हें अनुभव करना बहुत मुश्किल है, और उन्हें समझने के लिए हमने बहुत समय बिताया है, इसलिए यहां मैं बुनियादी जानकारी देना चाहता हूं, जिसके लिए बाकी सब चीजों से निपटना बहुत आसान होगा। तो चलिए शुरू करते हैं।

CCSDS का नेक मिशन

शायद किसी के पास एक सवाल था: सभी को मानकों का पालन क्यों करना चाहिए यदि आप अपने स्वयं के मालिकाना प्रोटोकॉल प्रोटोकॉल स्टैक (या अपने स्वयं के मानक, लाठी और नई सुविधाओं के साथ) विकसित कर सकते हैं, जिससे सिस्टम की सुरक्षा बढ़ जाती है?

जैसा कि अभ्यास से पता चलता है, निम्न कारणों से CCSDS मानकों का पालन करना अधिक लाभदायक है:

1. मानकों को प्रकाशित करने के लिए जिम्मेदार समिति में दुनिया की सभी प्रमुख एयरोस्पेस एजेंसियों के प्रतिनिधि शामिल थे, जो कई वर्षों के डिजाइन और विभिन्न अभियानों के संचालन में प्राप्त किए गए अपने अमूल्य अनुभव को सामने ला रहे हैं। इस अनुभव को अनदेखा करना और फिर से उनके लिए कदम रखना बहुत ही हास्यास्पद होगा।
2. ये मानक बाजार पर पहले से ही ग्राउंड स्टेशन उपकरण द्वारा समर्थित हैं।
3. समस्या निवारण के दौरान, आप हमेशा अन्य एजेंसियों के सहयोगियों से मदद मांग सकते हैं ताकि वे अपने ग्राउंड स्टेशन से डिवाइस के साथ संचार सत्र का संचालन कर सकें।

आर्किटेक्चर

मानक दस्तावेजों का एक सेट है जो सबसे आम OSI (ओपन सिस्टम इंटरकनेक्शन) मॉडल को दर्शाता है, सिवाय इसके कि चैनल स्तर पर, समुदाय विभाजन में टेलीमेट्री (चैनल "डाउन" - स्पेस - अर्थ) और टेलीकॉम (चैनल "अप") तक सीमित है।



कुछ स्तरों पर अधिक विस्तार से विचार करें, जो भौतिक के साथ शुरू होता है, और आगे बढ़ रहा है। अधिक स्पष्टता के लिए, हम मेजबान पक्ष की वास्तुकला पर विचार करेंगे। ट्रांसमीटर इसकी दर्पण छवि है।

शारीरिक स्तर

इस स्तर पर, संशोधित रेडियो संकेत एक बिट स्ट्रीम में परिवर्तित हो जाता है। यहां के मानक ज्यादातर प्रकृति में सिफारिशी हैं, क्योंकि इस स्तर पर लोहे के एक विशिष्ट कार्यान्वयन से अमूर्त करना मुश्किल है। यहाँ, CCSDS की प्रमुख भूमिका अनुमेय संयोजनों (BPSK, QPSK, 8-QAM, इत्यादि) को निर्धारित करना और प्रतीक तुल्यकालन तंत्र, डॉपलर शिफ्ट मुआवजा, आदि के कार्यान्वयन पर कुछ सिफारिशें देना है।

सिंक और एन्कोडिंग स्तर

औपचारिक रूप से, यह डेटा लिंक परत का एक उप-परत है, लेकिन अक्सर इसे CCSDS मानकों के ढांचे के भीतर इसके महत्व के कारण एक अलग परत के रूप में आवंटित किया जाता है। यह स्तर बिटस्ट्रीम को तथाकथित फ्रेम (टेलीमेट्री या टेलकमांड) में परिवर्तित करता है, जिसके बारे में हम बाद में बात करेंगे। भौतिक स्तर पर वर्ण सिंक्रनाइज़ेशन के विपरीत, जो आपको सही बिटस्ट्रीम प्राप्त करने की अनुमति देता है, फ्रेम सिंक्रनाइज़ेशन यहां किया जाता है। इस स्तर पर यात्रा करने वाले पथ पर विचार करें (नीचे से ऊपर):



हालांकि, इससे पहले यह कोडिंग के बारे में कुछ शब्द कहने लायक है। हवा पर डेटा भेजते समय अनिवार्य रूप से होने वाली बिट त्रुटियों को खोजने और / या सही करने के लिए यह प्रक्रिया आवश्यक है। यहां हम डिकोडिंग प्रक्रियाओं पर विचार नहीं करेंगे, लेकिन केवल स्तर के आगे के तर्क को समझने के लिए आवश्यक जानकारी प्राप्त करेंगे।

कोड ब्लॉक और निरंतर हैं। मानक एक विशेष प्रकार के कोडिंग के उपयोग को बाध्य नहीं करते हैं, लेकिन यह इस तरह मौजूद होना चाहिए। निरंतर लोगों में कनवोलुशन (कोलोविजनल) कोड शामिल हैं। उनका उपयोग करते हुए, एक निरंतर बिट स्ट्रीम एन्कोडेड है। ब्लॉक कोड के विपरीत, जहां डेटा को कोड ब्लॉक (कोडब्लॉक) में विभाजित किया गया है, और केवल पूरे ब्लॉक के हिस्से के रूप में डिकोड किया जा सकता है। कोड ब्लॉक प्रेषित डेटा और संलग्न अनावश्यक जानकारी है जो डेटा की शुद्धता और सही त्रुटियों को सत्यापित करने के लिए आवश्यक है। ब्लॉक कोड में प्रसिद्ध रीड-सोलोमन कोड शामिल हैं।

यदि कंसॉल्यूशनल कोडिंग का उपयोग किया जाता है, तो शुरुआत से बिटस्ट्रीम डिकोडर में जाता है। उनके काम का परिणाम (यह सब, निश्चित रूप से, लगातार हो रहा है) CADU डेटा इकाइयाँ (चैनल एक्सेस डेटा यूनिट) हैं। फ्रेम संरचना के लिए यह संरचना आवश्यक है। प्रत्येक CADU के अंत में एक सिंक्रोनाइज़ेशन मार्कर (ASM - संलग्न सिंक्रो मेकर) जुड़ा होता है। ये 4 बाइट्स हैं जिन्हें पहले से जाना जाता है, जिसके द्वारा सिंक्रनाइजर CADU की शुरुआत और अंत का पता लगाता है। इस तरह फ्रेम सिंक्रोनाइज़ेशन हासिल किया जाता है।

सिंक्रनाइज़ेशन और कोडिंग परत के संचालन का अगला वैकल्पिक चरण भौतिक परत की सुविधाओं के साथ जुड़ा हुआ है। यह व्युत्पन्नता है। तथ्य यह है कि प्रतीक सिंक्रनाइज़ेशन को प्राप्त करने के लिए, प्रतीकों के बीच लगातार स्विच करना आवश्यक है। इसलिए, यदि हम कहते हैं, डेटा का एक किलोबाइट केवल इकाइयों से मिलकर बनता है, तो सिंक्रनाइज़ेशन खो जाएगा। इसलिए, संचरण के दौरान, इनपुट डेटा को एक आवधिक छद्म यादृच्छिक अनुक्रम के साथ मिलाया जाता है ताकि शून्य और लोगों का घनत्व समान हो।

अगला, ब्लॉक कोड डिकोड किए जाते हैं, और जो रहता है वह सिंक्रनाइज़ेशन और कोडिंग स्तर - फ्रेम का अंतिम उत्पाद होगा।

चैनल स्तर

एक तरफ, लिंक लेयर हैंडलर फ्रेम प्राप्त करता है, और दूसरी ओर यह पैकेट का उत्पादन करता है। चूंकि औपचारिक रूप से पैकेटों का आकार सीमित नहीं है, उनके विश्वसनीय अग्रेषण के लिए उन्हें छोटे ढांचे - फ्रेम में तोड़ना आवश्यक है। यहां हम दो उपधाराओं पर विचार करते हैं: अलग से टेलीमेट्री (टीएम) और टेलीकॉम (टीसी) के लिए।

टेलीमेटरी

सीधे शब्दों में कहें, यह वह डेटा है जो अंतरिक्ष यान से ग्राउंड स्टेशन को प्राप्त होता है। सभी प्रेषित जानकारी को एक निश्चित लंबाई के छोटे टुकड़ों में विभाजित किया जाता है - फ़्रेम जिसमें संचारित डेटा और सेवा क्षेत्र होते हैं। फ्रेम संरचना पर अधिक विस्तार से विचार करें:



और हम टेलीमेट्री फ्रेम के मुख्य शीर्षक के साथ अपने विचार शुरू करेंगे। इसके अलावा, मैं अपने आप को कुछ स्थानों पर केवल मानकों का अनुवाद करने की अनुमति दूंगा, साथ ही साथ कुछ स्पष्टीकरण भी दूंगा।



मुख्य चैनल (मास्टर चैनल आईडी) के पहचानकर्ता के क्षेत्र में फ्रेम की संस्करण संख्या और डिवाइस की पहचानकर्ता होना चाहिए।

CCSDS मानकों के अनुसार, प्रत्येक अंतरिक्ष यान का अपना विशिष्ट पहचानकर्ता होना चाहिए, जिसके द्वारा यह संभव है कि एक फ्रेम होना, यह निर्धारित करना कि वह किस वाहन का है। औपचारिक रूप से, डिवाइस के पंजीकरण के लिए आवेदन करना आवश्यक है, और पहचानकर्ता के साथ उसका नाम, खुले स्रोतों में प्रकाशित किया जाएगा। हालांकि, अक्सर रूसी निर्माता इस प्रक्रिया को अनदेखा करते हैं, डिवाइस को एक मनमाना पहचानकर्ता निर्दिष्ट करते हैं। फ़्रेम संस्करण संख्या यह निर्धारित करने में मदद करती है कि मानकों का कौन सा संस्करण फ़्रेम को सही ढंग से पढ़ने के लिए उपयोग किया जाता है। यहां हम केवल "0" संस्करण के साथ सबसे रूढ़िवादी मानक मानते हैं।

वर्चुअल चैनल आईडी में उस चैनल का VCID होना चाहिए जिसमें से पैकेट आया था। VCID की पसंद पर कोई प्रतिबंध नहीं है, विशेष रूप से, आभासी चैनलों को क्रमिक रूप से गिने नहीं जाते हैं।

बहुत बार प्रेषित डेटा को मल्टीप्लेक्स करने की आवश्यकता होती है। इसके लिए एक आभासी चैनल तंत्र है। उदाहरण के लिए, उल्का-एम 2 उपग्रह एक रंगीन छवि को दृश्य श्रेणी में प्रसारित करता है, इसे तीन काले और सफेद लोगों में विभाजित करता है - प्रत्येक रंग अपने आभासी चैनल में एक अलग पैकेज के रूप में प्रसारित होता है, हालांकि इसके फ्रेम की संरचना में मानकों से कुछ विचलन होता है।

ऑपरेशनल कंट्रोल फ्लैग फील्ड टेलीमेट्री फ्रेम में ऑपरेशनल कंट्रोल फील्ड की मौजूदगी या अनुपस्थिति का संकेतक होना चाहिए। फ़्रेम के अंत में ये 4 बाइट्स टेलकमांड फ़्रेमों की डिलीवरी की निगरानी करते समय प्रतिक्रिया बनाए रखने के लिए कार्य करते हैं। हम उनके बारे में थोड़ी देर बाद बात करेंगे।

मुख्य और आभासी चैनलों के फ्रेम काउंटर प्रत्येक फ्रेम भेजे जाने पर एक से बढ़े हुए फ़ील्ड होते हैं। वे एक संकेतक के रूप में कार्य करते हैं कि कोई फ्रेम नहीं खो गया है।

टेलीमेट्री फ्रेम डेटा की स्थिति झंडे और डेटा के दो और बाइट्स हैं, जिनमें से हम केवल कुछ पर विचार करेंगे।



सेकेंडरी हैडर (सेकेंडरी हैडर) का फ्लैग फील्ड टेलीमेट्री फ्रेम में सेकेंडरी हैडर (सेकेंडरी हैडर) की मौजूदगी या अनुपस्थिति का सूचक होना चाहिए।

यदि वांछित है, तो आप प्रत्येक फ्रेम में एक अतिरिक्त हेडर जोड़ सकते हैं और अपने विवेक पर किसी भी डेटा को वहां रख सकते हैं।

पहले हेडर (प्रथम हैडर पॉइंटर) के लिए सूचक का क्षेत्र, तुल्यकालन ध्वज "1" के मूल्य के साथ, टेलीफ़ोनरी फ्रेम के डेटा क्षेत्र में पहले पैकेट के पहले ओकटेट की स्थिति का द्विआधारी प्रतिनिधित्व होना चाहिए। डेटा क्षेत्र की शुरुआत से स्थिति को आरोही क्रम में 0 से गिना जाता है। यदि टेलीमेट्री फ्रेम के डेटा क्षेत्र में एक पैकेट की शुरुआत नहीं होती है, तो पहले हेडर को पॉइंटर के क्षेत्र में द्विआधारी प्रतिनिधित्व "11111111111" में मान होना चाहिए (यह तब हो सकता है जब एक लंबा पैकेट एक से अधिक फ्रेम तक फैला हो)।

यदि डेटा फ़ील्ड में एक खाली पैकेट (आइडल डेटा) होता है, तो पहले हेडर के सूचक को बाइनरी प्रतिनिधित्व "11111111110" में मान होना चाहिए। इस क्षेत्र में, रिसीवर को स्ट्रीम को सिंक्रनाइज़ करना चाहिए। यह क्षेत्र लंघन फ्रेम के मामले में भी तुल्यकालन की बहाली की गारंटी देता है।

यही है, एक पैकेट 4 फ्रेम के बीच में शुरू हो सकता है, मान सकता है, और 20 वीं की शुरुआत में समाप्त हो सकता है। इसकी शुरुआत का पता लगाने के लिए, यह क्षेत्र बस कार्य करता है। पैकेट में एक हेडिंग भी होती है, जिसमें उसकी लंबाई दर्ज होती है, इसलिए जब पहली हेडिंग के लिए एक पॉइंटर मिलता है, तो लिंक-लेवल हैंडलर को इसे पढ़ना चाहिए, जिससे यह निर्धारित होता है कि पैकेट कहां खत्म होगा।
यदि कोई त्रुटि नियंत्रण फ़ील्ड प्रस्तुत किया जाता है, तो उसे मिशन के दौरान किसी विशेष भौतिक चैनल के लिए प्रत्येक टेलीमेट्री फ्रेम में समाहित किया जाना चाहिए।

इस फ़ील्ड की गणना CRC पद्धति का उपयोग करके की जाती है। प्रक्रिया को टेलीमेट्री फ्रेम के n-16 बिट्स को स्वीकार करना चाहिए और अंतिम 16 बिट्स में गणना परिणाम सम्मिलित करना चाहिए।

telecommand

टेलकमांड फ्रेम में कई महत्वपूर्ण अंतर हैं। उनमें से हैं:

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

टेलीमेट्री फ्रेम हेडर से कई क्षेत्र पहले से ही हमारे परिचित हैं। उनका एक ही उद्देश्य है, इसलिए यहां हम केवल नए क्षेत्रों पर विचार करते हैं।

रिसीवर पर फ्रेम जांच की निगरानी के लिए बाईपास ध्वज का एक बिट इस्तेमाल किया जाना चाहिए। इस ध्वज के मूल्य "0" से संकेत मिलता है कि यह फ्रेम एक प्रकार का फ्रेम है और इसे FARM के अनुसार जांचना चाहिए। इस ध्वज के मूल्य "1" को रिसीवर को इंगित करना चाहिए कि यह फ्रेम एक प्रकार का बी फ्रेम है और इसे FARM के अनुसार चेक को बायपास करना चाहिए।

यह ध्वज रिसीवर को सूचित करता है कि फ्रेम वितरण पुष्टिकरण तंत्र का उपयोग करना है जिसे FARM - फ़्रेम एक्सेप्टेंस एंड रिपोर्टिंग मैकेनिज्म कहा जाता है।

कंट्रोल कमांड फ्लैग का उपयोग यह समझने के लिए किया जाना चाहिए कि डेटा फ़ील्ड कमांड या डेटा को ट्रांसपोर्ट कर रहा है या नहीं। यदि ध्वज "0" है, तो डेटा फ़ील्ड में डेटा होना चाहिए। यदि ध्वज "1" है, तो डेटा फ़ील्ड में FARM की नियंत्रण जानकारी होनी चाहिए।
FARM एक स्टेट मशीन है जिसके मापदंडों को कॉन्फ़िगर किया जा सकता है।

RSVD। स्पेयर - आरक्षित बिट्स।

ऐसा लगता है कि सीसीएसडीएस की भविष्य में उनके लिए योजना है, और प्रोटोकॉल संस्करणों की पिछड़ी संगतता के लिए, उन्होंने इन बिट्स को मानक के वर्तमान संस्करणों में पहले से ही आरक्षित कर दिया है।

फ़्रेम लंबाई फ़ील्ड में बिट प्रतिनिधित्व में एक संख्या होनी चाहिए, जो ओकटेट माइनस एक में फ़्रेम की लंबाई के बराबर है।

फ़्रेम डेटा फ़ील्ड को अंतराल के बिना हेडर का पालन करना चाहिए और इसमें एक पूर्णांक संख्या ओक्टेट होना चाहिए, जो अधिकतम 1019 ऑक्टेट हो सकता है। इस फ़ील्ड में फ़्रेम डेटा या नियंत्रण आदेश की जानकारी का एक ब्लॉक होना चाहिए। फ़्रेम डेटा ब्लॉक में होना चाहिए:

• ऑक्टेट पूर्णांक उपयोगकर्ता डेटा
• उपयोगकर्ता डेटा के पूर्णांक ऑक्टेट के बाद खंड हेडर

यदि कोई शीर्ष लेख प्रदान किया जाता है, तो डेटा ब्लॉक में एक पैकेज, कई पैकेट या उसका कुछ भाग होना चाहिए। हेडर के बिना डेटा ब्लॉक में पैकेट के कुछ हिस्से नहीं हो सकते हैं, लेकिन इसमें एक निजी प्रारूप के डेटा ब्लॉक हो सकते हैं। इससे यह इस प्रकार है कि प्रेषित की आवश्यकता तब होती है जब प्रेषित डेटा ब्लॉक एक फ्रेम में फिट नहीं होता है। हेडर वाले डेटा ब्लॉक को एक सेगमेंट कहा जाता है।



एक दो-बिट ध्वज फ़ील्ड में होना चाहिए:

• "01" - यदि डेटा का पहला भाग डेटा ब्लॉक में है
• "00" - यदि डेटा का मध्य भाग डेटा ब्लॉक में है
• "10" - यदि डेटा का आखिरी टुकड़ा डेटा ब्लॉक में है
• "11" - यदि कोई विभाजन नहीं है और एक या एक से अधिक पैकेट एक पूरे के रूप में डेटा ब्लॉक में रखे गए हैं।

यदि MAP चैनल का उपयोग नहीं किया जाता है, तो MAP पहचानकर्ता फ़ील्ड में शून्य होना चाहिए।
कभी-कभी आभासी चैनलों को आवंटित 6 बिट पर्याप्त नहीं होते हैं। और अगर आपको बड़ी संख्या में चैनलों पर मल्टीप्लेक्स डेटा की आवश्यकता है, तो सेगमेंट हेडर से 6 बिट्स का उपयोग किया जाता है।

कृषि

आइए हम कर्मियों के नियंत्रण तंत्र के कामकाज तंत्र पर अधिक विस्तार से विचार करें। यह प्रणाली केवल उनके महत्व को देखते हुए दूरसंचार कर्मियों के साथ काम करने के लिए प्रदान करती है (टेलीमेट्री को हमेशा फिर से अनुरोध किया जा सकता है, और अंतरिक्ष यान को ग्राउंड स्टेशन को स्पष्ट रूप से सुनना चाहिए, और हमेशा इसकी आज्ञाओं का पालन करना चाहिए)। तो, मान लीजिए कि हमने अपने उपग्रह को फिर से भरने का फैसला किया है, और बोर्ड पर एक 10 किलोबाइट बाइनरी फ़ाइल भेजते हैं। चैनल स्तर पर, फ़ाइल को 10 फ़्रेम (0, 1, ..., 9) में विभाजित किया गया है, जो शीर्ष पर एक बार भेजा जाता है। जब ट्रांसमिशन पूरा हो जाता है, तो अंतरिक्ष यान को पैकेट के सही स्वागत की पुष्टि करनी चाहिए, या उस त्रुटि की रिपोर्ट करना चाहिए, जिस पर कोई त्रुटि हुई है। यह जानकारी निकटतम टेलीमेट्री फ्रेम में परिचालन नियंत्रण क्षेत्र को भेजी जाती है (या अंतरिक्ष यान एक खाली फ्रेम (निष्क्रिय फ्रेम) के संचरण की शुरुआत कर सकता है, अगर उसके पास कहने के लिए कुछ नहीं है)। प्राप्त टेलीमेट्री के आधार पर, हम या तो यह सुनिश्चित करते हैं कि सब कुछ ठीक है, या संदेश को फिर से भेजने के लिए आगे बढ़ें। मान लीजिए कि उपग्रह ने फ्रेम नंबर 7 नहीं सुना। इसलिए, हम फ्रेम 7, 8, 9 भेजते हैं। यदि कोई जवाब नहीं है, तो पैकेट को फिर से पूरी तरह से भेजा जाता है (और इसलिए कई बार जब तक हमें एहसास नहीं होता कि प्रयास बेकार हैं)।

नीचे कुछ क्षेत्रों के विवरण के साथ परिचालन नियंत्रण के क्षेत्र की संरचना है। इस क्षेत्र में मौजूद डेटा को CLCW - कम्युनिकेशन लिंक कंट्रोल वर्ड कहा जाता है।



चूँकि मुख्य फ़ील्ड्स के उद्देश्य से तस्वीर का अनुमान लगाना बहुत संभव है, जबकि दूसरों को देखना उबाऊ है, मैं स्पॉइलर के तहत विस्तृत विवरण छिपाता हूं

नेटवर्क परत

इस स्तर पर थोड़ा सा स्पर्श। यहां दो विकल्प संभव हैं: या तो स्पेस पैकेट प्रोटोकॉल का उपयोग करें, या CCSDS पैकेट में किसी अन्य प्रोटोकॉल को इनकैप्सुलेट करें।

अंतरिक्ष पैकेट प्रोटोकॉल की समीक्षा एक अलग लेख के लिए एक विषय है। यह इसलिए बनाया गया था ताकि तथाकथित एप्लिकेशन डेटा का आदान-प्रदान कर सकें। प्रत्येक एप्लिकेशन का अपना पता है, और अन्य अनुप्रयोगों के साथ डेटा का आदान-प्रदान करने के लिए बुनियादी कार्यक्षमता है। वहाँ भी सेवाएँ हैं जो मार्ग यातायात, प्रदर्शन नियंत्रण, आदि।

एन्कैप्सुलेशन के साथ, सब कुछ सरल और अधिक समझ में आता है। मानक अतिरिक्त हेडर जोड़कर सीसीएसडीएस पैकेट में किसी भी प्रोटोकॉल को एनकैप्सुलेट करना संभव बनाते हैं।



जहाँ एन्क्रिप्सलेटेड प्रोटोकॉल की लंबाई के आधार पर हेडर के अलग-अलग अर्थ होते हैं:



यहाँ मुख्य क्षेत्र लंबाई लंबाई है। यह 0 से 4 बाइट्स में भिन्न हो सकता है। इस शीर्ष लेख में भी आपको यहाँ से तालिका का उपयोग करते हुए, समझाया हुआ प्रोटोकॉल का प्रकार निर्दिष्ट करना होगा ।

आईपी ​​को एनकैप्सुलेट करते समय, पैकेट के प्रकार को निर्धारित करने के लिए एक और ऐड-इन का उपयोग किया जाता है।
आपको एक और हेडर जोड़ने की आवश्यकता है, जिसकी लंबाई एक ओकटेट से शुरू होती है:



जहां पीआईडी ​​एक अन्य प्रोटोकॉल पहचानकर्ता है जिसे यहां से लिया गया है

निष्कर्ष

पहली नज़र में, ऐसा लग सकता है कि सीसीएसडीएस हेडर बेहद बेमानी हैं, और कुछ क्षेत्रों को छोड़ दिया जा सकता है। दरअसल, परिणामी चैनल (नेटवर्क स्तर तक) की दक्षता लगभग 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 - टीसी सिंक्रोनाइज़ेशन और चैनल कोडिंग
CCSDS 232.1-B-2 संचार ऑपरेशन प्रक्रिया -1
CCSDS 401.0-B-28 रेडियो फ्रीक्वेंसी और मॉड्यूलेशन सिस्टम - भाग 1 (अर्थ स्टेशन और स्पेसक्राफ्ट)
CCSDS 702.1-B-1 - CCSDS स्पेस लिंक पर IP

पुनश्च
यदि आप अशुद्धि पाते हैं तो जोर से मत मारो। उन्हें रिपोर्ट करें और वे ठीक हो जाएंगे :)