Cisco Meraki, HPE Aruba এবং Ruckus-এ DFS রাডার ইভেন্ট: চ্যানেল পরিবর্তনের জন্য একটি ডায়াগনস্টিকস চেকলিস্ট

Cisco Meraki, HPE Aruba, বা Ruckus WiFi নেটওয়ার্কে IEEE 802.11h স্ট্যান্ডার্ডের অধীনে পরিচালিত DFS রাডার ইভেন্টগুলি নির্ণয় এবং সমাধান করতে, রাডার সনাক্তকরণের জন্য আপনার কন্ট্রোলার লগগুলি বিশ্লেষণ করুন। একবার সনাক্ত করা হলে, অ্যাক্সেস পয়েন্টটিকে অবশ্যই ১০ সেকেন্ডের মধ্যে 5GHz চ্যানেলটি খালি করতে হবে এবং ৩০ মিনিটের জন্য এটি থেকে দূরে থাকতে হবে।

আপনার 5GHz নেটওয়ার্কে একটি DFS রাডার ইভেন্ট দেখতে কেমন লাগে?

Dynamic Frequency Selection (DFS) এর মাধ্যমে WiFi রাডারের সাথে 5GHz ব্যান্ডের কিছু অংশ শেয়ার করতে পারে। IEEE 802.11h এই প্রক্রিয়াটিকে সংজ্ঞায়িত করে। নিয়ন্ত্রকেরা সময় নির্ধারণ করেন: মার্কিন যুক্তরাষ্ট্রে FCC-এর 47 CFR Part 15.407 এর অধীনে এবং ইউরোপ জুড়ে ETSI EN 301 893 এর অধীনে। ETSI অঞ্চলে, ৫২ থেকে ৬৪ এবং ১০০ থেকে ১৪০ নম্বর চ্যানেলগুলি হল DFS চ্যানেল। FCC নিয়মগুলি ১৪৪ নম্বর চ্যানেলকেও যুক্ত করে।

যখন একটি অ্যাক্সেস পয়েন্ট (AP) রাডার সনাক্ত করে, তখন এর ধাপগুলি নির্দিষ্ট থাকে:

1. সনাক্তকরণ (Detection): রেডিওটি তার অপারেটিং চ্যানেলে একটি পালস প্যাটার্নকে একটি রাডার সিগনেচারের সাথে মিলিয়ে দেখে।
2. চ্যানেল পরিবর্তন ঘোষণা (CSA): AP তার বিকনগুলিতে একটি CSA উপাদান যুক্ত করে, যা ক্লায়েন্টদের নতুন চ্যানেল এবং স্থানান্তরের কাউন্টডাউন সম্পর্কে জানায়।
3. চ্যানেল স্থানান্তর (Channel move): রেডিওটিকে অবশ্যই ১০ সেকেন্ডের মধ্যে সেই চ্যানেলে ট্রান্সমিট করা বন্ধ করতে হবে।
4. অনুপস্থিতি সময়কাল (Non-occupancy period): চ্যানেলটি কমপক্ষে ৩০ মিনিটের জন্য নিষিদ্ধ থাকে।
5. চ্যানেল উপলব্ধতা পরীক্ষা (CAC): একটি DFS চ্যানেল চালু হওয়ার আগে, রেডিওটি কমপক্ষে ৬০ সেকেন্ডের জন্য সিগন্যাল শোনে। ETSI অঞ্চলে, ১২০, ১২৪ এবং ১২৮ নম্বর চ্যানেলগুলি (৫৬০০ - ৫৬৫০ MHz) আবহাওয়া রাডারের সাথে শেয়ার করা হয় এবং সেখানে এই পরীক্ষাটি ১০ মিনিট স্থায়ী হয়।

