Cisco Meraki, HPE Aruba आणि Ruckus वरील DFS radar events: चॅनल बदलांच्या विश्लेषणासाठी मार्गदर्शक चेकलिस्ट
Cisco Meraki, HPE Aruba किंवा Ruckus वर 5GHz बंद पडण्याचे कारण DFS radar event आहे की नाही ते शोधा. मूळ रडार सिग्नल आणि चुकीचे सिग्नल (false positives) किंवा प्लॅनर हालचालींमधील फरक ओळखा. त्यानंतर, तुमच्या परिसरासाठी आवश्यक असणारी क्षमता कमी न करता, कोणत्या APs वरून कोणते चॅनल वगळायचे ते ठरवा.
आमच्या मुख्य मालिकेचा भाग: Guest WiFi मार्गदर्शक →
IEEE 802.11h मानकांनुसार कार्यरत असणाऱ्या Cisco Meraki, HPE Aruba, किंवा Ruckus WiFi नेटवर्कवरील DFS रडार इव्हेंट्सचे निदान आणि निवारण करण्यासाठी, रडार डिटेक्शन्ससाठी तुमचे कंट्रोलर लॉग्स तपासा. रडार आढळल्यास, एक्सेस पॉईंटने (AP) 10 सेकंदांच्या आत 5GHz चॅनेल रिकामे केले पाहिजे आणि पुढील 30 मिनिटे त्यापासून दूर राहिले पाहिजे.
तुमच्या 5GHz नेटवर्कवर DFS रडार इव्हेंट कसा दिसतो?
Dynamic Frequency Selection (DFS) मुळे WiFi ला 5GHz बँडचे काही भाग रडारसोबत शेअर करता येतात. IEEE 802.11h ही यंत्रणा परिभाषित करते. नियामक याच्या वेळा ठरवतात: अमेरिकेत 47 CFR Part 15.407 अंतर्गत FCC, आणि संपूर्ण युरोपमध्ये ETSI EN 301 893. ETSI क्षेत्रांमध्ये, चॅनेल 52 ते 64 आणि 100 ते 140 हे DFS चॅनेल्स आहेत. FCC नियमांमध्ये चॅनेल 144 देखील समाविष्ट आहे.
जेव्हा एखादा एक्सेस पॉईंट (AP) रडार शोधतो, तेव्हा पुढील प्रक्रिया निश्चित असते:
- शोधणे (Detection). रेडिओ त्याच्या ऑपरेटिंग चॅनेलवरील पल्स पॅटर्नला रडारच्या वैशिष्ट्यांशी जुळवून पाहतो.
- चॅनेल बदलण्याची घोषणा (CSA). AP त्याच्या बीकन्समध्ये CSA एलिमेंट जोडतो, ज्यामुळे क्लायंट्सना नवीन चॅनेल आणि तिथे स्थलांतरित होण्यासाठीचा काउंटडाउन समजतो.
- चॅनेल बदलणे (Channel move). रेडिओने 10 सेकंदांच्या आत त्या चॅनेलवरील ट्रान्समिशन थांबवले पाहिजे.
- वापर न करण्याचा कालावधी (Non-occupancy period). ते चॅनेल किमान 30 मिनिटांसाठी प्रतिबंधित केले जाते.
- चॅनेल उपलब्धता तपासणी (CAC). एखादे DFS चॅनेल वापरात येण्यापूर्वी, रेडिओ किमान 60 सेकंद ऐकतो (स्कॅन करतो). ETSI क्षेत्रांमध्ये, चॅनेल 120, 124 आणि 128 (5600-5650 MHz) हवामान रडारसोबत शेअर केले जातात, आणि तिथे ही तपासणी 10 मिनिटे चालते.
गेस्ट युजर्सना येणारा अनुभव हा त्यांच्या डिव्हाइसेसवर अवलंबून असतो. CSA चे पालन करणारे क्लायंट्स थोड्या विरामानंतर AP चे अनुसरण करतात. जे क्लायंट्स याकडे दुर्लक्ष करतात त्यांचे कनेक्शन तुटते, ते पुन्हा स्कॅन करतात आणि सहसा 2.4GHz किंवा शेजारील AP वर पुन्हा जोडले जातात. जर AP अशा एखाद्या DFS चॅनेलवर गेला ज्याची तपासणी अद्याप पूर्ण झालेली नाही, तर 5GHz रेडिओ एक मिनिट किंवा त्याहून अधिक काळ शांत राहू शकतो.
पाहण्यासाठीचे लक्षण पॅटर्न:
- एका AP वरील किंवा शेजारील AP च्या समूहातील प्रत्येक क्लायंट एकाच वेळी डिस्कनेक्ट होतो.
- AP वेगळ्या चॅनेलवर परत येतो, बहुधा 36 आणि 48 दरम्यानच्या नॉन-DFS चॅनेलवर.
- हा बदल तुमच्या नियोजित चॅनेल ऑप्टिमायझेशनच्या वेळेबाहेर होतो.
- तेच AP या पॅटर्नची पुनरावृत्ती करतात, कधीकधी दिवसाच्या ठराविक वेळी.
- 5GHz क्लायंट्स गायब होत असताना 2.4GHz वरील लोड अचानक वाढतो.
सामान्यतः DFS चॅनेल बदल कशामुळे होतात?
खरे रडार
युरोपमध्ये 5600-5650 MHz श्रेणीतील हवामान रडार हे एक सामान्य खरे स्त्रोत आहेत. अमेरिकेत, प्रमुख विमानतळांवरील Terminal Doppler Weather Radar (TDWR) याच श्रेणीचा वापर करतात. अंतरापेक्षा दृष्टीची थेट रेषा (Line of sight) जास्त महत्त्वाची असते. आऊटडोअर APs, वरचे मजले आणि काचेचे दर्शनी भाग असलेल्या इमारतींमधील APs रडार शोधू शकतात जे तळमजल्यावरील APs ना कधीच दिसत नाहीत.
केवळ जवळीक असण्यावरून अंदाज लावता येत नाही. अनेक विमानतळ पाळत ठेवणारे आणि सागरी नौकानयन रडार इतर बँडमध्ये कार्यरत असतात, जे 5GHz च्या बरेच बाहेर असतात. बंदराजवळील एखाद्या ठिकाणी कदाचित एकही रडार इव्हेंट नोंदवला जाणार नाही. तुमचा इव्हेंट लॉग हा पुरावा आहे, नकाशा नाही.
फॉल्स पॉझिटिव्ह्ज (चुकीचे संकेत)
DFS फॉल्स पॉझिटिव्ह म्हणजे रडार नसतानाही रडार आढळल्याचा संकेत मिळणे. रेडिओ ऊर्जेच्या तीव्र झोताला रडार पल्स पॅटर्न समजतो. सामान्य ट्रिगर कारणांमध्ये हे समाविष्ट आहे:
- वायरलेस व्हिडिओ लिंक्स किंवा सदोष उपकरणांमुळे येणारे पल्स्ड नॉन-WiFi व्यत्यय;
- जवळच्या AP कडून किंवा लगतच्या चॅनेलवरील पॉइंट-टू-पॉइंट लिंकवरून होणारे तीव्र ट्रान्समिशन;
- रेडिओ किंवा फर्मवेअरमधील त्रुटी, ज्या व्हेंडर सॉफ्टवेअर रिलीजमध्ये दुरुस्त करतात.
याचे मुख्य लक्षण म्हणजे विलगीकरण. एकाच दिशेने असणारे इतर शेजारील APs कोणतीही नोंद करत नसताना, एकच AP वेगवेगळ्या चॅनेलवर वारंवार घडणाऱ्या घटनांची नोंद करतो.
रुंद चॅनेलमुळे वास्तविक आणि खोट्या दोन्ही प्रकारच्या डिटेक्शनचा धोका वाढतो. ८० MHz चॅनेलमध्ये चार २० MHz सब-चॅनेल समाविष्ट असतात आणि त्यापैकी कोणत्याही एकावर झालेली नोंद संपूर्ण चॅनेलला हलवते.
नॉन-राडार बदल जे सारखेच दिसतात
चॅनेल प्लॅनर्स व्यत्यय आणि लोडसाठी रेडिओ हलवतात. Meraki Auto RF, Aruba ARM आणि AirMatch, आणि Ruckus ChannelFly आणि BackgroundScanning हे सर्व राडारशिवाय चॅनेल बदलतात. AP रीबूट आणि पॉवर बदलांमुळे देखील क्लायंट डिस्कनेक्ट होतात. या त्रुटींसाठी वेगवेगळ्या उपायांची गरज असते, त्यामुळे कोणतीही गोष्ट वगळण्यापूर्वी कारणाची खात्री करा.
राडारमुळे आउटेज झाले आहे की नाही हे तुम्ही कसे ओळखाल?
या चेकलिस्टनुसार क्रमाने काम करा:
- तक्रार अचूकपणे नोंदवा. अचूक वेळ (मिनिटासह) आणि खोली, मजला किंवा झोन मिळवा.
- चॅनेल-बदलाच्या घटना तपासा त्या भागात सेवा देणाऱ्या APs साठी, दोन्ही बाजूंच्या एक तासाच्या कालावधीसाठी.
- नोंदवलेले कारण वाचा. राडार किंवा DFS कारण हे मूळ कारणाची खात्री करते. व्यत्यय, गोंगाट (नॉईज) किंवा ऑप्टिमायझेशनचे कारण हे ते नाकारते.
- चॅनेलची नोंद घ्या. १२०, १२४ आणि १२८ वर एकत्रितपणे घडणाऱ्या घटना हवामान राडारकडे निर्देश करतात.
- बाधित APs ची संख्या मोजा. एकत्र असणारे अनेक शेजारील APs वास्तविक राडार दर्शवतात. केवळ एकच AP असणे हे खोट्या पॉझिटिव्हचा (फॉल्स पॉझिटिव्ह) संकेत देते.
- साप्ताहिक पॅटर्न शोधा. नियमित पुनरावृत्ती निश्चित वेळापत्रक किंवा स्वीप असलेले राडार दर्शवते.
- चॅनेलची रुंदी तपासा. केवळ ८० किंवा १६० MHz चॅनेलवर दिसणाऱ्या घटना चॅनेलच्या रुंदीला समस्येचा भाग बनवतात.
- फर्मवेअर रिलीज नोट्स वाचा तुमच्या AP मॉडेलवरील DFS डिटेक्शन दुरुस्त्यांसाठी.
जर तुम्ही Purple Guest WiFi चालवत असाल, तर ठिकाणानुसार लॉगइनचे प्रमाण तुम्हाला क्रॉस-चेक करण्याची सुविधा देते. एका साईटवर आलेली मोठी घसरण जी राडारच्या घटनेशी जुळते, ती अतिथींच्या (गेस्ट) प्रभावाची खात्री करते.
Meraki, Aruba आणि Ruckus वर तुम्ही DFS घटना कशा दुरुस्त कराल?
| व्हेंडर | राडार घटना कुठे दिसतात | चॅनेल प्लॅनर | तुम्ही चॅनेल कुठे प्रतिबंधित करता |
|---|---|---|---|
| Cisco Meraki | DFS घटनांसाठी फिल्टर केलेला वायरलेस इव्हेंट लॉग; प्रति AP आरएफ स्पेक्ट्रम पेज | Auto RF | आरएफ प्रोफाइल चॅनेल लिस्ट, जी बाधित APs वर लागू केली जाते |
| HPE Aruba | कंट्रोलर किंवा इन्स्टंट क्लस्टरवरील ARM इतिहास; AOS 8 आणि Aruba Central मधील AirMatch घटना | ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10) | एका AP ग्रुपसाठी रेडिओ प्रोफाइलमधील अनुमत चॅनेल लिस्ट |
| Ruckus | राडार डिटेक्शनसाठी SmartZone घटना आणि अलार्म | ChannelFly किंवा BackgroundScanning | एका समर्पित झोन किंवा AP ग्रुपसाठी रेडिओ सेटिंग्ज |
Cisco Meraki
Meraki इव्हेंट लॉगमध्ये DFS इव्हेंट्स म्हणून रडार डिटेक्शन रेकॉर्ड करते, ज्यामध्ये AP आणि चॅनेलचे नाव असते. इव्हेंट प्रकार आणि समस्येच्या वेळेनुसार फिल्टर करा. प्रत्येक AP साठी RF स्पेक्ट्रम पृष्ठ वापर आणि हस्तक्षेप दर्शवते, जे रडारला गर्दीपासून वेगळे करते. पुन्हा असे घडणे थांबवण्यासाठी, RF प्रोफाईल मधील Auto RF मधून संबंधित समस्या असलेले चॅनेल्स काढून टाका. ते प्रोफाईल केवळ बाधित APs वर लागू करा. Meraki चे स्वतःचे DFS दस्तऐवजीकरण अचूक पायऱ्या कव्हर करते.
HPE Aruba
ARM इतिहास प्रत्येक चॅनेल बदलाची त्याच्या कारणासह नोंद करतो आणि रडार डिटेक्शन एक वेगळे कारण म्हणून दिसते. AirMatch चॅनेल योजना केंद्रीय पद्धतीने तयार करते, परंतु रडार हिटमुळे AP ला लगेच चॅनेल बदलावे लागते. त्यामुळे, DFS चॅनेलवर दुपारच्या वेळी अनपेक्षित बदल हा एक मोठा संकेत आहे. केवळ बाधित APs असलेल्या AP ग्रुपसाठी रेडिओ प्रोफाईल मधील चॅनेल्स मर्यादित करा. पुन्हा कनेक्ट केल्यानंतर जर अतिथींना पुन्हा लॉगिन पृष्ठावर पाठवले जात असेल, तर ती एक स्वतंत्र त्रुटी आहे: HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist पहा.
Ruckus
जेव्हा AP रडार शोधते तेव्हा SmartZone एक इव्हेंट नोंदवते, ज्यामध्ये AP आणि चॅनेलचे नाव असते. त्या वेळेसाठी इव्हेंट्स आणि अलार्म तपासा, नंतर त्यांची तुलना ChannelFly किंवा BackgroundScanning उपक्रमांशी करा. रडार इव्हेंटशिवाय झालेला Ruckus DFS चॅनेल बदल हा प्लॅनरचा निर्णय असतो, DFS नाही. समर्पित झोन किंवा AP ग्रुपसाठी रेडिओ सेटिंग्जमधील समस्या असलेले चॅनेल्स काढून टाका.
तिन्ही प्लॅटफॉर्मवर, केवळ बाधित APs मध्ये बदल करा. संपूर्ण साइटवर हे चॅनेल्स वगळल्याने रडार कधीही न पाहिलेल्या APs ची क्षमता वाया जाते.
तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?
आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.
आपण विमानतळ, बंदर किंवा हवामान रडारजवळ DFS चॅनेल्स बंद करावेत का?
डिफॉल्टनुसार नाही. ETSI प्रदेशातील प्रत्येक DFS चॅनेल वगळल्यास केवळ चार 20 MHz चॅनेल्स उरतात: 36, 40, 44 आणि 48. FCC नियम नऊ चॅनेल्स सोडतात, ज्यामध्ये 149 ते 165 जोडले जातात. उच्च-घनता असलेल्या ठिकाणी, चार चॅनेल्स APs ला एअरटाइम शेअर करण्यास भाग पाडतात आणि प्रत्येक क्लायंटचा वेग कमी करतात. लॉग्सनुसार निर्णय घेऊ द्या.
| तुमच्या लॉग्समध्ये काय दिसते | संभाव्य कारण | शिफारस | शिल्लक राहिलेले 20 MHz चॅनेल्स (ETSI / FCC) |
|---|---|---|---|
| अनेक शेजारील APs वरील इव्हेंट्स, जे 120-128 वर केंद्रित आहेत | हवामान रडार | बाधित APs वर 120, 124 आणि 128 वगळा | 16 / 22 |
| अनेक APs वर दररोज बहुतेक DFS चॅनेल्सवरील इव्हेंट्स | जवळील शक्तिशाली रडार | केवळ बाधित APs वर DFS वगळा; इतरत्र ते चालू ठेवा | बाधित APs वर 4 / 9 |
| एकाच AP वर वारंवार येणारे इव्हेंट्स, वेगवेगळे चॅनेल्स | चुकीचे सिग्नल (False positive) | फर्मवेअर अपडेट करा, चाचणी करा किंवा रेडिओ बदला, DFS चालू ठेवा | 19 / 25 |
| केवळ 80 किंवा 160 MHz चॅनेल्सवरील इव्हेंट्स | रुंदीची असुरक्षितता | 40 किंवा 20 MHz वर कमी करा, DFS चालू ठेवा | 19 / 25 |
| चॅनेल बदलले परंतु कोणतीही रडार नोंद नाही | प्लॅनर किंवा हस्तक्षेप | हस्तक्षेप आणि पॉवर सुधारा, DFS चालू ठेवा | 19 / 25 |
सराव परिस्थिती: प्रादेशिक विमानतळाजवळील हॉटेल
ETSI प्रदेशातील एका १८० खोल्यांच्या हॉटेलपासून ३ किमी अंतरावर हवामान रडार असलेले विमानतळ होते. पश्चिमेकडील वरच्या मजल्यावरील पाहुण्यांनी बहुतेक दुपारच्या वेळी कनेक्शन तुटल्याची तक्रार केली. इव्हेंट लॉगवरून एका आठवड्यात ४६ पैकी ११ APs वर ६३ रडार इव्हेंट दिसून आले, हे सर्व १२_० ते १२_८ चॅनेलवर होते. टीमने त्या ११ APs ना हवामान चॅनेल्स वगळणाऱ्या आणि ४_० MHz विड्थ सेट करणाऱ्या प्रोफाईलवर हलवले. पुढील चार आठवड्यांत हॉटेलमध्ये शून्य रडार इव्हेंट्सची नोंद झाली. फ्रंट डेस्कवर येणाऱ्या WiFi तक्रारी आठवड्याला १४ वरून दोनवर आल्या. इतर ३५ APs ने प्रत्येक DFS चॅनेल कायम ठेवला. हॉटेलमधील उपयोजनांबद्दल अधिक माहितीसाठी, Hotels पहा.
प्रत्यक्ष उदाहरण: एक गोंगाट करणारा AP असलेली रिटेल साखळी
१२० स्टोअर असलेल्या एका रिटेल साखळीतील एका स्टोअरमध्ये दोन आठवड्यांत ५२, १०० आणि ११६ चॅनेल्सवर ३_० रडार इव्हेंट नोंदवले गेले. त्याच स्टोअरमधील शेजारील APs वर एकही इव्हेंट नोंदवला गेला नाही, ज्यावरून हा एक चुकीचा अलार्म (फॉल्स पॉझिटिव्ह) असल्याचे दिसून आले. AP मॉडेलच्या रिलीज नोट्समध्ये DFS डिटेक्शन फिक्सची यादी होती, म्हणून टीमने फर्मवेअर अपग्रेड केले. तरीही इव्हेंट्स सुरूच राहिले, आणि वॉरंटी अंतर्गत तो AP बदलण्यात आला. स्टोअरमधील रडार इव्हेंट्स शून्यावर आले, आणि ग्राहकांचे बिलिंग काउंटरच्या भागात कनेक्शन तुटणे थांबले. संपूर्ण इस्टेटने सर्व १९ चॅनेल्स कायम ठेवले. बहु-साइट अतिथी प्रवेशासाठी Retail पहा.
प्रत्यक्ष उदाहरण: बंदराजवळील कौन्सिल कार्यालये
एका कौन्सिल IT टीमने व्यावसायिक बंदराजवळील कार्यालयांमध्ये DFS निष्क्रिय करण्याची योजना आखली होती. ३_० दिवसांच्या लॉग्समध्ये एकही रडार इव्हेंट आढळला नाही. चॅनेल बदल हे शेजारील भाडेकरूच्या नेटवर्कला प्रतिसाद देणाऱ्या प्लॅनरमुळे झाले होते. टीमने DFS कायम ठेवले, ट्रान्समिट पॉवर कमी केली आणि चॅनेल प्लॅन निश्चित केला. साप्ताहिक ड्रॉप रिपोर्ट ९ वरून १ वर आले.
तुम्ही DFS इव्हेंट्सना पाहुण्यांच्या कामात पुन्हा अडथळा आणण्यापासून कसे रोखू शकता?
- गर्दीच्या ठिकाणी २० किंवा ४_० MHz चॅनेल्स वापरा. अरुंद चॅनेल्स एक्सपोजर कमी करतात आणि पुनर्वापर वाढवतात.
- प्रभावित APs वर केवळ १२० ते १२८ दरम्यान इव्हेंट्स केंद्रित असलेल्या ठिकाणी हवामान चॅनेल्स अत्यंत काळजीपूर्वक वगळा.
- फर्मवेअर अपडेट ठेवा आणि प्रत्येक रिलीज नोटमधील DFS फिक्स वाचा.
- दरमहा DFS इव्हेंट्सचे पुनरावलोकन करा, आणि आठवड्यातून काही पेक्षा जास्त इव्हेंट लॉग करणाऱ्या कोणत्याही AP साठी अलर्ट सेट करा.
- 6GHz साठी नियोजन करा. 6GHz बँडमध्ये कोणतीही DFS आवश्यकता नसते, त्यामुळे WiFi ६E आणि WiFi ७ क्लायंट रडार हालचाली पूर्णपणे टाळतात.
- RF ला अतिथी प्रवेशापासून वेगळे करा. Purple हे Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet वर हार्डवेअर-अज्ञेयवादी क्लाउड ओव्हरले म्हणून चालते. तुमचा कंट्रोलर चॅनेल प्लॅन व्यवस्थापित करतो आणि Purple अतिथी लॉगइन व्यवस्थापित करते. Purple ने २०२४ मध्ये ८०,०००+ पेक्षा जास्त लाइव्ह ठिकाणांवर ४४ कोटी लॉगइन्स हाताळले (Purple डेटा).
वारंवार विचारले जाणारे प्रश्न
काय Purple Guest WiFi आमच्या विद्यमान Meraki, Aruba किंवा Ruckus ऍक्सेस पॉईंट्सवर काम करते?
होय. Purple Guest WiFi हे एक हार्डवेअर-अज्ञेयवादी क्लाउड ओव्हरले आहे जे Cisco Meraki, HPE Aruba आणि Ruckus सोबतच Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet वर चालते. तुम्ही तुमचे ऍक्सेस पॉईंट्स, कंट्रोलर आणि RF कॉन्फिगरेशन कायम ठेवू शकता. Purple त्यावर अतिथी लॉगिन, जाणीवपूर्वक दिलेली संमती आणि प्रथम-पक्ष डेटाची भर घालते. कोणतीही तोडफोड किंवा बदल करण्याची आवश्यकता नाही, आणि तुमचे DFS सेटिंग्ज तुमच्या नियंत्रणाखाली राहतात.
काय Purple आमचे DFS किंवा चॅनेल सेटिंग्ज बदलेल?
नाही. Purple रेडिओ चॅनेल्स, चॅनेल विड्थ किंवा ट्रान्समिट पॉवर सेट करत नाही. ते Meraki Auto RF, Aruba ARM किंवा AirMatch, आणि Ruckus ChannelFly किंवा BackgroundScanning मध्ये राहतात. Purple रेडिओ लेयरच्या वर गेस्ट ऑथेंटिकेशन आणि डेटा कॅप्चर हाताळते. हे वेगळेपण तुम्हाला गेस्ट लॉगिन अनुभवाला स्पर्श न करता तुमच्या वेंडर डॅशबोर्डमधील DFS समस्या सोडवण्यास आणि RF ला स्पर्श न करता लॉगिन सेटिंग्ज बदलण्यास अनुमती देते.
DFS चॅनेल्स अक्षम करणे कायद्याला सुसंगत आहे का?
होय. ETSI EN 301 893 आणि FCC Part 15.407 नुसार तुम्ही वापरत असलेल्या कोणत्याही DFS चॅनेलवर रडार डिटेक्शन आवश्यक आहे. यापैकी कोणतेही तुम्हाला DFS चॅनेल्स वापरण्याची सक्ती करत नाही. त्यांना वगळणे नेहमीच सुसंगत असते. तुम्ही कधीही करू नये अशी गोष्ट म्हणजे डिटेक्शन अक्षम करून DFS चॅनेलवर काम करणे. वगळण्याची खरी किंमत म्हणजे क्षमता: ETSI प्रदेशांमध्ये, प्रत्येक DFS चॅनेल काढून टाकल्यास 19 ऐवजी चार 20 MHz चॅनेल्स शिल्लक राहतात.
DFS समस्या टाळण्यासाठी आम्हाला नवीन ऍक्सेस पॉईंट्सची आवश्यकता आहे का?
सहसा नाही. बहुतेक DFS समस्या कॉन्फिगरेशनसह सोडवल्या जातात: प्रभावित APs वरील वेदर चॅनेल्स वगळणे, चॅनेल विड्थ अरुंद करणे किंवा फर्मवेअर अपडेट करणे. फर्मवेअर अपडेटनंतरही एका रेडिओमध्ये वारंवार खोट्या त्रुटी येत राहिल्यास किंवा जेव्हा तुम्ही 6GHz क्षमता जोडता तेव्हा बदलणे योग्य ठरते. 6GHz बँडमध्ये कोणतीही DFS आवश्यकता नसते, त्यामुळे WiFi 6E आणि WiFi 7 ऍक्सेस पॉईंट्स त्यांना सपोर्ट करणाऱ्या क्लायंटसाठी रडारच्या हालचाली काढून टाकतात.
DFS चॅनेल्स वगळल्याने गर्दीच्या ठिकाणी गेस्ट WiFi ला त्रास होईल का?
होय, जर तुम्ही ते संपूर्ण साईटवर वगळले तर. ETSI प्रदेशात, चार 20 MHz चॅनेल्स स्टेडियम, कॉन्फरन्स सेंटर किंवा मोठ्या हॉटेलमधील डझनभर APs वेगळे करू शकत नाहीत. APs शेवटी एअरटाइम शेअर करतात आणि प्रत्येक पाहुण्यासाठी थ्रूपुट कमी होतो. रडार नोंदवणाऱ्या फक्त APs वरच चॅनेल्स वगळा आणि इतर सर्व ठिकाणी DFS सुरू ठेवा. हा दृष्टिकोन क्षमता न गमावता समस्या मर्यादित करतो.
UK, युरोप आणि US मधील DFS नियम वेगळे आहेत का?
होय. UK आणि EU ETSI EN 301 893 चे पालन करतात, जे चॅनेल 52 ते 64 आणि 100 ते 140 वर DFS लागू करते. यामध्ये वेदर चॅनेल 120, 124 आणि 128 वर 10 मिनिटांची उपलब्धता तपासणी देखील आवश्यक आहे. US FCC Part 15.407 चे पालन करते, जे चॅनेल 144 जोडते आणि नऊ नॉन - DFS चॅनेल्स सोडते. दोन्ही नियमांमध्ये डिटेक्शननंतर किमान 30 मिनिटे नॉन - ऑक्युपन्सी आवश्यक आहे.
एखादा MSP मिश्र-वेंडर इस्टेटमध्ये DFS इव्हेंट्सचे निदान करू शकतो का?
होय, परंतु रडार इव्हेंट्स प्रत्येक वेंडरच्या स्वतःच्या टूलिंगमध्ये असतात: Meraki इव्हेंट लॉग, Aruba ARM हिस्ट्री किंवा AirMatch इव्हेंट्स, आणि SmartZone इव्हेंट्स आणि अलार्म्स. MSP ने टूलऐवजी चेकलिस्टचे मानकीकरण केले पाहिजे आणि प्रत्येक घटनेची वेळ, चॅनेल, AP संख्या आणि कारण नोंदवले पाहिजे. Purple तुम्हाला त्या सर्व वेंडर्सच्या गेस्ट ऍक्सेससाठी एक प्लॅटफॉर्म देते, तर RF चे निदान प्रत्येक कंट्रोलरमध्येच राहते.
महत्वाच्या व्याख्या
Dynamic Frequency Selection (DFS)
IEEE 802.11h मधील यंत्रणा जी WiFi ला 5GHz बँडचे भाग रडारसह शेअर करण्याची परवानगी देते. रेडिओने रडार शोधणे, 10 सेकंदात चॅनल सोडणे आणि किमान 30 मिनिटे नॉन-ऑक्युपन्सी पाळणे बंधनकारक आहे.
जेव्हा एखादा 5GHz रेडिओ चॅनल 52 ते 64 किंवा 100 ते 140 वापरतो, तेव्हा तुम्हाला DFS चा सामना करावा लागतो. रडार आढळल्यावर क्लायंट लगेच का डिस्कनेक्ट होतात, हे याच्या नियमांवरून समजते.
IEEE 802.11h
IEEE 802.11 दुरुस्ती जी 5GHz ऑपरेशनसाठी रडारसह DFS आणि चॅनल स्विच सिग्नलिंग परिभाषित करते. रेग्युलेटर शोध आणि वेळेची मूल्ये निश्चित करतात, दुरुस्ती नाही.
Cisco Meraki, HPE Aruba आणि Ruckus मधील प्रत्येक एंटरप्राइझ AP याची अंमलबजावणी करतो. याच कारणामुळे रडार आढळल्यास तुमच्या प्लॅनरचा विचार न करता चॅनल त्वरित बदलावा लागतो.
ETSI EN 301 893
5GHz रेडिओ LAN उपकरणांसाठी युरोपियन सुसंवादित मानक. हे चॅनेल 52 ते 64 आणि 100 ते 140 वर DFS लागू करते आणि हवामान चॅनेल 120, 124 आणि 128 वर 10-मिनिटांची उपलब्धता तपासणी सेट करते.
UK आणि EU मधील ठिकाणे याचे पालन करतात. हे हवामान चॅनेलवरील दीर्घ शांतता स्पष्ट करते आणि सर्व DFS वगळल्यास केवळ चार 20 MHz चॅनेल का उरतात हे सांगते.
47 CFR Part 15.407
US मधील विनापरवाना 5GHz उपकरणांचे नियमन करणारा FCC नियम. यासाठी DFS चॅनेलवर रडार शोधणे आवश्यक आहे, DFS श्रेणीमध्ये चॅनेल 144 जोडतो आणि नऊ नॉन-DFS चॅनेल शिल्लक ठेवतो.
US मधील मालमत्ता हे लागू करतात. हे पुष्टी करते की DFS चॅनेल वगळणे सुसंगत आहे, तर शोध अक्षम करून त्यावर ऑपरेट करणे नियमांचे उल्लंघन आहे.
Channel switch announcement (CSA)
IEEE 802.11h अंतर्गत AP त्याच्या बीकन्समध्ये जोडणारा एक घटक, जो क्लायंटला नवीन चॅनेल आणि स्थलांतराचा काउंटडाउन सांगतो.
CSA चे पालन करणारे क्लायंट थोड्या विश्रांतीसह AP चे अनुसरण करतात. याकडे दुर्लक्ष करणारे क्लायंट डिस्कनेक्ट होतात आणि पुन्हा स्कॅन करतात, ज्याला अतिथी कनेक्शन तुटणे म्हणतात.
Channel availability check (CAC)
DFS चॅनेल सेवेमध्ये येण्यापूर्वीचा ऐकण्याचा कालावधी: किमान ६० सेकंद, किंवा ETSI वेदर चॅनेल्स १२०, १२४ आणि १२८ (५६००-५६५० MHz) वर १० मिनिटे.
जर AP अशा DFS चॅनेलवर गेले ज्याने आपली तपासणी पूर्ण केली नसेल, तर 5GHz रेडिओ एक मिनिट किंवा त्याहून अधिक काळ शांत राहू शकतो.
Non-occupancy period
रडार शोधल्यानंतर एखादा चॅनेल किमान ३० मिनिटांपर्यंत वापरण्यास बंदी असणारा कालावधी, जो ETSI EN 301 893 आणि FCC Part 15.407 दोन्हीसाठी आवश्यक आहे.
हे स्पष्ट करते की रडारच्या घटनेनंतर एखादा AP वेगळ्या चॅनेलवर (सहसा ३६ ते ४८) का परत येतो आणि तिथेच का राहतो.
Terminal Doppler Weather Radar (TDWR)
अमेरिकेतील प्रमुख विमानतळांवर वापरले जाणारे हवामान रडार, जे ५६००-५६५० MHz रेंजमध्ये कार्यरत असते आणि 5GHz WiFi DFS चॅनेल्सना ओव्हरलॅप करते.
मोठ्या विमानतळांजवळील US मधील ठिकाणे या चॅनेल्सवर वास्तविक रडार इव्हेंट्सची नोंद करू शकतात. अंतरापेक्षा दृष्टीची रेषा (line of sight) अधिक महत्त्वाची असते.
DFS false positive
रडार नसतानाही रडार शोधला जाणे, जिथे रेडिओ पल्सड एनर्जीला रडार पॅटर्न म्हणून समजतो. याच्या कारणांमध्ये व्हिडिओ लिंक्स, शेजारील चॅनेल ट्रान्समीटर आणि रेडिओ किंवा फर्मवेअरमधील दोष यांचा समावेश होतो.
याचे लक्षण म्हणजे शेजारील AP कोणतीही नोंद करत नसताना, एकच AP विविध चॅनेल्सवर वारंवार घडणाऱ्या इव्हेंट्सची नोंद करतो. यावरील उपाय म्हणजे फर्मवेअर किंवा रेडिओ बदलणे, चॅनेल वगळणे नव्हे.
Channel width (80 and 160 MHz)
बाँड केलेले 5GHz चॅनेल्स: एक ८० MHz चॅनेल चार २० MHz सब-चॅनेल्स व्यापतो, आणि यापैकी कोणत्याही एकावर रडार आढळल्यास संपूर्ण चॅनेल हलविला जातो.
रुंद चॅनेल्समुळे वास्तविक आणि चुकीच्या दोन्ही प्रकारच्या रडार शोधण्याच्या शक्यता वाढतात. गर्दीच्या ठिकाणी ४० किंवा २० MHz वर येण्याने इव्हेंट्स कमी होतात आणि पुनर्वापर वाढतो.
Channel planner (Auto RF, ARM, AirMatch, ChannelFly)
हस्तक्षेप आणि लोडनुसार चॅनेल्स बदलणारे वेंडर ऑटोमेशन: Meraki Auto RF, Aruba ARM आणि AirMatch, आणि Ruckus ChannelFly किंवा BackgroundScanning.
प्लॅनर मुव्ह्समुळे देखील DFS मुव्ह्सप्रमाणेच क्लायंट डिस्कनेक्ट होतात. कोणताही चॅनेल वगळण्यापूर्वी लॉग केलेले कारण तपासून खात्री करा.
6GHz band
WiFi 6E आणि WiFi 7 द्वारे वापरला जाणारा स्पेक्ट्रम, ज्यामध्ये कोणतीही DFS आवश्यकता नसते.
६GHz क्षमता जोडल्याने त्याला सपोर्ट करणाऱ्या क्लायंट्ससाठी रडार मुव्ह्सची समस्या दूर होते, ज्यामुळे सतत DFS समस्या असणाऱ्या साईट्ससाठी हा दीर्घकालीन उपाय ठरतो.
सोडवलेली उदाहरणे
ETSI क्षेत्रात असलेल्या, वेदर रडार असलेल्या विमानतळापासून 3 किमी अंतरावर असलेल्या एका 180 खोल्यांच्या हॉटेलमध्ये, पश्चिमेकडील वरच्या मजल्यावरील पाहुण्यांनी बहुतांश दुपारी कनेक्शन तुटत असल्याची तक्रार केली. टीमने काय बदल केले पाहिजेत?
इव्हेंट लॉगवरून असे दिसून आले की एका आठवड्यात 46 पैकी 11 APs वर एकूण 63 radar events झाले, जे सर्व चॅनल 120 ते 128 वर होते. हवामान चॅनलवर केंद्रित असलेले अनेक शेजारील APs हे मूळ वेदर रडार दर्शवतात, चुकीचे सिग्नल (false positives) नाही. टीमने केवळ त्या 11 APs ला वेदर चॅनल वगळणाऱ्या प्रोफाइलवर हलवले आणि 40 MHz विड्थ सेट केली. इतर 35 APs ने प्रत्येक DFS चॅनल राखून ठेवला, ज्यामुळे क्षमता सुरक्षित राहिली. पुढील चार आठवड्यांत हॉटेलमध्ये एकही radar event नोंदवला गेला नाही. फ्रंट डेस्कवरील WiFi तक्रारी दर आठवड्याला 14 वरून थेट दोनवर आल्या.
120 स्टोअर्सच्या रिटेल साखळीतील एका स्टोअरने दोन आठवड्यांत चॅनल 52, 100 आणि 116 वर 30 radar events ची नोंद केली. त्याच स्टोअरमधील शेजारील APs वर एकही नोंद झाली नाही. टीमने यावर काय उपाय करावा?
शेजारील AP शांत असताना एकाच AP वर वेगवेगळ्या चॅनलवर वारंवार इव्हेंट होणे, हे चुकीचे सिग्नल (false positive) चे लक्षण आहे. चॅनल वगळल्यास मूळ समस्येचे निवारण न होता क्षमता गमावली गेली असती. या AP मॉडेलच्या रिलीज नोट्समध्ये DFS शोध दुरुस्ती (fix) नमूद केली होती, म्हणून टीमने आधी फर्मवेअर अपग्रेड केले. तरीही इव्हेंट्स सुरूच राहिले, ज्यामुळे वॉरंटी अंतर्गत AP बदलण्यात आला. स्टोअरमधील radar events शून्यावर आले आणि बिलिंग काउंटर जवळील ग्राहकांचे कनेक्शन तुटणे थांबले. संपूर्ण नेटवर्कने सर्व 19 चॅनल राखून ठेवले.
एका कौन्सिल IT टीमने व्यावसायिक बंदराजवळील ऑफिसमध्ये DFS बंद करण्याचे नियोजित केले कारण कर्मचारी आणि अभ्यागतांनी वारंवार कनेक्शन तुटत असल्याची तक्रार केली होती. हा निर्णय योग्य होता का?
केवळ जवळील अंतर हे कारण असू शकत नाही, कारण अनेक सागरी रडार 5GHz च्या बाहेर कार्य करतात. टीमने 30 दिवसांचे लॉग तपासले आणि त्यांना एकही radar event आढळला नाही. शेजारील भाडेकरूच्या नेटवर्कला प्रतिसाद देणाऱ्या प्लॅनरमुळे चॅनल बदल झाले होते. DFS बंद केल्याने नेटवर्क क्षमता नष्ट झाली असती आणि मूळ त्रुटी तशीच राहिली असती. टीमने DFS चालू ठेवले, ट्रान्समिट पॉवर कमी केली आणि चॅनल प्लॅन दुरुस्त केला. साप्ताहिक कनेक्शन तुटण्याच्या तक्रारी नऊ वरून केवळ एकवर आल्या.
वारंवार विचारले जाणारे प्रश्न
Purple Guest WiFi आमच्या सध्याच्या Meraki, Aruba किंवा Ruckus ऍक्सेस पॉईंट्सवर काम करते का?
होय. Purple Guest WiFi हे एक हार्डवेअर-स्वतंत्र क्लाउड ओव्हरले आहे जे Cisco Meraki, HPE Aruba आणि Ruckus सह Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet वर चालते. तुम्ही तुमचे ऍक्सेस पॉईंट्स, कंट्रोलर्स आणि RF कॉन्फिगरेशन तसेच ठेवू शकता. Purple यामध्ये अतिथी लॉगिन, जाणीवपूर्वक पर्याय निवडणे आणि फर्स्ट-पार्टी डेटाची जोड देते. जुने काढून नवीन टाकण्याची कोणतीही आवश्यकता नाही, आणि तुमचे DFS सेटिंग्ज तुमच्याच नियंत्रणात राहतात.
Purple आमच्या DFS किंवा चॅनल सेटिंग्समध्ये बदल करेल का?
नाही. Purple रेडिओ चॅनेल्स, चॅनेल विड्थ किंवा ट्रान्समिट पॉवर सेट करत नाही. ते Meraki Auto RF, Aruba ARM किंवा AirMatch आणि Ruckus ChannelFly किंवा BackgroundScanning मध्येच राहतात. Purple केवळ रेडिओ लेयरच्या वर अतिथी प्रमाणीकरण आणि डेटा कॅप्चर हाताळते. या वेगळेपणामुळे तुम्ही अतिथी लॉगिन अनुभवाला स्पर्श न करता तुमच्या वेंडर डॅशबोर्डमधील DFS समस्या सोडवू शकता आणि RF सेटिंग्जला स्पर्श न करता लॉगिन सेटिंग्ज बदलू शकता.
DFS चॅनेल्स अक्षम (disable) करणे नियमांनुसार वैध आहे का?
होय. ETSI EN 301 893 आणि FCC Part 15.407 नुसार तुम्ही वापरत असलेल्या कोणत्याही DFS चॅनलवर रडार शोधणे आवश्यक आहे. यापैकी कशामध्येही तुम्हाला DFS चॅनेल्स वापरण्याची सक्ती नाही. त्यांना वगळणे हे नेहमीच नियमांचे पालन करणारे ठरते. तुम्ही कधीही करू नये अशी गोष्ट म्हणजे शोध कार्य अक्षम (disabled) ठेवून DFS चॅनलवर कार्य करणे. हे चॅनेल्स वगळण्याची खरी किंमत क्षमतेच्या (capacity) स्वरूपात मोजावी लागते: ETSI क्षेत्रांमध्ये, प्रत्येक DFS चॅनल वगळल्यास 19 ऐवजी केवळ चार 20 MHz चॅनेल्स उरतात.
DFS समस्या टाळण्यासाठी आम्हाला नवीन ऍक्सेस पॉईंट्सची गरज आहे का?
सहसा नाही. बहुतेक DFS समस्या कॉन्फिगरेशनद्वारे सोडवल्या जातात: प्रभावित APs वरील वेदर चॅनेल्स वगळणे, चॅनलची रुंदी कमी करणे किंवा फर्मवेअर अपडेट करणे. जेव्हा फर्मवेअर अपडेटनंतरही एखादे रेडिओ सतत चुकीचे सिग्नल (false positives) देत राहते किंवा तुम्ही 6GHz क्षमता जोडत असता, तेव्हा ते बदलणे फायदेशीर ठरते. 6GHz बँडमध्ये कोणतीही DFS आवश्यकता नसते, त्यामुळे WiFi 6E आणि WiFi 7 ऍक्सेस पॉईंट्स त्यांना सपोर्ट करणाऱ्या क्लायंट्ससाठी रडार शिफ्ट्सची समस्या पूर्णपणे दूर करतात.
DFS चॅनेल्स वगळल्याने एखाद्या गर्दीच्या ठिकाणी गेस्ट WiFi ला फटका बसेल का?
होय, जर तुम्ही त्यांना संपूर्ण साईटवर वगळले तर. ETSI क्षेत्रामध्ये, चार 20 MHz चॅनेल्स स्टेडियम, कॉन्फरन्स सेंटर किंवा मोठ्या हॉटेलमधील डझनभर APs वेगळे करू शकत नाहीत. परिणामी APs एअरटाइम शेअर करतात आणि प्रत्येक गेस्टसाठी थ्रूपुट कमी होतो. केवळ रडार लॉग करणाऱ्या APs वर चॅनेल्स वगळा आणि इतर सर्व ठिकाणी DFS सुरू ठेवा. हा दृष्टिकोन क्षमतेचा बळी न देता समस्येवर नियंत्रण मिळवतो.
यूके, युरोप आणि यूएस मधील DFS नियम एकमेकांपासून भिन्न आहेत का?
होय. यूके आणि ईयू ETSI EN 301 893 चे पालन करतात, जे चॅनल 52 ते 64 आणि 100 ते 140 वर DFS लागू करते. यामध्ये वेदर चॅनेल्स 120, 124 आणि 128 वर 10 मिनिटांची उपलब्धता तपासणी देखील आवश्यक आहे. यूएस FCC Part 15.407 चे पालन करते, जे चॅनल 144 जोडते आणि नऊ नॉन-DFS चॅनेल्स सोडते. दोन्ही नियमांमध्ये रडार आढळल्यानंतर किमान 30 मिनिटे नॉन-ऑक्युपन्सी आवश्यक आहे.
एक MSP वेगवेगळ्या व्हेंडर्सच्या इन्फ्रास्ट्रक्चरमधील DFS इव्हेंट्सचे निदान करू शकतो का?
होय, परंतु रडार इव्हेंट्स प्रत्येक व्हेंडरच्या स्वतःच्या टूलिंगमध्ये असतात: Meraki इव्हेंट लॉग, Aruba ARM हिस्टरी किंवा AirMatch इव्हेंट्स, आणि SmartZone इव्हेंट्स आणि अलार्म्स. MSP ने टूलऐवजी चेकलिस्टचे मानकीकरण केले पाहिजे आणि प्रत्येक घटनेची वेळ, चॅनल, AP संख्या आणि कारण नोंदवले पाहिजे. Purple तुम्हाला या सर्व व्हेंडर्समध्ये गेस्ट ऍक्सेससाठी एकच प्लॅटफॉर्म प्रदान करते, तर RF निदान प्रत्येक कंट्रोलरमध्येच राहते.
या मालिकेमध्ये पुढे वाचा
जेव्हा Cisco Meraki WiFi 6 ची विक्री संपुष्टात येईल, तेव्हा WiFi 6 वरून WiFi 7 ऍक्सेस पॉईंट रिफ्रेशचे नियोजन करणे
हे तांत्रिक संदर्भ मल्टि-साइट ऑपरेटरना ३१ डिसेंबर २०२६ च्या अंतिम-ऑर्डर तारखेपूर्वी Cisco Meraki WiFi 6 वरून WiFi 7 रिफ्रेश करण्यासाठी निर्णय फ्रेमवर्क प्रदान करते. हे इस्टेट आणि बॅकहॉल नियोजनाला Meraki Dashboard तपासणीसह जोडते जे प्रत्येक ऍक्सेस पॉईंट बदलताना Purple ऑथेंटिकेशन आणि लोकेशन-ॲनालिटिक्सची सुसंगतता सुरक्षित ठेवते.
GDPR आणि Guest WiFi: व्हेन्यू मार्केटर्स आणि IT साठी अनुपालन मार्गदर्शक
हे तांत्रिक मार्गदर्शक व्हेन्यू IT आणि मार्केटिंग टीम्सना captive portal ला अनुपालनाची दुर्लक्षित जागा न बनवता, GDPR अंतर्गत Guest WiFi डेटा संकलनाचे व्यवस्थापन कसे करावे हे दाखवते. हे नेटवर्क ऍक्सेस, प्रायव्हसी माहिती, पर्यायी मार्केटिंग निवडी आणि CRM फ्लो या गोष्टी वेगळ्या करते, आणि नंतर Purple Connect, Capture आणि Engage चे या ऑपरेशनल निर्णयांसह मॅपिंग करते.
Cisco Catalyst WLC आणि अतिथी WiFi: Purple सह कॅप्टिव्ह पोर्टल सेटअप
Cisco Catalyst 9800 (IOS-XE) वायरलेस LAN कंट्रोलर Purple अतिथी WiFi सह कसे कार्य करतो: बाह्य वेब प्रमाणीकरण, RADIUS आणि वॉल्ड गार्डन, अचूक कॉन्फिगरेशनसाठी Purple च्या टप्प्याटप्प्याने सेटअप मार्गदर्शिकेच्या लिंकसह.
तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?
आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.