अन्तरिक्ष संचार मापदण्डहरूको बारेमा थोरै

Meteor M1 उपग्रह
स्रोत: vladtime.ru

परिचय

अन्तरिक्ष प्रविधिको सञ्चालन रेडियो संचार बिना असम्भव छ, र यस लेखमा म अन्तरिक्ष डाटा प्रणाली (CCSDS) को लागि अन्तर्राष्ट्रिय सल्लाहकार समिति द्वारा विकसित मापदण्ड को आधार गठन गर्ने मुख्य विचारहरु को व्याख्या गर्ने प्रयास गर्नेछु। यो संक्षिप्त नाम तल प्रयोग गरिनेछ। ।

यो पोस्ट मुख्यतया डाटा लिङ्क तहमा केन्द्रित हुनेछ, तर अन्य तहहरूको लागि आधारभूत अवधारणाहरू पनि प्रस्तुत गरिनेछ। यस लेखले कुनै पनि हिसाबले मापदण्डहरूको पूर्ण र पूर्ण विवरण हुन खोज्दैन। मा हेर्न सक्नुहुन्छ साइट CCSDS। जे होस्, तिनीहरू बुझ्न धेरै गाह्रो छन्, र हामीले तिनीहरूलाई बुझ्नको लागि धेरै समय बिताएका छौं, त्यसैले यहाँ म आधारभूत जानकारी प्रदान गर्न चाहन्छु, जसमा सबै कुरा बुझ्न धेरै सजिलो हुनेछ। त्यसैले, सुरु गरौं।

CCSDS को नोबल मिशन

सायद कसैसँग प्रश्न छ: यदि तपाइँ तपाइँको आफ्नै स्वामित्व रेडियो प्रोटोकल स्ट्याक (वा तपाइँको आफ्नै मानक, ब्ल्याकज्याक र नयाँ सुविधाहरू सहित) को विकास गर्न सक्नुहुन्छ भने किन सबैले मापदण्डहरूको पालना गर्नुपर्छ, जसले प्रणालीको सुरक्षा बढाउँछ?

अभ्यासले देखाएको रूपमा, निम्न कारणहरूको लागि CCSDS मापदण्डहरू पालना गर्नु बढी लाभदायक छ:

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

वास्तुकला

मानकहरू सबै भन्दा साधारण OSI (ओपन सिस्टम इन्टरकनेक्शन) मोडेललाई प्रतिबिम्बित गर्ने कागजातहरूको सेट हो, डेटा लिङ्क स्तरमा समानता टेलिमेट्री (डाउनलिंक - स्पेस - अर्थ) र टेलिकममान्डहरू (अपलिङ्क) मा विभाजनमा सीमित छ।

केही स्तरहरूलाई थप विवरणमा हेरौं, भौतिकबाट सुरु गरेर माथि जानुहोस्। थप स्पष्टताको लागि, हामी प्राप्त पक्षको वास्तुकलालाई विचार गर्नेछौं। प्रसारण गर्ने भनेको यसको मिरर इमेज हो।

भौतिक तह

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

सिंक्रोनाइजेसन र एन्कोडिङ स्तर

औपचारिक रूपमा, यो डाटा लिङ्क तहको सबलेयर हो, तर CCDS मापदण्डहरू भित्र यसको महत्त्वको कारणले प्राय: यसलाई छुट्टै तहमा विभाजन गरिन्छ। यो तहले बिट स्ट्रिमलाई तथाकथित फ्रेमहरू (टेलिमेट्री वा टेलिकममान्डहरू) मा रूपान्तरण गर्दछ, जसको बारेमा हामी पछि कुरा गर्नेछौं। भौतिक तहमा प्रतीक सिङ्क्रोनाइजेसनको विपरीत, जसले तपाईंलाई सही बिट स्ट्रिम प्राप्त गर्न अनुमति दिन्छ, यहाँ फ्रेम सिङ्क्रोनाइजेसन गरिन्छ। यस स्तरमा डेटा लिने बाटोलाई विचार गर्नुहोस् (तलदेखि माथिसम्म):