অতিথিরা কী ধরণের অভিজ্ঞতার মুখোমুখি হবেন তা তাদের ডিভাইসের উপর নির্ভর করে। যে সমস্ত ক্লায়েন্ট CSA মেনে চলে তারা সামান্য বিরতি সহ AP-কে অনুসরণ করে। যে সমস্ত ক্লায়েন্ট এটি উপেক্ষা করে তারা সংযোগ হারায়, আবার স্ক্যান করে এবং পুনরায় যুক্ত হয়, প্রায়শই 2.4GHz-এ বা কোনো প্রতিবেশী AP-তে। যদি AP এমন একটি DFS চ্যানেলে স্থানান্তরিত হয় যা এখনও পরীক্ষা পাস করেনি, তবে 5GHz রেডিওটি এক মিনিট বা তার বেশি সময়ের জন্য নিষ্ক্রিয় থাকতে পারে।

যে প্যাটার্নটি লক্ষ্য করতে হবে:

• একটি নির্দিষ্ট AP বা প্রতিবেশী AP-এর একটি গ্রুপের প্রতিটি ক্লায়েন্ট একই মুহূর্তে বিচ্ছিন্ন হয়ে যায়।
• AP একটি ভিন্ন চ্যানেলে ফিরে আসে, প্রায়শই ৩৬ থেকে ৪৮ এর মধ্যে থাকা একটি নন - DFS চ্যানেলে।
• পরিবর্তনটি আপনার নির্ধারিত চ্যানেল অপ্টিমাইজেশান উইন্ডোর বাইরে ঘটে।
• একই AP গুলি এই প্যাটার্নের পুনরাবৃত্তি করে, কখনও কখনও দিনের একই সময়ে।
• 2.4GHz লোড হঠাৎ বৃদ্ধি পায় যখন 5GHz ক্লায়েন্টরা অদৃশ্য হয়ে যায়।

সাধারণত কী কারণে DFS চ্যানেল পরিবর্তন হয়?

আসল রাডার

ইউরোপে ৫৬০০ - ৫৬৫০ MHz রেঞ্জের আবহাওয়া রাডারগুলি একটি সাধারণ আসল উৎস। মার্কিন যুক্তরাষ্ট্রে, প্রধান বিমানবন্দরগুলির Terminal Doppler Weather Radar (TDWR) একই রেঞ্জ ব্যবহার করে। দূরত্বের চেয়ে সরাসরি দৃষ্টিসীমা (Line of sight) বেশি গুরুত্বপূর্ণ। আউটডোর AP, উপরের তলা এবং কাঁচের দেয়াল বিশিষ্ট ভবনগুলি এমন রাডার সনাক্ত করে যা নিচতলার AP গুলি কখনই দেখতে পায় না।

শুধুমাত্র কাছাকাছি থাকাটা খুব কমই নির্দেশ করে। অনেক বিমানবন্দর নজরদারি এবং সামুদ্রিক নেভিগেশন রাডার অন্যান্য ব্যান্ডে কাজ করে, যা 5GHz-এর অনেক বাইরে। একটি বন্দরের পাশে অবস্থিত একটি ভেন্যুতে কখনও একটি রাডার ইভেন্টও লগ নাও হতে পারে। আপনার ইভেন্ট লগই আসল প্রমাণ, মানচিত্র নয়।

ভুল সনাক্তকরণ (False positives)

একটি DFS ফলস পজিটিভ হল কোনো রাডার উপস্থিত না থাকা সত্ত্বেও রাডার সনাক্তকরণ। রেডিওটি শক্তির একটি হঠাৎ প্রবাহকে রাডার পালস প্যাটার্ন হিসাবে ভুল ব্যাখ্যা করে। সাধারণ কারণগুলির মধ্যে রয়েছে:

• ওয়্যারলেস ভিডিও লিঙ্ক বা ত্রুটিপূর্ণ সরঞ্জাম থেকে পালসড অ-WiFi হস্তক্ষেপ;
• কাছাকাছি কোনো AP বা সংলগ্ন চ্যানেলে পয়েন্ট-টু-পয়েন্ট লিঙ্ক থেকে শক্তিশালী ট্রান্সমিশন;
• রেডিও বা ফার্মওয়্যার ত্রুটি, যা বিক্রেতারা সফ্টওয়্যার রিলিজে সংশোধন করে থাকেন।

