आपके नेटवर्क में शायद पहले से ही इसके लक्षण दिख रहे हैं। एक इंस्टॉलर के साथ कुछ स्मार्ट थर्मोस्टेट आए। दूसरे के साथ डोर कंट्रोलर आए। फैसिलिटी टीम ने लीक सेंसर जोड़ दिए। मार्केटिंग टीम फुटफॉल काउंटर चाहती है। ऑपरेशन्स टीम एसेट टैग चाहती है। गेस्ट डिवाइसेज, स्टाफ टैबलेट, कैमरे, कियोस्क और बिल्डिंग सिस्टम सभी को कनेक्टिविटी की आवश्यकता है, लेकिन वे सभी एक ही भाषा नहीं बोलते हैं, और वे निश्चित रूप से लैपटॉप की तरह काम नहीं करते हैं।
यहीं से कई एंटरप्राइज IoT प्रोजेक्ट्स डगमगाने लगते हैं। टीमें डिवाइस, रेडियो या क्लाउड डैशबोर्ड पर ध्यान केंद्रित करती हैं, और कम्युनिकेशन मॉडल को बाद के लिए छोड़ देती हैं। फिर नेटवर्क का दायरा बढ़ता है। अचानक समस्या एक और सेंसर जोड़ने की नहीं रह जाती। समस्या अलग-अलग ट्रैफिक पैटर्न, अलग-अलग ट्रस्ट लेवल और बिल्कुल अलग फेलियर मोड्स वाले सैकड़ों या हजारों डिवाइसेज को ऑपरेट करने की बन जाती है।
व्यावहारिक समाधान protocols for IoT को समझने से शुरू होता है। केवल एक शब्दावली अभ्यास के रूप में नहीं, बल्कि एक ऑपरेटिंग मॉडल के रूप में। एक बार जब आप जान जाते हैं कि कौन सा प्रोटोकॉल क्या करता है, वह स्टैक में कहाँ बैठता है, और यह ऑनबोर्डिंग, आइसोलेशन और सपोर्ट ओवरहेड को कैसे प्रभावित करता है, तो इस अराजकता को मैनेज करना आसान हो जाता है।
कनेक्टेड डिवाइसेज की अराजकता पर काबू पाना
एक होटल में, गेस्ट नेटवर्क पर पैकेट लॉस की समस्या मामूली लग सकती है जब तक कि रूम कंट्रोलर उसी एयरटाइम को शेयर न करने लगें और अपडेट मिस न करने लगें। रिटेल में, हर कुछ सेकंड में रिपोर्ट करने वाले कतार काउंटर की जरूरतें एक समृद्ध कंटेंट खींचने वाले डिजिटल साइनेज प्लेयर से बिल्कुल अलग होती हैं। अस्पताल या बड़े कार्यालय में, बैटरी से चलने वाले सेंसर को लंबे समय तक चलने की आवश्यकता हो सकती है, जबकि फिक्स्ड इंफ्रास्ट्रक्चर भारी प्रोटोकॉल और सख्त कंट्रोल प्लेन को संभाल सकता है।
गलती सभी कनेक्टेड डिवाइसेज के साथ ऐसा व्यवहार करने में है जैसे वे एक ही स्टैंडर्ड नेटवर्क डिजाइन का हिस्सा हों।
प्रोटोकॉल का चुनाव एक ऑपरेशनल समस्या क्यों बन जाता है
एक प्रोटोकॉल केवल एक तकनीकी प्राथमिकता नहीं है। यह तय करता है कि:
- डिवाइसेज कितनी बार बात करते हैं और नेटवर्क पर वे कितने चैट्टी हैं
- उपयोगी डेटा भेजने के लिए वे कितनी बैटरी खर्च करते हैं
- बिना शेयर किए गए क्रेडेंशियल्स के उन्हें ऑनबोर्ड करना कितना आसान है
- जब कई सिस्टम्स को एक ही टेलीमेट्री की आवश्यकता होती है, तो वे कितनी अच्छी तरह स्केल होते हैं
- क्लाउड सर्विसेज, ब्रोकर्स, गेटवे और आइडेंटिटी कंट्रोल्स के साथ वे कितनी आसानी से इंटीग्रेट होते हैं
मिश्रित नेटवर्क चलाने वाली टीमों के लिए, यह एक आर्किटेक्चर समस्या के साथ-साथ एक सपोर्ट समस्या भी बन जाती है। यदि आप पहले से ही कनेक्टेड एंडपॉइंट्स की बढ़ती संख्या से निपट रहे हैं, तो Purple का यह देखना कि how many devices are connected to the internet एक उपयोगी रिमाइंडर है कि डिवाइस की वृद्धि धीमी नहीं हो रही है। अधिक एंडपॉइंट्स का अर्थ है अधिक प्रोटोकॉल विविधता, न कि कम।
व्यावहारिक नियम: जहाँ भी संभव हो अपने ऑनबोर्डिंग और सुरक्षा मॉडल को स्टैंडर्डाइज करें, लेकिन हर डिवाइस टाइप को एक ही कम्युनिकेशन प्रोटोकॉल पर चलने के लिए मजबूर न करें।
एक अच्छा सेटअप कैसा दिखता है
एक व्यावहारिक IoT वातावरण में आमतौर पर तीन विशेषताएं होती हैं।
पहला, प्रोटोकॉल डिवाइस की सीमाओं से मेल खाता हो। छोटे सेंसरों को वेब-शैली संचार का भारी भार नहीं उठाना चाहिए यदि उन्हें केवल स्थिति परिवर्तनों को पब्लिश करने की आवश्यकता है।
दूसरा, प्रोटोकॉल वातावरण से मेल खाता हो। घने इनडोर स्थान, कंक्रीट की इमारतें और मल्टी-टेनेंट स्थल उन डिज़ाइनों को प्रभावित करते हैं जो लैब की स्थितियों में ठीक दिख रहे थे।
तीसरा, प्रोटोकॉल आपके लिए आवश्यक सुरक्षा मॉडल का समर्थन करता हो। यदि आपकी टीम विशिष्ट पहचान असाइन नहीं कर सकती है, एक्सेस को आसानी से रद्द नहीं कर सकती है, और फ़ंक्शन के आधार पर उपकरणों को सेगमेंट नहीं कर सकती है, तो पायलट काम करने के बाद भी प्रोटोकॉल भविष्य के लिए परेशानियाँ पैदा कर रहा है।
हर प्रोटोकॉल निर्णय के दौरान इसी फ्रेम को ध्यान में रखना चाहिए।
IoT संचार की चार परतें
जब टीमें एक ही मीटिंग में MQTT, CoAP, Thread, LoRaWAN, TCP, UDP और WiFi जैसे नाम सुनती हैं, तो बातचीत आमतौर पर उलझ जाती है क्योंकि ये सभी प्रोटोकॉल एक ही समस्या का समाधान नहीं करते हैं। उन्हें समझने का सबसे सही तरीका उन्हें परतों में अलग करना है।
IoT संचार को एक पैकेज भेजने की तरह समझें।
पैकेज का उदाहरण जो वास्तव में मददगार है
- एप्लिकेशन लेयर (Application layer)। यह पार्सल के अंदर की वस्तु है। यह डेटा का अर्थ है। एक तापमान रीडिंग, एक दरवाजा खोलने का निर्देश, एक डिवाइस स्थिति अपडेट।
- ट्रांसपोर्ट लेयर (Transport layer)। यह इस बात से संबंधित है कि पार्सल को कैसे हैंडल किया जाता है। क्या आप डिलीवरी की पुष्टि चाहते हैं, या आप इसे कम ओवरहेड के साथ जल्दी भेजना चाहते हैं?
- नेटवर्क लेयर (Network layer)। यह पता और रूटिंग लॉजिक है जो नेटवर्क के पार पार्सल को सही गंतव्य तक पहुँचाता है।
- लिंक लेयर (Link layer)। यह डिलीवरी वाहन और स्थानीय पथ है। WiFi, ईथरनेट, Zigbee, Thread, सेलुलर IoT और अन्य स्थानीय कनेक्टिविटी विकल्प यहाँ मौजूद होते हैं।
यह वैचारिक मॉडल कई गलत डिज़ाइनों पर होने वाली बहसों को रोकता है। MQTT की तुलना WiFi से करना वैसा ही है जैसे बॉक्स में मौजूद वस्तु की तुलना उसे ले जाने वाली वैन से करना। वे अलग-अलग परतों से संबंधित हैं।
एंटरप्राइज टीमों को इस लेयर्ड व्यू की आवश्यकता क्यों है
एक बार जब आप इस स्टैक को स्पष्ट रूप से देख लेते हैं, तो प्रोटोकॉल का चयन बहुत आसान हो जाता है। आप किसी एक परिचित नाम को चुनकर हर जगह उसका उपयोग करने की कोशिश करने के बजाय, सीमाओं के आधार पर संयोजन कर सकते हैं।
उदाहरण के लिए, एक बिल्डिंग सेंसर एक लाइटवेट एप्लिकेशन प्रोटोकॉल, छोटे संदेशों के लिए उपयुक्त ट्रांसपोर्ट विकल्प, गेटवे के माध्यम से एक IP-आधारित नेटवर्क पथ, और बिल्डिंग के भीतर एक कम-शक्ति वाले लिंक लेयर का उपयोग कर सकता है। इसके विपरीत, एक कैमरा वायर्ड ईथरनेट या WiFi पर हो सकता है और पूरी तरह से अलग एप्लिकेशन पैटर्न का उपयोग कर सकता है।
इस क्षेत्र में एक महत्वपूर्ण मील का पत्थर OASIS मानक के रूप में MQTT का मानकीकरण और RFC 7252 में परिभाषित CoAP था। यह इसलिए महत्वपूर्ण था क्योंकि उद्यम बाजार को सीमित संसाधनों वाले उपकरणों को संभालने के लिए सामान्य, इंटरऑपरेबल तरीकों की आवश्यकता थी। इसका पृष्ठभूमि व्यापक रूप से अपनाए जाने की है। TechAhead ने डेटा का हवाला देते हुए दिखाया कि उद्यम अपनाने और प्रोटोकॉल मानकीकरण के संदर्भ में 2021 में EU के 29% व्यवसायों द्वारा IoT उपकरणों का उपयोग किया गया था, जो समान डिजिटल वातावरणों में इंटरऑपरेबिलिटी और सुरक्षा की योजना बनाने वाली UK की टीमों के लिए प्रासंगिक है ( EMQX on MQTT, CoAP, and LwM2M )।
एक सरल स्टैक जिसका उपयोग आप डिज़ाइन समीक्षाओं में कर सकते हैं
| लेयर | पूछे जाने वाला प्रश्न | सामान्य उदाहरण |
|---|---|---|
| Application | डेटा का क्या अर्थ है और इसका आदान-प्रदान कैसे किया जाता है? | MQTT, CoAP, HTTP, LwM2M |
| Transport | वितरण को कैसे संभाला जाता है? | TCP, UDP |
| Network | ट्रैफ़िक को कैसे एड्रेस और रूट किया जाता है? | IP-आधारित नेटवर्किंग |
| Link | उपकरण भौतिक रूप से कैसे कनेक्ट होता है? | Ethernet, WiFi, Zigbee, Thread, LoRaWAN, NB-IoT |
यदि कोई डिज़ाइन समीक्षा अटक जाती है, तो सबसे पहले एक प्रश्न पूछें: “हम वास्तव में किस लेयर के बारे में बात कर रहे हैं?” इससे आमतौर पर भ्रम जल्दी दूर हो जाता है।
प्रमुख Application और Transport प्रोटोकॉल की तुलना
स्टैक के शीर्ष पर, मौलिक निर्णय अक्सर इस बात के इर्द-गिर्द घूमता है कि उपकरण applications, brokers या प्रबंधन प्लेटफ़ॉर्म के साथ डेटा का आदान-प्रदान कैसे करते हैं। उद्यम टीमें इस प्रभाव को सबसे सीधे तौर पर महसूस करती हैं क्योंकि ये प्रोटोकॉल मैसेजिंग शैली, एकीकरण के प्रयास और वायर पर समाप्त होने वाले अनावश्यक ट्रैफ़िक की मात्रा को निर्धारित करते हैं।
बाजार एक कारण से हल्के विकल्पों की ओर बढ़ा है। उद्देश्य-निर्मित IoT प्रोटोकॉल जैसे कि MQTT और CoAP में दो वर्षों में 11% की वृद्धि होने की उम्मीद है, जिसमें उपयोग में आसानी और विश्वसनीयता को डेवलपर्स द्वारा सबसे महत्वपूर्ण आवश्यकताओं के रूप में पहचाना गया है, जैसा कि IoT Analytics on IoT protocols के अनुसार है। यह अधिकांश उद्यम टीमों द्वारा व्यावहारिक रूप से देखे जाने वाले अनुभवों के अनुरूप है। सीमित संसाधनों वाले उपकरणों को केवल यह कहने के लिए कि “तापमान अभी भी सामान्य है” बहुत अधिक प्रोटोकॉल ओवरहेड ले जाने से कोई लाभ नहीं होता है।
Application और Transport प्रोटोकॉल की तुलना
| प्रोटोकॉल | मॉडल | अंतर्निहित Transport | ओवरहेड | इनके लिए सर्वश्रेष्ठ |
|---|---|---|---|---|
| MQTT | पब्लिश और सब्सक्राइब | आमतौर पर TCP | कम | टेलीमेट्री, रिमोट मॉनिटरिंग, मेनी-टू-मेनी डेटा वितरण |
| CoAP | अनुरोध और प्रतिक्रिया | आमतौर पर UDP | बहुत कम | सीमित संसाधनों वाले उपकरण, छोटे संदेश, कम-लेटेंसी स्थानीय इंटरैक्शन |
| HTTP(S) | अनुरोध और प्रतिक्रिया (Request and response) | TCP | उच्च (Higher) | वेब एकीकरण, APIs, ब्राउज़र-अनुकूल वर्कफ़्लो |
| LwM2M | डिवाइस प्रबंधन उन्मुख | आमतौर पर हल्के ट्रांसपोर्ट के साथ उपयोग किया जाता है | निम्न से मध्यम | प्रोविज़निंग, लाइफसाइकिल प्रबंधन, रिमोट कॉन्फ़िगरेशन |
जब कई प्रणालियों को एक ही डेटा की आवश्यकता होती है, तो MQTT काम करता है
MQTT अक्सर एंटरप्राइज IoT के लिए डिफ़ॉल्ट होता है क्योंकि यह कुशल और परिचालन रूप से साफ है। डिवाइस विषयों (topics) पर संदेश प्रकाशित करते हैं। संबंधित प्रणालियाँ इसे सब्सक्राइब करती हैं। इसका मतलब है कि एक सेंसर हर उपभोक्ता द्वारा डिवाइस को अलग से पोल किए बिना सुविधाओं की निगरानी, एनालिटिक्स, अलर्टिंग और रखरखाव वर्कफ़्लो को फ़ीड कर सकता है।
आतिथ्य (hospitality) और खुदरा (retail) संपदाओं के लिए, यह बहुत मायने रखता है। एक प्रशीतन (refrigeration) सेंसर, अधिभोग (occupancy) सेंसर, या पावर मीटर को अक्सर एक साथ कई बैक-एंड कार्यों को पूरा करने की आवश्यकता होती है। MQTT इसे सहजता से करता है।
CoAP बहुत छोटे, बहुत सीमित उपकरणों के लिए उपयुक्त है
CoAP आमतौर पर तब बेहतर फिट बैठता है जब डिवाइस का फ़ुटप्रिंट बहुत छोटा हो, ट्रैफ़िक सरल हो, और UDP-आधारित हल्का संदेश सेवा स्वीकार्य हो। यह वहां उपयोगी है जहां कम विलंबता और न्यूनतम ओवरहेड एक समृद्ध संदेश मॉडल से अधिक मायने रखते हैं।
इसके बावजूद, टीमें कभी-कभी CoAP के एकीकरण ओवरहेड को कम आंकती हैं। यह डिवाइस की ओर से सुंदर हो सकता है और एंटरप्राइज की ओर से अजीब हो सकता है यदि आपके टूलिंग, ब्रोकर्स, ऑब्जर्वेबिलिटी स्टैक और सुरक्षा नियंत्रण अलग-अलग मान्यताओं के आसपास बने हैं।
डिज़ाइन सावधानी: कागज़ पर सबसे कुशल प्रोटोकॉल स्वचालित रूप से प्रोडक्शन में सबसे कम-बाधा वाला विकल्प नहीं होता है।
HTTP का अभी भी एक स्थान है, लेकिन हर जगह नहीं
HTTP और HTTPS उपयोगी बने हुए हैं क्योंकि हर क्लाउड टीम, डेवलपर और एकीकरण प्लेटफ़ॉर्म पहले से ही उन्हें समझता है। यदि डिवाइस को REST API को कॉल करने, कभी-कभार बड़े पेलोड अपलोड करने, या मौजूदा वेब एप्लिकेशन वर्कफ़्लो में फिट होने की आवश्यकता है, तो HTTP सही उत्तर हो सकता है।
समस्या इसका दुरुपयोग है। एक भारी अनुरोध-प्रतिक्रिया पैटर्न के माध्यम से छोटे स्टेट अपडेट भेजने वाला बैटरी-चालित सेंसर आमतौर पर टालने योग्य ओवरहेड बनाता है। यह काम करता है, लेकिन "काम करता है" और "पैमाने पर अच्छी तरह से काम करता है" एक ही बात नहीं हैं।
LwM2M तब मदद करता है जब प्रबंधन प्राथमिकता हो
LwM2M पर तब ध्यान देने योग्य है जब बड़ी चुनौती टेलीमेट्री नहीं बल्कि फ़्लीट संचालन है। प्रोविज़निंग, रिमोट सेटिंग्स, सॉफ़्टवेयर स्टेट और लाइफसाइकिल प्रबंधन सभी डिवाइस प्रबंधन के लिए बने प्रोटोकॉल के साथ अधिक संरचित हो जाते हैं। व्यवहार में, कई संगठन टेलीमेट्री के लिए एक प्रोटोकॉल और नियंत्रण और लाइफसाइकिल कार्यों के लिए दूसरे प्रबंधन लेयर का उपयोग करते हैं।
एक एंटरप्राइज टेस्ट जो थ्योरी से परे है
यह पूछें: क्या डिवाइस को बार-बार छोटे अपडेट प्रकाशित करने की, सीधे आदेशों का जवाब देने की, या वेब-अनुकूल इंटरफ़ेस प्रदर्शित करने की आवश्यकता है?
- कई उपभोक्ताओं के लिए लगातार टेलीमेट्री: आमतौर पर MQTT फिट बैठता है
- बहुत छोटे फ़ुटप्रिंट और हल्के एक्सचेंज: CoAP अक्सर सबसे उपयुक्त होता है
- सीधा API एकीकरण और ब्राउज़र/क्लाउड अनुकूलता: HTTP(S) उपयुक्त रहता है
- फ़्लीट प्रबंधन और संरचित डिवाइस नियंत्रण: LwM2M पर विचार किया जा सकता है
यदि आपके परिवेश में वीडियो शामिल है, तो सामान्य IoT मैसेजिंग को स्ट्रीमिंग प्रोटोकॉल के साथ न मिलाएं। कैमरा वर्कफ़्लो का मूल्यांकन करने वाली टीमों के लिए, RTSP फ़ीड के बारे में यह प्राइमर उपयोगी है क्योंकि वीडियो ट्रांसपोर्ट की डिज़ाइन प्राथमिकताएं कम-पावर वाले सेंसर टेलीमेट्री से बहुत भिन्न होती हैं।
नेटवर्क और लिंक लेयर प्रोटोकॉल को समझना
एक बार एप्लिकेशन प्रोटोकॉल चुन लिए जाने के बाद, वास्तविक दुनिया का सबसे कठिन प्रश्न अक्सर यह होता है कि डिवाइस नेटवर्क पर कैसे आता है। इस चुनौती के कारण अक्सर इमारतों, संपत्तियों और मिश्रित उपयोग वाले स्थानों में प्रोजेक्ट विफल हो जाते हैं। एप्लिकेशन लेयर पर प्रोटोकॉल स्टैक एकदम सही लग सकता है और फिर भी खराब प्रदर्शन कर सकता है क्योंकि परिवेश के लिए लिंक और नेटवर्क के विकल्प गलत थे।
घनी इमारतों को खुले स्थलों से भिन्न समाधान की आवश्यकता होती है
कैंपस और औद्योगिक परिवेश के लिए, कम-पावर वाले मेश विकल्प जैसे कि Zigbee और Thread घने इनडोर स्थानों में बैटरी से चलने वाले नोड्स के लिए उपयुक्त हैं, जबकि LoRaWAN और NB-IoT मल्टी-किलोमीटर टेलीमेट्री के लिए बेहतर अनुकूल हैं। यह बैंडविड्थ, लेटेंसी और बैटरी लाइफ के बीच का समझौता है, और सही उत्तर वास्तविक यूके उपयोग के मामले पर निर्भर करता है, जैसे कि इनडोर एसेट ट्रैकिंग बनाम रिमोट एस्टेट मॉनिटरिंग, जैसा कि औद्योगिक IoT संचार प्रोटोकॉल के इस गाइड में रेखांकित किया गया है।
यह समझौता वेंडर की प्राथमिकता से अधिक महत्वपूर्ण है।
मैं एंटरप्राइज डिज़ाइन में लिंक विकल्पों को कैसे वर्गीकृत करता हूँ
कम दूरी और उच्च थ्रूपुट
WiFi और ईथरनेट इसी श्रेणी में आते हैं। स्थिर पावर, बड़े पेलोड या सीधे IT एकीकरण वाले उपकरणों के लिए ये स्पष्ट विकल्प हैं। कैमरे, कियोस्क, मीडिया प्लेयर और फिक्स्ड उपकरण आमतौर पर इसी श्रेणी में आते हैं।
इसका नकारात्मक पहलू पावर का उपयोग और एयरटाइम का टकराव है। यदि आप महत्वपूर्ण ट्रैफ़िक वाले उसी वायरलेस इंफ्रास्ट्रक्चर पर बहुत सारे कम-मूल्य वाले उपकरणों को रखते हैं, तो आप स्वयं सहायता कॉल को आमंत्रित करते हैं।
कम दूरी और कम-पावर मेश
Zigbee और Thread तब अधिक समझदारी भरे विकल्प होते हैं जब डिवाइस छोटे, बैटरी से चलने वाले हों और किसी घनी इमारत में फैले हों। स्मार्ट रूम, शेल्फ सेंसर, ऑक्यूपेंसी डिवाइस और पर्यावरण निगरानी अक्सर इस पैटर्न में फिट होते हैं।
मेश इनडोर में बेहतरीन हो सकता है, लेकिन केवल तभी जब टीमें गेटवे प्लेसमेंट, रोमिंग व्यवहार और आसपास के रेडियो परिवेश से होने वाले हस्तक्षेप की योजना बनाती हैं।
लंबी दूरी और कम-पावर वाइड एरिया
जब साइट फैली हुई हो, डेटा कम मात्रा में हो, और थ्रूपुट की तुलना में बैटरी दक्षता अधिक महत्वपूर्ण हो, तो LoRaWAN और NB-IoT बेहतर विकल्प हैं। उपयोगिताएँ (utilities), संपत्तियाँ, परिधि निगरानी (perimeter monitoring), और रिमोट टेलीमेट्री इसके सामान्य उदाहरण हैं।
नेटवर्क टीम का ब्लाइंड स्पॉट
कई नेटवर्क इंजीनियर IP साइड को अच्छी तरह से जानते हैं लेकिन उन्होंने सीमित या गैर-पारंपरिक डिवाइस नेटवर्क के साथ अधिक समय नहीं बिताया है। यदि आपकी टीम को IoT जटिलता जोड़ने से पहले कोर राउटिंग और स्विचिंग अवधारणाओं पर फिर से विचार करने की आवश्यकता है, तो एक मजबूत Cisco CCNA परीक्षा की तैयारी मदद कर सकती है क्योंकि बहुत सारी IoT समस्या निवारण अभी भी मजबूत नेटवर्किंग बुनियादी बातों पर निर्भर करती है।
IP-आधारित IoT एस्टेट के लिए, एड्रेस प्लानिंग भी कई टीमों की अपेक्षा से अधिक मायने रखती है। मिश्रित एंडपॉइंट वृद्धि, सेगमेंटेशन और लंबे डिवाइस जीवनचक्र बड़े पैमाने पर परिनियोजन से पहले IPv6 और IPv4 के बीच अंतर पर फिर से विचार करने के अच्छे कारण हैं।
IoT में, रेडियो का चुनाव शायद ही कभी "सर्वोत्तम रेंज" के बारे में होता है। यह इस बारे में है कि क्या सिग्नल वास्तविक इमारत, वास्तविक हस्तक्षेप और वास्तविक सहायता मॉडल में जीवित रहता है।
आमतौर पर क्या काम करता है और क्या नहीं
- अच्छी तरह से काम करता है: समृद्ध ट्रैफ़िक पैटर्न वाले संचालित डिवाइस के लिए WiFi
- अच्छी तरह से काम करता है: घने इनडोर बैटरी एस्टेट के लिए Zigbee या Thread
- अच्छी तरह से काम करता है: कम मात्रा वाले, लंबी दूरी के टेलीमेट्री के लिए LoRaWAN या NB-IoT
- आमतौर पर विफल रहता है: हर डिवाइस श्रेणी पर जबरन लागू किया गया एक कनेक्टिविटी मानक
- आमतौर पर विफल रहता है: साइट की स्थितियों के बजाय लैब कवरेज मैप के आधार पर चयन करना
वह आखिरी बिंदु अंतहीन परेशानी का कारण बनता है। इनडोर सामग्री, किरायेदार का घनत्व और RF शोर उत्तर को बदल देते हैं।
अपने व्यवसाय के लिए सही प्रोटोकॉल कैसे चुनें
अधिकांश खरीदार पूछते हैं कि कौन सा प्रोटोकॉल सबसे अच्छा है। यह गलत सवाल है। उपयोगी सवाल यह है कि कौन सा प्रोटोकॉल आपके द्वारा संचालित किए जाने वाले डिवाइस, वातावरण, ट्रैफ़िक पैटर्न और सुरक्षा मॉडल के लिए सबसे उपयुक्त है।
यूके में, यह विशेष रूप से महत्वपूर्ण है क्योंकि प्रोटोकॉल का चयन अक्सर सैद्धांतिक रेंज के बजाय वास्तविक रेडियो स्थितियों द्वारा आकार लेता है। Ofcom का डेटा लाइसेंस-मुक्त बैंड का भारी उपयोग दिखाता है, और सरकारी डेटा इनडोर मोबाइल कवरेज के नॉट-स्पॉट्स को उजागर करता है, जिसका अर्थ है कि दीवार की पैठ, हस्तक्षेप और बैकहॉल विश्वसनीयता अक्सर स्पेक शीट की हेडलाइन से अधिक मायने रखती है। Kore Wireless यूके IoT प्रोटोकॉल ट्रेड-ऑफ की अपनी चर्चा में उस चुनौती का अच्छी तरह से सारांश प्रस्तुत करता है।
भौतिक वास्तविकता से शुरुआत करें
कंक्रीट का होटल, स्टील-फ्रेम वाली रिटेल यूनिट और खुली उपयोगिता साइट एक जैसा व्यवहार नहीं करते हैं। शुरुआत स्थान से करें, न कि वेंडर की स्लाइड से।
पूछें:
- डिवाइस कहाँ रहेगा? प्लांट रूम, बेडरूम, कॉरिडोर, कार पार्क, रूफटॉप, कैंपस एज।
- सिग्नल को क्या रोकता है? कंक्रीट, मेटल, लिफ्ट, रेफ्रिजरेशन यूनिट, घनी आबादी।
- बैकहॉल का मालिक कौन है? आपकी टीम, एक प्रबंधित प्रदाता, एक तृतीय पक्ष, या एक मोबाइल ऑपरेटर।
एक प्रोटोकॉल जो खाली परीक्षण कक्ष में आदर्श दिखता है, वह हस्तक्षेप और हलचल से भरे लाइव भवन में विफल हो सकता है।
व्यवसाय के व्यवहार से प्रोटोकॉल का मिलान करें
एक उपयोगी चयन दृष्टिकोण प्रत्येक उपयोग के मामले को वास्तविक आवश्यकताओं के सबसे छोटे सेट से मिलाना है।
होटल थर्मोस्टेट और पर्यावरण सेंसर
ये डिवाइस आमतौर पर छोटे अपडेट भेजते हैं, अक्सर निश्चित अंतराल पर या स्थिति में बदलाव होने पर। उन्हें वेब-शैली के संचार की आवश्यकता नहीं होती है, लेकिन उन्हें स्थिर संचालन और प्रबंधनीय बैटरी या पावर व्यवहार की आवश्यकता होती है। लाइटवेट मैसेजिंग और स्थानीय गेटवे अनुशासन आमतौर पर भारी API-केंद्रित डिजाइनों से बेहतर होते हैं।
रिटेल बीकन और फ़ुटफ़ॉल डिवाइस
यहाँ इनडोर घनत्व मायने रखता है। आप व्यस्त RF स्थितियों में सह-अस्तित्व, बैटरी लाइफ और पूर्वानुमानित संचालन की परवाह करते हैं। यदि डिवाइस किसी दुकान या शॉपिंग सेंटर में फैले हुए हैं, तो सब कुछ मानक WiFi पर धकेलने के बजाय कम दूरी के कम-पावर वाले विकल्प अक्सर अधिक समझदारी वाले होते हैं।
अस्पताल या कैंपस एसेट ट्रैकर
कवरेज सबसे कठिन हिस्सा बन जाता है। ब्रोशर के दावों की तुलना में डेड स्पॉट, भवन निर्माण सामग्री और हलचल के पैटर्न अधिक मायने रखते हैं। लंबी दूरी के टेलीमेट्री प्रोटोकॉल वितरित संपत्तियों के लिए मदद कर सकते हैं, लेकिन वे सटीक इनडोर स्थान या लगातार अपडेट के लिए उपयुक्त नहीं हो सकते हैं।
एक व्यावहारिक निर्णय चेकलिस्ट
- पावर बजट पहले: यदि डिवाइस बैटरी पर चलता है, तो चैट या भारी विकल्पों को शुरुआत में ही हटा दें।
- ट्रैफ़िक पैटर्न अगला: छोटे, लगातार स्थिति परिवर्तन लाइटवेट मैसेजिंग के पक्ष में होते हैं।
- विलंबता सहिष्णुता मायने रखती है: कुछ निगरानी विलंब को सहन कर सकती है। सुरक्षा और नियंत्रण अक्सर ऐसा नहीं कर सकते।
- एकीकरण का बोझ मायने रखता है: एक प्रोटोकॉल जिसे आपकी प्लेटफ़ॉर्म टीम पहले से ही सुरक्षित और देख सकती है, वह थोड़े अधिक सुव्यवस्थित विकल्प से अधिक मूल्यवान हो सकता है।
- सपोर्ट मॉडल स्केल तय करता है: यदि फील्ड टीमें डिवाइसों को आसानी से बदल, रीसेट या रीप्रोविज़न नहीं कर सकती हैं, तो आपकी परिचालन लागत तेजी से बढ़ती है।
चयन नियम: उस प्रोटोकॉल को चुनें जो आपको न्यूनतम परिचालन जटिलता के साथ स्वीकार्य डिवाइस प्रदर्शन देता है। न कि उस प्रोटोकॉल को जिसका डेटाशीट सबसे अच्छा हो।
सबसे मजबूत डिज़ाइन आमतौर पर शुद्ध नहीं होते हैं। वे सीमित टेलीमेट्री के लिए एक प्रोटोकॉल परिवार का उपयोग करते हैं, समृद्ध अनुप्रयोगों के लिए दूसरे का, और पहचान और नीति के लिए एक अलग प्रबंधन प्लेन का उपयोग करते हैं।
डिवाइस पहचान के साथ IoT सुरक्षा को एकीकृत करना
अधिकांश प्रोटोकॉल चर्चाएं बहुत जल्दी समाप्त हो जाती हैं। वे संदेश के आकार, बैटरी उपयोग और रेंज की तुलना करते हैं, फिर मान लेते हैं कि सुरक्षा समस्या को बाद में जोड़ा जा सकता है। एंटरप्राइज़ वातावरण में, यह उल्टा है। प्राथमिक चुनौती यह साबित करना है कि प्रत्येक डिवाइस वैध है, उसे सही पहुंच प्रदान करना है, और कुछ बदलने पर उस पहुंच को साफ-सुथरे तरीके से रद्द करना है।
यही वह जगह है जहां कई IoT परिनियोजन अभी भी विफल हो जाते हैं।
अनुपालन ने बातचीत को बदल दिया है
यूके के PSTI शासन और NCSC मार्गदर्शन के लिए अद्वितीय, प्रति-डिवाइस क्रेडेंशियल की आवश्यकता होती है और डिफ़ॉल्ट पासवर्ड पर प्रतिबंध लगाया जाता है। यह प्रोटोकॉल योजना को एक साधारण MQTT बनाम CoAP चर्चा से आगे धकेलता है और एक कठिन प्रश्न की ओर ले जाता है: कौन से प्रोटोकॉल और प्लेटफ़ॉर्म डिवाइस पहचान, सर्टिफिकेट लाइफसाइकिल मैनेजमेंट और न्यूनतम-विशेषाधिकार पहुंच को लागू करना आसान बनाते हैं? सामान्य प्रोटोकॉल समीक्षाओं में यह अनुपालन पहलू अक्सर छूट जाता है, लेकिन यह IoT सुरक्षा और नीति आवश्यकताओं की इस समीक्षा में चर्चा किए गए यूके संदर्भ में केंद्रीय है।
डिफ़ॉल्ट क्रेडेंशियल, साझा प्री-शेयर्ड कुंजियाँ, और फ्लैट नेटवर्क ट्रस्ट बहु-उपयोगकर्ता स्थानों में अच्छी तरह से स्केल नहीं होते हैं। वे घटना प्रतिक्रिया को भी कठिन बना देते हैं। यदि कोई एक इंस्टॉलर एक सामान्य कुंजी जानता है, या कोई एक टेनेंट-नियंत्रित डिवाइस व्यापक पहुंच साझा करता है, तो रोकथाम आवश्यकता से अधिक कठिन हो जाती है।
प्रोटोकॉल शुद्धता से अधिक पहचान क्यों मायने रखती है
एक सुरक्षित IoT डिज़ाइन को प्रत्येक डिवाइस को चार प्रश्नों का स्पष्ट उत्तर देने की आवश्यकता होती है:
- आप कौन हैं?
- आपको कैसे ऑनबोर्ड किया गया था?
- आपको कहाँ तक पहुँचने की अनुमति है?
- मैं बिना किसी व्यवधान के विश्वास को कैसे रद्द या रोटेट करूँ?
यही कारण है कि गंभीर एंटरप्राइज़ संपत्तियों के लिए साझा रहस्यों की तुलना में सर्टिफिकेट-आधारित प्रमाणीकरण आमतौर पर अधिक रक्षात्मक होता है। यह प्रति डिवाइस विशिष्ट पहचान, अधिक स्पष्ट रद्दीकरण, और ज़ीरो-ट्रस्ट नीति के साथ कहीं बेहतर संरेखण का समर्थन करता है।
पारंपरिक WiFi एक्सेस कंट्रोल के आदी टीमों के लिए, यह समझना कि एक RADIUS सर्वर क्या है सहायक होता है क्योंकि उपकरणों के लिए पहचान-आधारित पहुंच अभी भी अनुशासित प्रमाणीकरण और नीति प्रवर्तन पर निर्भर करती है, भले ही एंडपॉइंट लैपटॉप वाला कोई व्यक्ति न हो।
साझा क्रेडेंशियल्स IoT को परिनियोजन (deployment) के समय सरल और उसके शेष जीवनकाल के लिए महंगा बना देते हैं।
वह प्लेटफ़ॉर्म प्रश्न जो एंटरप्राइज़ टीमों को पूछना चाहिए
केवल यह न पूछें कि क्या कोई प्रोटोकॉल एन्क्रिप्शन का समर्थन करता है। यह पूछें कि क्या आपका प्लेटफ़ॉर्म डिवाइस की पहचान को पॉलिसी, डायरेक्टरी लॉजिक, सेगमेंटेशन और लाइफ़साइकल नियंत्रणों से जोड़ सकता है।
मिश्रित एस्टेट्स में, इसमें ब्रोकर्स, गेटवे, NAC टूलिंग, PKI और Wi-Fi ऑनबोर्डिंग सिस्टम का मिलकर काम करना शामिल हो सकता है। उस व्यापक पहचान परत में एक विकल्प Purple है, जो पासवर्ड रहित एक्सेस, सर्टिफिकेट-ग्रेड ऑनबोर्डिंग फ़्लो और कर्मचारियों व मल्टी-टेनेंट वातावरण के लिए Entra ID, Google Workspace और Okta जैसे पहचान सिस्टम के साथ एकीकरण का समर्थन करता है। इसका उद्देश्य किसी एक प्रोटोकॉल को जबरन लागू करना नहीं है। इसका उद्देश्य विविध डिवाइस और उपयोगकर्ताओं को एक सुसंगत ट्रस्ट फ्रेमवर्क प्रदान करना है।
यह उन क्षेत्रों में विशेष रूप से महत्वपूर्ण हो जाता है जहां विफलता की परिचालन लागत अधिक होती है। हेल्थकेयर इसका एक स्पष्ट उदाहरण है। यदि आप एक व्यापक उद्योग दृष्टिकोण चाहते हैं, तो IoT in medical पर यह लेख उपयोगी है क्योंकि मेडिकल वातावरण बिल्कुल दिखाता है कि पहचान, सेगमेंटेशन और नियंत्रित एक्सेस कच्चे कनेक्टिविटी से अधिक क्यों मायने रखते हैं।
आपकी सुसंगत IoT रणनीति का निर्माण
IoT के प्रोटोकॉल में कोई एक सबसे अच्छा उत्तर नहीं है। इसमें समझौतों (trade-offs) का एक सेट होता है, और एक अच्छा आर्किटेक्चर उन समझौतों को काम के साथ मिलाने से आता है।
उपयोगी पैटर्न सीधा है। एक स्तरित (layered) मॉडल का उपयोग करें ताकि आपकी टीम को पता रहे कि वह एप्लिकेशन व्यवहार, ट्रांसपोर्ट, एड्रेसिंग या भौतिक कनेक्टिविटी पर चर्चा कर रही है या नहीं। वहां लाइटवेट मैसेजिंग चुनें जहां डिवाइस सीमित क्षमता वाले हैं। वास्तविक बिल्डिंग या एस्टेट के लिए सही लिंक तकनीक चुनें, न कि लैब के लिए। उन डिवाइसेस के लिए समृद्ध प्रोटोकॉल रखें जिन्हें वास्तव में उनकी आवश्यकता है।
एक परिपक्व एंटरप्राइज़ दृष्टिकोण कैसा दिखता है
एक ठोस IoT रणनीति में आमतौर पर शामिल होते हैं:
- एक जबरन मानक के बजाय, विभिन्न डिवाइस श्रेणियों के लिए अलग-अलग प्रोटोकॉल
- एक सामान्य ऑनबोर्डिंग और पॉलिसी मॉडल, ताकि ऑपरेशन्स खंडित न हों
- केवल VLAN आदत के बजाय, भूमिका और जोखिम के आधार पर सेगमेंटेशन
- पहचान-प्रथम सुरक्षा (Identity-first security), ताकि प्रत्येक डिवाइस को स्पष्ट रूप से प्रमाणित, अधिकृत और निरस्त किया जा सके
यही वह चीज़ है जो सेंसर और स्मार्ट एंडपॉइंट्स के एक उलझे हुए संग्रह को एक प्रबंधनीय प्लेटफ़ॉर्म में बदल देती है।
सबसे बड़ा बदलाव मानसिक है। IoT को नेटवर्किंग अपवाद के रूप में देखना बंद करें। इसे अपनी पहचान और एक्सेस एस्टेट के हिस्से के रूप में देखें। जब टीमें ऐसा करती हैं, तो प्रोटोकॉल का चयन आसान हो जाता है, ऑनबोर्डिंग सुरक्षित हो जाती है और दीर्घकालिक सहायता बहुत अधिक पूर्वानुमानित हो जाती है।
यदि आप इस बात की समीक्षा कर रहे हैं कि गेस्ट, स्टाफ और IoT वातावरणों में कनेक्टेड डिवाइस कैसे प्रमाणित होते हैं, तो आइडेंटिटी लेयर के हिस्से के रूप में Purple का मूल्यांकन करना बेहद उपयोगी है। यह एंटरप्राइज़ टीमों को मल्टी-यूज़र स्थानों और मिश्रित डिवाइस परिसंपत्तियों में साझा पासवर्ड और खंडित ऑनबोर्डिंग की जगह नीति-संचालित, पासवर्ड-रहित एक्सेस लागू करने का एक आसान तरीका देता है।
