আপনার নেটওয়ার্কে সম্ভবত ইতিমধ্যে লক্ষণগুলি দেখা যাচ্ছে। একজন ইনস্টলারের সাথে কয়েকটি স্মার্ট থার্মোস্ট্যাট এসেছে। অন্যজনের সাথে এসেছে ডোর কন্ট্রোলার। ফ্যাসিলিটিজ দল লিক সেন্সর যুক্ত করেছে। মার্কেটিং টিম ফুটফল কাউন্টার চায়। অপারেশনস টিম অ্যাসেট ট্যাগ চায়। গেস্ট ডিভাইস, স্টাফদের ট্যাবলেট, ক্যামেরা, কিয়স্ক এবং বিল্ডিং সিস্টেম সবকিছুরই কানেক্টিভিটি প্রয়োজন, কিন্তু তারা সবাই একই ভাষায় কথা বলে না এবং তারা অবশ্যই ল্যাপটপের মতো আচরণ করে না।
এখানেই অনেক এন্টারপ্রাইজ IoT প্রজেক্টে সমস্যা শুরু হয়। টিমগুলি ডিভাইস, রেডিও বা ক্লাউড ড্যাশবোর্ডের দিকে মনোযোগ দেয় এবং কমিউনিকেশন মডেলকে অবহেলা করে। তারপর এই সংখ্যা বৃদ্ধি পায়। হঠাৎ করেই সমস্যাটি আর একটি অতিরিক্ত সেন্সর যুক্ত করার মধ্যে সীমাবদ্ধ থাকে না। এটি তখন শত শত বা হাজার হাজার ডিভাইস পরিচালনা করার বিষয় হয়ে দাঁড়ায়, যার প্রতিটির ট্র্যাফিক প্যাটার্ন আলাদা, ট্রাস্ট লেভেল আলাদা এবং ফেইলিউর মোডও সম্পূর্ণ আলাদা।
ব্যবহারিক সমাধান শুরু হয় protocols for IoT বোঝার মাধ্যমে। শুধুমাত্র শব্দার্থ জানার জন্য নয়, একটি অপারেটিং মডেল হিসেবে এটি বুঝতে হবে। কোন প্রোটোকল কী কাজ করে, স্ট্যাকের মধ্যে এটি কোথায় থাকে এবং অনবোর্ডিং, আইসোলেশন ও সাপোর্ট ওভারহেডে এটি কীভাবে প্রভাব ফেলে তা একবার জেনে গেলে, এই বিশৃঙ্খলা সহজে নিয়ন্ত্রণযোগ্য হয়ে ওঠে।
কানেক্টেড ডিভাইসের বিশৃঙ্খলা নিয়ন্ত্রণ করা
একটি হোটেলে, গেস্ট নেটওয়ার্কে প্যাকেট লসের সমস্যাটি সামান্য মনে হতে পারে, যতক্ষণ না রুম কন্ট্রোলগুলি একই এয়ারটাইম শেয়ার করে এবং আপডেট মিস করতে শুরু করে। রিটেইলে, প্রতি কয়েক সেকেন্ড পর পর রিপোর্ট পাঠানো একটি কিউ কাউন্টারের প্রয়োজন রিচ কন্টেন্ট পুল করা একটি ডিজিটাল সাইনেজ প্লেয়ারের চেয়ে সম্পূর্ণ ভিন্ন। একটি হাসপাতাল বা বড় অফিসে, ব্যাটারি-চালিত সেন্সরগুলির দীর্ঘ সময় ধরে চলার প্রয়োজন হতে পারে, যেখানে ফিক্সড ইনফ্রাস্ট্রাকচার ভারী প্রোটোকল এবং কঠোর কন্ট্রোল প্লেন সহ্য করতে পারে।
ভুলটি হলো সমস্ত কানেক্টেড ডিভাইসকে এমনভাবে বিবেচনা করা যেন তারা সবাই একটি স্ট্যান্ডার্ড নেটওয়ার্ক ডিজাইনের অংশ।
কেন প্রোটোকল নির্বাচন একটি অপারেশনাল সমস্যা হয়ে ওঠে
প্রোটোকল কেবল একটি প্রযুক্তিগত পছন্দ নয়। এটি নির্ধারণ করে:
- ডিভাইসগুলি কত ঘন ঘন যোগাযোগ করে এবং নেটওয়ার্কে তারা কতটা অ্যাক্টিভ থাকে
- প্রয়োজনীয় ডেটা পাঠাতে তারা কতটা ব্যাটারি খরচ করে
- শেয়ার্ড ক্রেডেন্সিয়াল ছাড়াই তাদের অনবোর্ড করা কতটা সহজ
- একাধিক সিস্টেমের একই টেলিমেট্রি প্রয়োজন হলে তারা কতটা ভালোভাবে স্কেল করতে পারে
- ক্লাউড সার্ভিস, ব্রোকার, গেটওয়ে এবং আইডেন্টিটি কন্ট্রোলের সাথে তারা কত সহজে ইন্টিগ্রেট হতে পারে
যেসব টিম মিশ্র এস্টেট পরিচালনা করছে, তাদের জন্য এটি আর্কিটেকচারাল সমস্যার পাশাপাশি একটি সাপোর্ট সমস্যাও হয়ে দাঁড়ায়। আপনি যদি ইতিমধ্যেই কানেক্টেড এন্ডপয়েন্টের ক্রমবর্ধমান সংখ্যা নিয়ে কাজ করে থাকেন, তবে Purple-এর how many devices are connected to the internet সংক্রান্ত আলোচনাটি একটি কার্যকর অনুস্মারক যে ডিভাইসের বৃদ্ধি ধীর হচ্ছে না। বেশি এন্ডপয়েন্ট মানে বেশি প্রোটোকলের বৈচিত্র্য, কম নয়।
ব্যবহারিক নিয়ম: যেখানেই সম্ভব আপনার অনবোর্ডিং এবং সিকিউরিটি মডেল স্ট্যান্ডার্ডাইজ করুন, তবে প্রতিটি ডিভাইসের ধরনকে জোর করে একই কমিউনিকেশন প্রোটোকল ব্যবহার করতে বাধ্য করবেন না।
একটি আদর্শ রূপ কেমন হওয়া উচিত
একটি কার্যকর IoT পরিবেশের সাধারণত তিনটি বৈশিষ্ট্য থাকে।
প্রথমত, প্রোটোকলটি ডিভাইসের সীমাবদ্ধতার সাথে সামঞ্জস্যপূর্ণ হতে হবে। ছোট সেন্সরগুলোর ওয়েব-স্টাইল যোগাযোগের মতো ভারী লোড বহন করা উচিত নয়, যদি তাদের কেবল স্ট্যাটাস পরিবর্তনগুলো প্রকাশ করার প্রয়োজন হয়।
দ্বিতীয়ত, প্রোটোকলটি পরিবেশের সাথে সামঞ্জস্যপূর্ণ হতে হবে। ঘন অভ্যন্তরীণ স্থান, কংক্রিটের ভবন এবং মাল্টি-টেন্যান্ট ভেন্যুগুলোতে এমন ডিজাইন ব্যর্থ হতে পারে যা ল্যাব পরিস্থিতিতে ঠিকঠাক কাজ করেছিল।
তৃতীয়ত, প্রোটোকলটি আপনার প্রয়োজনীয় সিকিউরিটি মডেলকে সমর্থন করতে হবে। আপনার টিম যদি ইউনিক আইডেন্টিটি অ্যাসাইন করতে না পারে, ক্লিনলি অ্যাক্সেস বাতিল করতে না পারে এবং ফাংশন অনুযায়ী ডিভাইসগুলোকে সেগমেন্ট করতে না পারে, তবে পাইলট প্রজেক্ট সফল হলেও প্রোটোকলটি ভবিষ্যতে সমস্যা তৈরি করবে।
প্রতিটি প্রোটোকল সংক্রান্ত সিদ্ধান্ত নেওয়ার সময় এই ফ্রেমওয়ার্কটি মাথায় রাখা উচিত।
IoT যোগাযোগের চারটি স্তর (Layers)
যখন টিমগুলো একই মিটিংয়ে MQTT, CoAP, Thread, LoRaWAN, TCP, UDP এবং WiFi এর মতো নামগুলো শোনে, তখন আলোচনাটি সাধারণত গুলিয়ে যায় কারণ এই প্রোটোকলগুলো সবই এক সমস্যার সমাধান করে না। এগুলো বোঝার সবচেয়ে সহজ উপায় হলো এদের বিভিন্ন স্তরে ভাগ করা।
IoT যোগাযোগকে একটি পার্সেল পাঠানোর মতো মনে করতে পারেন।
পার্সেলের উপমা যা বুঝতে সাহায্য করবে
- Application layer: এটি পার্সেলের ভেতরের আইটেম। এটি হলো ডেটার আসল অর্থ। যেমন একটি তাপমাত্রা পরিমাপ, দরজা খোলার কমান্ড বা ডিভাইসের স্ট্যাটাস আপডেট।
- Transport layer: এটি হলো পার্সেলটি কীভাবে হ্যান্ডেল করা হচ্ছে। আপনি কি ডেলিভারি কনফার্মেশন চান, নাকি কম ওভারহেডে এটি দ্রুত পাঠাতে চান?
- Network layer: এটি হলো অ্যাড্রেস এবং রাউটিং লজিক যা পার্সেলটিকে নেটওয়ার্কের মাধ্যমে সঠিক গন্তব্যে নিয়ে যায়।
- Link layer: এটি হলো ডেলিভারি গাড়ি এবং স্থানীয় পথ। WiFi, ইথারনেট, Zigbee, Thread, সেলুলার IoT এবং অন্যান্য স্থানীয় কানেক্টিভিটি মেথড এখানে কাজ করে।
এই মানসিক মডেলটি অনেক ভুল ডিজাইনের বিতর্ক বন্ধ করে দেয়। WiFi এর সাথে MQTT-এর তুলনা করা অনেকটা বাক্সের ভেতরের জিনিসের সাথে সেটি বহনকারী ভ্যানের তুলনা করার মতো। এগুলো সম্পূর্ণ ভিন্ন স্তরের অন্তর্ভুক্ত।
কেন এন্টারপ্রাইজ টিমগুলোর এই লেয়ার্ড ভিউ প্রয়োজন
একবার স্ট্যাকটি স্পষ্টভাবে বুঝতে পারলে, প্রোটোকল নির্বাচন করা অনেক সহজ হয়ে যায়। কোনো একটি পরিচিত নাম বেছে নিয়ে সর্বত্র ব্যবহার করার চেষ্টার পরিবর্তে আপনি সীমাবদ্ধতার ওপর ভিত্তি করে বিভিন্ন প্রোটোকল মিলিয়ে ব্যবহার করতে পারেন।
উদাহরণস্বরূপ, একটি বিল্ডিং সেন্সর হয়তো একটি লাইটওয়েট অ্যাপ্লিকেশন প্রোটোকল, ছোট মেসেজের জন্য উপযোগী একটি ট্রান্সপোর্ট অপশন, গেটওয়ের মাধ্যমে একটি IP-ভিত্তিক নেটওয়ার্ক পথ এবং বিল্ডিংয়ের ভেতরে একটি লো-পাওয়ার লিঙ্ক লেয়ার ব্যবহার করতে পারে। বিপরীতে, একটি ক্যামেরা তারযুক্ত ইথারনেট বা WiFi এর মাধ্যমে সংযুক্ত হয়ে সম্পূর্ণ ভিন্ন একটি অ্যাপ্লিকেশন প্যাটার্ন ব্যবহার করতে পারে।
এই ক্ষেত্রে একটি বড় মাইলফলক ছিল OASIS স্ট্যান্ডার্ড হিসেবে MQTT এবং RFC 7252-এ সংজ্ঞায়িত CoAP-এর স্ট্যান্ডার্ডাইজেশন। এটি গুরুত্বপূর্ণ ছিল কারণ এন্টারপ্রাইজ বাজারের সীমিত ক্ষমতাসম্পন্ন ডিভাইসগুলি পরিচালনা করার জন্য সাধারণ, ইন্টারঅপারেবল উপায়ের প্রয়োজন ছিল। এর পটভূমি হলো ব্যাপক গ্রহণযোগ্যতা। 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 |
যদি কোনও ডিজাইন রিভিউ আটকে যায়, তবে প্রথমে একটি প্রশ্ন জিজ্ঞাসা করুন: “আমরা আসলে কোন লেয়ার নিয়ে কথা বলছি?” এটি সাধারণত বিভ্রান্তি দ্রুত দূর করে।
মূল অ্যাপ্লিকেশন এবং ট্রান্সপোর্ট প্রোটোকলের তুলনা
স্ট্যাকের শীর্ষে, মৌলিক সিদ্ধান্তটি প্রায়শই ডিভাইসগুলি কীভাবে অ্যাপ্লিকেশন, ব্রোকার বা ম্যানেজমেন্ট প্ল্যাটফর্মের সাথে ডেটা আদান-প্রদান করে তার উপর নির্ভর করে। এন্টারপ্রাইজ টিমগুলি এই প্রভাবটি সবচেয়ে সরাসরি অনুভব করে কারণ এই প্রোটোকলগুলি মেসেজিং স্টাইল, ইন্টিগ্রেশন প্রচেষ্টা এবং লাইনে কতটা অপ্রয়োজনীয় ট্রাফিক শেষ পর্যন্ত জমা হয় তা নির্ধারণ করে।
বাজার একটি যুক্তিসঙ্গত কারণে হালকা বিকল্পগুলির দিকে এগিয়ে গেছে। বিশেষ উদ্দেশ্যে তৈরি আইওটি প্রোটোকল যেমন MQTT এবং CoAP দুই বছরে ১১% বৃদ্ধি পাবে বলে আশা করা হচ্ছে, যেখানে ব্যবহারের সহজতা এবং নির্ভরযোগ্যতা ডেভেলপারদের দ্বারা সবচেয়ে গুরুত্বপূর্ণ প্রয়োজনীয়তা হিসাবে চিহ্নিত করা হয়েছে, IoT Analytics on IoT protocols অনুসারে। এটি বেশিরভাগ এন্টারপ্রাইজ টিম বাস্তবে যা দেখে তার সাথে মিলে যায়। সীমিত ক্ষমতাসম্পন্ন ডিভাইসগুলির শুধুমাত্র “তাপমাত্রা এখনও স্বাভাবিক রয়েছে” বলার জন্য প্রচুর প্রোটোকল ওভারহেড বহন করার কোনো প্রয়োজন নেই।
অ্যাপ্লিকেশন এবং ট্রান্সপোর্ট প্রোটোকলের তুলনা
| প্রোটোকল | মডেল | ভিত্তিগত ট্রান্সপোর্ট | ওভারহেড | যার জন্য সবচেয়ে ভালো |
|---|---|---|---|---|
| MQTT | পাবলিশ এবং সাবস্ক্রাইব | সাধারণত TCP | কম | টেলিমეტ্রি, রিমোট মনিটরিং, বহু-থেকে-বহু ডেটা বিতরণ |
| CoAP | রিকোয়েস্ট এবং রেসপন্স | সাধারণত UDP | খুব কম | সীমিত ক্ষমতাসম্পন্ন ডিভাইস, ছোট মেসেজ, কম-লেটেন্সি স্থানীয় ইন্টারঅ্যাকশন |
| HTTP(S) | Request and response | TCP | Higher | Web integration, APIs, browser-friendly workflows |
| LwM2M | Device management oriented | Commonly used with lightweight transports | Low to moderate | Provisioning, lifecycle management, remote configuration |
যখন একাধিক সিস্টেমের একই ডেটার প্রয়োজন হয় তখন MQTT কাজ করে
এন্টারপ্রাইজ IoT-এর জন্য MQTT প্রায়শই ডিফল্ট পছন্দ কারণ এটি অত্যন্ত দক্ষ এবং পরিচালনাগতভাবে পরিচ্ছন্ন। ডিভাইসগুলি নির্দিষ্ট টপিকে মেসেজ পাবলিশ করে। আগ্রহী সিস্টেমগুলি তা সাবস্ক্রাইব করে। এর অর্থ হলো প্রতিটি গ্রাহক আলাদাভাবে ডিভাইসটিকে পোল না করেই একটিমাত্র সেন্সর ফ্যাসিলিটিজ মনিটরিং, অ্যানালিটিক্স, অ্যালার্টিং এবং মেইনটেইন্যান্স ওয়ার্কফ্লোতে ডেটা সরবরাহ করতে পারে।
হসপিটালিটি এবং রিটেইল এস্টেটের ক্ষেত্রে এটি অত্যন্ত গুরুত্বপূর্ণ। একটি রেফ্রিজারেশন সেন্সর, অকুপেন্সি সেন্সর বা পাওয়ার মিটারকে প্রায়শই একসাথে একাধিক ব্যাক-এন্ড ফাংশনে কাজ করতে হয়। MQTT এই কাজটি খুব সুন্দরভাবে সম্পন্ন করে।
খুব ছোট এবং অত্যন্ত সীমিত ডিভাইসের জন্য CoAP উপযুক্ত
ডিভাইসের ফুটপ্রিন্ট যখন খুব ছোট হয়, ট্রাফিক সহজ হয় এবং UDP-ভিত্তিক লাইটওয়েট মেসেজিং গ্রহণযোগ্য হয়, তখন CoAP সাধারণত সবচেয়ে ভালো কাজ করে। এটি সেখানে উপযোগী যেখানে রিচ মেসেজিং মডেলের চেয়ে কম লেটেন্সি এবং ন্যূনতম ওভারহেড বেশি গুরুত্বপূর্ণ।
তা সত্ত্বেও, টিমগুলি কখনও কখনও CoAP-এর ইন্টিগ্রেশন ওভারহেডকে কম মূল্যায়ন করে। আপনার টুলিং, ব্রোকার, অবজারভেবিলিটি স্ট্যাক এবং সিকিউরিটি কন্ট্রোল যদি ভিন্ন অনুমানের ভিত্তিতে তৈরি হয়, তবে এটি ডিভাইস এন্ডে চমৎকার হলেও এন্টারপ্রাইজ এন্ডে কিছুটা জটিল হতে পারে।
ডিজাইন সতর্কতা: খাতাকলমে সবচেয়ে দক্ষ প্রোটোকলটিই প্রোডাকশনের ক্ষেত্রে স্বয়ংক্রিয়ভাবে সবচেয়ে সহজ পছন্দ নাও হতে পারে।
HTTP-এর এখনও স্থান রয়েছে, তবে সব জায়গায় নয়
HTTP এবং HTTPS এখনও কার্যকর কারণ প্রতিটি ক্লাউড টিম, ডেভেলপার এবং ইন্টিগ্রেশন প্ল্যাটফর্ম এগুলো ইতিমধ্যেই বোঝে। ডিভাইসটির যদি কোনও REST API কল করার, মাঝে মাঝে বড় পেলোড আপলোড করার বা বিদ্যমান ওয়েব অ্যাপ্লিকেশন ওয়ার্কফ্লোতে ফিট হওয়ার প্রয়োজন হয়, তবে HTTP সঠিক সিদ্ধান্ত হতে পারে।
সমস্যাটি হলো এর অপব্যবহার। একটি ব্যাটারি চালিত সেন্সর যখন একটি ভারী রিকোয়েস্ট-রেসপন্স প্যাটার্নের মাধ্যমে ছোট স্টেট আপডেট পাঠায়, তখন এটি সাধারণত অপ্রয়োজনীয় ওভারহেড তৈরি করে। এটি কাজ করে, তবে "কাজ করা" এবং "স্কেলেবলভাবে ভালোভাবে কাজ করা" এক জিনিস নয়।
যখন ম্যানেজমেন্ট সবচেয়ে অগ্রাধিকার পায় তখন LwM2M সাহায্য করে
যখন বড় চ্যালেঞ্জটি টেলিমেট্রি নয় বরং ফ্লিট অপারেশনস হয়, তখন LwM2M-এর দিকে নজর দেওয়া উচিত। ডিভাইস ম্যানেজমেন্টের জন্য তৈরি একটি প্রোটোকলের মাধ্যমে প্রোভিশনিং, রিমোট সেটিংস, সফটওয়্যার স্টেট এবং লাইফসাইকেল ম্যানেজমেন্ট সবই আরও সুসংগঠিত হয়। বাস্তবে, অনেক প্রতিষ্ঠান টেলিমেট্রির জন্য একটি প্রোটোকল এবং কন্ট্রোল ও লাইফসাইকেল ফাংশনের জন্য অন্য একটি ম্যানেজমেন্ট লেয়ার ব্যবহার করে।
একটি এন্টারপ্রাইজ টেস্ট যা তত্ত্বকে পরিষ্কার করে
নিজেকে এই প্রশ্নটি করুন: ডিভাইসটির কি বারবার ছোট আপডেট পাবলিশ করা, সরাসরি কমান্ডের প্রতিক্রিয়া জানানো, নাকি একটি ওয়েব-ফ্রেন্ডলি ইন্টারফেস প্রকাশ করা প্রয়োজন?
- একাধিক গ্রাহকের কাছে ঘন ঘন টেলিমেট্রি: সাধারণত MQTT উপযুক্ত
- অত্যন্ত ছোট ফুটপ্রিন্ট এবং লাইটওয়েট এক্সচেঞ্জ: CoAP প্রায়শই উপযুক্ত হয়
- সরাসরি API ইন্টিগ্রেশন এবং ব্রাউজার/ক্লাউড সামঞ্জস্যতা: HTTP(S) মানানসই হয়
- ফ্লিট ম্যানেজমেন্ট এবং স্ট্রাকচার্ড ডিভাইস কন্ট্রোল: LwM2M একবার দেখে নেওয়া উচিত
আপনার পরিবেশে যদি ভিডিও অন্তর্ভুক্ত থাকে, তবে সাধারণ IoT মেসেজিংকে স্ট্রিমিং প্রোটোকলের সাথে গুলিয়ে ফেলবেন না। যে সমস্ত টিম ক্যামেরা ওয়ার্কফ্লো মূল্যায়ন করছে, তাদের জন্য RTSP ফিড সম্পর্কে এই প্রাইমারটি দরকারী কারণ ভিডিও পরিবহনের ডিজাইনের অগ্রাধিকারগুলি লো-পাওয়ার সেন্সর টেলিমেট্রি থেকে সম্পূর্ণ আলাদা।
নেটওয়ার্ক এবং লিঙ্ক লেয়ার প্রোটোকল পরিচালনা করা
অ্যাপ্লিকেশন প্রোটোকলটি বেছে নেওয়ার পরে, বাস্তব জগতের আরও কঠিন প্রশ্নটি প্রায়শই হয় যে কীভাবে ডিভাইসটি মোটেও নেটওয়ার্কে যুক্ত হবে। এই চ্যালেঞ্জের কারণে প্রায়ই বিল্ডিং, এস্টেট এবং মিশ্র-ব্যবহারের স্থানগুলিতে প্রকল্পগুলি ব্যর্থ হয়। অ্যাপ্লিকেশন লেয়ারে প্রোটোকল স্ট্যাকটি নিখুঁত দেখায় এবং তবুও লিঙ্ক এবং নেটওয়ার্ক পছন্দগুলি পরিবেশের জন্য ভুল হওয়ার কারণে এটি আশানুরূপ পারফর্ম নাও করতে পারে।
ঘন বিল্ডিংগুলির জন্য উন্মুক্ত সাইটগুলির চেয়ে ভিন্ন উত্তরের প্রয়োজন
ক্যাম্পাস এবং ইন্ডাস্ট্রিয়াল সেটিংসের জন্য, Zigbee এবং Thread এর মতো লো-পাওয়ার মেশ অপশনগুলি ঘন ইনডোর স্পেসগুলিতে ব্যাটারি-চালিত নোডগুলির জন্য উপযুক্ত, যখন LoRaWAN এবং NB-IoT বহু-কিলোমিটার টেলিমেট্রির জন্য আরও ভালভাবে মিলে যায়। এর ট্রেড-অফ হল ব্যান্ডউইথ, লেটেন্সি এবং ব্যাটারি লাইফের মধ্যে, এবং সঠিক উত্তরটি প্রকৃত UK ব্যবহারের ক্ষেত্রের উপর নির্ভর করে, যেমন ইনডোর অ্যাসেট ট্র্যাকিং বনাম রিমোট এস্টেট মনিটরিং, যা ইন্ডাস্ট্রিয়াল IoT কমিউনিকেশন প্রোটোকলের এই গাইডে রূপরেখা দেওয়া হয়েছে।
সেই ট্রেড-অফটি ভেন্ডর পছন্দের চেয়ে বেশি গুরুত্বপূর্ণ।
এন্টারপ্রাইজ ডিজাইনে আমি কীভাবে লিঙ্ক পছন্দগুলিকে গ্রুপ করি
স্বল্প-পরিসর এবং উচ্চতর থ্রুপুট
WiFi এবং ইথারনেট এখানে অন্তর্ভুক্ত। স্থির শক্তি, বৃহত্তর পে-লোড বা সরাসরি আইটি ইন্টিগ্রেশন সহ ডিভাইসগুলির জন্য এগুলি স্পষ্ট পছন্দ। ক্যামেরা, কিয়স্ক, মিডিয়া প্লেয়ার এবং ফিক্সড অ্যাপ্লায়েন্সগুলি সাধারণত এই বিভাগে পড়ে।
এর অসুবিধা হল শক্তির ব্যবহার এবং এয়ারটাইম নিয়ে প্রতিযোগিতা। আপনি যদি একই ওয়্যারলেস পরিকাঠামোতে ক্রটিকাল ট্রাফিকের সাথে অনেকগুলি চ্যাটি কম-মূল্যের ডিভাইস রাখেন, তবে আপনি নিজেই সাপোর্ট কলের ঝামেলা তৈরি করবেন।
স্বল্প-পরিসর এবং কম-পাওয়ারের মেশ
ডিভাইসগুলি ছোট, ব্যাটারি-চালিত এবং একটি ঘন বিল্ডিংয়ের মধ্যে ছড়িয়ে থাকলে Zigbee এবং Thread আরও বেশি অর্থবহ হয়। স্মার্ট রুম, শেলফ সেন্সর, অকুপেন্সি ডিভাইস এবং পরিবেশগত পর্যবেক্ষণ প্রায়শই এই প্যাটার্নে ফিট করে।
ইনডোরে মেশ চমৎকার হতে পারে, তবে কেবল তখনই যখন টিম গেটওয়ে প্লেসমেন্ট, রোমিং আচরণ এবং আশেপাশের রেডিও পরিবেশের হস্তক্ষেপের জন্য পরিকল্পনা করে।
দীর্ঘ-পরিসর এবং লো-পাওয়ার ওয়াইড এরিয়া
যখন সাইটটি বিস্তৃত হয়, ডেটা খুব কম থাকে এবং থ্রুপুটের চেয়ে ব্যাটারির কার্যকারিতা বেশি গুরুত্বপূর্ণ হয়, তখন LoRaWAN এবং NB-IoT সবচেয়ে উপযুক্ত। ইউটিলিটি, এস্টেট, পেরিমিটার মনিটরিং এবং রিমোট টেলিমেট্রি এর সাধারণ উদাহরণ।
নেটওয়ার্ক টিমের অন্ধ স্থান
অনেক নেটওয়ার্ক ইঞ্জিনিয়ার IP সাইডটি ভালো বোঝেন কিন্তু সীমাবদ্ধ বা অপ্রচলিত ডিভাইস নেটওয়ার্কের সাথে খুব বেশি সময় কাটাননি। IoT-এর জটিলতা যোগ করার আগে যদি আপনার টিমের কোর রাউটিং এবং সুইচিং কনসেপ্টগুলি ঝালাই করে নেওয়ার প্রয়োজন হয়, তবে একটি ভালো Cisco CCNA পরীক্ষার প্রস্তুতি সাহায্য করতে পারে, কারণ অনেক IoT ট্রাবলশুটিং এখনও শক্তিশালী নেটওয়ার্কিং ভিত্তির ওপর নির্ভর করে।
IP-ভিত্তিক IoT এস্টেটের জন্য, অ্যাড্রেস প্ল্যানিংও অনেক টিমের প্রত্যাশার চেয়ে বেশি গুরুত্বপূর্ণ। মিক্সড এন্ডপয়েন্ট বৃদ্ধি, সেগমেন্টেশন এবং দীর্ঘ ডিভাইস লাইফসাইকেল হল ডেপ্লয়মেন্ট বড় হওয়ার আগে IPv6 এবং IPv4-এর মধ্যে পার্থক্য পুনরায় পর্যালোচনা করার উপযুক্ত কারণ।
IoT-তে, রেডিওর পছন্দ খুব কমই "সেরা রেঞ্জ"-এর ওপর নির্ভর করে। এটি নির্ভর করে সিগন্যালটি আসল বিল্ডিং, আসল ইন্টারফেয়ারেন্স এবং আসল সাপোর্ট মডেলের মধ্যে টিকে থাকে কিনা তার ওপর।
সাধারণত কোনটি কাজ করে এবং কোনটি করে না
- ভালো কাজ করে: রিচ ট্রাফিক প্যাটার্ন সহ চালিত ডিভাইসের জন্য WiFi
- ভালো কাজ করে: ঘন ইনডোর ব্যাটারি এস্টেটের জন্য Zigbee বা Thread
- ভালো কাজ করে: স্পার্স, লং-রেঞ্জ টেলিমেট্রির জন্য LoRaWAN বা NB-IoT
- সাধারণত ব্যর্থ হয়: প্রতিটি ডিভাইস ক্লাসের ওপর জোর করে একটিমাত্র কানেক্টিভিটি স্ট্যান্ডার্ড চাপানো
- সাধারণত ব্যর্থ হয়: সাইটের পরিস্থিতির পরিবর্তে ল্যাব কভারেজ ম্যাপের ওপর ভিত্তি করে পছন্দ করা
শেষের পয়েন্টটি সীমাহীন সমস্যার সৃষ্টি করে। ইনডোর ম্যাটেরিয়াল, টেন্যান্ট ডেনসিটি এবং RF নয়েজ উত্তর বদলে দেয়।
আপনার ব্যবসার জন্য কীভাবে সঠিক প্রোটোকল বেছে নেবেন
অধিকাংশ ক্রেতা জিজ্ঞেস করেন কোন প্রোটোকলটি সবচেয়ে ভালো। এটি ভুল প্রশ্ন। দরকারী প্রশ্নটি হল কোন প্রোটোকলটি আপনার প্রয়োজনীয় ডিভাইস, পরিবেশ, ট্রাফিক প্যাটার্ন এবং সিকিউরিটি মডেলের সাথে সবচেয়ে ভালোভাবে খাপ খায়।
যুক্তরাজ্যে এটি বিশেষভাবে গুরুত্বপূর্ণ কারণ প্রোটোকল নির্বাচন প্রায়শই তাত্ত্বিক রেঞ্জের চেয়ে বাস্তব রেডিও পরিস্থিতির দ্বারা নির্ধারিত হয়। Ofcom-এর ডেটা লাইসেন্স-মুক্ত ব্যান্ডের ব্যাপক ব্যবহার দেখায় এবং সরকারি ডেটা ইনডোর মোবাইল কভারেজের নট-স্পটগুলিকে হাইলাইট করে, যার অর্থ স্পেক শীটের হেডলাইনের চেয়ে দেয়াল ভেদ করার ক্ষমতা, ইন্টারফেয়ারেন্স এবং ব্যাকহল নির্ভরযোগ্যতা প্রায়শই বেশি গুরুত্বপূর্ণ। Kore Wireless তাদের UK IoT protocol trade-offs সংক্রান্ত আলোচনায় এই চ্যালেঞ্জটি চমৎকারভাবে তুলে ধরেছে।
শারীরিক বাস্তবতা দিয়ে শুরু করুন
একটি কংক্রিটের হোটেল, একটি স্টিল-ফ্রেমের রিটেল ইউনিট এবং একটি ওপেন ইউটিলিটি সাইট একইভাবে কাজ করে না। ভেন্ডরের স্লাইড দেখে নয়, ভেন্যু দিয়ে শুরু করুন।
জিজ্ঞেস করুন:
- ডিভাইসটি কোথায় থাকবে? প্ল্যান্ট রুম, বেডরুম, করিডোর, কার পার্ক, ছাদ, ক্যাম্পাস এজ।
- কোন জিনিস সিগন্যাল ব্লক করে? কংক্রিট, ধাতু, লিফট, রেফ্রিজারেশন ইউনিট, ঘন বসতি।
- ব্যাকহল কার মালিকানাধীন? আপনার টিম, একজন পরিচালিত প্রদানকারী, কোনো তৃতীয় পক্ষ বা একজন মোবাইল অপারেটর।
একটি খালি টেস্ট রুমে যে প্রোটোকলটিকে আদর্শ মনে হয়, তা হস্তক্ষেপ এবং গতিবিধিতে পূর্ণ একটি লাইভ বিল্ডিংয়ে ব্যর্থ হতে পারে।
ব্যবসায়িক আচরণের সাথে প্রোটোকল মেলান
একটি দরকারী নির্বাচন পদ্ধতি হলো প্রতিটি ব্যবহারের ক্ষেত্রকে আসল প্রয়োজনীয়তার সবচেয়ে ছোট সেটের সাথে ম্যাপ করা।
হোটেল থার্মোস্ট্যাট এবং পরিবেশগত সেন্সর
এই ডিভাইসগুলো সাধারণত ছোট ছোট আপডেট পাঠায়, প্রায়শই নির্দিষ্ট ব্যবধানে বা অবস্থা পরিবর্তনের সময়। এদের ওয়েব-স্টাইল যোগাযোগের প্রয়োজন হয় না, তবে এদের স্থিতিশীল অপারেশন এবং পরিচালনাযোগ্য ব্যাটারি বা পাওয়ার আচরণের প্রয়োজন হয়। হালকা ওজনের মেসেজিং এবং স্থানীয় গেটওয়ে ডিসিপ্লিন সাধারণত ভারী API-কেন্দ্রিক ডিজাইনকে ছাড়িয়ে যায়।
রিটেল বীকন এবং ফুটফল ডিভাইস
এখানে ইনডোর ঘনত্ব গুরুত্বপূর্ণ। আপনি ব্যস্ত RF পরিস্থিতিতে সহাবস্থান, ব্যাটারি লাইফ এবং অনুমানযোগ্য অপারেশন নিয়ে চিন্তা করেন। ডিভাইসগুলো যদি কোনো দোকান বা শপিং সেন্টারে ছড়ানো থাকে, তবে সবকিছু স্ট্যান্ডার্ড WiFi-এ পুশ করার চেয়ে শর্ট-রেঞ্জ লো-পাওয়ার অপশনগুলো বেছে নেওয়া প্রায়শই বেশি অর্থবহ হয়।
হাসপাতাল বা ক্যাম্পাস অ্যাসেট ট্র্যাকার
কভারেজ এখানে কঠিন অংশ হয়ে দাঁড়ায়। ব্রোশারের দাবির চেয়ে ডেড স্পট, বিল্ডিংয়ের উপকরণ এবং চলাচলের ধরণ বেশি গুরুত্বপূর্ণ। ডিস্ট্রিবিউটেড এস্টেটের জন্য লং-রেঞ্জ টেলিমেট্রি প্রোটোকল সাহায্য করতে পারে, তবে সেগুলো হয়তো নিখুঁত ইনডোর লোকেশন বা ঘন ঘন আপডেটের জন্য উপযুক্ত নাও হতে পারে।
একটি ব্যবহারিক সিদ্ধান্তের চেকলিস্ট
- পাওয়ার বাজেট প্রথমে: ডিভাইসটি যদি ব্যাটারিতে চলে, তবে শুরুতেই চ্যাটি বা ভারী অপশনগুলো বাদ দিন।
- ট্রাফিক প্যাটার্ন এর পরে: ছোট, ঘন ঘন অবস্থা পরিবর্তন হালকা ওজনের মেসেজিংয়ের পক্ষে যায়।
- লেটেন্সি সহনশীলতা গুরুত্বপূর্ণ: কিছু মনিটরিং বিলম্ব সহ্য করতে পারে। নিরাপত্তা এবং নিয়ন্ত্রণ প্রায়শই তা পারে না।
- ইন্টিগ্রেশনের বোঝা বিবেচ্য: আপনার প্ল্যাটফর্ম টিম ইতিমধ্যে যে প্রোটোকলটি সুরক্ষিত এবং পর্যবেক্ষণ করতে পারে, সেটি সামান্য হালকা অন্য কোনো বিকল্পের চেয়ে বেশি মূল্যবান হতে পারে।
- সাপোর্ট মডেল স্কেল নির্ধারণ করে: ফিল্ড টিম যদি ডিভাইসগুলো পরিষ্কারভাবে প্রতিস্থাপন, রিসেট বা রিপ্রোভিশন করতে না পারে, তবে আপনার অপারেটিং খরচ দ্রুত বৃদ্ধি পাবে।
নির্বাচন বিধি: এমন প্রোটোকল বেছে নিন যা আপনাকে সর্বনিম্ন অপারেশনাল জটিলতার সাথে গ্রহণযোগ্য ডিভাইস পারফরম্যান্স দেয়। সবচেয়ে চমৎকার ডেটাশীট থাকা প্রোটোকলটি নয়।
সবচেয়ে শক্তিশালী ডিজাইনগুলো সাধারণত বিশুদ্ধ হয় না। এগুলো সীমাবদ্ধ টেলিমেট্রির জন্য একটি প্রোটোকল ফ্যামিলি, সমৃদ্ধ অ্যাপ্লিকেশনের জন্য অন্য একটি এবং আইডেন্টিটি ও পলিসির জন্য একটি পৃথক ম্যানেজমেন্ট প্লেন ব্যবহার করে।
ডিভাইস আইডেন্টিটি দিয়ে IoT সিকিউরিটি একীকরণ করা
অধিকাংশ প্রোটোকল আলোচনা খুব দ্রুত শেষ হয়ে যায়। তারা মেসেজের আকার, ব্যাটারি ব্যবহার এবং রেঞ্জ তুলনা করে, তারপর ধরে নেয় যে সিকিউরিটি সমস্যাটি পরে যোগ করা যাবে। এন্টারপ্রাইজ পরিবেশে, এটি সম্পূর্ণ উল্টো। প্রাথমিক চ্যালেঞ্জ হলো প্রতিটি ডিভাইস বৈধ তা প্রমাণ করা, সেটিকে সঠিক অ্যাক্সেস দেওয়া এবং কোনো পরিবর্তন হলে সেই অ্যাক্সেসটি পরিষ্কারভাবে বাতিল করা।
সেখানেই অনেক IoT ডেপ্লয়মেন্ট এখনও ভেঙে পড়ে।
কমপ্লায়েন্স আলোচনাকে বদলে দিয়েছে
যুক্তরাজ্যের PSTI ব্যবস্থা এবং NCSC নির্দেশিকার জন্য অনন্য, প্রতি-ডিভাইস ক্রেডেনশিয়াল প্রয়োজন এবং ডিফল্ট পাসওয়ার্ড নিষিদ্ধ করে। এটি প্রোটোকল পরিকল্পনাকে একটি সাধারণ MQTT বনাম CoAP আলোচনার বাইরে নিয়ে যায় এবং একটি কঠিন প্রশ্নের দিকে ঠেলে দেয়: কোন প্রোটোকল এবং প্ল্যাটফর্মগুলো ডিভাইস আইডেন্টিটি, সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্ট এবং লিস্ট-প্রিভিলেজ অ্যাক্সেস কার্যকর করা সহজ করে তোলে? এই কমপ্লায়েন্স দিকটি প্রায়শই সাধারণ প্রোটোকল আলোচনায় বাদ পড়ে যায়, তবে IoT সিকিউরিটি এবং পলিসি প্রয়োজনীয়তার এই পর্যালোচনায় আলোচিত যুক্তরাজ্যের প্রেক্ষাপটে এটি অত্যন্ত গুরুত্বপূর্ণ।
ডিফল্ট ক্রেডেনশিয়াল, শেয়ার্ড প্রি-শেয়ার্ড কী এবং ফ্ল্যাট নেটওয়ার্ক ট্রাস্ট মাল্টি-ইউজার ভেন্যুতে ভালোভাবে স্কেল করে না। এগুলো ইনসিডেন্ট রেসপন্সকেও কঠিন করে তোলে। যদি একজন ইনস্টলার একটি সাধারণ কী জানে, অথবা একটি ভাড়াটে-নিয়ন্ত্রিত ডিভাইস ব্যাপক অ্যাক্সেস শেয়ার করে, তবে কনটেইনমেন্ট করা প্রয়োজনের চেয়ে বেশি কঠিন হয়ে পড়ে।
প্রোটোকল বিশুদ্ধতার চেয়ে আইডেন্টিটি কেন বেশি গুরুত্বপূর্ণ
একটি সুরক্ষিত IoT ডিজাইনের প্রতিটি ডিভাইসের জন্য চারটি প্রশ্নের পরিষ্কার উত্তর দেওয়া প্রয়োজন:
- আপনি কে?
- আপনাকে কীভাবে অনবোর্ড করা হয়েছে?
- আপনার কী অ্যাক্সেস করার অনুমতি আছে?
- আমি কীভাবে কোনো ব্যাঘাত ছাড়াই ট্রাস্ট বাতিল বা রোটেট করব?
সেজন্যই সার্টিফিকেট-ভিত্তিক অথেনটিকেশন সাধারণত গুরুতর এন্টারপ্রাইজ এস্টেটের জন্য শেয়ার্ড সিক্রেটের চেয়ে বেশি গ্রহণযোগ্য। এটি প্রতি ডিভাইসে অনন্য আইডেন্টিটি, পরিষ্কারভাবে অ্যাক্সেস বাতিলকরণ এবং জিরো-ট্রাস্ট পলিসির সাথে অনেক ভালো সামঞ্জস্য সমর্থন করে।
ঐতিহ্যগত WiFi অ্যাক্সেস কন্ট্রোলে অভ্যস্ত টিমগুলোর জন্য, একটি RADIUS সার্ভার কী তা বোঝা সাহায্য করে কারণ ডিভাইসের জন্য আইডেন্টিটি-ভিত্তিক অ্যাক্সেস এখনও সুশৃঙ্খল অথেনটিকেশন এবং পলিসি প্রয়োগের উপর নির্ভর করে, এমনকি যখন এন্ডপয়েন্টটি ল্যাপটপসহ কোনো ব্যক্তি না হয়।
Shared credentials IoT-কে ডেপ্লয়মেন্টের সময় সহজ করে তোলে এবং এর বাকি কর্মজীবনের জন্য ব্যয়বহুল করে তোলে।
এন্টারপ্রাইজ টিমগুলোর যে প্ল্যাটফর্ম সংক্রান্ত প্রশ্নটি জিজ্ঞাসা করা উচিত
কেবল একটি প্রোটোকল এনক্রিপশন সমর্থন করে কিনা তা জিজ্ঞাসা করবেন না। আপনার প্ল্যাটফর্ম ডিভাইস আইডেন্টিটিকে পলিসি, ডিরেক্টরি লজিক, সেগমেন্টেশন এবং লাইফসাইকেল কন্ট্রোলের সাথে সংযুক্ত করতে পারে কিনা তা জিজ্ঞাসা করুন।
মিশ্র এস্টেটে, এর সাথে ব্রোকার, গেটওয়ে, NAC টুলিং, PKI এবং WiFi অনবোর্ডিং সিস্টেম একসঙ্গে কাজ করতে পারে। সেই বৃহত্তর আইডেন্টিটি লেয়ারের একটি বিকল্প হলো Purple, যা পাসওয়ার্ডহীন অ্যাক্সেস, সার্টিফিকেট-গ্রেড অনবোর্ডিং ফ্লো এবং স্টাফ ও মাল্টি-টেন্যান্ট এনভায়রনমেন্টের জন্য Entra ID, Google Workspace এবং Okta-র মতো আইডেন্টিটি সিস্টেমের সাথে ইন্টিগ্রেশন সমর্থন করে। উদ্দেশ্য কোনো একটি প্রোটোকলকে জোর করে চাপিয়ে দেওয়া নয়। এটি হলো বিভিন্ন ডিভাইস এবং ব্যবহারকারীকে একটি সামঞ্জস্যপূর্ণ ট্রাস্ট ফ্রেমওয়ার্ক প্রদান করা।
এটি বিশেষ করে এমন সেক্টরগুলোতে গুরুত্বপূর্ণ হয়ে ওঠে যেখানে ব্যর্থতার অপারেশনাল খরচ অনেক বেশি। স্বাস্থ্যসেবা এর একটি স্পষ্ট উদাহরণ। আপনি যদি একটি বৃহত্তর ইন্ডাস্ট্রির দৃষ্টিভঙ্গি চান, তবে IoT in medical -এর ওপর এই লেখাটি দরকারী কারণ মেডিকেল এনভায়রনমেন্টগুলো ঠিক দেখায় কেন আইডেন্টিটি, সেগমেন্টেশন এবং নিয়ন্ত্রিত অ্যাক্সেস কেবল র-কানেক্টিভিটির চেয়ে বেশি গুরুত্বপূর্ণ।
আপনার সুসংহত IoT স্ট্র্যাটেজি তৈরি করা
IoT-র জন্য প্রোটোকলে একক কোনো সেরা উত্তর নেই। এখানে কিছু ট্রেড-অফ রয়েছে এবং ভালো আর্কিটেকচার আসে সেই ট্রেড-অফগুলোকে কাজের সাথে মিলিয়ে নেওয়ার মাধ্যমে।
দরকারী প্যাটার্নটি সহজ। একটি লেয়ার্ড মডেল ব্যবহার করুন যাতে আপনার টিম বুঝতে পারে তারা অ্যাপ্লিকেশন বিহেভিয়ার, ট্রান্সপোর্ট, অ্যাড্রেসিং নাকি ফিজিক্যাল কানেক্টিভিটি নিয়ে আলোচনা করছে। ডিভাইসগুলো সীমাবদ্ধ হলে লাইটওয়েট মেসেজিং বেছে নিন। ল্যাবের জন্য নয়, বরং প্রকৃত বিল্ডিং বা এস্টেটের জন্য সঠিক লিঙ্ক টেকনোলজি বেছে নিন। যে ডিভাইসগুলোর সত্যিই প্রয়োজন, সেগুলোর জন্য আরও সমৃদ্ধ প্রোটোকল রাখুন।
একটি পরিপক্ক এন্টারপ্রাইজ অ্যাপ্রোচ দেখতে কেমন হয়
একটি শক্তিশালী IoT স্ট্র্যাটেজিতে সাধারণত অন্তর্ভুক্ত থাকে:
- একটি জোরপূর্বক স্ট্যান্ডার্ডের পরিবর্তে বিভিন্ন ডিভাইস ক্লাসের জন্য বিভিন্ন প্রোটোকল
- একটি সাধারণ অনবোর্ডিং এবং পলিসি মডেল, যাতে অপারেশনগুলো বিভক্ত না হয়ে যায়
- কেবল VLAN অভ্যাসের মাধ্যমে নয়, বরং ভূমিকা এবং ঝুঁকি অনুসারে সেগমেন্টেশন
- আইডেন্টিটি-ফার্স্ট সিকিউরিটি, যাতে প্রতিটি ডিভাইসকে পরিষ্কারভাবে অথেন্টিকেট, অথরাইজ এবং রিভোক করা যায়
এটাই সেন্সর এবং স্মার্ট এন্ডপয়েন্টগুলোর একটি বিশৃঙ্খল সংগ্রহকে একটি পরিচালনাযোগ্য প্ল্যাটফর্মে রূপান্তরিত করে।
সবচেয়ে বড় পরিবর্তনটি হলো মানসিকতায়। IoT-কে নেটওয়ার্কিংয়ের ব্যতিক্রম হিসেবে বিবেচনা করা বন্ধ করুন। এটিকে আপনার আইডেন্টিটি এবং অ্যাক্সেস এস্টেটের অংশ হিসেবে বিবেচনা করুন। টিমগুলো যখন এটি করে, তখন প্রোটোকল নির্বাচন সহজ হয়, অনবোর্ডিং নিরাপদ হয় এবং দীর্ঘমেয়াদী সাপোর্ট অনেক বেশি অনুমানযোগ্য হয়ে ওঠে।
আপনি যদি অতিথি, কর্মী এবং IoT পরিবেশের মধ্যে সংযুক্ত ডিভাইসগুলি কীভাবে প্রমাণীকরণ করে তা পর্যালোচনা করে থাকেন, তবে আইডেন্টিটি লেয়ারের অংশ হিসেবে Purple মূল্যায়ন করার মতো। এটি এন্টারপ্রাইজ টিমগুলোকে একাধিক ব্যবহারকারীর ভেন্যু এবং মিশ্র ডিভাইস এস্টেট জুড়ে শেয়ার করা পাসওয়ার্ড এবং খণ্ডিত অনবোর্ডিং-এর পরিবর্তে পলিসি-চালিত, পাসওয়ার্ডহীন অ্যাক্সেস ব্যবহারের সুবিধা দেয়।