এর আসল প্রমাণ হলো আইসোলেশন। একই আকাশের দৃশ্যমানতা থাকা সত্ত্বেও প্রতিবেশী ডিভাইসগুলো কোনো লগ না রাখলেও, একটি নির্দিষ্ট AP বিভিন্ন চ্যানেলে বারবার ঘটনার লগ তৈরি করে।

চওড়া চ্যানেলগুলো প্রকৃত এবং মিথ্যা উভয় প্রকার সনাক্তকরণের ঝুঁকি বাড়িয়ে দেয়। একটি 80 MHz চ্যানেল চারটি 20 MHz উপ-চ্যানেল জুড়ে বিস্তৃত থাকে, এবং এর যেকোনো একটিতে কোনো সনাক্তকরণ ঘটলে পুরো চ্যানেলটি স্থানান্তরিত হয়।

রাডার ছাড়া অন্য পরিবর্তন যা দেখতে একই রকম

হস্তক্ষেপ এবং লোডের কারণে চ্যানেল প্ল্যানাররা রেডিও স্থানান্তর করে। Meraki Auto RF, Aruba ARM এবং AirMatch, এবং Ruckus ChannelFly এবং BackgroundScanning সবই রাডার ছাড়াই চ্যানেল পরিবর্তন করে। AP রিবুট এবং পাওয়ার পরিবর্তনের ফলেও ক্লায়েন্টরা সংযোগ বিচ্ছিন্ন হয়। এই ত্রুটিগুলোর জন্য ভিন্ন ভিন্ন সমাধানের প্রয়োজন হয়, তাই কোনো কিছু বাদ দেওয়ার আগে কারণটি নিশ্চিত করুন।

কীভাবে বুঝবেন যে রাডারের কারণেই এই বিভ্রাট ঘটেছে?

ক্রমানুসারে এই চেকলিস্টটি অনুসরণ করুন:

1. অভিযোগের স্থান ও সময় নির্দিষ্ট করুন। মিনিট অনুযায়ী সঠিক সময় এবং রুম, ফ্লোর বা জোন চিহ্নিত করুন।
2. চ্যানেল পরিবর্তনের ইভেন্টগুলো সংগ্রহ করুন যা ওই এলাকায় পরিষেবা প্রদানকারী AP-গুলোর জন্য এক ঘণ্টা আগে বা পরের ঘটনা দেখাবে।
3. লগ করা কারণটি পড়ুন। একটি রাডার বা DFS কারণ প্রকৃত উৎস নিশ্চিত করে। একটি হস্তক্ষেপ, নয়েজ বা অপ্টিমাইজেশান সংক্রান্ত কারণ এটিকে নাকচ করে দেয়।
4. চ্যানেলটি নোট করুন। ১২০, ১২৪ এবং ১২৮ চ্যানেলে পুঞ্জীভূত ঘটনাগুলো আবহাওয়া রাডারের দিকে নির্দেশ করে।
5. আক্রান্ত AP-গুলোর সংখ্যা গণনা করুন। একসাথে বেশ কয়েকটি প্রতিবেশী ডিভাইস আক্রান্ত হলে তা প্রকৃত রাডারের ইঙ্গিত দেয়। কেবল একটি মাত্র AP আক্রান্ত হলে তা ফলস পজিটিভের সম্ভাবনা নির্দেশ করে।
6. সাপ্তাহিক প্যাটার্ন খুঁজুন। নিয়মিত পুনরাবৃত্তি একটি নির্দিষ্ট সময়সূচী বা সুইপ সহ রাডারের উপস্থিতি নির্দেশ করে।
7. চ্যানেলের প্রস্থ পরীক্ষা করুন। কেবল ৮০ বা ১৬০ MHz চ্যানেলে ঘটা ঘটনাগুলো প্রমাণ করে যে চ্যানেলের প্রস্থও এই সমস্যার অংশ।
8. আপনার AP মডেলের DFS সনাক্তকরণ সমাধানের জন্য ফার্মওয়্যার রিলিজ নোটগুলো পড়ুন।

