रियल Wi‑Fi थ्रूपुट: AI-नेटवर्क प्लानिंग का सच

डिवाइस के डिब्बे पर “1200 Mbps” लिखा है, पर मीटिंग कॉल में आवाज़ टूटती है—यही सबसे आम, और सबसे महंगा भ्रम है। वजह सीधी है: Wi‑Fi का advertised data rate और आपको मिलने वाला real-world throughput एक चीज़ नहीं हैं। और 2025 में, जब एंटरप्राइज़ नेटवर्क एक साथ Wi‑Fi 7, 6 GHz, और प्राइवेट 5G की तरफ बढ़ रहे हैं, यह फर्क सिर्फ “स्पीड” का नहीं रह जाता—यह AI-driven नेटवर्क ऑप्टिमाइज़ेशन की नींव बन जाता है।

“थ्योरी” पर बने KPI और “रियल” पर चलने वाला ट्रैफिक हमेशा टकराते हैं। मैंने कई नेटवर्क ऑडिट में यही देखा है: टीम AP जोड़ती जाती है, चैनल बदलती रहती है, लेकिन असल समस्या बनी रहती है—हम गलत मीट्रिक को सही मानकर डिज़ाइन कर रहे होते हैं। इस पोस्ट में हम उसी गैप को साफ करेंगे, और दिखाएंगे कि डेटा रेट बनाम थ्रूपुट समझना AI मॉडलिंग, ट्रैफिक प्रेडिक्शन, और 5G/Wi‑Fi को-एक्ज़िस्टेंस के लिए क्यों जरूरी है।

डेटा रेट और थ्रूपुट में फर्क क्या है?

डेटा रेट (PHY rate) वह स्पीड है जिस पर आपका क्लाइंट और AP रेडियो लेयर पर बिट्स “भेजने की क्षमता” रखते हैं; जबकि थ्रूपुट वह स्पीड है जो आपको एप्लिकेशन लेयर पर सच में “मिलती” है—फाइल ट्रांसफर, वीडियो स्ट्रीम, या API कॉल में।

सीधी बात: डेटा रेट संभावित क्षमता है; थ्रूपुट उपयोगी डिलीवरी है।

बॉक्स पर दिखने वाले नंबर क्यों धोखा देते हैं?

Advertised रेट अक्सर इन “आदर्श” मान्यताओं पर होता है:

• बिल्कुल साफ RF वातावरण (interference नगण्य)
• 1 क्लाइंट, 1 AP, बिना भीड़
• चौड़ा चैनल (80/160/320 MHz) और हाई MCS
• बहुत अच्छा SNR और नज़दीकी दूरी

रियल दुनिया में—ऑफिस, अस्पताल, मॉल, कॉलेज—इनमें से लगभग कुछ भी स्थिर नहीं होता। थ्रूपुट घटता है क्योंकि बीच में ये लागतें जुड़ती हैं:

• MAC overhead (ACK, preamble, interframe spacing)
• contention (CSMA/CA), backoff और retries
• encryption/encapsulation overhead
• co-channel/adjacent-channel interference
• roaming, power-save व्यवहार, legacy clients

एक उपयोगी thumb rule: बहुत अच्छे हालात में भी थ्रूपुट अक्सर PHY rate का लगभग 50%–70% रहता है। भीड़/इंटरफेरेंस में यह इससे भी कम हो सकता है।

क्लाइंट डेटा रेट कैसे चुनता है—और आपको क्या गलतफहमी होती है

क्लाइंट ही अक्सर डेटा रेट “चुनता” है, AP नहीं। क्लाइंट अपने हिसाब से SNR, error rate, retries, और अपने ड्राइवर/चिपसेट लॉजिक के आधार पर MCS ऊपर-नीचे करता रहता है। यही कारण है कि एक ही जगह पर:

• एक लैपटॉप ठीक चलता है
• दूसरा फोन धीमा लगता है
• तीसरा डिवाइस बार-बार 2.4 GHz पर चला जाता है

AP “डेटा रेट्स” को कैसे कंट्रोल करता है?

