नवीन Access Points न खरेदी करता WiFi स्पीड कशी सुधारावी

नवीन access points न खरेदी करता WiFi चा वेग कसा सुधारावा एक Purple Technical Briefing - अंदाजे १० मिनिटे --- परिचय आणि संदर्भ (अंदाजे १ मिनिट) --- Purple Technical Briefing मालिकेत आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण एका अत्यंत सामान्य विषयावर चर्चा करत आहोत ज्याबद्दल मी एंटरप्राइझ स्थळांवरील आयटी डायरेक्टर्स आणि CTOs सोबत वारंवार बोलतो - तो म्हणजे WiFi क्षमता समस्या. तुमचे हॉटेल, रिटेल इस्टेट, कॉन्फरन्स सेंटर किंवा स्टेडियम असू शकते. तुमचे पाहुणे आणि कर्मचारी संथ WiFi बद्दल तक्रार करत आहेत. तुमची पहिली प्रतिक्रिया - आणि प्रामाणिकपणे सांगायचे तर, ज्यावर तुमचा इन्फ्रास्ट्रक्चर विक्रेता अवलंबून असतो - ती म्हणजे अधिक access points खरेदी करणे. नवीन हार्डवेअर, मोठे डिप्लॉयमेंट, मोठे इनव्हॉइस. पण खरी गोष्ट ही आहे. मी पुनरावलोकन केलेल्या बहुतांश प्रकरणांमध्ये, समस्या access points ची अजिबात नसते. समस्या त्यांच्यामधून काय चालले आहे याबद्दल असते. आणि ती एक सॉफ्टवेअरची समस्या आहे, ज्याचा अर्थ त्याचा उपाय देखील सॉफ्टवेअरमध्येच आहे. आज मी तुम्हाला नेमके हेच सांगणार आहे की DNS filtering आणि सॉफ्टवेअर-लेअर ऑप्टिमायझेशन कसे तुमच्या विद्यमान बँडविड्थपैकी तीस टक्के किंवा त्याहून अधिक भाग परत मिळवू शकते - तेही एकाही हार्डवेअरला स्पर्श न करता. आम्ही याचे तांत्रिक आर्किटेक्चर, प्रत्यक्ष डिप्लॉयमेंटच्या परिस्थिती आणि तुम्ही तुमच्या CFO कडे मांडू शकता असा बिझनेस केस या विषयांचा समावेश करणार आहोत. चला तर मग, सुरुवात करूया. --- तांत्रिक सखोल विश्लेषण (अंदाजे ५ मिनिटे) --- प्रथम, मुख्य समस्या समजून घेऊया. जेव्हा तुम्ही सामान्य एंटरप्राइझ गेस्ट WiFi नेटवर्कवर प्रत्यक्षात बँडविड्थ कशामुळे वापरली जात आहे हे पाहता, तेव्हा त्याचे वर्गीकरण बहुतांश लोकांसाठी खरोखरच आश्चर्यकारक असते. जाहिरात नेटवर्क्स आणि थर्ड-पार्टी ट्रॅकर्स - म्हणजे प्रत्येक डिव्हाइसवरील प्रत्येक ॲप सतत पाठवत असलेला पार्श्वभूमीतील टेलिमेट्री डेटा - हे सामान्य गेस्ट नेटवर्कवरील DNS क्वेरीच्या एकूण प्रमाणापैकी पंचवीस ते चाळीस टक्क्यांच्या दरम्यान असतात. या अशा विनंत्या नाहीत ज्या तुमचे पाहुणे जाणूनबुजून करत आहेत. त्या स्वयंचलित असतात. जेव्हा जेव्हा कोणी त्यांच्या फोनवर न्यूज ॲप, सोशल मीडिया प्लॅटफॉर्म किंवा रिटेल ॲप उघडते, तेव्हा ते ॲप जाहिरात सर्व्हर्स, ॲनालिटिक्स प्लॅटफॉर्म आणि ट्रॅकिंग पिक्सल्सना डझनभर DNS लुकअप्स पाठवत असते. या ट्रॅफिकपैकी काहीही तुमच्या पाहुण्यांना मूल्य देत नाही. पण हे सर्व तुमच्या अपलिंक क्षमतेचा वापर करत असते. त्यावर भर म्हणून, तुमच्याकडे मालवेअर आणि बॉटनेत ट्रॅफिक देखील असते. तडजोड केलेली डिव्हाइसेस - आणि मोठ्या गेस्ट नेटवर्कवर तुमच्याकडे अशी तडजोड केलेली डिव्हाइसेस नक्कीच असणार - कमांड-अँड-कंट्रोल सर्व्हर्सना सतत संपर्क साधण्याचा प्रयत्न करत असतात. हे ट्रॅफिक केवळ बँडविड्थ वाया घालवत नाही, तर ते अनुपालन (compliance) आणि सुरक्षेचे दायित्व देखील असते. त्यामुळे एकही बाईट कायदेशीर ट्रॅफिक - जसे की व्हिडिओ कॉल, वेबपेज, पेमेंट ट्रान्झॅक्शन - तुमच्या अपलिंकपर्यंत पोहोचण्यापूर्वीच, तुम्ही तुमच्या उपलब्ध क्षमतेचा एक तृतीयांश ते अर्धा हिस्सा नको असलेल्या ट्रॅफिकवर वाया घालवलेला असतो. आता, DNS फिल्टरिंग रिझोल्यूशन लेयरवर कार्य करते. प्रत्येक इंटरनेट विनंतीची सुरुवात DNS क्वेरीने होते - एक लुकअप जो डोमेन नेमचे IP ॲड्रेसमध्ये भाषांतर करतो. DNS फिल्टरिंग ती क्वेरी तुमच्या अपलिंकपर्यंत पोहोचण्यापूर्वीच अडवते. जर डोमेन जाहिरात नेटवर्क, ज्ञात मालवेअर होस्ट किंवा पॉलिसी - प्रतिबंधित श्रेणीमध्ये रिझोल्व्ह होत असेल, तर ती क्वेरी DNS लेयरवरच ब्लॉक केली जाते. डिव्हाइसला शून्य प्रतिसाद मिळतो. कोणताही डेटा ट्रान्सफर केला जात नाही. कोणतीही बँडविड्थ वापरली जात नाही. हे फायरवॉल किंवा प्रॉक्सीपेक्षा पूर्णपणे वेगळे आहे. फायरवॉल पॅकेट्स आधीच आल्यानंतर त्यांची तपासणी करते. प्रॉक्सी ट्रॅफिकला प्रवाहाच्या मध्यभागी अडवते. DNS फिल्टरिंग विनंती सुरू होण्यापूर्वीच थांबवते - म्हणूनच बँडविड्थची रिकव्हरी खूप महत्त्वपूर्ण असते. तुम्ही आधीच आलेल्या ट्रॅफिकची साफसफाई करत नाही आहात; तुम्ही पहिल्यांदाच त्याची विनंती केली जाण्यापासून रोखत आहात. आर्किटेक्चरच्या दृष्टिकोनातून, उपयोजन सोपे आहे. तुम्ही तुमच्या DHCP सर्व्हरला क्लायंट डिव्हाइसेसना तुमच्या ISP च्या डीफॉल्ट DNS ऐवजी तुमच्या DNS फिल्टरिंग रिझोल्व्हरकडे निर्देशित करण्यासाठी कॉन्फिगर करता. हे सहसा तुमच्या DHCP कॉन्फिगरेशनमधील दोन ओळींचे बदल असते. फिल्टरिंगचे नियम मध्यवर्ती पातळीवर व्यवस्थापित केले जातात - तुमच्या कम्प्लायन्स आवश्यकतांनुसार क्लाउडमध्ये किंवा ऑन - प्रिमिस - आणि ते कोणत्या ॲक्सेस पॉइंटशी जोडलेले आहेत याची पर्वा न करता सर्व कनेक्ट केलेल्या डिव्हाइसेसवर समान रीतीने लागू केले जातात. मल्टी - साईट ऑपरेटर्ससाठी हा एक महत्त्वाचा मुद्दा आहे. दोनशे स्टोअर्स असलेली रिटेल साखळी किंवा पन्नास मालमत्ता असलेला हॉटेल समूह एकाच मॅनेजमेंट कन्सोलवरून संपूर्ण इस्टेटमध्ये सुसंगत DNS फिल्टरिंग पॉलिसी लागू करू शकतो. कोणतीही ऑन - साईट इंजिनीअरिंग भेट नाही. प्रति - साईट कॉन्फिगरेशन नाही. पॉलिसीमधील बदल काही मिनिटांत लागू होतात. आता, येथे एक महत्त्वाचा तांत्रिक विचार आहे ज्याकडे मला येथील आर्किटेक्ट्सचे लक्ष वेधायचे आहे. DNS over HTTPS - DoH - च्या उदयामुळे पारंपारिक DNS फिल्टरिंगसाठी एक आव्हान निर्माण झाले आहे. जेव्हा एखादे डिव्हाइस DoH वापरते, तेव्हा ते त्याच्या DNS क्वेरीज एन्क्रिप्ट करते आणि त्या थेट एका विशिष्ट रिझोल्व्हरकडे पाठवते - सामान्यतः ब्राउझर व्हेंडरद्वारे ऑपरेट केलेले - तुमच्या नेटवर्क - लेव्हल DNS ला पूर्णपणे बायपास करते. याचा अर्थ तुमच्या फिल्टरिंग नियमांना बगल दिली जाते. यावर उपाय म्हणजे नेटवर्क स्तरावर DoH इंटरसेप्शन लागू करणे. यामध्ये DoH ट्रॅफिक ओळखणे - जे ज्ञात रिझोल्व्हर IP श्रेणींसाठी पोर्ट 443 वर चालते - आणि एकतर ते ब्लॉक करणे किंवा ते तुमच्या स्वतःच्या DoH - सक्षम फिल्टरिंग रिझोल्व्हरकडे रिडायरेक्ट करणे समाविष्ट आहे. हे अधिक प्रगत कॉन्फिगरेशन आहे, परंतु आधुनिक नेटवर्कवर फिल्टरिंगची प्रभावीता राखण्यासाठी हे आवश्यक आहे जिथे Chrome, Firefox आणि iOS वाढत्या प्रमाणात एन्क्रिप्टेड DNS वर डीफॉल्ट होत आहेत. Purple ने सार्वजनिक WiFi फिल्टरिंगसाठी DNS over HTTPS च्या प्रभावांवर एक तपशीलवार मार्गदर्शक प्रकाशित केले आहे, जे मी या माहितीसोबत वाचण्याची शिफारस करेन. DNS फिल्टरिंगच्या पलीकडे, समांतरपणे लागू करण्यासारखे अनेक पूरक सॉफ्टवेअर - लेयर ऑप्टिमायझेशन आहेत. बँड स्टिअरिंग (Band steering) हे सर्वात प्रभावशाली उपायांपैकी एक आहे. बहुतांश आधुनिक ॲक्सेस पॉइंट्स २.४ गिगाहर्ट्झ आणि ५ गिगाहर्ट्झ या दोन्ही बँड्सना सपोर्ट करतात. ५ गिगाहर्ट्झ बँड लक्षणीयरीत्या जास्त थ्रूपुट देतो परंतु त्याची रेंज कमी असते. ॲक्टिव्ह बँड स्टिअरिंगशिवाय, उपकरणे सहसा डिफॉल्टनुसार २.४ गिगाहर्ट्झ बँडशी जोडली जातात - विशेषतः जुनी उपकरणे आणि IoT हार्डवेअर - ज्यामुळे आधीच जुन्या ट्रॅफिकमुळे गर्दी असलेल्या बँडवर आणखी गर्दी निर्माण होते. तुमच्या वायरलेस कंट्रोलरमध्ये बँड स्टिअरिंग सुरू केल्याने सक्षम उपकरणांना ५ गिगाहर्ट्झवर पाठवले जाते, ज्यामुळे ज्या उपकरणांना खरोखर गरज आहे त्यांच्यासाठी २.४ गिगाहर्ट्झ मोकळा होतो. SSID एकत्रिकरण (consolidation) हा दुसरा जलद मार्ग आहे. तुम्ही ब्रॉडकास्ट करत असलेला प्रत्येक SSID बीकन फ्रेम्सद्वारे - व्यवस्थापन ट्रॅफिक जे रेंजमधील प्रत्येक उपकरणाला प्रोसेस करावे लागते - एअरटाइम वापरतो. विविध विभाग, कंत्राटदार आणि अतिथी स्तरांसाठी आठ किंवा दहा SSID चालवणारे ठिकाण व्यवस्थापनावरील ओव्हरहेडवर एअरटाइमची मोजण्यायोग्य टक्केवारी वाया घालवत असते. अतिथी, कर्मचारी, IoT आणि व्यवस्थापन अशा तीन किंवा चार SSID मध्ये एकत्रिकरण करणे - आणि स्वतंत्र SSID ऐवजी विभाजनासाठी VLAN टॅगिंग वापरणे यामुळे तो एअरटाइम त्वरित परत मिळवला जाऊ शकतो. QoS - Quality of Service - पॉलिसी अंमलबजावणी हा तिसरा मार्ग आहे. QoS शिवाय, 4K व्हिडिओ स्ट्रीमिंग करणारा एकच अतिथी रेडिओ सेल संपवू शकतो, ज्यामुळे त्या ॲक्सेस पॉइंटवरील इतर प्रत्येक उपकरणाचा अनुभव खराब होतो. प्रति-क्लायंट रेट लिमिटिंग आणि ट्रॅफिक प्राधान्यीकरण लागू केल्याने - मोठ्या प्रमाणावरील स्ट्रीमिंगपेक्षा VoIP आणि POS ट्रान्झॅक्शन ट्रॅफिकला प्राधान्य दिल्याने - पीक लोडमध्येही व्यवसायासाठी महत्त्वाचे असणारे ट्रॅफिक सुरक्षित राहील याची खात्री होते. शेवटी, चॅनेल प्लॅनिंग आणि ट्रान्समिट पॉवर ऑप्टिमायझेशन. सुरवातीच्या सेटअप दरम्यान हे अनेकदा सेट करून सोडून दिले जाते आणि पुन्हा कधीही तपासले जात नाही. जसे RF वातावरण बदलते - नवीन इमारती, हस्तक्षेपाचे नवीन स्त्रोत, उपकरणांच्या घनतेमधील बदल - तुमचे चॅनेल असायन्मेंट्स को-चॅनेल हस्तक्षेप निर्माण करत असू शकतात ज्यामुळे थ्रूपुट लक्षणीयरीत्या कमी होतो. पॅसिव्ह RF सर्वे करणे आणि चॅनेल असायन्मेंट्स पुन्हा ऑप्टिमाइझ करणे हा एक शून्य-खर्च पर्याय आहे जो भरीव थ्रूपुट सुधारणा देऊ शकतो. --- अंमलबजावणीच्या शिफारसी आणि धोके (अंदाजे २ मिनिटे) --- मी तुम्हाला मध्यम आकाराच्या ठिकाणासाठी - समजा दोनशे खोल्यांचे हॉटेल किंवा प्रादेशिक रिटेल वितरण केंद्र - यासाठी एक व्यावहारिक अंमलबजावणी क्रम सांगतो. बेसलाइन मोजमापाने सुरुवात करा. तुम्ही काहीही बदलण्यापूर्वी, कॅटेगरीनुसार DNS क्वेरी व्हॉल्यूम, प्रति-क्लायंट बँडविड्थ वापर आणि दिवसाच्या वेळेनुसार अपलिंक वापर कॅप्चर करण्यासाठी तुमचे नेटवर्क तयार करा. हे तुम्हाला तुमच्या ROI गणनेसाठी आधीची स्थिती दर्शवते. बहुतांश एंटरप्राइझ WiFi ॲनालिटिक्स प्लॅटफॉर्म्स हा डेटा मूळ स्वरूपात दाखवतील - उदाहरणार्थ, Purple चे ॲनालिटिक्स प्लॅटफॉर्म उपकरण-स्तरीय दृश्यमानता प्रदान करते ज्यामुळे हा बेसलाइन व्यायाम सोपा होतो. पायरी दोन: मॉनिटरिंग मोडमध्ये DNS फिल्टरिंग उपयोजित करा. बहुतेक एंटरप्राइझ DNS फिल्टरिंग सोल्यूशन्स पॅसिव्ह मोडला सपोर्ट करतात जेथे क्वेरी लॉग आणि वर्गीकृत केल्या जातात परंतु ब्लॉक केल्या जात नाहीत. तुम्ही कोणतेही धोरण लागू करण्यापूर्वी तुमच्या ट्रॅफिकचे स्वरूप समजून घेण्यासाठी हे अठ्ठेचाळीस ते बहात्तर तास चालवा. हे पहिल्याच दिवशी कायदेशीर ट्रॅफिकमध्ये व्यत्यय आणण्यापासून फॉल्स पॉझिटिव्हना प्रतिबंधित करते. पायरी तीन: टप्प्याटप्प्याने ब्लॉकिंग सक्षम करा. सर्वात जास्त खात्री असलेल्या श्रेणींपासून सुरुवात करा - ज्ञात मालवेअर डोमेन, बॉटनेट कमांड-अँड-कंट्रोल आणि जाहिरात नेटवर्क. हे कमी जोखीम असलेले ब्लॉक्स आहेत ज्यांचा बँडविड्थवर मोठा प्रभाव पडतो. कोणत्याही अनपेक्षित ब्लॉक्सचा शोध घेण्यासाठी पहिल्या आठवड्यासाठी दररोज लॉगचे पुनरावलोकन करा. पायरी चार: QoS आणि बँड स्टीअरिंग लेयर करा. एकदा DNS फिल्टरिंग स्थिर झाल्यावर, प्रति-क्लायंट रेट लिमिटिंग आणि बँड स्टीअरिंग लागू करा. गर्दी नसलेल्या वेळेत या बदलांची चाचणी घ्या आणि POS टर्मिनल्स, VoIP हँडसेट्स आणि इतर व्यवसाय-गंभीर डिव्हाइसेस योग्यरित्या कार्य करत असल्याची पडताळणी करा. पायरी पाच: दस्तऐवजीकरण आणि मोजमाप करा. तीस दिवसांनंतर, तुमची बँडविड्थ वापर मेट्रिक्स काढा आणि तुमच्या बेसलाइनशी तुलना करा. बहुतेक उपयोजनांमध्ये, तुम्हाला अपलिंक वापरामध्ये वीस ते चाळीस टक्के घट दिसेल. तो तुमचा ROI आकडा आहे. आता, अडचणींबद्दल बोलूया. मी पाहणारी सर्वात सामान्य अडचण म्हणजे ओव्हर-ब्लॉकिंग. तुम्ही आधी लॉगचे पुनरावलोकन न करता आक्रमक कंटेंट फिल्टरिंग श्रेणी सक्षम केल्यास, तुम्ही कायदेशीर सेवा ब्लॉक कराल. क्लाउड स्टोरेज, बिझनेस SaaS ॲप्लिकेशन्स आणि काही पेमेंट प्रोसेसिंग डोमेन देखील व्यापक श्रेणी ब्लॉक्समध्ये दिसू शकतात. नेहमी सावधगिरीने सुरुवात करा आणि नंतर विस्तार करा. दुसरी अडचण म्हणजे DoH बायपासकडे दुर्लक्ष करणे. तुम्ही DoH कडे लक्ष न देता DNS फिल्टरिंग उपयोजित केल्यास, अधिक डिव्हाइसेस डीफॉल्टनुसार एन्क्रिप्टेड DNS वापरू लागल्याने तुमच्या फिल्टरिंगची परिणामकारकता काळानुरूप कमी होईल. पहिल्या दिवसापासून नेटवर्क पॉलिसी स्तरावर या समस्येचे निराकरण करा. तिसरी अडचण म्हणजे IoT ट्रॅफिकचे वर्गीकरण करण्यात अयशस्वी होणे. IoT डिव्हाइसेस - स्मार्ट टीव्ही, बिल्डिंग मॅनेजमेंट सिस्टम, डिजिटल साइनेज - अनेकदा उत्पादकांच्या टेलीमेट्री सर्व्हर्सवर लक्षणीय DNS ट्रॅफिक जनरेट करतात. तुम्ही IoT ला त्याच्या स्वतःच्या फिल्टरिंग धोरणासह स्वतंत्र VLAN वर विभाजित करत नसल्यास, तुम्ही तुमचे फिल्टरिंग नियम कडक करता तेव्हा तुम्ही अनवधानाने डिव्हाइसच्या कार्यक्षमतेमध्ये अडथळा आणू शकता. --- रॅपिड-फायर प्रश्न आणि उत्तरे (अंदाजे १ मिनिट) --- मला सर्वात वारंवार विचारल्या जाणाऱ्या प्रश्नांचा आढावा घेऊ द्या. "यामुळे अतिथींच्या अनुभवावर परिणाम होईल का?" व्यवहारात, अतिथींच्या हे कधीच लक्षात येत नाही. जे डोमेन ब्लॉक केले जात आहेत ते बॅकग्राउंड टेलीमेट्री आहेत, त्यांनी सक्रियपणे विनंती केलेली सामग्री नाही. उलट, त्यांचा अनुभव अधिक चांगला होतो कारण ते प्रत्यक्षात ज्या गोष्टी करण्याचा प्रयत्न करत आहेत त्यासाठी अधिक बँडविड्थ उपलब्ध असते. "यासाठी आमच्या ॲक्सेस पॉइंट्समध्ये बदल करावे लागतील का?" नाही. DNS फिल्टरिंग हे DHCP आणि DNS रिझॉल्व्हर लेयरवर कॉन्फिगर केले जाते. तुमच्या ॲक्सेस पॉइंट्सना स्पर्शही केला जात नाही. "याने GDPR चे पालन होते का?" DNS filtering हे डोमेन क्वेरीजचा लॉग ठेवते, कन्टेन्टचा नाही. तुम्ही डीप पॅकेट इन्स्पेक्शन (deep packet inspection) करत नाही आहात. तुमच्याकडे योग्य डेटा रिटेन्शन पॉलिसी असेल आणि तुमच्या प्रायव्हसी नोटीसमध्ये नेटवर्क मॉनिटरिंगचा समावेश असेल — जे की कोणत्याही परिस्थितीत असायलाच हवे — तर DNS filtering हे GDPR सोबत पूर्णपणे सुसंगत आहे. सार्वजनिक क्षेत्र आणि आरोग्य सेवांच्या डिप्लॉयमेंटसाठी, हा सहसा निवडीऐवजी एक कम्प्लायन्सचा नियम असतो. "PCI-DSS चे काय?" DNS filtering हे कार्डधारक डेटा एन्व्हायरनमेंटला माहित असलेल्या दुर्भावनापूर्ण (malicious) डोमेन्सशी संपर्क साधण्यापासून रोखून तुमच्या PCI-DSS च्या स्थितीला अधिक मजबूत करते. हे एक पॉझिटिव्ह नियंत्रण आहे, धोका नाही. - सारांश आणि पुढील पावले (अंदाजे १ मिनिट) - या सर्वांचा निष्कर्ष काढायचा तर: बहुतांश एंटरप्राइझ WiFi परफॉर्मन्सच्या समस्या या हार्डवेअरच्या समस्या नसतात. त्या सॉफ्टवेअरच्या समस्या असतात — विशेषतः, DNS लेयरवर इंटेलिजेंट ट्रॅफिक मॅनेजमेंटचा अभाव. DNS filtering डिप्लॉय करून, तुम्ही तुमच्या सध्याच्या बँडविड्थपैकी तीस टक्के किंवा त्याहून अधिक बँडविड्थ परत मिळवू शकता, तुमच्या सध्याच्या ॲक्सेस पॉइंट इन्फ्रास्ट्रक्चरचे कार्यरत आयुष्य दोन ते चार वर्षांनी वाढवू शकता आणि त्याच वेळी तुमची सुरक्षा आणि कम्प्लायन्सची स्थिती सुधारू शकता. याच्या डिप्लॉयमेंटचा कालावधी काही महिन्यांचा नसून काही तासांचा असतो. याचा कॅपिटल एक्स्पेंडिचर (भांडवली खर्च) हा हार्डवेअर रिफ्रेशच्या तुलनेत अगदी नगण्य आहे. पुढील व्यावहारिक पावले सोपी आहेत. या आठवड्यात तुमच्या नेटवर्कवर DNS ट्रॅफिक ऑडिट चालवा — बहुतांश एंटरप्राइझ प्लॅटफॉर्म तुम्हाला कोणत्याही अतिरिक्त साधनांशिवाय हा डेटा देतील. तुमचे सर्वात जास्त बँडविड्थ वापरणारे डोमेन कॅटेगरी ओळखा. त्यानंतर त्या कॅटेगरीनुसार DNS filtering सोल्यूशनचे मूल्यमापन करा. जर तुम्ही मोठ्या प्रमाणावर गेस्ट WiFi नेटवर्क चालवत असाल — जसे की हॉस्पिटॅलिटी, रिटेल, इव्हेंट्स, सार्वजनिक क्षेत्र — तर Purple चे प्लॅटफॉर्म एकाच डिप्लॉयमेंटमध्ये गेस्ट WiFi मॅनेजमेंट आणि ॲनालिटिक्ससह DNS filtering समाकलित (integrate) करते. याचा अर्थ असा की तुम्हाला तीन वेगवेगळ्या प्लॅटफॉर्म्सऐवजी एकाच प्लॅटफॉर्मवरून बँडविड्थ रिक्लेमेशन, कम्प्लायन्स कंट्रोल्स आणि गेस्ट डेटा इनसाइट्स मिळतात. Purple टेक्निकल ब्रीफिंग ऐकल्याबद्दल धन्यवाद. संपूर्ण इम्प्लीमेंटेशन गाईडन्स, आर्किटेक्चर डायग्राम्स आणि सविस्तर उदाहरणे सोबतच्या लेखी मार्गदर्शकामध्ये उपलब्ध आहेत. पुन्हा भेटूया तोपर्यंत धन्यवाद.