আপনি যদি Purple গেস্ট WiFi ব্যবহার করেন, তবে ভেন্যু অনুযায়ী লগইন ভলিউম আপনাকে ক্রস-চেক করার সুবিধা দেবে। একটি রাডার ইভেন্টের সাথে মিলে যাওয়া কোনো একটি সাইটের তীব্র হ্রাস গেস্টদের উপর প্রভাব নিশ্চিত করে।

Meraki, Aruba এবং Ruckus-এ কীভাবে DFS ইভেন্টগুলো সমাধান করবেন?

বিক্রেতা	যেখানে রাডার ইভেন্টগুলো প্রদর্শিত হয়	চ্যানেল প্ল্যানার	যেখানে আপনি চ্যানেলগুলো সীমাবদ্ধ করবেন
Cisco Meraki	DFS ইভেন্টের জন্য ফিল্টার করা ওয়্যারলেস ইভেন্ট লগ; প্রতি AP-তে RF স্পেকট্রাম পেজ	Auto RF	RF প্রোফাইল চ্যানেল তালিকা, যা আক্রান্ত AP-গুলোতে প্রয়োগ করা হয়েছে
HPE Aruba	কন্ট্রোলার বা Instant ক্লাস্টারে 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 থেকে সমস্যাযুক্ত চ্যানেলগুলো সরিয়ে দিন। সেই প্রোফাইলটি শুধুমাত্র আক্রান্ত AP-গুলোর ক্ষেত্রে প্রয়োগ করুন। Meraki-এর নিজস্ব DFS ডকুমেন্টেশনে এই সংক্রান্ত সঠিক পদক্ষেপগুলো আলোচনা করা হয়েছে।

HPE Aruba

ARM ইতিহাস প্রতিটি চ্যানেল পরিবর্তনের কারণসহ তালিকাভুক্ত করে এবং রাডার সনাক্তকরণ একটি সুনির্দিষ্ট কারণ হিসেবে প্রদর্শিত হয়। AirMatch কেন্দ্রীয়ভাবে চ্যানেল প্ল্যান তৈরি করে, কিন্তু একটি রাডার হিট AP-কে সরাসরি স্থানান্তরিত হতে বাধ্য করে। তাই একটি DFS চ্যানেলে বিকেলের মাঝামাঝি সময়ে একটি অপ্রত্যাশিত পরিবর্তন একটি বড় সংকেত। শুধুমাত্র আক্রান্ত AP-গুলো ধারণকারী একটি AP গ্রুপের জন্য রেডিও প্রোফাইলে চ্যানেলগুলো সীমাবদ্ধ করুন। যদি গেস্টরা পুনরায় সংযুক্ত হওয়ার পর একটি লগইন পেজে ফিরে যায়, তবে সেটি একটি আলাদা সমস্যা: HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist দেখুন।

Ruckus

যখন কোনো AP রাডার সনাক্ত করে, তখন SmartZone একটি ইভেন্ট তৈরি করে, যেখানে AP এবং চ্যানেলের নাম উল্লেখ থাকে। নির্দিষ্ট উইন্ডোর জন্য ইভেন্ট এবং অ্যালার্মগুলো পরীক্ষা করুন, তারপর সেগুলোকে ChannelFly বা BackgroundScanning অ্যাক্টিভিটির সাথে তুলনা করুন। কোনো রাডার ইভেন্ট ছাড়াই একটি Ruckus DFS চ্যানেল পরিবর্তন হলো প্ল্যানারের সিদ্ধান্ত, DFS নয়। একটি ডেডিকেটেড জোন বা AP গ্রুপের জন্য রেডিও সেটিংসে সমস্যাযুক্ত চ্যানেলগুলো সরিয়ে দিন।

তিনটি প্ল্যাটফর্মেরই শুধুমাত্র আক্রান্ত AP-গুলোতে পরিবর্তন করুন। সাইট-ব্যাপী এটি বাদ দিলে এমন সব AP-তেও ক্যাপাসিটি কমে যায় যা কখনোই রাডার দেখেনি।

বিমানবন্দর, বন্দর বা আবহাওয়া রাডারের কাছাকাছি আপনার কি DFS চ্যানেল নিষ্ক্রিয় করা উচিত?