AP आम तौर पर basic/mandatory rates और minimum data rates जैसी पॉलिसी से कुछ हद तक कंट्रोल करता है। उद्देश्य अच्छा है: बहुत धीमे rates को बंद करके airtime बर्बाद होने से बचाना। लेकिन यहां अक्सर कंपनियां गलती कर देती हैं:

• minimum rate बहुत ऊंचा सेट कर देते हैं → edge coverage पर retries बढ़ जाते हैं
• बहुत नीचे रखते हैं → airtime slow clients खा जाते हैं

बेहतर तरीका: minimum rates को “कवरेज” नहीं, टारगेट SNR और यूज़-केस के हिसाब से सेट करें। वॉइस/वीडियो के लिए अलग, बारकोड स्कैनर/IoT के लिए अलग।

2025 में यह विषय AI और 5G के लिए इतना अहम क्यों हो गया है

AI नेटवर्क ऑप्टिमाइज़ेशन को अच्छे फैसले लेने के लिए अच्छे डेटा की जरूरत होती है। अगर आप AI को गलत मीट्रिक (advertised rate या सिर्फ RSSI) खिला रहे हैं, तो आउटपुट भी वैसा ही होगा।

1) AI मॉडलिंग में “गलत लेबल” की कीमत

अगर आपका AI/एनालिटिक्स सिस्टम यह मानता है कि 80 MHz चैनल का मतलब हमेशा ज्यादा throughput है, तो वह ये गलत सुझाव दे सकता है:

• चैनल चौड़ा करो → जबकि इंटरफेरेंस/DFS/को-चैनल भीड़ बढ़ रही हो
• ज्यादा AP जोड़ो → जबकि contention बढ़कर throughput और गिर रहा हो

रियल throughput और airtime utilization, retry rate, MCS distribution जैसे फीचर्स AI को यह समझाते हैं कि bottleneck कहाँ है—RF में, MAC में, या backhaul में।

2) 5G + Wi‑Fi 7 को-एक्ज़िस्टेंस: ट्रैफिक रूटिंग की समझ

एंटरप्राइज़ में अब “एक नेटवर्क” नहीं होता। अक्सर तीन लेयर साथ चलती हैं:

• Wi‑Fi (कैंपस/इंडोर)
• प्राइवेट 5G (मिशन-क्रिटिकल, deterministic जरूरत)
• पब्लिक 5G (मोबिलिटी, बैकअप)

यहाँ AI का काम सिर्फ मॉनिटरिंग नहीं, policy-based steering भी है: कौन सा ऐप/डिवाइस किस नेटवर्क पर जाए। यह decision थ्योरी पर नहीं, रियल throughput + latency + loss पर होना चाहिए।

3) एनॉमली डिटेक्शन और RCA (Root Cause Analysis)

थ्रूपुट गिरा तो कारण कई हो सकते हैं—ISP, बैकहॉल, AP CPU, RF इंटरफेरेंस, या सिर्फ “भीड़”। AI तभी सही RCA करेगा जब आपके पास ये टेलीमेट्री हो:

• per-client throughput (uplink/downlink)
• retries और packet loss
• channel utilization (busy time)
• RSSI के साथ SNR/Noise floor
• roaming events और sticky client संकेत

मेरा स्टैंड: 2025 में भी कई नेटवर्क टीमें RSSI को “स्पीड मीटर” समझती हैं। RSSI उपयोगी है, पर अकेला मीट्रिक आपको गलत दिशा में ले जाता है।

प्रैक्टिकल प्लानिंग: रियल थ्रूपुट को डिज़ाइन इनपुट बनाइए

नेटवर्क प्लानिंग में सबसे बड़ा सुधार तब आता है जब आप “कितनी स्पीड चाहिए” को एप्लिकेशन-फर्स्ट तरीके से लिखते हैं।

1) ऐप-आधारित थ्रूपुट बजट (एक सरल फ्रेमवर्क)

पहले यूज़-केस लिखें, फिर थ्रूपुट तय करें:

• HD वीडियो कॉल: प्रति यूज़र ~2–4 Mbps (क्वालिटी/कोडेक पर निर्भर)
• स्क्रीन शेयर + कॉल: ~4–8 Mbps
• POS/बारकोड/VoIP: कम Mbps, पर कम latency + कम loss जरूरी
• क्लाउड बैकअप/फाइल सिंक: हाई throughput, latency कम क्रिटिकल

