Cisco Meraki, HPE Aruba और Ruckus पर DFS रडार घटनाएं: चैनल परिवर्तनों के लिए एक नैदानिक चेकलिस्ट

Cisco Meraki, HPE Aruba, या Ruckus WiFi नेटवर्क पर, जो IEEE 802.11h मानक के तहत काम कर रहे हैं, DFS रडार घटनाओं का निदान और समाधान करने के लिए, रडार डिटेक्शन के लिए अपने कंट्रोलर लॉग का विश्लेषण करें। एक बार पता चलने पर, एक्सेस पॉइंट को 10 सेकंड के भीतर 5GHz चैनल को खाली करना होगा और 30 मिनट तक इससे बाहर रहना होगा।

आपके 5GHz नेटवर्क पर DFS रडार घटना कैसी दिखती है?

Dynamic Frequency Selection (DFS) WiFi को रडार के साथ 5GHz बैंड के कुछ हिस्सों को साझा करने की अनुमति देता है। IEEE 802.11h इस तंत्र को परिभाषित करता है। नियामक समय निर्धारित करते हैं: अमेरिका में FCC 47 CFR Part 15.407 के तहत, और पूरे यूरोप में ETSI EN 301 893 के तहत। ETSI क्षेत्रों में, चैनल 52 से 64 और 100 से 140 DFS चैनल हैं। FCC नियम चैनल 144 को जोड़ते हैं।

जब एक एक्सेस पॉइंट (AP) रडार का पता लगाता है, तो अनुक्रम निश्चित होता है:

1. डिटेक्शन (पता लगाना): रेडियो अपने ऑपरेटिंग चैनल पर पल्स पैटर्न को रडार सिग्नेचर से मिलाता है।
2. चैनल स्विच अनाउंसमेंट (CSA): AP अपने बीकन में एक CSA तत्व जोड़ता है, जिससे क्लाइंट्स को नया चैनल और वहां जाने का काउंटडाउन पता चलता है।
3. चैनल मूव (चैनल बदलना): रेडियो को 10 सेकंड के भीतर उस चैनल पर ट्रांसमिट करना बंद करना होगा।
4. नॉन-ऑक्यूपेंसी पीरियड (गैर-अधिभोग अवधि): चैनल कम से कम 30 मिनट के लिए सीमा से बाहर रहता है।
5. चैनल एवेलेबिलिटी चेक (CAC): एक DFS चैनल के सेवा में आने से पहले, रेडियो कम से कम 60 सेकंड के लिए सुनता है। ETSI क्षेत्रों में, चैनल 120, 124 और 128 (5600-5650 MHz) मौसम रडार के साथ साझा किए जाते हैं, और वहां जांच 10 मिनट तक चलती है।

मेहमानों को क्या अनुभव होता है यह उनके डिवाइस पर निर्भर करता है। जो क्लाइंट CSA का सम्मान करते हैं, वे थोड़े समय के विराम के साथ AP का अनुसरण करते हैं। जो क्लाइंट इसे अनदेखा करते हैं, वे कनेक्शन खो देते हैं, फिर से स्कैन करते हैं और फिर से जुड़ते हैं, अक्सर 2.4GHz या किसी पड़ोसी AP पर। यदि AP किसी ऐसे DFS चैनल पर जाता है जिसने अपनी जांच पास नहीं की है, तो 5GHz रेडियो एक मिनट या उससे अधिक समय तक शांत रह सकता है।

देखने योग्य पैटर्न:

• एक AP, या पड़ोसी APs के समूह पर मौजूद प्रत्येक क्लाइंट एक ही क्षण में डिस्कनेक्ट हो जाता है।
• AP एक अलग चैनल पर वापस आता है, जो अक्सर 36 और 48 के बीच का एक नॉन-DFS चैनल होता है।
• बदलाव आपके निर्धारित चैनल ऑप्टिमाइजेशन विंडो से बाहर होता है।
• वही APs इस पैटर्न को दोहराते हैं, कभी-कभी दिन के समान समय पर।
• 2.4GHz लोड बढ़ जाता है जबकि 5GHz क्लाइंट गायब हो जाते हैं।

आमतौर पर DFS चैनल परिवर्तन किस कारण से होते हैं?

वास्तविक रडार

यूरोप में 5600-5650 MHz रेंज में मौसम रडार एक आम वास्तविक स्रोत हैं। अमेरिका में, प्रमुख हवाई अड्डों पर Terminal Doppler Weather Radar (TDWR) इसी रेंज का उपयोग करता है। दूरी से अधिक लाइन ऑफ साइट मायने रखती है। आउटडोर APs, ऊपरी मंजिलें और कांच के मुखौटे उस रडार का पता लगा लेते हैं जिसे ग्राउंड-फ्लोर के APs कभी नहीं देख पाते।