यद्यपि, त्यो भन्दा पहिले, यो कोडिङको बारेमा केही शब्दहरू भन्न लायक छ। यो प्रक्रिया रेडियो च्यानलमा डाटा पठाउँदा अपरिहार्य रूपमा देखा पर्ने बिट त्रुटिहरू फेला पार्न र/वा सच्याउन आवश्यक छ। यहाँ हामी डिकोडिङ प्रक्रियाहरू विचार गर्दैनौं, तर स्तरको थप तर्क बुझ्न आवश्यक जानकारी मात्र प्राप्त गर्नेछौं।

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

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

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

अर्को, ब्लक कोडहरू डिकोड गरिएका छन्, र के बाँकी छ सिङ्क्रोनाइजेसन र एन्कोडिङ स्तरको अन्तिम उत्पादन हो - एक फ्रेम।

डाटा लिङ्क तह

एकातिर, लिङ्क तह प्रोसेसरले फ्रेमहरू प्राप्त गर्दछ, र अर्कोतिर यसले प्याकेटहरू जारी गर्दछ। प्याकेटहरूको साइज औपचारिक रूपमा सीमित नभएकोले, तिनीहरूको भरपर्दो प्रसारणको लागि तिनीहरूलाई सानो संरचना - फ्रेमहरूमा तोड्न आवश्यक छ। यहाँ हामी दुई उपखण्डहरू हेर्नेछौं: टेलिमेट्री (TM) र टेलिकमान्डहरू (TC) को लागि अलग।

टेलीमेट्री

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

र टेलीमेट्री फ्रेमको मुख्य हेडरको साथ हाम्रो विचार सुरु गरौं। यसबाहेक, म आफैलाई केही ठाउँहरूमा मानकहरू अनुवाद गर्न अनुमति दिनेछु, बाटोमा केही स्पष्टीकरणहरू दिँदै।

मास्टर च्यानल आईडी फिल्डमा फ्रेम संस्करण नम्बर र उपकरण पहिचानकर्ता समावेश हुनुपर्छ।

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

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

धेरै पटक त्यहाँ मल्टिप्लेक्स ट्रान्समिट डाटा आवश्यक छ। यस उद्देश्यका लागि, भर्चुअल च्यानलहरूको संयन्त्र छ। उदाहरणका लागि, Meteor-M2 उपग्रहले दृश्य दायरामा रङ छविलाई प्रसारण गर्दछ, यसलाई तीनवटा कालो र सेतोमा विभाजन गर्दछ - प्रत्येक रङ छुट्टै प्याकेटमा आफ्नै भर्चुअल च्यानलमा प्रसारित हुन्छ, यद्यपि त्यहाँ मापदण्डहरूबाट केही विचलन छ। यसको फ्रेम को संरचना।

अपरेशनल कन्ट्रोल फ्ल्याग फिल्ड टेलिमेट्री फ्रेममा अपरेशनल कन्ट्रोल फिल्डको उपस्थिति वा अनुपस्थितिको सूचक हुनेछ। फ्रेमको अन्त्यमा यी 4 बाइटहरूले टेलिकमान्ड फ्रेमहरूको डेलिभरी नियन्त्रण गर्दा प्रतिक्रिया प्रदान गर्न सेवा गर्दछ। हामी तिनीहरूको बारेमा केहि पछि कुरा गर्नेछौं।

मुख्य र भर्चुअल च्यानल फ्रेम काउन्टरहरू फिल्डहरू हुन् जुन प्रत्येक पटक फ्रेम पठाउँदा एकद्वारा बढाइन्छ। एकल फ्रेम हराएको छैन भनेर सूचकको रूपमा सेवा गर्नुहोस्।

टेलिमेट्री फ्रेम डेटा स्थिति झण्डा र डाटा को दुई थप बाइट हो, जस मध्ये हामी केहि मात्र हेर्नेछौं।

माध्यमिक हेडर फ्ल्याग फिल्ड टेलिमेट्री फ्रेममा माध्यमिक हेडरको उपस्थिति वा अनुपस्थितिको सूचक हुनुपर्छ।