ডিফল্ট হিসেবে নয়। একটি ETSI অঞ্চলে প্রতিটি DFS চ্যানেল বাদ দিলে মাত্র চারটি 20 MHz চ্যানেল বাকি থাকে: 36, 40, 44 এবং 48। FCC নিয়মে নয়টি বাকি থাকে, যা 149 থেকে 165 পর্যন্ত যোগ করে। একটি উচ্চ-ঘনত্বপূর্ণ ভেন্যুতে, চারটি চ্যানেল AP-গুলোকে এয়ারটাইম শেয়ার করতে বাধ্য করে এবং প্রতিটি ক্লায়েন্টকে ধীরগতির করে দেয়। লগ দেখে সিদ্ধান্ত নিতে দিন।

আপনার লগ যা দেখায়	সম্ভাব্য কারণ	সুপারিশ	অবশিষ্ট 20 MHz চ্যানেল (ETSI / FCC)
কাছাকাছি কয়েকটি AP-তে ইভেন্ট, যা 120-128 এর মধ্যে ক্লাস্টারড	আবহাওয়া রাডার	আক্রান্ত AP-গুলোতে 120, 124 এবং 128 বাদ দিন	16 / 22
প্রতিদিন অনেক AP জুড়ে বেশিরভাগ DFS চ্যানেলে ইভেন্ট	কাছাকাছি শক্তিশালী রাডার	শুধুমাত্র আক্রান্ত AP-গুলোতে DFS বাদ দিন; অন্য জায়গায় এটি চালু রাখুন	আক্রান্ত AP-গুলোতে 4 / 9
একটি AP-তে বারবার ইভেন্ট, ভিন্ন ভিন্ন চ্যানেলে	ফলস পজিটিভ	ফার্মওয়্যার আপডেট করুন, রেডিও পরীক্ষা করুন বা প্রতিস্থাপন করুন, DFS চালু রাখুন	19 / 25
শুধুমাত্র 80 বা 160 MHz চ্যানেলে ইভেন্ট	উইডথ এক্সপোজার	40 বা 20 MHz-এ কমিয়ে আনুন, DFS চালু রাখুন	19 / 25
চ্যানেল পরিবর্তন হয়েছে কিন্তু কোনো রাডার এন্ট্রি নেই	প্ল্যানার বা ইন্টারফেয়ারেন্স	ইন্টারফেয়ারেন্স এবং পাওয়ার ঠিক করুন, DFS চালু রাখুন	19 / 25

একটি বাস্তব উদাহরণ: একটি আঞ্চলিক বিমানবন্দরের কাছে অবস্থিত হোটেল

একটি আবহাওয়া রাডারযুক্ত বিমানঘাঁটি থেকে ৩ কিমি দূরে ETSI অঞ্চলের একটি ১৮০ কক্ষের হোটেল অবস্থিত ছিল। পশ্চিমমুখী উপরের তলার অতিথিরা বেশিরভাগ বিকেলে সংযোগ বিচ্ছিন্ন হওয়ার রিপোর্ট করেছিলেন। ইভেন্ট লগটি এক সপ্তাহে ৪৬টি AP-এর মধ্যে ১১টিতে ৬৩টি রাডার ইভেন্ট দেখিয়েছে, যার সবগুলোই ১২০ থেকে ১২৮ চ্যানেলে ছিল। টিম সেই ১১টি AP-কে আবহাওয়া চ্যানেলগুলি বাদ দিয়ে একটি প্রোফাইলে স্থানান্তরিত করেছে এবং ৪০ MHz প্রস্থ সেট করেছে। পরবর্তী চার সপ্তাহে হোটেলটিতে কোনো রাডার ইভেন্ট লগ করা হয়নি। ফ্রন্ট ডেস্কে WiFi সংক্রান্ত অভিযোগ সপ্তাহে ১৪টি থেকে কমে দুটিতে নেমে এসেছে। অন্য ৩৫টি AP প্রতিটি DFS চ্যানেল বজায় রেখেছে। হোটেল স্থাপনার বিষয়ে আরও জানতে, Hotels দেখুন।

বাস্তব পরিস্থিতি: একটি কোলাহলপূর্ণ AP সহ একটি খুচরা চেইন

