तुमच्या नेटवर्कमध्ये कदाचित आधीच ही लक्षणे दिसत असतील. एका इन्स्टॉलरसोबत काही स्मार्ट थर्मोस्टॅट्स आले. दुसऱ्यासोबत डोअर कंट्रोलर्स आले. फॅसिलिटीजने लीक सेन्सर्स जोडले. मार्केटिंगला फूटफॉल काउंटर्स हवे आहेत. ऑपरेशन्सला अॅसेट टॅग्ज हवे आहेत. गेस्ट डिवाइसेस, स्टाफ टॅब्लेट्स, कॅमेरा, किओस्क आणि बिल्डिंग सिस्टम्स या सर्वांना कनेक्टिव्हिटी हवी आहे, परंतु ते सर्व एकाच भाषेत बोलत नाहीत आणि ते नक्कीच लॅपटॉपसारखे वागत नाहीत.
इथेच अनेक एंटरप्राइज IoT प्रोजेक्ट्स डगमगू लागतात. टीम्स केवळ डिव्हाइस, रेडिओ किंवा क्लाउड डॅशबोर्डवर लक्ष केंद्रित करतात आणि कम्युनिकेशन मॉडेलचा विचार नंतर करतात. मग इस्टेट वाढते. अचानक समस्या केवळ आणखी एक सेन्सर जोडण्याची उरत नाही. तर वेगवेगळ्या ट्रॅफिक पॅटर्न्स, विविध ट्रस्ट लेव्हल्स आणि अत्यंत वेगळ्या फेल्युअर मोड्स असलेल्या शेकडो किंवा हजारो डिवाइसेस ऑपरेट करण्याची असते.
यावरील व्यावहारिक उपाय म्हणजे protocols for IoT समजून घेणे. केवळ व्याख्या पाठ करणे म्हणून नाही, तर एक ऑपरेटिंग मॉडेल म्हणून. एकदा तुम्हाला समजले की कोणता प्रोटोकॉल काय करतो, तो स्टॅकमध्ये कुठे बसतो आणि ऑनबोर्डिंग, आयसोलेशन आणि सपोर्ट ओव्हरहेडवर त्याचा कसा परिणाम होतो, की मग हा गोंधळ आटोक्यात आणता येतो.
कनेक्टेड डिवाइसेसचा गोंधळ आटोक्यात आणणे
एखाद्या हॉटेलमध्ये, गेस्ट नेटवर्कवरील पॅकेट लॉसची समस्या अगदी किरकोळ वाटू शकते, जोपर्यंत रूम कंट्रोल्स समान एअरटाइम शेअर करत नाहीत आणि त्यांचे अपडेट्स मिस होऊ लागत नाहीत. रिटेलमध्ये, दर काही सेकंदांनी रिपोर्ट करणाऱ्या क्यु काउंटरच्या गरजा, रिच कंटेंट खेचणाऱ्या डिजिटल साइनेज प्लेयरपेक्षा खूप वेगळ्या असतात. हॉस्पिटल किंवा मोठ्या ऑफिसमध्ये, बॅटरीवर चालणारे सेन्सर्स दीर्घकाळ टिकणे आवश्यक असू शकते, तर फिक्स्ड इन्फ्रास्ट्रक्चर जड प्रोटोकॉल आणि अधिक कडक कंट्रोल प्लेन्स सहन करू शकतात.
सर्व कनेक्टेड डिवाइसेसना एकाच स्टँडर्ड नेटवर्क डिझाइनवर असावे अशा प्रकारे वागवणे ही चूक आहे.
प्रोटोकॉलची निवड ही ऑपरेशनल समस्या का बनते
प्रोटोकॉल ही केवळ तांत्रिक पसंती नसते. तो खालील गोष्टी ठरवतो:
- डिव्हाइसेस किती वेळा संवाद साधतात आणि नेटवर्कवर ते किती चॅटी (chatty) असतात
- उपयुक्त डेटा पाठवण्यासाठी ते किती बॅटरी वापरतात
- शेअर केलेल्या क्रेडेंशियल्सशिवाय ते ऑनबोर्ड करणे किती सोपे आहे
- जेव्हा एकाधिक सिस्टम्सना समान टेलिमेट्रीची आवश्यकता असते तेव्हा ते किती चांगल्या प्रकारे स्केल होतात
- क्लाउड सर्व्हिसेस, ब्रोकर्स, गेटवेज आणि आयडेंटिटी कंट्रोल्ससह ते किती सुलभतेने इंटिग्रेट होतात
मिश्र इस्टेट चालवणाऱ्या टीम्ससाठी, ही आर्किटेक्चर समस्येइतकीच सपोर्टची समस्या बनते. जर तुम्ही आधीच वाढत्या कनेक्टेड एंडपॉइंट्सच्या संख्येशी झगडत असाल, तर Purple चे how many devices are connected to the internet कडे पाहणे हे एक उपयुक्त स्मरणपत्र आहे की डिव्हाइसची वाढ मंदावलेली नाही. अधिक एंडपॉइंट्स म्हणजे अधिक प्रोटोकॉल विविधता, कमी नाही.
व्यावहारिक नियम: तुम्ही जिथे शक्य असेल तिथे तुमचे ऑनबोर्डिंग आणि सिक्युरिटी मॉडेल स्टँडर्डाइज करा, परंतु प्रत्येक डिव्हाइस प्रकाराला एकाच कम्युनिकेशन प्रोटोकॉलवर चालण्यासाठी जबरदस्ती करू नका.
उत्कृष्ट रचना कशी असावी
कार्यक्षम IoT वातावरणात सहसा तीन गुणधर्म असतात.
पहिले म्हणजे, प्रोटोकॉल डिव्हाइसच्या मर्यादांशी सुसंगत असावा. जर लहान सेन्सर्सना फक्त स्थितीतील बदल (state changes) कळवायचे असतील, तर त्यांच्यावर वेब-स्टाईल कम्युनिकेशनचे ओझे असू नये.
दुसरे म्हणजे, प्रोटोकॉल वातावरणाशी सुसंगत असावा. गर्दीच्या बंद जागा, काँक्रीटच्या इमारती आणि बहु-भाडेकरू (multi-tenant) ठिकाणे अशा डिझाइनची परीक्षा घेतात जी प्रयोगशाळेच्या वातावरणात योग्य वाटत होती.
तिसरे म्हणजे, प्रोटोकॉल तुमच्या आवश्यक सुरक्षा मॉडेलला सपोर्ट करणारा असावा. जर तुमची टीम युनिक ओळख नियुक्त करू शकत नसेल, ॲक्सेस सुरक्षितपणे रद्द करू शकत नसेल आणि कार्यानुसार डिव्हाइसेसचे विभाजन करू शकत नसेल, तर प्रायोगिक तत्त्वावर (pilot) काम यशस्वी झाले तरीही हा प्रोटोकॉल भविष्यात समस्या निर्माण करेल.
प्रोटोकॉलचा कोणताही निर्णय घेताना हा दृष्टिकोन डोळ्यांसमोर ठेवणे आवश्यक आहे.
IoT कम्युनिकेशनचे चार स्तर (Layers)
जेव्हा टीम्स एकाच मीटिंगमध्ये 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 चे मानकीकरण होते. ते महत्त्वाचे होते कारण एंटरप्राइझ मार्केटला मर्यादित उपकरणांना (constrained devices) हाताळण्यासाठी सामान्य, इंटरऑपरेबल मार्गांची आवश्यकता होती. याची पार्श्वभूमी व्यापक स्वीकार ही आहे. TechAhead ने डेटा उद्धृत केला आहे ज्यानुसार एंटरप्राइझ वापर आणि प्रोटोकॉल मानकीकरणाच्या संदर्भात २०२१ मध्ये २९% EU व्यवसायांद्वारे IoT उपकरणे वापरली गेली, जे तत्सम डिजिटल वातावरणात इंटरऑपरेबिलिटी आणि सुरक्षिततेसाठी नियोजन करणाऱ्या UK मधील टीम्ससाठी सुसंगत आहे ( EMQX on MQTT, CoAP, and LwM2M ).
डिझाइन रिव्ह्यूमध्ये तुम्ही वापरू शकता असा एक साधा स्टॅक
| स्तर (Layer) | विचारण्याचा प्रश्न | ठराविक उदाहरणे |
|---|---|---|
| Application | डेटाचा अर्थ काय आहे आणि त्याचे आदानप्रदान कसे केले जाते? | MQTT, CoAP, HTTP, LwM2M |
| Transport | डिलिव्हरी कशी हाताळली जाते? | TCP, UDP |
| Network | ट्रॅफिकला पत्ता कसा दिला जातो आणि त्याचे राउटिंग कसे केले जाते? | IP-आधारित नेटवर्किंग |
| Link | उपकरण भौतिकरित्या कसे कनेक्ट होते? | Ethernet, WiFi, Zigbee, Thread, LoRaWAN, NB-IoT |
जर एखादा डिझाइन रिव्ह्यू अडकला, तर आधी एक प्रश्न विचारा: “आम्ही नक्की कोणत्या स्तरावर बोलत आहोत?” यामुळे सहसा गोंधळ पटकन दूर होतो.
मुख्य ॲप्लिकेशन आणि ट्रान्सपोर्ट प्रोटोकॉलची तुलना करणे
स्टॅकच्या शीर्षस्थानी, मुख्य निर्णय बऱ्याचदा याभोवती फिरतो की उपकरणे ॲप्लिकेशन्स, ब्रोकर्स किंवा मॅनेजमेंट प्लॅटफॉर्मसह डेटाचे आदानप्रदान कसे करतात. एंटरप्राइझ टीम्सना याचा प्रभाव थेट जाणवतो कारण हे प्रोटोकॉल मेसेजिंग शैली, इंटिग्रेशनसाठी लागणारे प्रयत्न आणि वायरवर किती अनावश्यक ट्रॅफिक निर्माण होते हे ठरवतात.
मार्केट हलक्या पर्यायांकडे वळले आहे याचे एक कारण आहे. विशिष्ट कारणासाठी बनवलेले IoT प्रोटोकॉल जसे की MQTT आणि CoAP यामध्ये दोन वर्षांत ११% वाढ होण्याची अपेक्षा आहे, ज्यामध्ये डेव्हलपर्सनी वापरण्यास सुलभता आणि विश्वासार्हता या सर्वात महत्त्वाच्या आवश्यकता असल्याचे ओळखले आहे, IoT Analytics on IoT protocols नुसार. हे बहुतांश एंटरप्राइझ टीम्स प्रत्यक्ष व्यवहारात जे पाहतात त्याच्याशी सुसंगत आहे. मर्यादित उपकरणांना फक्त “तापमान अजूनही सामान्य आहे” हे सांगण्यासाठी बऱ्याच प्रोटोकॉल ओव्हरहेडचा भार वाहून नेण्याचा काही फायदा होत नाही.
ॲप्लिकेशन आणि ट्रान्सपोर्ट प्रोटोकॉल तुलना
| प्रोटोकॉल | मॉडेल | अंतर्निहित ट्रान्सपोर्ट | ओव्हरहेड | यासाठी सर्वोत्तम |
|---|---|---|---|---|
| MQTT | पब्लिश आणि सबस्क्राइब | सहसा TCP | कमी | टेलिमेट्री, रिमोट मॉनिटरिंग, मेनी-टू-मेनी डेटा वितरण |
| CoAP | रिक्वेस्ट आणि रिस्पॉन्स | सहसा UDP | अतिशय कमी | मर्यादित उपकरणे, लहान संदेश, कमी-लेटन्सी स्थानिक परस्परसंवाद |
| HTTP(S) | विनंती आणि प्रतिसाद (Request and response) | TCP | उच्च (Higher) | वेब एकत्रीकरण, APIs, ब्राउझर-अनुकूल वर्कफ्लो |
| LwM2M | डिव्हाइस व्यवस्थापन केंद्रित | सामान्यतः लाईटवेट ट्रान्सपोर्टसह वापरले जाते | कमी ते मध्यम | प्रोविजनिंग, लाइफसायकल व्यवस्थापन, रिमोट कॉन्फिगरेशन |
जेव्हा अनेक प्रणालींना समान डेटाची आवश्यकता असते तेव्हा MQTT कार्य करते
एंटरप्राइझ IoT साठी MQTT हा सहसा डीफॉल्ट पर्याय असतो कारण तो कार्यक्षम आणि ऑपरेशनल दृष्ट्या सुटसुटीत असतो. डिव्हाइसेस विशिष्ट टॉपिक्सवर मेसेज पब्लिश करतात. संबंधित प्रणाली त्याचे सबस्क्रिप्शन घेतात. याचा अर्थ प्रत्येक ग्राहकाला स्वतंत्रपणे डिव्हाइस पोल न करता, एकच सेन्सर फॅसिलिटी मॉनिटरिंग, अॅनालिटिक्स, अलर्टिंग आणि मेंटेनन्स वर्कफ्लोला डेटा पुरवू शकतो.
हॉस्पिटॅलिटी आणि रिटेल इस्टेटसाठी हे महत्त्वाचे आहे. रेफ्रिजरेशन सेन्सर, ऑक्युपन्सी सेन्सर किंवा पॉवर मीटरला बऱ्याचदा एकाच वेळी अनेक बॅक-एंड फंक्शन्सना सेवा देणे आवश्यक असते. MQTT हे काम उत्तम प्रकारे करते.
CoAP अतिशय लहान, मर्यादित संसाधने असलेल्या डिव्हाइसेससाठी योग्य आहे
जेव्हा डिव्हाइसचा आकार खूप लहान असतो, ट्रॅफिक सोपे असते आणि UDP-आधारित लाईटवेट मेसेजिंग स्वीकार्य असते, तेव्हा CoAP हा सहसा चांगला पर्याय ठरतो. जिथे कमी लॅटन्सी आणि कमीत कमी ओव्हरहेड हे रिच मेसेजिंग मॉडेलपेक्षा जास्त महत्त्वाचे असतात तिथे हे उपयुक्त ठरते.
असे असले तरी, टीम्स काहीवेळा CoAP च्या एकत्रीकरणाच्या (integration) खर्चाचा अंदाज कमी लावतात. डिव्हाइसच्या बाजूने हे सोपे असू शकते, परंतु जर तुमचे टूलिंग, ब्रोकर्स, ऑब्झर्वेबिलिटी स्टॅक आणि सिक्युरिटी कंट्रोल्स इतर गृहितकांवर तयार केले असतील तर एंटरप्राइझच्या बाजूने ते कठीण जाऊ शकते.
डिझाईनबाबत खबरदारी: कागदावर सर्वात कार्यक्षम असणारा प्रोटोकॉल प्रत्यक्ष वापरात सर्वात कमी अडथळ्यांचा असेलच असे नाही.
HTTP चे अजूनही एक स्थान आहे, परंतु सर्वत्र नाही
HTTP आणि HTTPS अजूनही उपयुक्त आहेत कारण प्रत्येक क्लाउड टीम, डेव्हलपर आणि इंटिग्रेशन प्लॅटफॉर्मला ते आधीपासूनच माहित आहेत. जर डिव्हाइसला एखादा REST API कॉल करायचा असेल, कधीकधी मोठे पेलोड अपलोड करायचे असतील किंवा अस्तित्वात असलेल्या वेब अॅप्लिकेशन वर्कफ्लोमध्ये बसायचे असेल, तर HTTP हा योग्य पर्याय असू शकतो.
याचा चुकीचा वापर ही खरी समस्या आहे. बॅटरीवर चालणारा सेन्सर जर हेवी रिक्वेस्ट-रिस्पॉन्स पॅटर्नद्वारे लहान स्टेट अपडेट्स पाठवत असेल, तर त्यामुळे अनावश्यक ओव्हरहेड तयार होतो. हे काम करते, परंतु "काम करणे" आणि "मोठ्या प्रमाणावर उत्तम रीतीने काम करणे" यात फरक आहे.
जेव्हा व्यवस्थापन ही मुख्य प्राथमिकता असते तेव्हा LwM2M मदत करते
जेव्हा मुख्य आव्हान टेलिमेट्री नसून फ्लीट ऑपरेशन्स हे असते, तेव्हा LwM2M कडे लक्ष देणे गरजेचे आहे. डिव्हाइस व्यवस्थापनासाठी तयार केलेल्या प्रोटोकॉलमुळे प्रोविजनिंग, रिमोट सेटिंग्स, सॉफ्टवेअर स्टेट आणि लाइफसायकल व्यवस्थापन हे सर्व अधिक सुव्यवस्थित होते. प्रत्यक्ष व्यवहारात, अनेक संस्था टेलिमेट्रीसाठी एक प्रोटोकॉल आणि नियंत्रण व लाइफसायकल फंक्शन्ससाठी दुसरा व्यवस्थापन स्तर वापरतात.
एक एंटरप्राइझ चाचणी जी सिद्धांताच्या पलीकडे जाते
स्वतःला हा प्रश्न विचारा: डिव्हाइसला वारंवार लहान अपडेट्स पब्लिश करायचे आहेत, थेट कमांड्सना प्रतिसाद द्यायचा आहे की वेब-अनुकूल इंटरफेस दाखवायचा आहे?
- अनेक ग्राहकांना वारंवार पाठवली जाणारी टेलिमेट्री: यासाठी सहसा MQTT योग्य ठरते
- अतिशय कमी फूटप्रिंट्स आणि हलकी देवाणघेवाण: CoAP योग्य ठरते
- थेट API एकत्रीकरण आणि ब्राउझर/क्लाउड सुसंगतता: HTTP(S) योग्य ठरते
- फ्लीट व्यवस्थापन आणि संरचित डिव्हाइस नियंत्रण: LwM2M चा विचार करणे योग्य आहे
तुमच्या वातावरणात व्हिडिओ समाविष्ट असल्यास, सामान्य IoT मेसेजिंगला स्ट्रीमिंग प्रोटोकॉलसोबत जोडू नका. कॅमेरा वर्कफ्लोचे मूल्यांकन करणाऱ्या टीम्ससाठी, RTSP फीड्स बद्दलची ही प्राथमिक माहिती उपयुक्त आहे कारण व्हिडिओ ट्रान्सपोर्टच्या डिझाइन प्राधान्ये कमी-शक्तीच्या सेन्सर टेलिमेट्रीपेक्षा खूप भिन्न असतात.
नेटवर्क आणि लिंक लेयर प्रोटोकॉल समजून घेणे
एकदा ॲप्लिकेशन प्रोटोकॉल निवडल्यानंतर, डिव्हाइस नेटवर्कवर कसे येते हा सर्वात कठीण आणि व्यावहारिक प्रश्न असतो. या आव्हानामुळे अनेकदा इमारतींमध्ये, इस्टेट्समध्ये आणि संमिश्र वापराच्या ठिकाणी प्रोजेक्ट्स अयशस्वी होतात. ॲप्लिकेशन लेयरवर प्रोटोकॉल स्टॅक परिपूर्ण दिसू शकतो आणि तरीही लिंक आणि नेटवर्क निवडी पर्यावरणासाठी चुकीच्या असल्यामुळे कामगिरी खालावू शकते.
दाट लोकवस्तीच्या इमारतींना खुल्या जागांपेक्षा वेगळ्या पर्यायाची गरज असते
कॅम्पस आणि औद्योगिक वातावरणासाठी, Zigbee आणि Thread सारखे कमी-शक्तीचे मेश पर्याय दाट घरातील जागांमधील बॅटरी-चालित नोड्ससाठी योग्य आहेत, तर LoRaWAN आणि NB-IoT हे बहु-किलोमीटर टेलिमेट्रीसाठी अधिक योग्य आहेत. यामध्ये बँडविड्थ, लेटन्सी आणि बॅटरीचे आयुष्य यामध्ये तडजोड करावी लागते आणि योग्य उत्तर प्रत्यक्ष युके (UK) वापर प्रकरणावर अवलंबून असते, जसे की घरातील मालमत्ता ट्रॅकिंग विरुद्ध रिमोट इस्टेट मॉनिटरिंग, ज्याचे वर्णन औद्योगिक IoT कम्युनिकेशन प्रोटोकॉलच्या या मार्गदर्शकामध्ये केले आहे.
ती तडजोड कोणत्याही विशिष्ट व्हेंडरच्या पसंतीपेक्षा अधिक महत्त्वाची ठरते.
मी एंटरप्राइझ डिझाइनमध्ये लिंक पर्यायांचे वर्गीकरण कसे करतो
कमी-अंतर आणि उच्च थ्रूपुट
WiFi आणि इथरनेट येथे येतात. स्थिर वीज पुरवठा, मोठा पेलोड किंवा सोपे आयटी (IT) एकत्रीकरण असलेल्या उपकरणांसाठी हे स्पष्ट पर्याय आहेत. कॅमेरे, किओस्क, मीडिया प्लेयर्स आणि स्थिर उपकरणे सहसा या श्रेणीमध्ये येतात.
याचा नकारात्मक बाजू म्हणजे विजेचा वापर आणि एअरटाइम संघर्ष. जर तुम्ही महत्त्वाच्या ट्रॅफिक सारख्याच वायरलेस इन्फ्रास्ट्रक्चरवर खूप जास्त चॅटी कमी-मूल्याचे डिव्हाइसेस ठेवले, तर तुम्ही स्वतःच सपोर्ट कॉल्स निर्माण करता.
कमी-अंतर आणि कमी-शक्तीचे मेश
जेव्हा उपकरणे लहान, बॅटरी-चालित आणि दाट इमारतीमध्ये पसरलेली असतात तेव्हा Zigbee आणि Thread अधिक अर्थपूर्ण ठरतात. स्मार्ट रूम, शेल्फ सेन्सर, ऑक्युपन्सी डिव्हाइसेस आणि पर्यावरणीय मॉनिटरिंग सहसा या पॅटर्नमध्ये बसतात.
मेश हे घरामध्ये उत्कृष्ट असू शकते, परंतु केवळ तेव्हाच जेव्हा टीम्स गेटवे प्लेसमेंट, रोमिंग वर्तन आणि आजूबाजूच्या रेडिओ वातावरणातील हस्तक्षेपाचे नियोजन करतात.
दीर्घ-अंतर आणि कमी-शक्तीचे वाईड एरिया
जेव्हा साइट पसरलेली असते, डेटा विरळ असतो आणि थ्रूपुटपेक्षा बॅटरी कार्यक्षमता अधिक महत्त्वाची असते तेव्हा LoRaWAN आणि NB-IoT हे अधिक चांगले पर्याय ठरतात. युटिलिटीज, इस्टेट्स, पेरीमीटर मॉनिटरिंग आणि रिमोट टेलिमेट्री ही याची सामान्य उदाहरणे आहेत.
नेटवर्क टीमचा ब्लाइंड स्पॉट
अनेक नेटवर्क इंजिनिअर्सना IP बाजू चांगली माहीत असते परंतु त्यांनी मर्यादित किंवा अपारंपरिक डिव्हाइस नेटवर्कसोबत जास्त वेळ घालवलेला नसतो. IoT च्या गुंतागुंतीमध्ये जाण्यापूर्वी तुमच्या टीमला मुख्य राउटींग आणि स्विचिंग संकल्पनांची उजळणी हवी असल्यास, मजबूत Cisco CCNA परीक्षा तयारी मदत करू शकते कारण बरीच IoT ट्रबलशूटिंग अजूनही मजबूत नेटवर्किंगच्या मूलभूत गोष्टींवर अवलंबून असते.
IP-आधारित IoT इस्टेट्ससाठी, अनेक टीम्सच्या अपेक्षेपेक्षा ॲड्रेस प्लॅनिंग देखील अधिक महत्त्वाचे ठरते. मिश्रित एंडपॉइंट वाढ, सेगमेंटेशन आणि दीर्घ डिव्हाइस लाइफसायकल ही उपयोजन मोठे होण्यापूर्वी IPv6 आणि IPv4 मधील फरक समजून घेण्याची चांगली कारणे आहेत.
IoT मध्ये, रेडिओची निवड क्वचितच "सर्वोत्तम श्रेणी" बद्दल असते. ती सिग्नल खऱ्या इमारतीत, खऱ्या हस्तक्षेपात आणि खऱ्या सपोर्ट मॉडेलमध्ये टिकून राहतो की नाही याबद्दल असते.
सहसा काय काम करते आणि काय करत नाही
- चांगले काम करते: अधिक समृद्ध ट्रॅफिक पॅटर्न असलेल्या संचलित उपकरणांसाठी WiFi
- चांगले काम करते: दाट इनडोअर बॅटरी इस्टेट्ससाठी Zigbee किंवा Thread
- चांगले काम करते: विरळ, लांब पल्ल्याच्या टेलिमेट्रीसाठी LoRaWAN किंवा NB-IoT
- सहसा अपयशी ठरते: प्रत्येक डिव्हाइस क्लासवर एकच कनेक्टिव्हिटी मानक सक्तीने लागू करणे
- सहसा अपयशी ठरते: साइटच्या परिस्थितीऐवजी लॅब कव्हरेज मॅप्सवर आधारित निवड करणे
हा शेवटचा मुद्दा अनंत अडचणी निर्माण करतो. घरातील साहित्य, भाडेकरूंची घनता आणि RF गोंगाट यामुळे उत्तर बदलते.
तुमच्या व्यवसायासाठी योग्य प्रोटोकॉल कसा निवडावा
बहुतेक खरेदीदार विचारतात की कोणता प्रोटोकॉल सर्वोत्तम आहे. तो चुकीचा प्रश्न आहे. उपयुक्त प्रश्न हा आहे की कोणता प्रोटोकॉल तुम्हाला ऑपरेट करण्यासाठी आवश्यक असलेल्या डिव्हाइस, पर्यावरण, ट्रॅफिक पॅटर्न आणि सुरक्षा मॉडेलशी सर्वोत्तम जुळतो.
UK मध्ये, हे विशेषतः महत्त्वाचे आहे कारण प्रोटोकॉलची निवड अनेकदा सैद्धांतिक श्रेणीऐवजी वास्तविक रेडिओ परिस्थितीनुसार आकारली जाते. Ofcom डेटा परवाना-मुक्त बँडचा मोठा वापर दर्शवतो आणि सरकारी डेटा इनडोअर मोबाईल कव्हरेज नसलेले स्पॉट्स हायलाइट करतो, ज्याचा अर्थ भिंत भेदण्याची क्षमता, हस्तक्षेप आणि बॅकहॉलची विश्वासार्हता या गोष्टी स्पेक शीटच्या हेडलाईनपेक्षा अधिक महत्त्वाच्या ठरतात. Kore Wireless त्यांच्या UK IoT प्रोटोकॉल तडजोडींच्या चर्चेत या आव्हानाचा चांगला सारांश मांडते.
भौतिक वास्तविकतेपासून सुरुवात करा
एक काँक्रीटचे हॉटेल, स्टील-फ्रेम असलेला रिटेल विभाग आणि मोकळी युटिलिटी साईट या सर्वांचे वर्तन सारखे नसते. सुरुवात जागेपासून करा, विक्रेत्याच्या प्रेझेंटेशन स्लाइडवरून नाही.
विचारा:
- डिव्हाइस कुठे कार्यरत असेल? प्लांट रूम, बेडरूम, कॉरिडॉर, कार पार्क, रूफटॉप, किंवा कॅम्पस एज.
- सिग्नलला कशामुळे अडथळा येतो? काँक्रीट, धातू, लिफ्ट, रेफ्रिजरेशन युनिट्स किंवा दाट लोकवस्ती.
- बॅकहॉलची मालकी कोणाकडे आहे? तुमची टीम, व्यवस्थापित प्रदाता (मॅनेज्ड प्रोव्हायडर), एखादा थर्ड पार्टी किंवा मोबाईल ऑपरेटर.
एका रिकाम्या टेस्ट रूममध्ये आदर्श वाटणारा प्रोटोकॉल, अडथळे आणि हालचालींनी भरलेल्या प्रत्यक्ष इमारतीमध्ये अयशस्वी ठरू शकतो.
प्रोटोकॉल आणि व्यावसायिक गरजांची सांगड घाला
प्रत्येक वापराच्या उदाहरणाला प्रत्यक्ष गरजांच्या अगदी लहान सेटशी जुळवणे हा एक उपयुक्त निवड दृष्टिकोन आहे.
हॉटेल थर्मोस्टॅट्स आणि पर्यावरण सेन्सर्स
ही डिव्हाइसेस सहसा लहान अपडेट्स पाठवतात, बऱ्याचदा ठराविक अंतराने किंवा स्थिती बदलल्यावर. त्यांना वेब-शैलीतील संवादाची गरज नसते, परंतु त्यांना स्थिर ऑपरेशन आणि सोपे बॅटरी किंवा वीज व्यवस्थापन हवे असते. वजनदार API-केंद्रित डिझाइनपेक्षा हलके मेसेजिंग आणि स्थानिक गेटवे शिस्त सहसा अधिक फायदेशीर ठरते.
रिटेल बीकन्स आणि फूटफॉल डिव्हाइसेस
येथे इनडोअर घनता महत्त्वाची ठरते. व्यस्त RF परिस्थितींमध्ये सहअस्तित्व, बॅटरी आयुष्य आणि अंदाज लावता येण्याजोगे कार्य या गोष्टी तुमच्यासाठी महत्त्वाच्या आहेत. जर डिव्हाइसेस एखाद्या दुकानात किंवा शॉपिंग सेंटरमध्ये पसरलेले असतील, तर सर्व काही मानक WiFi वर लोड करण्यापेक्षा कमी पल्ल्याचे, कमी पॉवरचे पर्याय सहसा अधिक सयुक्तिक ठरतात.
हॉस्पिटल किंवा कॅम्पसचे ॲसेट ट्रॅकर्स
कव्हरेज हा सर्वात कठीण भाग बनतो. ब्रोशरमधील दाव्यांपेक्षा डेड स्पॉट्स, इमारतीचे साहित्य आणि हालचालींचे स्वरूप अधिक महत्त्वाचे ठरते. लांब पल्ल्याचे टेलिमेट्री प्रोटोकॉल विखुरलेल्या मालमत्तेसाठी मदत करू शकतात, परंतु ते इनडोअर मधील अचूक लोकेशन किंवा वारंवार अपडेट्ससाठी योग्य नसतील.
एक व्यावहारिक निर्णय चेकलिस्ट
- पॉवर बजेट सर्वात आधी: जर डिव्हाइस बॅटरीवर चालत असेल, तर जास्त चॅटी किंवा वजनदार पर्याय आधीच वगळा.
- त्यानंतर ट्रॅफिक पॅटर्न: लहान, वारंवार होणाऱ्या स्थिती बदलांसाठी हलके मेसेजिंग अधिक सोयीचे ठरते.
- लेटन्सी सहनशीलता महत्त्वाची आहे: काही मॉनिटरिंगमध्ये विलंब सहन केला जाऊ शकतो. सुरक्षा आणि नियंत्रणामध्ये मात्र विलंब चालत नाही.
- इंटिग्रेशनचा भार विचारात घ्या: ज्या प्रोटोकॉलला तुमची प्लॅटफॉर्म टीम आधीपासूनच सुरक्षित आणि ट्रॅक करू शकते, त्याचे मूल्य किंचित हलक्या असलेल्या पर्यायापेक्षा नक्कीच जास्त असू शकते.
- सपोर्ट मॉडेल स्केलेबिलिटी ठरवते: जर फिल्ड टीम्स डिव्हाइसेस व्यवस्थितपणे बदलू, रिसेट करू किंवा पुन्हा सक्रिय करू शकत नसतील, तर तुमचा ऑपरेटिंग खर्च वेगाने वाढतो.
निवडीचा नियम: सर्वात कमी कार्यात्मक गुंतागुंतीसह तुम्हाला स्वीकार्य डिव्हाइस कार्यप्रदर्शन देणारा प्रोटोकॉल निवडा. सर्वात छान डेटाशीट असलेला प्रोटोकॉल नाही.
सर्वात मजबूत डिझाइन सहसा शुद्ध नसतात. ते मर्यादित टेलिमेट्रीसाठी एक प्रोटोकॉल फॅमिली, अधिक समृद्ध ॲप्लिकेशन्ससाठी दुसरी आणि ओळख आणि पॉलिसीसाठी स्वतंत्र व्यवस्थापन स्तर वापरतात.
डिव्हाइस ओळखीसह IoT सुरक्षितता युनिफाय करणे
बहुतेक प्रोटोकॉल चर्चा फार लवकर थांबतात. ते मेसेजचा आकार, बॅटरीचा वापर आणि रेंजची तुलना करतात, नंतर असे गृहीत धरतात की सुरक्षिततेची समस्या नंतर जोडली जाऊ शकते. एंटरप्राइझ वातावरणात, हे उलट आहे. प्रत्येक डिव्हाइस वैध असल्याचे सिद्ध करणे, त्याला योग्य प्रवेश नियुक्त करणे आणि काही बदल झाल्यावर तो प्रवेश सुरक्षितपणे रद्द करणे हे प्राथमिक आव्हान आहे.
तिथेच अनेक IoT उपयोजन अजूनही कोलमडतात.
अनुपालनाने (Compliance) चर्चा बदलली आहे
UK च्या PSTI प्रणाली आणि NCSC मार्गदर्शक तत्त्वांनुसार अनन्य, प्रति-डिव्हाइस क्रेडेंशियल्स आवश्यक आहेत आणि डीफॉल्ट पासवर्डवर बंदी आहे. हे प्रोटोकॉल नियोजनाला साध्या MQTT विरुद्ध CoAP चर्चेच्या पलीकडे आणि एका कठीण प्रश्नाकडे ढकलते: कोणते प्रोटोकॉल आणि प्लॅटफॉर्म डिव्हाइस ओळख, प्रमाणपत्र जीवनचक्र व्यवस्थापन आणि किमान-विशेषाधिकार प्रवेश लागू करणे सुलभ करतात? हा अनुपालनाचा दृष्टिकोन सामान्य प्रोटोकॉल पुनरावलोकनांमध्ये अनेकदा गमावला जातो, परंतु IoT सुरक्षितता आणि पॉलिसी आवश्यकतांच्या या पुनरावलोकनात चर्चा केलेल्या UK संदर्भात तो केंद्रस्थानी आहे.
डीफॉल्ट क्रेडेंशियल्स, शेअर केलेल्या प्री-शेअर्ड की आणि फ्लॅट नेटवर्क ट्रस्ट मल्टी-युझर ठिकाणांमध्ये योग्यरित्या स्केल होत नाहीत. ते घटनेला प्रतिसाद देणे देखील कठीण करतात. जर एका इन्स्टॉलरला सामायिक की माहित असेल किंवा एका भाडेकरू-नियंत्रित डिव्हाइसमध्ये व्यापक प्रवेश सामायिक केला असेल, तर नियंत्रण ठेवणे कठीण होते.
प्रोटोकॉल शुद्धतेपेक्षा ओळख का महत्त्वाची आहे
सुरक्षित IoT डिझाइनसाठी प्रत्येक डिव्हाइसने चार प्रश्नांची स्पष्ट उत्तरे देणे आवश्यक आहे:
- तुम्ही कोण आहात?
- तुम्ही ऑनबोर्ड कसे झाले?
- तुम्हाला कशापर्यंत पोहोचण्याची परवानगी आहे?
- व्यत्यय न आणता मी ट्रस्ट कसा रद्द किंवा रोटेट करू?
म्हणूनच गंभीर एंटरप्राइझ मालमत्तेसाठी सामायिक रहस्यांपेक्षा प्रमाणपत्र-आधारित प्रमाणीकरण (certificate-based authentication) सहसा अधिक बचावात्मक असते. हे प्रति डिव्हाइस अनन्य ओळख, सुलभ रद्दीकरण आणि झिरो-ट्रस्ट पॉलिसीसह अधिक चांगल्या समन्वयाला समर्थन देते.
पारंपारिक WiFi प्रवेश नियंत्रणाची सवय असलेल्या टीम्ससाठी, RADIUS सर्व्हर काय आहे हे समजून घेणे उपयुक्त ठरते कारण डिव्हाइसेससाठी ओळख-आधारित प्रवेश अद्याप शिस्तबद्ध प्रमाणीकरण आणि पॉलिसी अंमलबजावणीवर अवलंबून असतो, अगदी एंडपॉइंट लॅपटॉप असलेला व्यक्ती नसला तरीही.
सामायिक क्रेडेन्शियलमुळे IoT उपयोजन करताना सोपे वाटते परंतु उर्वरित जीवनकाळासाठी ते खर्चिक ठरते.
एंटरप्राइझ टीम्सनी विचारला पाहिजे असा प्लॅटफॉर्म संदर्भातील प्रश्न
केवळ एखादा प्रोटोकॉल एन्क्रिप्शनला सपोर्ट करतो की नाही एवढेच विचारू नका. तुमचा प्लॅटफॉर्म डिव्हाइसच्या ओळखीला पॉलिसी, डिरेक्टरी लॉजिक, सेगमेंटेशन आणि लाइफसायकल कंट्रोल्सशी जोडू शकतो का ते विचारा.
मिश्रित मालमत्तेमध्ये, यामध्ये ब्रोकर्स, गेटवेज, NAC टूलींग, PKI आणि Wi-Fi ऑनबोर्डिंग सिस्टम्स एकत्र काम करत असतील. त्या व्यापक ओळख स्तरातील एक पर्याय म्हणजे Purple आहे, जो पासवर्डलेस ॲक्सेस, सर्टिफिकेट-ग्रेड ऑनबोर्डिंग फ्लो आणि कर्मचाऱ्यांसाठी आणि मल्टी-टेनंट वातावरणासाठी Entra ID, Google Workspace आणि Okta सारख्या आयडेंटिटी सिस्टम्ससह इंटिग्रेशनला सपोर्ट करतो. याचा अर्थ एकाच प्रोटोकॉलची सक्ती करणे असा नाही. तर विविध डिव्हाइसेस आणि युजर्सना एक सुसंगत ट्रस्ट फ्रेमवर्क प्रदान करणे हा आहे.
हे अशा क्षेत्रांमध्ये विशेषतः महत्वाचे ठरते जिथे बिघाड झाल्यास अधिक ऑपरेशनल खर्च येतो. आरोग्यसेवा हे याचे स्पष्ट उदाहरण आहे. जर तुम्हाला व्यापक उद्योग दृष्टिकोन हवा असेल, तर IoT in medical वरील हा लेख उपयुक्त आहे कारण वैद्यकीय वातावरणामध्ये केवळ साध्या कनेक्टिव्हिटीपेक्षा आयडेंटिटी, सेगमेंटेशन आणि नियंत्रित ॲक्सेस का महत्त्वाचा आहे हे तंतोतंत दिसून येते.
तुमची सुसंगत IoT रणनीती तयार करणे
IoT च्या प्रोटोकॉलमध्ये कोणताही एक सर्वोत्तम पर्याय नाही. त्यामध्ये काही तडजोडी कराव्या लागतात आणि चांगली आर्किटेक्चर रचना या तडजोडींना कामाशी जुळवून घेण्यातूनच आकारास येते.
यासाठीचा उपयुक्त पॅटर्न सोपा आहे. लेअर्ड मॉडेल वापरा जेणेकरून तुमच्या टीमला हे समजेल की ते ॲप्लिकेशनचे वर्तन, ट्रान्सपोर्ट, ॲड्रेसिंग किंवा फिजिकल कनेक्टिव्हिटी यापैकी कशाबद्दल चर्चा करत आहेत. जिथे डिव्हाइसेस मर्यादित आहेत तिथे लाईटवेट मेसेजिंग निवडा. प्रयोगशाळेऐवजी वास्तविक इमारत किंवा मालमत्तेसाठी योग्य लिंक टेक्नॉलॉजी निवडा. ज्या डिव्हाइसेसना खरोखर गरज आहे त्यांच्यासाठी अधिक समृद्ध प्रोटोकॉल ठेवा.
एक परिपक्व एंटरप्राइझ दृष्टिकोन कसा दिसतो
एका भक्कम IoT रणनीतीमध्ये सामान्यतः खालील गोष्टींचा समावेश होतो:
- विविध डिव्हाइस वर्गांसाठी भिन्न प्रोटोकॉल, कोणत्याही एका सक्तीच्या मानकाऐवजी
- एक सामान्य ऑनबोर्डिंग आणि पॉलिसी मॉडेल, जेणेकरून ऑपरेशन्स विखुरले जाणार नाहीत
- भूमिका आणि जोखमीनुसार सेगमेंटेशन, केवळ पारंपारिक VLAN च्या सवयीनुसार नाही
- आयडेंटिटी-फर्स्ट सिक्युरिटी, जेणेकरून प्रत्येक डिव्हाइसचे सुरक्षितपणे ऑथेंटिकेशन, ऑथोरायझेशन आणि ते रद्द (revoked) केले जाऊ शकेल
यामुळेच सेन्सर्स आणि स्मार्ट एंडपॉइंट्सचा विखुरलेला संग्रह एका व्यवस्थापन करण्यायोग्य प्लॅटफॉर्ममध्ये रूपांतरित होतो.
सर्वात मोठा बदल हा मानसिकतेचा आहे. IoT कडे नेटवर्किंगचा अपवाद म्हणून पाहणे थांबवा. त्याऐवजी तुमच्या आयडेंटिटी आणि ॲक्सेस मालमत्तेचा तो एक भाग आहे असे समजा. जेव्हा टीम्स असे करतात, तेव्हा प्रोटोकॉल निवडणे सोपे होते, ऑनबोर्डिंग अधिक सुरक्षित होते आणि दीर्घकालीन सपोर्ट खूप अधिक प्रेडिक्टेबल बनतो.
जर तुम्ही अतिथी, कर्मचारी आणि IoT वातावरणात कनेक्ट केलेली उपकरणे कशी ऑथेंटिकेट होतात याचे पुनरावलोकन करत असाल, तर आयडेंटिटी लेयरचा एक भाग म्हणून Purple चे मूल्यांकन करणे नक्कीच फायदेशीर आहे. हे एंटरप्राइझ टीम्सना मल्टि-युझर ठिकाणे आणि मिश्रित उपकरण मालमत्तेमध्ये सामायिक केलेले पासवर्ड आणि विखंडित ऑनबोर्डिंग बदलून पॉलिसी-चालित, पासवर्डशिवाय प्रवेश मिळवण्याचा मार्ग प्रदान करते.
