নির্দোষতা প্রমাণের গড় সময়: কীভাবে প্রমাণ করবেন যে এটি WiFi-এর সমস্যা নয়

আত্মবিশ্বাসী, কর্তৃত্বপূর্ণ এবং কথোপকথনের সুরে কথা বলুন - যেমন একজন সিনিয়র নেটওয়ার্ক কনসালট্যান্ট কফি খেতে খেতে কোনো ক্লায়েন্টকে ব্রিফ করছেন। পরিমিত গতি, স্পষ্ট উচ্চারণ, মাঝে মাঝে সূক্ষ্ম রসিকতা। কোনো লেকচার নয়। কোনো সেলস পিচ নয়। কেবল এমন একজনের কাছ থেকে সরাসরি কথা যিনি এই সমস্যাটি শতবার দেখেছেন: Purple-এর টেকনিক্যাল ব্রিফে আপনাকে স্বাগত জানাই। আজ আমি আপনাদের সাথে এমন একটি বিষয় নিয়ে কথা বলতে যাচ্ছি যা প্রতিটি নেটওয়ার্ক ম্যানেজার মনেপ্রাণে জানেন, এমনকি তারা যদি এর আনুষ্ঠানিক নামটি নাও শুনে থাকেন। নির্দোষতা প্রমাণের গড় সময়। বা MTTI। [সামান্য বিরতি] যে সময়টি আপনি প্রমাণ করতে ব্যয় করেন যে এটি আপনার ভুল নয়। পরিস্থিতিটি কল্পনা করুন। সকাল নয়টা বাজে। একটি বিল্ড-টু-রেন্ট ব্লকের বাসিন্দারা ফ্রন্ট ডেস্কে কল করা শুরু করেছেন। WiFi কাজ করছে না। প্রপার্টি ম্যানেজার ম্যানেজড WiFi প্রদানকারীকে কল করেন। ম্যানেজড WiFi প্রদানকারী আইএসপি-কে কল করেন। আইএসপি বলে রাউটার পরীক্ষা করতে। রাউটার টিম বলে অ্যাক্সেস পয়েন্টগুলো পরীক্ষা করতে। অ্যাক্সেস পয়েন্ট ভেন্ডর বলে ক্লায়েন্ট ডিভাইসগুলো পরীক্ষা করতে। আর এই সবকিছুর মাঝে পঁয়তাল্লিশ মিনিট কেটে গেছে, এবং কেউ আসলে কিছুই সমাধান করেনি। ঠিক এটাই হলো বাস্তবে নির্দোষতা প্রমাণের গড় সময়। [সামান্য বিরতি] আর এটি আপনার ধারণার চেয়েও বেশি ক্ষতি করছে। আমাকে এটি সঠিকভাবে সংজ্ঞায়িত করতে দিন। নির্দোষতা প্রমাণের গড় সময় হলো একটি সমস্যা শনাক্ত হওয়ার পর থেকে যেকোনো নির্দিষ্ট টিমের প্রমাণ সহ এটি প্রদর্শন করতে পারার গড় সময় যে, তাদের ডোমেনটি মূল কারণ নয়। এটি শনাক্তকরণের গড় সময়ের মতো নয়, যা প্রকৃত মূল কারণ খুঁজে বের করার জন্য প্রতিষ্ঠান-ব্যাপী মেট্রিক। MTTI হলো একটি সীমাবদ্ধ গণ্ডি। এটি ব্যক্তিগত। এটি নেটওয়ার্ক টিমের পক্ষ থেকে বলা যে, এই যে ডেটা, এটি আমাদের সমস্যা নয়, এখন অন্য কোথাও খুঁজুন। সমস্যা হলো সঠিক টুলিং ছাড়া এই প্রমাণ দিতে সময় লাগে। আর MTTI-এর প্রতিটি মিনিট সরাসরি আপনার সমাধানের গড় সময় অর্থাৎ MTTR-এর সাথে যুক্ত হয়। এই দুটি অবিচ্ছেদ্য। তাহলে কেন সবসময় প্রথমে WiFi-কে দোষারোপ করা হয়? [সামান্য বিরতি] তিনটি কারণ। প্রথমত, WiFi দৃশ্যমান। যখন কোনো কিছু ভেঙে পড়ে, মানুষ যে জিনিসটি দেখতে পায় সেটির দিকে তাকায়, আর তাদের ফোনের WiFi সিগন্যাল বারগুলো হলো সংযোগের সবচেয়ে দৃশ্যমান সূচক। দ্বিতীয়ত, WiFi হলো ডিভাইসের আগের শেষ হপ, তাই কোনো ডিভাইস ইন্টারনেটে পৌঁছাতে না পারলে প্রথমে এটিকেই সন্দেহজনক মনে হয়। তৃতীয়ত, এবং এটি বেশ অস্বস্তিকর, ওয়্যারলেস টিমগুলো প্রায়শই দ্রুত নির্দোষতা প্রমাণ করতে পারে না কারণ তাদের কাছে সঠিক টেলিমেট্রি থাকে না। আপনি যদি দুই মিনিটেরও কম সময়ে ওয়্যারলেস লেয়ারের সচল থাকার প্রমাণ দেখাতে না পারেন, তবে আপনাকে পরবর্তী এক ঘণ্টা নিজেকে রক্ষা করতেই ব্যয় করতে হবে। এখন, একটি একক-টেন্যান্ট এন্টারপ্রাইজ পরিবেশে এটি বিরক্তিকর। কিন্তু একটি মাল্টি-টেন্যান্ট পরিবেশে এটি সত্যিই ক্ষতিকারক। প্রিমিয়ার ইন (Premier Inn)-এর মতো একটি হোটেল, বা একটি বিল্ড-টু-রেন্ট আবাসিক ব্লক, অথবা ব্যাক-টু-ব্যাক ইভেন্ট চলাকালীন কোনো কনফারেন্স সেন্টারের কথা চিন্তা করুন। আপনার কাছে একজন প্রপার্টি ম্যানেজার আছেন যিনি নেটওয়ার্কের মালিক নন। আপনার কাছে এমন বাসিন্দা বা অতিথি আছেন যারা নেটওয়ার্ক বোঝেন না। এবং আপনার কাছে একজন ম্যানেজড WiFi প্রদানকারী আছেন যিনি ওয়্যারলেস লেয়ারের জন্য দায়ী কিন্তু আইএসপি সার্কিট, ভবনের ভেতরের ক্যাবলিং বা ক্লায়েন্ট ডিভাইসের জন্য দায়ী নন। যখন কোনো কিছু কাজ করে না, প্রপার্টি ম্যানেজার WiFi প্রদানকারীকে দোষারোপ করেন কারণ সেই চুক্তির দিকেই তারা আঙুল তুলতে পারেন। বাসিন্দা ভবন কর্তৃপক্ষকে দোষারোপ করেন কারণ তারা তাদের ভাড়া দেন। আর WiFi প্রদানকারীকে দ্রুত নেটওয়ার্কটিকে নির্দোষ প্রমাণ করতে হয়, অন্যথায় সম্পর্কের অবনতি ঘটে। [সামান্য বিরতি] এই প্রসঙ্গে MTTI কেবল একটি প্রযুক্তিগত মেট্রিক নয়। এটি একটি বাণিজ্যিক মেট্রিকও বটে। তাহলে চলুন সেই পদ্ধতি সম্পর্কে কথা বলি যা আসলে এটিকে সংক্ষিপ্ত করে। এখানে পাঁচটি স্তর রয়েছে এবং আপনার পাঁচটিই প্রয়োজন। প্রথম স্তর: অবিচ্ছিন্ন সিন্থেটিক চেক। কোনো টিকিট তৈরি করার আগেই, আপনার নেটওয়ার্কের এজ থেকে স্বয়ংক্রিয় প্রোব চালানো উচিত, যা DNS রেজোলিউশন, HTTP রিচিবিলিটি, পরিচিত এন্ডপয়েন্টগুলোর লেটেন্সি এবং অথেন্টিকেশন ফ্লো পরীক্ষা করবে। Juniper Mist-এর Marvis বা ThousandEyes-এর মতো প্ল্যাটফর্মে বিল্ট-ইন সিন্থেটিক টেস্টিং প্রতি কয়েক মিনিটে এই চেকগুলো চালায়। যখন কোনো সমস্যা ঘটে, আপনি একটি গ্রাফ টেনে দেখাতে পারেন যে ঠিক কখন WiFi লেয়ারটিতে শেষবার একটি সফল সিন্থেটিক চেক হয়েছিল এবং অভিযোগের সময় এটি সচল ছিল নাকি ধীরগতির ছিল। এটি একাই MTTI-কে নাটকীয়ভাবে কমিয়ে দেয়, কারণ আপনি হয় নিশ্চিত করেন যে WiFi সচল ছিল, অথবা নিশ্চিত করেন যে এটি ছিল না, এবং এটি নিয়ে তর্ক করা বন্ধ করেন। দ্বিতীয় স্তর: হপ-বাই-হপ পাথ ভিজিবিলিটি। এখানেই বেশিরভাগ টিম ব্যর্থ হয়। আপনি প্রমাণ করতে পারেন যে অ্যাক্সেস পয়েন্টটি সচল আছে। আপনি প্রমাণ করতে পারেন যে সুইচটি সচল আছে। কিন্তু আপনি কি প্রমাণ করতে পারেন যে সুইচ থেকে আইএসপি হ্যান্ডঅফ পর্যন্ত পথটি সচল আছে? একটি মাল্টি-টেন্যান্ট ভবনে প্রায়শই এমন হপ থাকে যা আপনার মালিকানাধীন নয়। ভবনের ভেতরের ডিস্ট্রিবিউশন নেটওয়ার্ক, ল্যান্ডলর্ডের কোর সুইচ, আইএসপি-র সীমানা পয়েন্ট। আপনার এমন পাথ ট্রেস ডেটা প্রয়োজন যা এই সীমানাগুলো অতিক্রম করে। কেবল ৮.৮.৮.৮-এ একটি পিং নয়। প্রকৃত ট্রেসরুট-স্টাইল ভিজিবিলিটি যা আপনাকে প্রতিটি হপ, এর লেটেন্সি এবং এটি প্যাকেট ড্রপ করছে কিনা তা দেখায়। যখন আপনি দেখাতে পারেন যে এক থেকে চার নম্বর হপগুলো সচল আছে এবং পাঁচ নম্বর হপটি, যা আইএসপি-র এজ রাউটার, সেটি চল্লিশ শতাংশ প্যাকেট লস দেখাচ্ছে, তখন আলোচনার মোড় তাৎক্ষণিকভাবে ঘুরে যায়। তৃতীয় স্তর: অন-ডিমান্ড প্যাকেট ক্যাপচার সহ ফ্লো ডেটা। NetFlow এবং IPFIX আপনাকে নেটওয়ার্কে কীসের সাথে কীসের কথা হচ্ছে তার একটি কথোপকথন-স্তরের দৃশ্য প্রদান করে। যখন একজন বাসিন্দা বলেন যে স্ট্রিমিং পরিষেবাটি কাজ করছে না, ফ্লো ডেটা আপনাকে বলে যে সেই পরিষেবার IP রেঞ্জে ট্রাফিকটি আদৌ নেটওয়ার্ক থেকে বের হচ্ছে কিনা। যদি এটি সফলভাবে নেটওয়ার্ক থেকে বের হয় এবং সমস্যাটি ডাউনস্ট্রিমে থাকে, তবে সেটিই আপনার প্রমাণ। যদি এটি আদৌ নেটওয়ার্ক থেকে বের না হয়, তবে আপনি জানি কোথায় খুঁজতে হবে। Cisco Meraki এবং HPE Aruba-এর মতো প্ল্যাটফর্মে উপলব্ধ অন-ডিমান্ড প্যাকেট ক্যাপচার আপনাকে হার্ডওয়্যার স্পর্শ না করেই একটি নির্দিষ্ট ক্লায়েন্ট বা VLAN-এর জন্য একটি লক্ষ্যযুক্ত ক্যাপচার করার সুবিধা দেয়। এটি হলো আপনার ফরেনসিক স্তর। আপনি এটি খুব কমই ব্যবহার করবেন, তবে যখন প্রয়োজন হবে, এটিই হবে চূড়ান্ত প্রমাণ। চতুর্থ স্তর: টপোলজি এবং ডিপেন্ডেন্সি ম্যাপিং। একটি মাল্টি-টেন্যান্ট পরিবেশে, আপনার একটি লাইভ ম্যাপ প্রয়োজন যা দেখায় কোন অ্যাক্সেস পয়েন্টগুলো কোন টেন্যান্টদের পরিষেবা দিচ্ছে, সেই AP-গুলো কোন সুইচের সাথে সংযুক্ত, সেই সুইচগুলো কোন আপলিঙ্ক ব্যবহার করে এবং কোন আইএসপি সার্কিট প্রতিটি আপলিঙ্ককে পরিষেবা দেয়। যখন কোনো সমস্যা ঘটে, আপনি অবিলম্বে ব্লাস্ট রেডিয়াস বা প্রভাবের পরিধি শনাক্ত করতে পারেন। এটি কি একজন টেন্যান্টকে প্রভাবিত করছে নাকি সমস্ত টেন্যান্টকে? একটি ফ্লোর নাকি পুরো ভবন? একটি VLAN নাকি সমস্ত VLAN? টপোলজি ম্যাপ থেকে ত্রিশ সেকেন্ডের মধ্যে উত্তর দেওয়া এই স্কোপিং প্রশ্নটি আপনাকে বলে দেয় যে সমস্যাটি WiFi লেয়ারে, ভবনের নেটওয়ার্কে নাকি WAN-এ রয়েছে। এটি আপনাকে এটিও বলে দেয় যে কাকে যুক্ত করতে হবে এবং কাকে আপনি অবিলম্বে বাদ দিতে পারেন। পঞ্চম স্তর: ইভেন্ট কোরিলেশন। এটিই সবকিছুকে একসাথে বেঁধে রাখে। চেঞ্জ লগ, আইএসপি রক্ষণাবেক্ষণের অ্যালার্ট, ডিভাইসের ফার্মওয়্যার আপডেট, পাওয়ার ইভেন্ট এবং ব্যবহারকারীর অভিযোগ—সবকিছুই একই টাইমলাইনে থাকা প্রয়োজন। যখন আপনি ক্লায়েন্ট অ্যাসোসিয়েশন ব্যর্থতার একটি স্পাইকের সাথে বারো মিনিট আগে হওয়া একটি ফার্মওয়্যার পুশ ওভারলে করবেন, তখন আপনি আপনার মূল কারণটি পেয়ে যাবেন। যখন আপনি একটি লেটেন্সি স্পাইকের সাথে একটি আইএসপি রক্ষণাবেক্ষণের উইন্ডো ওভারলে করবেন যা আপনাকে জানানো হয়নি, তখন আপনার কাছে এস্কেলেশনের জন্য প্রমাণ থাকবে। ইভেন্ট কোরিলেশন খুব আকর্ষণীয় কিছু নয়, তবে এটি একটি পঁয়তাল্লিশ মিনিটের দোষারোপের খেলা এবং চার মিনিটের নির্দোষতা প্রমাণের মধ্যে পার্থক্য তৈরি করে। এখন, সাংস্কৃতিক দিকটি নিয়ে একটি কথা বলা যাক, কারণ এখানেই অনেক টিম ভুল করে। MTTI হ্রাস করার লক্ষ্য দোষারোপের খেলায় দ্রুত জয়ী হওয়া নয়। এটি হলো দোষারোপের খেলাটি সম্পূর্ণভাবে বন্ধ করা। [সামান্য বিরতি] যৌথ প্রমাণ পরিস্থিতি বদলে দেয়। যখন WiFi প্রদানকারী প্রপার্টি ম্যানেজারকে একটি ড্যাশবোর্ডের লিঙ্ক পাঠাতে পারেন যা ওয়্যারলেস লেয়ারে সবুজ, ভবনের ভেতরের সুইচে হলুদ এবং আইএসপি সার্কিটে লাল দেখায়, তখন আলোচনাটি আর বৈরী থাকে না। এটি সহযোগিতামূলক হয়ে ওঠে। প্রপার্টি ম্যানেজার আইএসপি-কে কল করেন। আইএসপি সার্কিটটি ঠিক করে। বাসিন্দারা সংযোগ ফিরে পান। এবং WiFi প্রদানকারীর চুক্তিটি নবায়ন করা হয় কারণ তারাই সমস্যাটি খুঁজে পেয়েছিলেন। এটিই হলো অবজারভেবিলিটি টুলিংয়ে বিনিয়োগ করার বাণিজ্যিক কারণ। কেবল দ্রুত সমস্যা সমাধান নয়, বরং যারা আপনাকে অর্থ প্রদান করছেন তাদের সাথে আরও ভালো সম্পর্ক তৈরি করা। আসুন বিষয়টিকে আরও স্পষ্ট করতে কয়েকটি দ্রুত পরিস্থিতি দেখে নেওয়া যাক। প্রথম পরিস্থিতি: একটি ৩৫০-রুমের হোটেল। প্রিমিয়ার ইন-স্টাইল প্রপার্টির অতিথিরা রিপোর্ট করতে শুরু করেন যে ইন-রুম WiFi ধীরগতির। ফ্রন্ট ডেস্ক ম্যানেজড WiFi প্রদানকারীর কাছে একটি টিকিট লগ করে। সিন্থেটিক চেক চালু থাকায়, প্রদানকারী দেখতে পান যে সকাল সাতটা তেতাল্লিশ মিনিটে DNS রেজোলিউশনের সময় বারো মিলিসেকেন্ড থেকে চারশত মিলিসেকেন্ডে পৌঁছেছে। WiFi লেয়ারটি সচল আছে। পাথ ট্রেস দেখায় যে লেটেন্সিটি তৃতীয় হপে তৈরি হচ্ছে, যা আইএসপি-র অ্যাগ্রিগেশন রাউটার। প্রদানকারী হোটেল ম্যানেজারকে পাথ ট্রেসের একটি স্ক্রিনশট পাঠান যেখানে ত্রুটিপূর্ণ হপটি লাল রঙে চিহ্নিত করা হয়েছে, পাশাপাশি সিন্থেটিক চেক গ্রাফটি দেখায় যে পুরো সময়জুড়ে WiFi লেয়ারটি সচল ছিল। আইএসপি-কে কল করা হয়। আইএসপি তাদের দিকে একটি রাউটিং সমস্যা নিশ্চিত করে। অভিযোগ থেকে WiFi লেয়ারের নির্দোষতা প্রমাণ করার মোট সময়: can ছয় মিনিট। সম্পূর্ণ ঘটনার জন্য MTTR: বাইশ মিনিট, কারণ আইএসপি-র সমাধান করতে ষোলো মিনিট সময় লেগেছিল। অবজারভেবিলিটি টুলিং ছাড়া, সেই can ছয় মিনিটের নির্দোষতা প্রমাণ করতে চল্লিশ মিনিটের পারস্পরিক তর্ক চলত এবং MTTR এক ঘণ্টারও বেশি হতো। দ্বিতীয় পরিস্থিতি: একটি রিটেইল চেইন। দুইশত স্টোর জুড়ে WiFi থাকা একটি জাতীয় খুচরা বিক্রেতা প্রতিষ্ঠান লক্ষ্য করে যে একটি নির্দিষ্ট অঞ্চলের পয়েন্ট-অফ-সেল টার্মিনালগুলো পেমেন্ট প্রসেসরের সাথে মাঝে মাঝে সংযোগ হারিয়ে ফেলছে। নেটওয়ার্ক টিমকে অবিলম্বে দোষারোপ করা হয়। ফ্লো ডেটা দেখায় যে পেমেন্ট প্রসেসরের IP রেঞ্জের ট্রাফিক সফলভাবে স্টোর নেটওয়ার্ক থেকে বের হচ্ছে। সমস্যাটি নেটওয়ার্কের নয়। পেমেন্ট প্রসেসর VLAN-এ একটি প্যাকেট ক্যাপচার দেখায় যে TCP রিট্রান্সমিশন স্পাইক করছে, যা পেমেন্ট প্রসেসরের সার্ভার-সাইডের সমস্যার দিকে ইঙ্গিত করে। নেটওয়ার্ক টিম ফ্লো ডেটা এবং ক্যাপচার সামারি পেমেন্ট প্রসেসরের সাপোর্ট টিমের সাথে শেয়ার করে। পেমেন্ট প্রসেসর তাদের দিকে একটি ভুল কনফিগার করা লোড ব্যালেন্সার শনাক্ত করে। নেটওয়ার্ক টিমের MTTI: আট মিনিট। পেমেন্ট প্রসেসরের সমাধানের সময়: পঁয়ত্রিশ মিনিট। ফ্লো ডেটা ছাড়া, নেটওয়ার্ক টিম সেই পঁয়ত্রিশ মিনিট নিখুঁতভাবে কাজ করা VLAN-গুলো পুনরায় কনফিগার করতে এবং সুইচগুলো রিবুট করতে ব্যয় করত। ঠিক আছে। এই বিষয়ে আমাকে প্রায়শই জিজ্ঞাসা করা মূল প্রশ্নগুলোর দ্রুত উত্তর দেওয়া যাক। এটি কি WiFi নাকি ডিভাইসের সমস্যা? AP থেকেই একটি সিন্থেটিক চেক চালান। যদি AP সফলভাবে ইন্টারনেটে পৌঁছাতে পারে এবং ডিভাইসটি না পারে, তবে এটি ডিভাইসের সমস্যা। যদি AP ইন্টারনেটে পৌঁছাতে না পারে, তবে এটি ডিভাইসের আপস্ট্রিমের সমস্যা। এটি কি WiFi নাকি আইএসপি-র সমস্যা? ইন্টারনেটে পাথ ট্রেস করুন। যদি লেটেন্সি বা প্যাকেট লস আপনার নেটওয়ার্ক সীমানার বাইরের কোনো হপে ঘটে, তবে এটি আইএসপি-র সমস্যা। MTTI এবং শনাক্তকরণের গড় সময়ের মধ্যে পার্থক্য কী? MTTI হলো আপনার টিমের নির্দোষতা প্রমাণ করার সময়। শনাক্তকরণের গড় সময় হলো প্রকৃত অপরাধীকে খুঁজে বের করার জন্য প্রতিষ্ঠানের সময়। MTTI হলো শনাক্তকরণের গড় সময়ের একটি সাবসেট। নতুন টুল না কিনে আমি কীভাবে MTTI কমাতে পারি? আপনার যা আছে তা দিয়েই শুরু করুন। Cisco Meraki, HPE Aruba এবং Juniper Mist সহ বেশিরভাগ এন্টারপ্রাইজ অ্যাক্সেস পয়েন্ট প্ল্যাটর্মে বিল্ট-ইন সিন্থেটিক টেস্টিং এবং ক্লায়েন্ট ডায়াগনস্টিকস রয়েছে। সেগুলো ব্যবহার করুন। আপনার টপোলজি ডকুমেন্ট করুন। একটি শেয়ার্ড ড্যাশবোর্ড তৈরি করুন যা প্রপার্টি ম্যানেজার বা অপারেশন টিম দেখতে পারে। স্বচ্ছতা হলো সবচেয়ে সাশ্রয়ী উপায়ে MTTI কমানোর হাতিয়ার। উপসংহারে বলা যায়। নির্দোষতা প্রমাণের গড় সময় হলো প্রতিটি নেটওয়ার্ক সমস্যার একটি লুকানো কর। মাল্টি-টেন্যান্ট পরিবেশে, যেখানে জবাবদিহিতা প্রদানকারী, ল্যান্ডলর্ড এবং আইএসপি-দের মধ্যে বিভক্ত, এটি এমন একটি মেট্রিক যা নির্ধারণ করে যে আপনি চুক্তিগুলো ধরে রাখবেন নাকি হারাবেন। এটি হ্রাস করার পদ্ধতিটি জটিল নয়: সিন্থেটিক চেক, পাথ ভিজিবিলিটি, ফ্লো ডেটা, টপোলজি ম্যাপিং এবং ইভেন্ট কোরিলেশন। লক্ষ্য দোষারোপের খেলায় জয়ী হওয়া নয়। এটি হলো দোষারোপের খেলাটিকে যৌথ প্রমাণ দিয়ে প্রতিস্থাপন করা, যাতে প্রতিটি টিম তাদের নিজেদের রক্ষা করার পরিবর্তে সমস্যাটি সমাধানের দিকে মনোনিবেশ করতে পারে। [সামান্য বিরতি] কারণ নির্দোষতা প্রমাণ করতে ব্যয় করা প্রতিটি মিনিট হলো আপনার বাসিন্দা, অতিথি বা ক্রেতাদের সংযোগহীন থাকার সময়ের সাথে যুক্ত হওয়া অতিরিক্ত মিনিট। আর এটাই হলো সেই সংখ্যা যা আসলে গুরুত্বপূর্ণ। can শোনার জন্য ধন্যবাদ। আপনি যদি দেখতে চান কীভাবে Purple-এর মাল্টি-টেন্যান্ট WiFi প্ল্যাটফর্ম ৮০,০০০-এরও বেশি লাইভ ভেন্যুতে এই ধরণের অবজারভেবিলিটি ডেটা প্রদর্শন করে, তবে purple dot ai-তে যান।