केवल निकटता से बहुत कम अनुमान लगाया जा सकता है। कई हवाईअड्डा निगरानी और समुद्री नेविगेशन रडार अन्य बैंडों में काम करते हैं, जो 5GHz से काफी बाहर हैं। किसी बंदरगाह के बगल में स्थित स्थान पर कभी भी एक भी रडार घटना दर्ज नहीं हो सकती है। आपका इवेंट लॉग ही इसका सबूत है, न कि नक्शा।

गलत संकेत (फॉल्स पॉजिटिव)

एक DFS फॉल्स पॉजिटिव रडार की अनुपस्थिति में भी रडार का पता लगाना है। रेडियो ऊर्जा के एक विस्फोट को रडार पल्स पैटर्न के रूप में पढ़ता है। सामान्य ट्रिगर्स में शामिल हैं:

• वायरलेस वीडियो लिंक या खराब उपकरणों से होने वाला स्पंदित (pulsed) गैर-WiFi व्यवधान;
• पास के AP या आस-पास के चैनल पर पॉइंट-टू-पॉइंट लिंक से मजबूत ट्रांसमिशन;
• रेडियो या फर्मवेयर दोष, जिन्हें विक्रेता सॉफ़्टवेयर रिलीज़ में ठीक करते हैं।

पहचानने का तरीका अलगाव (isolation) है। एक AP विभिन्न चैनलों पर बार-बार होने वाली घटनाओं को लॉग करता है जबकि समान आसमान देखने वाले पड़ोसी AP कोई घटना लॉग नहीं करते हैं।

चौड़े चैनल वास्तविक और गलत दोनों प्रकार की पहचान के जोखिम को बढ़ाते हैं। एक 80 MHz चैनल चार 20 MHz उप-चैनलों में फैला होता है, और उनमें से किसी पर भी पहचान होने से पूरा चैनल बदल जाता है।

गैर-रडार बदलाव जो समान दिखते हैं

चैनल प्लानर व्यवधान और लोड के लिए रेडियो को बदलते हैं। Meraki Auto RF, Aruba ARM और AirMatch, और Ruckus ChannelFly और BackgroundScanning सभी बिना रडार के चैनल बदलते हैं। AP रीबूट और पावर परिवर्तन भी क्लाइंट को ड्रॉप करते हैं। इन खराबीयों को अलग-अलग समाधानों की आवश्यकता होती है, इसलिए किसी भी चीज़ को बाहर करने से पहले कारण की पुष्टि करें।

आप यह कैसे पता लगाते हैं कि रुकावट रडार के कारण हुई थी?

इस चेकलिस्ट के अनुसार क्रम से काम करें:

1. शिकायत को पिन करें। मिनट तक का सही समय और कमरा, फर्श या ज़ोन प्राप्त करें।
2. चैनल-परिवर्तन की घटनाएं निकालें उस क्षेत्र में सेवा देने वाले AP के लिए, दोनों तरफ एक घंटे का समय लें।
3. लॉग किए गए कारण को पढ़ें। रडार या DFS का कारण वजह की पुष्टि करता है। एक व्यवधान, शोर या अनुकूलन का कारण इसे खारिज करता है।
4. चैनल पर ध्यान दें। 120, 124 और 128 पर केंद्रित घटनाएं मौसम रडार की ओर इशारा करती हैं।
5. प्रभावित AP की गिनती करें। एक साथ कई पड़ोसी AP वास्तविक रडार का संकेत देते हैं। केवल एक AP गलत सकारात्मक (false positive) का संकेत देता है।
6. साप्ताहिक पैटर्न देखें। नियमित दोहराव एक निश्चित शेड्यूल या स्वीप वाले रडार का सुझाव देते हैं।
7. चैनल की चौड़ाई की जाँच करें। केवल 80 या 160 MHz चैनलों पर दिखाई देने वाली घटनाएं चौड़ाई को समस्या का हिस्सा बनाती हैं।
8. फर्मवेयर रिलीज़ नोट्स पढ़ें अपने AP मॉडल पर DFS पहचान फिक्स के लिए।

यदि आप Purple Guest 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 से समस्या वाले चैनलों को हटा दें। उस प्रोफ़ाइल को केवल प्रभावित 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 की क्षमता कम हो जाती है जिन्होंने कभी रडार नहीं देखा।