একটি ১২০-দোকানের খুচরা চেইন দেখেছে যে একটি দোকানে দুই সপ্তাহে ৫২, ১০০ এবং ১১৬ চ্যানেলে ৩০টি রাডার ইভেন্ট লগ হয়েছে। একই দোকানের প্রতিবেশী AP-গুলি কোনো ইভেন্ট লগ করেনি, যা একটি মিথ্যা ইতিবাচক সংকেত নির্দেশ করে। AP মডেলটির রিলিজ নোটে একটি DFS সনাক্তকরণ সংশোধন তালিকাভুক্ত ছিল, তাই টিম ফার্মওয়্যার আপগ্রেড করেছে। ইভেন্টগুলি চলতেই থাকে এবং ওয়ারেন্টির অধীনে AP-টি প্রতিস্থাপন করা হয়। দোকানে রাডার ইভেন্টগুলি শূন্যে নেমে এসেছে এবং ক্রেতারা ক্যাশ কাউন্টার এলাকায় সংযোগ হারানো বন্ধ করে দিয়েছেন। এস্টেটটি সমস্ত ১৯টি চ্যানেলই বজায় রেখেছে। বহু-সাইট গেস্ট অ্যাক্সেসের জন্য Retail দেখুন।

বাস্তব পরিস্থিতি: একটি বন্দরের পাশে কাউন্সিলের অফিস

একটি কাউন্সিলের IT টিম একটি বাণিজ্যিক বন্দরের পাশে অবস্থিত অফিসে DFS নিষ্ক্রিয় করার পরিকল্পনা করেছিল। ত্রিশ দিনের লগে কোনো রাডার ইভেন্টই দেখা যায়নি। চ্যানেলের পরিবর্তনগুলি একজন প্রতিবেশী ভাড়াটিয়ার নেটওয়ার্কের প্রতি পরিকল্পনাকারীর প্রতিক্রিয়া থেকে এসেছে। টিম DFS বজায় রেখেছে, ট্রান্সমিট পাওয়ার কমিয়েছে এবং চ্যানেল প্ল্যান ঠিক করেছে। সাপ্তাহিক ড্রপ রিপোর্ট নয়টি থেকে কমে একটিতে নেমে এসেছে।

কীভাবে আপনি DFS ইভেন্টগুলিকে অতিথিদের আবার বিঘ্নিত করা থেকে রক্ষা করবেন?

• ঘনবসতিপূর্ণ ভেন্যুতে ২০ বা ৪০ MHz চ্যানেল ব্যবহার করুন। সংকীর্ণ চ্যানেলগুলি এক্সপোজার কমায় এবং পুনরায় ব্যবহার যোগ করে।
• যেখানে ইভেন্টগুলি ১২০ থেকে ১২৮-এর মধ্যে ক্লাস্টার করে, সেখানে শুধুমাত্র আক্রান্ত AP-গুলিতে সার্জিক্যালি আবহাওয়া চ্যানেলগুলি বাদ দিন।
• ফার্মওয়্যার আপ-টু-ডেট রাখুন এবং প্রতিটি রিলিজ নোটে DFS সংশোধনগুলি পড়ুন।
• মাসিক DFS ইভেন্টগুলি পর্যালোচনা করুন, এবং সপ্তাহে মুষ্টিমেয়ের বেশি লগ করা যেকোনো AP-তে অ্যালার্ট পান।
• 6GHz-এর জন্য পরিকল্পনা করুন। 6GHz ব্যান্ডে কোনো DFS প্রয়োজনীয়তা নেই, তাই WiFi 6E এবং WiFi 7 ক্লায়েন্টরা রাডার স্থানান্তর সম্পূর্ণভাবে এড়িয়ে যায়।
• 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 চ্যানেল সরিয়ে ফেললে ১৯টির পরিবর্তে মাত্র চারটি 20 MHz চ্যানেল অবশিষ্ট থাকে।

DFS সমস্যা এড়ানোর জন্য আমাদের কি নতুন অ্যাক্সেস পয়েন্টের প্রয়োজন?