यदि तपाइँ चाहनुहुन्छ भने, तपाइँ प्रत्येक फ्रेममा अतिरिक्त हेडर थप्न सक्नुहुन्छ र तपाइँको विवेकमा कुनै पनि डेटा राख्न सक्नुहुन्छ।

पहिलो हेडर सूचक क्षेत्र, जब सिङ्क्रोनाइजेसन झण्डा "1" मा सेट गरिन्छ, टेलीमेट्री फ्रेमको डाटा फिल्डमा पहिलो प्याकेटको पहिलो अक्टेटको स्थितिको बाइनरी प्रतिनिधित्व समावेश गर्दछ। स्थिति ० बाट डेटा क्षेत्रको सुरुदेखि बढ्दो क्रममा गणना गरिन्छ। यदि टेलिमेट्री फ्रेमको डाटा फिल्डमा प्याकेटको सुरुवात छैन भने, पहिलो हेडर फिल्डमा पोइन्टरमा बाइनरी प्रतिनिधित्व "0" मा मान हुनुपर्छ (एउटा लामो प्याकेट एक भन्दा बढी फ्रेममा फैलिएको भए यो हुन सक्छ। )।

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

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

यो क्षेत्र CRC विधि प्रयोग गरेर गणना गरिन्छ। प्रक्रियाले टेलिमेट्री फ्रेमको n-16 बिटहरू लिनुपर्छ र अन्तिम 16 बिटहरूमा गणनाको नतिजा सम्मिलित गर्नुपर्छ।

टिभी टोलीहरू

टिभी कमाण्ड फ्रेममा धेरै महत्त्वपूर्ण भिन्नताहरू छन्। उनीहरु मध्ये:

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

टेलीमेट्री फ्रेम हेडरबाट धेरै क्षेत्रहरू हामीलाई पहिले नै परिचित छन्। तिनीहरूको एउटै उद्देश्य छ, त्यसैले यहाँ हामी नयाँ क्षेत्रहरू मात्र विचार गर्नेछौं।

बाइपास फ्ल्यागको एक बिट रिसीभरमा फ्रेम जाँच नियन्त्रण गर्न प्रयोग गर्नुपर्छ। यस झण्डाको लागि "०" को मानले फ्रेम एक प्रकारको फ्रेम हो र FARM अनुसार प्रमाणित गरिनुपर्छ भन्ने संकेत गर्छ। यस झण्डाको लागि "0" को मानले रिसीभरलाई यो फ्रेम टाइप B फ्रेम हो र FARM जाँचलाई बाइपास गर्नुपर्छ भनेर संकेत गर्नुपर्छ।

यो फ्ल्यागले प्रापकलाई FARM - फ्रेम स्वीकृति र रिपोर्टिङ मेकानिज्म भनिने फ्रेम डेलिभरी स्वीकृति संयन्त्र प्रयोग गर्ने कि नगर्ने जानकारी दिन्छ।

कन्ट्रोल कमाण्ड फ्ल्याग डाटा फिल्डले कमाण्ड वा डाटा ट्रान्सपोर्ट गर्छ कि भनेर बुझ्नको लागि प्रयोग गरिनुपर्छ। यदि झण्डा "0" हो, तब डाटा फिल्डमा डाटा समावेश हुनुपर्छ। यदि झण्डा "1" हो भने, डाटा फिल्डमा FARM को लागि नियन्त्रण जानकारी समावेश हुनुपर्छ।
FARM एक सीमित राज्य मेसिन हो जसको प्यारामिटरहरू कन्फिगर गर्न सकिन्छ।

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

यस्तो देखिन्छ कि CCSDS सँग भविष्यमा तिनीहरूको लागि योजनाहरू छन्, र प्रोटोकल संस्करणहरूको पछाडि अनुकूलताको लागि तिनीहरूले मानकको हालको संस्करणहरूमा यी बिटहरू आरक्षित गरेका छन्।

फ्रेम लम्बाइ फिल्डमा बिट प्रतिनिधित्वको संख्या समावेश हुनुपर्छ जुन अक्टेट माइनस वनमा फ्रेम लम्बाइ बराबर हुन्छ।