क्या आपको हवाई अड्डे, बंदरगाह या मौसम रडार के पास 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 पर बार-बार होने वाले इवेंट, विभिन्न चैनल	गलत पहचान	फ़र्मवेयर अपडेट करें, रेडियो का परीक्षण करें या बदलें, DFS चालू रखें	19 / 25
केवल 80 या 160 MHz चैनलों पर इवेंट	चैनल चौड़ाई का प्रभाव	40 या 20 MHz पर आएं, DFS चालू रखें	19 / 25
चैनल परिवर्तन लेकिन कोई रडार प्रविष्टि नहीं	प्लानर या हस्तक्षेप	हस्तक्षेप और पावर को ठीक करें, DFS चालू रखें	19 / 25

व्यावहारिक परिदृश्य: एक क्षेत्रीय हवाई अड्डे के पास एक होटल

ETSI क्षेत्र में एक 180 कमरों वाला होटल मौसम रडार वाले हवाई क्षेत्र से 3 किमी की दूरी पर स्थित था। पश्चिम की ओर मुख वाले ऊपरी तलों के मेहमानों ने अधिकांश दोपहरों में कनेक्शन टूटने की शिकायत की। इवेंट लॉग ने एक सप्ताह में 46 APs में से 11 पर 63 रडार इवेंट दिखाए, जो सभी चैनल 120 से 128 पर थे। टीम ने उन 11 APs को मौसम चैनलों को छोड़कर एक प्रोफ़ाइल में स्थानांतरित कर दिया और 40 MHz चौड़ाई सेट की। अगले चार हफ्तों में होटल में शून्य रडार इवेंट दर्ज किए गए। फ्रंट डेस्क पर WiFi की शिकायतें प्रति सप्ताह 14 से घटकर दो रह गईं। अन्य 35 APs ने प्रत्येक DFS चैनल को बनाए रखा। होटल परिनियोजन के बारे में अधिक जानकारी के लिए, Hotels देखें।

व्यावहारिक परिदृश्य: एक शोर करने वाले AP वाली रिटेल श्रृंखला

एक 120-स्टोर वाली रिटेल श्रृंखला ने देखा कि एक स्टोर में चैनल 52, 100 और 116 पर एक पखवाड़े में 30 रडार इवेंट दर्ज किए गए। उसी स्टोर में पड़ोसी APs ने कोई इवेंट दर्ज नहीं किया, जिससे झूठी रिपोर्ट (फ़ॉल्स पॉज़िटिव) की ओर संकेत मिला। AP मॉडल के रिलीज़ नोट्स में एक DFS डिटेक्शन फिक्स सूचीबद्ध था, इसलिए टीम ने फ़र्मवेयर को अपग्रेड किया। इवेंट्स जारी रहे, और AP को वारंटी के तहत बदल दिया गया। स्टोर पर रडार इवेंट गिरकर शून्य हो गए, और खरीदारों ने बिलिंग काउंटर क्षेत्र में कनेक्शन खोना बंद कर दिया। इस संपत्ति ने सभी 19 चैनलों को बनाए रखा। मल्टी-साइट गेस्ट एक्सेस के लिए Retail देखें।

व्यावहारिक परिदृश्य: बंदरगाह के पास काउंसिल कार्यालय

एक काउंसिल IT टीम ने एक व्यावसायिक बंदरगाह के बगल में स्थित कार्यालयों में DFS को निष्क्रिय करने की योजना बनाई। तीस दिनों के लॉग में कोई भी रडार इवेंट नहीं दिखा। चैनल में बदलाव पड़ोसी किरायेदार के नेटवर्क पर योजनाकार की प्रतिक्रिया के कारण आए थे। टीम ने DFS को बनाए रखा, ट्रांसमिट पावर को कम किया और चैनल प्लान को ठीक किया। साप्ताहिक ड्रॉप रिपोर्ट नौ से घटकर एक रह गई।

आप DFS इवेंट्स को मेहमानों को फिर से बाधित करने से कैसे रोकते हैं?

• सघन स्थानों में 20 या 40 MHz चैनलों का उपयोग करें। संकीर्ण चैनल एक्सपोज़र को कम करते हैं और पुनः उपयोग को बढ़ाते हैं।
• केवल प्रभावित APs पर, जहां इवेंट्स 120 से 128 पर केंद्रित हैं, वहां मौसम चैनलों को सर्जिकल रूप से बाहर निकालें।
• फ़र्मवेयर को अद्यतित रखें और प्रत्येक रिलीज़ नोट में 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 ने 2024 में 80,000+ से अधिक सक्रिय स्थानों पर 44 करोड़ लॉगिन सेवाएँ प्रदान कीं (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 चालू रखें। यह दृष्टिकोण क्षमता को छोड़े बिना समस्या को सीमित करता है।

क्या यूके, यूरोप और यूएस के बीच 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 डायग्नोसिस प्रत्येक कंट्रोलर में रहता है।