সাধারণত নয়। বেশিরভাগ DFS সমস্যা কনফিগারেশনের মাধ্যমে সমাধান করা হয়: ক্ষতিগ্রস্থ AP-গুলিতে ওয়েদার চ্যানেলগুলি বাদ দেওয়া, চ্যানেলের উইথ সংকীর্ণ করা বা ফার্মওয়্যার আপডেট করা। প্রতিস্থাপন তখন অর্থবহ হয় যখন একটি রেডিও ফার্মওয়্যার আপডেটের পরেও ভুল পজিটিভ ফলাফল দেখাতে থাকে, অথবা যখন আপনি 6GHz ধারণক্ষমতা যোগ করেন। 6GHz ব্যান্ডে কোনো DFS প্রয়োজনীয়তা নেই, তাই WiFi 6E এবং WiFi 7 অ্যাক্সেস পয়েন্টগুলি এটি সমর্থন করে এমন ক্লায়েন্টদের জন্য রাডার সরানোর ঝামেলা দূর করে।

DFS চ্যানেলগুলি বাদ দিলে কি একটি ব্যস্ত ভেন্যুতে গেস্ট WiFi ক্ষতিগ্রস্ত হবে?

হ্যাঁ, যদি আপনি সেগুলিকে পুরো সাইট জুড়ে বাদ দেন। একটি ETSI অঞ্চলে, চারটি 20 MHz চ্যানেল একটি স্টেডিয়াম, কনফারেন্স সেন্টার বা বড় হোটেলে কয়েক ডজন AP-কে আলাদা করতে পারে না। AP-গুলি এয়ারটাইম শেয়ার করতে বাধ্য হয় এবং প্রত্যেক গেস্টের জন্য থ্রুপুট হ্রাস পায়। কেবল রাডার লগ করা AP-গুলিতেই চ্যানেলগুলি বাদ দিন এবং অন্য সব জায়গায় DFS চালু রাখুন। এই পদ্ধতিটি ধারণক্ষমতা না কমিয়েই সমস্যার সমাধান করে।

UK, ইউরোপ এবং US-এর মধ্যে কি DFS নিয়মগুলি আলাদা?

হ্যাঁ। UK এবং EU, ETSI EN 301 893 অনুসরণ করে, যা ৫২ থেকে ৬৪ এবং ১০০ থেকে ১৪০ নম্বর চ্যানেলে DFS প্রয়োগ করে। এর জন্য ১২০, ১২৪ এবং ১২৮ নম্বর ওয়েদার চ্যানেলগুলিতে ১০ মিনিটের একটি অ্যাভেলেবিলিটি চেক প্রয়োজন। US, FCC Part 15.407 অনুসরণ করে, যা ১৪৪ নম্বর চ্যানেল যোগ করে এবং নয়টি নন-DFS চ্যানেল রাখে। উভয় ক্ষেত্রেই সনাক্তকরণের পরে কমপক্ষে ৩০ মিনিটের নন-অকুপেন্সি প্রয়োজন।

একজন MSP কি একটি মিক্সড-ভেন্ডর এস্টেট জুড়ে DFS ঘটনাগুলি সনাক্ত করতে পারেন?

হ্যাঁ, তবে রাডার ইভেন্টগুলি প্রতিটি ভেন্ডরের নিজস্ব টুলের মধ্যে থাকে: Meraki ইভেন্ট লগ, Aruba ARM হিস্ট্রি বা AirMatch ইভেন্ট, এবং SmartZone ইভেন্ট ও অ্যালার্ম। একজন MSP-এর উচিত টুলের পরিবর্তে চেকলিস্টটিকে মানক করা এবং প্রতিটি ঘটনার সময়, চ্যানেল, AP কাউন্ট এবং কারণ রেকর্ড করা। Purple আপনাকে সেই সমস্ত ভেন্ডর জুড়ে গেস্ট অ্যাক্সেসের জন্য একটি সিঙ্গেল প্ল্যাটফর্ম দেয়, অন্যদিকে RF ডায়াগনসিস প্রতিটি কন্ট্রোলারে থেকে যায়।