फ्रेम डेटा फिल्डले खाली ठाउँहरू बिना हेडर पछ्याउनु पर्छ र अक्टेटहरूको पूर्ण संख्या समावेश गर्नुपर्छ, जुन लम्बाइमा अधिकतम 1019 अक्टेट हुन सक्छ। यो फिल्डमा फ्रेम डाटा ब्लक वा नियन्त्रण आदेश जानकारी समावेश हुनुपर्छ। फ्रेम डाटा ब्लक समावेश हुनुपर्छ:

• प्रयोगकर्ता डेटा अक्टेटहरूको पूर्णांक संख्या
• खण्ड हेडर पछि प्रयोगकर्ता डेटा अक्टेटहरूको पूर्णांक संख्या

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

दुई-बिट झण्डा क्षेत्र समावेश हुनुपर्छ:

• "01" - यदि डाटाको पहिलो भाग डाटा ब्लकमा छ
• "00" - यदि डाटाको बीचको भाग डाटा ब्लकमा छ
• "१०" - यदि डाटाको अन्तिम टुक्रा डाटा ब्लकमा छ
• "11" - यदि त्यहाँ कुनै विभाजन छैन र एक वा धेरै प्याकेटहरू डाटा ब्लकमा पूर्ण रूपमा फिट हुन्छन्।

यदि MAP च्यानलहरू प्रयोग गरिएन भने MAP ID फिल्डमा शून्यहरू हुनुपर्छ।
कहिलेकाहीँ भर्चुअल च्यानलहरूमा छुट्याइएको 6 बिटहरू पर्याप्त हुँदैनन्। र यदि यो च्यानलहरूको ठूलो संख्यामा डाटा मल्टिप्लेक्स गर्न आवश्यक छ भने, खण्ड हेडरबाट अर्को 6 बिटहरू प्रयोग गरिन्छ।

फार्म

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

तल केही क्षेत्रहरूको विवरणको साथ परिचालन नियन्त्रण क्षेत्रको संरचना छ। यस फिल्डमा रहेको डाटालाई CLCW - कम्युनिकेशन लिंक कन्ट्रोल वर्ड भनिन्छ।

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

CLCW क्षेत्रहरूको व्याख्यानियन्त्रण शब्द प्रकार:
यस प्रकारको लागि, नियन्त्रण शब्दमा ० समावेश हुनुपर्छ

नियन्त्रण शब्द संस्करण (CLCW संस्करण संख्या):
यस प्रकारको लागि, नियन्त्रण शब्द बिट प्रतिनिधित्वमा "00" बराबर हुनुपर्छ।

स्थिति क्षेत्र:
यस क्षेत्रको प्रयोग प्रत्येक मिसनको लागि छुट्टै निर्धारण गरिएको छ। विभिन्न अन्तरिक्ष एजेन्सीहरु द्वारा स्थानीय सुधार को लागी प्रयोग गर्न सकिन्छ।

भर्चुअल च्यानल पहिचान:
भर्चुअल च्यानलको पहिचानकर्ता समावेश हुनुपर्छ जसमा यो नियन्त्रण शब्द सम्बन्धित छ।

भौतिक च्यानल पहुँच झण्डा:
झण्डाले रिसीभरको भौतिक तहको तयारीको बारेमा जानकारी प्रदान गर्नुपर्छ। यदि रिसीभरको भौतिक तह फ्रेमहरू प्राप्त गर्न तयार छैन भने, फिल्डमा "1", अन्यथा "0" समावेश हुनुपर्छ।

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

अवरुद्ध झण्डा:
यो बिटले प्रत्येक भर्चुअल च्यानलको लागि FARM लक स्थिति समावेश गर्नेछ। यस फिल्डमा "1" को मानले FARM असक्षम गरिएको छ र प्रत्येक भर्चुअल तहको लागि फ्रेमहरू खारेज गरिनेछ, अन्यथा "0" भनी सङ्केत गर्नुपर्छ।

प्रतिक्षा झण्डा:
यो बिट रिसीभरले निर्दिष्ट भर्चुअल च्यानलमा डाटा प्रक्रिया गर्न सक्दैन भनेर संकेत गर्न प्रयोग गरिनेछ। "1" को मानले संकेत गर्दछ कि यो भर्चुअल च्यानलमा सबै फ्रेमहरू खारेज गरिनेछ, अन्यथा "०"।