फिर capacity प्लान करें:

1. एक ज़ोन में एक साथ एक्टिव यूज़र्स
2. प्रति यूज़र target throughput
3. expected efficiency (50–70% thumb rule)
4. overhead + peak factor (जैसे 1.2x)

2) “डेटा रेट” नहीं, airtime को बचाइए

Wi‑Fi का असली करंसी airtime है। उच्च PHY rate होने पर भी अगर airtime busy है, अनुभव खराब होगा। इसलिए:

• co-channel interference घटाइए (सेल साइज, चैनल प्लान)
• excessive transmit power से बचिए (sticky clients बढ़ते हैं)
• minimum rates और band steering पॉलिसी सोच-समझकर
• high-density में channel width बढ़ाने से पहले congestion देखें

3) AI को क्या KPIs दीजिए ताकि ऑप्टिमाइज़ेशन सच में काम करे

अगर आपका लक्ष्य “AI-driven network optimization” है, तो इन KPIs को baseline बनाइए:

• median और p95 throughput (डाउन/अप)
• p95 latency और jitter (वॉइस/वीडियो के लिए)
• retry % और packet loss %
• channel busy time (utilization)
• MCS index distribution और NSS (spatial streams)
• roaming success rate और time-to-roam

Snippet-worthy नियम: “AI को PHY rate मत दिखाइए; उसे throughput, airtime और retries दिखाइए—यही यूज़र अनुभव का असली नक्शा है।”

अक्सर पूछे जाने वाले सवाल (नेटवर्क टीम के लिए)

Wi‑Fi “स्पीड” टेस्ट और थ्रूपुट में क्या फर्क है?

स्पीड टेस्ट अक्सर एक या दो TCP flows से मापता है और सर्वर/रूटिंग भी असर डालते हैं। थ्रूपुट की सही तस्वीर के लिए आपको LAN-side टेस्ट, multi-client टेस्ट, और airtime/reties टेलीमेट्री साथ देखनी चाहिए।

ज्यादा AP लगाने से थ्रूपुट क्यों घट जाता है?

क्योंकि high-density में AP बढ़ने से contention और co-channel बढ़ सकते हैं। Wi‑Fi में सबको medium साझा करना होता है; ज्यादा transmitter का मतलब हमेशा ज्यादा capacity नहीं।

6 GHz/Wi‑Fi 7 लेने से समस्या अपने आप हल हो जाएगी?

6 GHz में साफ स्पेक्ट्रम मिलने से मदद मिलती है, और Wi‑Fi 7 में मल्टी-लिंक जैसी क्षमताएँ भी हैं। पर अगर डिज़ाइन में airtime, पॉलिसी, और क्लाइंट मिक्स की समझ नहीं है, तो नई टेक्नोलॉजी भी जल्दी “औसत” हो जाती है।

अगला कदम: रियल थ्रूपुट को AI-रेडी बनाइए

डेटा रेट बनाम थ्रूपुट समझना कोई अकादमिक बहस नहीं है। यह तय करता है कि आपका नेटवर्क प्लानिंग डॉक्यूमेंट “सुंदर” रहेगा या यूज़र्स का अनुभव “स्थिर” होगा। और दूरसंचार और 5G में AI की बड़ी कहानी में यही बेसिक्स AI को सही ट्रेनिंग डेटा देती है—ताकि वह ट्रैफिक प्रेडिक्शन, anomaly detection, और policy steering में भरोसेमंद बने।

अगर आप 2026 की तैयारी कर रहे हैं—Wi‑Fi 7 अपग्रेड, इंडोर 5G, या AI-आधारित ऑप्टिमाइज़ेशन—तो शुरुआत इसी से करें: अपने नेटवर्क को “रियल throughput” के हिसाब से मापिए, मॉडल कीजिए, और डिज़ाइन कीजिए।

आपके नेटवर्क में सबसे ज्यादा mismatch कहाँ है—advertised rates में, coverage में, या high-density airtime में?