अगाडि झण्डा:
यो फ्ल्यागमा "1" समावेश हुनेछ यदि एक वा बढी प्रकारको A फ्रेमहरू खारेज गरिएको छ वा खाली ठाउँहरू फेला परेका छन्, त्यसैले पुन: पठाउन आवश्यक छ। "0" झण्डाले त्यहाँ कुनै पनि छाडिएको फ्रेम वा स्किपहरू थिएन भनी संकेत गर्छ।

प्रतिक्रिया मूल्य:
प्राप्त नभएको फ्रेम नम्बर। telecommand फ्रेम हेडरमा काउन्टर द्वारा निर्धारित

नेटवर्क तह

यो स्तरमा अलिकति छुनुहोस्। यहाँ दुईवटा विकल्पहरू छन्: या त स्पेस प्याकेट प्रोटोकल प्रयोग गर्नुहोस्, वा CCSDS प्याकेटमा कुनै अन्य प्रोटोकल इनक्याप्सुल गर्नुहोस्।

स्पेस प्याकेट प्रोटोकलको एक सिंहावलोकन छुट्टै लेखको लागि विषय हो। यो तथाकथित अनुप्रयोगहरूलाई निर्बाध रूपमा डाटा आदान प्रदान गर्न अनुमति दिन डिजाइन गरिएको हो। प्रत्येक अनुप्रयोगको आफ्नै ठेगाना र अन्य अनुप्रयोगहरूसँग डाटा आदानप्रदान गर्न आधारभूत कार्यक्षमता हुन्छ। त्यहाँ पनि सेवाहरू छन् जुन ट्राफिक, नियन्त्रण डेलिभरी, आदि।

encapsulation संग सबै कुरा सरल र स्पष्ट छ। मापदण्डहरूले अतिरिक्त हेडर थपेर कुनै पनि प्रोटोकलहरूलाई CCSDS प्याकेटहरूमा समेट्न सम्भव बनाउँछ।

जहाँ हेडरको प्रोटोकलको लम्बाइमा निर्भर गर्दै विभिन्न अर्थहरू छन्:

यहाँ मुख्य क्षेत्र लम्बाइको लम्बाइ हो। यो 0 देखि 4 बाइट सम्म भिन्न हुन सक्छ। साथै यो हेडरमा तपाईँले तालिका प्रयोग गरेर encapsulated प्रोटोकल को प्रकार संकेत गर्नुपर्छ यहाँ देखि.

IP encapsulation ले प्याकेटको प्रकार निर्धारण गर्न अर्को एड-अन प्रयोग गर्दछ।
तपाईंले थप एउटा हेडर, एक अक्टेट लामो थप्न आवश्यक छ:

जहाँ PID अर्को प्रोटोकल पहिचानकर्ता हो यहाँ देखि

निष्कर्षमा

पहिलो नजरमा, CCSDS हेडरहरू अत्यन्तै अनावश्यक छन् र केही क्षेत्रहरू खारेज गर्न सकिन्छ जस्तो लाग्न सक्छ। वास्तवमा, नतिजा च्यानल (नेटवर्क स्तर सम्म) को दक्षता लगभग 40% छ। यद्यपि, यी मापदण्डहरू लागू गर्न आवश्यक पर्ने बित्तिकै, यो स्पष्ट हुन्छ कि प्रत्येक क्षेत्र, प्रत्येक शीर्षकको आफ्नै महत्त्वपूर्ण मिशन छ, जसलाई बेवास्ता गर्दै धेरै अस्पष्टताहरू निम्त्याउँछ।

यदि habrasociety ले यस विषयमा चासो देखाउँछ भने, म अन्तरिक्ष संचारको सिद्धान्त र अभ्यासमा समर्पित लेखहरूको सम्पूर्ण श्रृंखला प्रकाशित गर्न पाउँदा खुसी हुनेछु। तपाईको ध्यानाकर्सनको लागि धन्यवाद!

स्रोतहरू

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