तुमचे Stadium WiFi का मंदावते (आणि ते कसे दुरुस्त करावे)

कार्यकारी सारांश (Executive Summary)

उच्च-घनता असलेल्या ठिकाणांचे व्यवस्थापन करणाऱ्या CTOs आणि IT Directors साठी, stadium WiFi slow होण्याची घटना हा एक सततचा आणि खर्चिक ऑपरेशनल धोका आहे. मल्टि-गीगाबीट बॅकहॉल, हाय-डेन्सिटी ॲक्सेस पॉइंट्स आणि अचूक RF प्लॅनिंगवर मोठा भांडवली खर्च करूनही, जेव्हा स्टेडियमची क्षमता ८०% पेक्षा जास्त होते तेव्हा नेटवर्क अनेकदा ठप्प होते. याचे मूळ कारण क्वचितच हार्डवेअरची मर्यादा असते. हे बॅकग्राउंड ट्रॅफिकचे अदृश्य वादळ असते. जेव्हा ५०,००० डिव्हाइसेस एकाच वेळी Guest WiFi नेटवर्कशी कनेक्ट होतात, तेव्हा ते लाखो मायक्रो-ट्रान्झॅक्शन्स सुरू करतात — प्रोग्रामॅटिक जाहिराती लोड करणे, टेलिमेट्री सिंक करणे आणि बॅकग्राउंड SDK कॉल्स कार्यान्वित करणे. कोणताही एक युझर सक्रियपणे वेब ब्राउझ करण्यापूर्वीच हे "चॅटर" उपलब्ध बँडविड्थचा ६०% पर्यंत भाग वापरू शकते, ज्यामुळे NAT पूल संपतात आणि एअरटाइम संपून जातो. हे मार्गदर्शक या गर्दीच्या तांत्रिक मेकॅनिक्सचे तपशील देते, एज DNS फिल्टरिंग लागू करण्यासाठी विक्रेता-तटस्थ आर्किटेक्चरल ब्ल्यूप्रिंट प्रदान करते आणि असे करण्याचे ROI मोजते.

तांत्रिक सखोल विश्लेषण: उच्च-घनता गर्दीचे स्वरूप

बॅकग्राउंड ट्रॅफिकचे वादळ

जेव्हा एखादे डिव्हाइस गेस्ट WiFi नेटवर्कशी जोडले जाते, तेव्हा ते लगेचच बॅकग्राउंड ॲक्टिव्हिटीचा असा प्रवाह सुरू करते ज्याचा युझर सक्रियपणे करत असलेल्या कामाशी काहीही संबंध नसतो. आधुनिक मोबाईल ॲप्लिकेशन्समध्ये अनेक थर्ड-पार्टी SDKs समाविष्ट असतात — जसे की ॲनालिटिक्स प्लॅटफॉर्म, क्रॅश रिपोर्टिंग सर्व्हिसेस आणि प्रोग्रामॅटिक जाहिरात नेटवर्कसाठी. प्रत्येक SDK स्वतंत्रपणे काम करतो आणि स्वतःच्या वेळापत्रकानुसार स्वतःच्या सर्व्हरशी संपर्क साधतो. स्टेडियमच्या वातावरणात, ५०,००० डिव्हाइसेस एकाच वेळी या क्रिया करत असल्याने एक ट्रॅफिक प्रोफाइल तयार होते जे इतर कोणत्याही डिप्लॉयमेंट परिस्थितीपेक्षा पूर्णपणे वेगळे असते.

या ट्रॅफिकचे वैशिष्ट्य म्हणजे उच्च प्रमाण, कमी-पेलोड विनंत्या (high volume, low-payload requests): लहान-पॅकेट TCP हँडशेक, DNS क्वेरी आणि ट्रॅकिंग पिक्सेल व जाहिरात क्रिएटिव्हसाठी HTTP GET विनंत्या. जरी प्रति डिव्हाइस ट्रान्सफर केलेला एकूण डेटा स्वतंत्रपणे पाहिल्यास नगण्य वाटू शकत असला, तरी नेटवर्कच्या स्पेक्ट्रल कार्यक्षमतेवर होणारा एकूण परिणाम अत्यंत घातक असतो. IEEE 802.11 मानकानुसार WiFi हे एक सामायिक माध्यम आहे; कोणत्याही डिव्हाइसद्वारे ट्रान्समिट केलेल्या प्रत्येक पॅकेटला एअरटाइमसाठी स्पर्धा करावी लागते. लाखो बॅकग्राउंड मायक्रो-ट्रान्झॅक्शन्स या सामायिक माध्यमाला संपवून टाकतात, ज्यामुळे वैध युझर सेशन्ससाठी अपुरा एअरटाइम उरतो.

मोठ्या प्रमाणावर अपयशाचे तीन प्रकार (Three Failure Modes at Scale)

उच्च-घनतेची गर्दी सामान्यतः तीन वेगवेगळ्या अपयशाच्या प्रकारांद्वारे प्रकट होते, जे सहसा एकाच वेळी घडतात:

State Table Exhaustion हे यापैकी सर्वात घातक आहे. एक सामान्य एंटरप्राइझ फायरवॉल ५,००,००० ते १०,००,००० समवर्ती कनेक्शन स्टेट्स हाताळण्यासाठी डिझाइन केलेले असू शकते. ५०,०००-डिव्हाइस असलेल्या स्टेडियममध्ये, प्रत्येक डिव्हाइस २० ते ३० पार्श्वभूमी कनेक्शन्स राखत असल्याने, कोणत्याही सक्रिय वापरकर्त्याच्या ट्रॅफिकचा विचार करण्यापूर्वीच सैद्धांतिक कनेक्शन स्टेट संख्या दहा लाखांपेक्षा जास्त होते. याचा परिणाम म्हणजे सर्वत्र पॅकेट्स ड्रॉप होतात आणि कनेक्शन्स अयशस्वी होतात, ज्यामुळे प्रत्येक वापरकर्त्याच्या स्वतःच्या वर्तनाचा विचार न करता त्यांच्यावर परिणाम होतो.

Airtime Saturation हे 802.11 कॉन्टेंशन मेकॅनिझम (CSMA/CA) मुळे अधिक गुंतागुंतीचे बनते. प्रत्येक डिव्हाइसने ट्रान्समिट करण्यापूर्वी ऐकणे आवश्यक आहे, आणि डिव्हाइसच्या घनतेसह कोलिजनची (टक्कर) शक्यता वेगाने वाढते. जाहिरात नेटवर्क्स आणि टेलिमेट्री सेवांमधील पार्श्वभूमी ट्रॅफिक कायदेशीर वापरकर्त्याच्या ट्रॅफिकला रांगेत उभे राहण्यास भाग पाडते, ज्यामुळे लेटन्सी वाढते आणि ॲक्सेस पॉइंट्सच्या सैद्धांतिक क्षमतेपेक्षा प्रभावी थ्रूपुट खूपच कमी होतो.

DNS Resolver Overload कडे सहसा दुर्लक्ष केले जाते. एका सामान्य स्टेडियमच्या उपयोजनात, WiFi Analytics मधून असे दिसून येते की जाहिरात नेटवर्क डोमेन्स — जसे की प्रमुख प्रोग्रामॅटिक जाहिरात प्लॅटफॉर्मद्वारे ऑपरेट केले जाणारे — सातत्याने सर्वाधिक विचारल्या जाणाऱ्या पहिल्या पाच DNS नोंदींमध्ये दिसतात. प्रत्येक क्वेरी, वैयक्तिकरित्या लहान असली तरी, स्थानिक रिझॉल्व्हर्सवरील एकूण लोडमध्ये भर घालते आणि डाउनस्ट्रीम TCP कनेक्शनचे प्रयत्न सुरू करते जे स्टेट टेबलवर अधिक भार टाकतात.

अंमलबजावणी मार्गदर्शक: Edge DNS Filtering आर्किटेक्चर

या बिघाड पॅटर्नला धोरणात्मक प्रतिसाद म्हणजे अधिक हार्डवेअरची तरतूद करणे नव्हे, तर गोंगाटाचा स्त्रोत काढून टाकणे हा आहे. Edge DNS Filtering ही प्राथमिक शमन धोरण आहे, आणि योग्यरित्या तैनात केल्यावर, ते ४०% पर्यंत WAN बँडविड्थ परत मिळवू शकते आणि सरासरी लेटन्सी ६०ms किंवा त्याहून अधिक कमी करू शकते.

आर्किटेक्चरल ब्ल्यूप्रिंट

Edge DNS filtering नेटवर्कच्या परिघावर DNS क्वेरी अडवून कार्य करते. जेव्हा एखादे डिव्हाइस ज्ञात जाहिरात नेटवर्क, टेलिमेट्री सर्व्हर किंवा मालवेअर डोमेनच्या IP पत्त्याची विनंती करते, तेव्हा फिल्टर शून्य मार्गाने प्रतिसाद देतो — एकतर 0.0.0.0 किंवा NXDOMAIN प्रतिसाद देतो. हे डिव्हाइसला TCP कनेक्शन स्थापित करण्यापासून प्रतिबंधित करते, ज्यामुळे संबंधित स्टेट-टेबल ओव्हरहेड, एअरटाइमचा वापर आणि WAN बँडविड्थचा वापर दूर होतो.

उपयोजन पायऱ्या

पायरी १: स्थानिक DNS रिझॉल्व्हर्स तैनात करा व्हिन्यू एजवर अत्यंत उपलब्ध स्थानिक DNS रिझॉल्व्हर्स लागू करा. हे कनेक्ट केलेल्या डिव्हाइसच्या संपूर्ण क्वेरी लोड हाताळण्यास सक्षम असावेत. केवळ अपस्ट्रीम ISP रिझॉल्व्हर्सवर अवलंबून राहू नका, कारण यामुळे लेटन्सी वाढते आणि तुमची फिल्टर करण्याची क्षमता नाहीशी होते.

पायरी २: थ्रेट इंटेलिजन्स आणि जाहिरात-ब्लॉकिंग फीड्स समाकलित करा एंटरप्राइझ-ग्रेड थ्रेट इंटेलिजन्स फीड्सचे सबस्क्रिप्शन घ्या ज्यामध्ये ज्ञात जाहिरात नेटवर्क डोमेन्स, टेलिमेट्री सर्व्हर्स आणि मालवेअर इन्फ्रास्ट्रक्चर समाविष्ट आहेत. हे फीड्स डायनॅमिकली अपडेट केले जाणे आवश्यक आहे — आदर्शपणे दर काही तासांनी — जेणेकरून जाहिरात नेटवर्कद्वारे ब्लॉकिंग टाळण्यासाठी वापरल्या जाणाऱ्या नवीन नोंदणीकृत डोमेन्सचा शोध घेता येईल.

पायरी ३: DHCP पॉलिसी कॉन्फिगर करा सर्व गेस्ट डिव्हाइसेसना स्थानिक, फिल्टर केलेल्या रिझॉल्व्हर्सचे IP ॲड्रेस वितरित करण्यासाठी DHCP सर्व्हर्स कॉन्फिगर करा. क्लायंट DNS ट्रॅफिकला फिल्टरद्वारे निर्देशित करण्यासाठी ही प्राथमिक अंमलबजावणी यंत्रणा आहे.

पायरी ४: एग्रेस फायरवॉल नियम लागू करा ही पायरी अत्यंत महत्त्वाची आहे आणि अनेकदा वगळली जाते. मंजूर स्थानिक रिझॉल्व्हर्स व्यतिरिक्त इतर कोणत्याही गंतव्यस्थानावरील सर्व आउटबाउंड DNS ट्रॅफिक (TCP/UDP पोर्ट ५३) ब्लॉक करण्यासाठी कडक एग्रेस फायरवॉल नियम लागू करा. हे हार्डकोड केलेल्या DNS सेटिंग्ज असलेल्या डिव्हाइसेसना फिल्टर बायपास करण्यापासून रोखते.

पायरी ५: DNS over HTTPS (DoH) चे निराकरण करा आमच्या DNS Over HTTPS (DoH): Implications for Public WiFi Filtering या मार्गदर्शकामध्ये तपशीलवार वर्णन केल्याप्रमाणे, आधुनिक ऑपरेटिंग सिस्टीम्स आणि ब्राउझर DNS क्वेरी कूटबद्ध (encrypt) करण्यासाठी DoH चा वाढता वापर करत आहेत, ज्यामुळे त्या बाह्य रिझॉल्व्हर्सकडे पाठवल्या जातात आणि स्थानिक फिल्टरिंग पूर्णपणे बायपास होते. नेटवर्क प्रशासकांनी फायरवॉल स्तरावर ज्ञात DoH प्रदात्यांचे IP ॲड्रेस स्पष्टपणे ब्लॉक केले पाहिजेत. हे क्लायंटला मानक, अनइन्क्रिप्टेड DNS वर परत येण्यास भाग पाडते, जे नंतर फिल्टर केले जाऊ शकते. आंतरराष्ट्रीय उपयोजनांसाठी या मार्गदर्शकाचे पोर्तुगीज भाषेतील समतुल्य रूप DNS Over HTTPS (DoH): Implicações para a Filtragem de WiFi Público येथे उपलब्ध आहे.

पायरी ६: आयडेंटिटी आणि ॲक्सेस मॅनेजमेंटसह समाकलित करा कमाल परिणामकारकतेसाठी, DNS फिल्टरिंग पॉलिसींना वापरकर्ता प्रमाणीकरणाशी (user authentication) जोडा. पासवर्डशिवाय प्रवेशावरील आमच्या २०२६ च्या मार्गदर्शकामध्ये शोधल्याप्रमाणे — प्रोफाइल-आधारित प्रमाणीकरणाचा फायदा घेतल्याने व्हिन्यूना वापरकर्त्याच्या भूमिकांवर आधारित भिन्न फिल्टरिंग पॉलिसी लागू करण्याची अनुमती मिळते. सामान्य प्रवेश वापरकर्त्यांना आक्रमक फिल्टरिंग मिळते; प्रेस, कॉर्पोरेट किंवा VIP वापरकर्त्यांना अधिक सवलत देणाऱ्या पॉलिसी मिळू शकतात ज्या विशिष्ट व्यावसायिक ॲप्लिकेशन्सना परवानगी देतात.

केस स्टडीज

केस स्टडी १: ६०,०००-सीट फुटबॉल स्टेडियम, UK

एका प्रीमियर लीग फुटबॉल क्लबला हाफ टाईम दरम्यान गंभीर नेटवर्क डिग्रेडेशनचा अनुभव येत होता, ज्यामध्ये कॅप्टिव्ह पोर्टल (Captive Portal) टाईम आउट होत होते आणि पीक मोमेंट्समध्ये सोशल मीडिया शेअरिंग अयशस्वी होत होते. WAN सर्किट हे १०Gbps चे समर्पित कनेक्शन होते, जे या घटनेदरम्यान केवळ २८% वापरावर कार्यरत होते. तथापि, फायरवॉल स्टेट टेबल ९७% क्षमतेवर होते.

WiFi Analytics चा वापर करून ट्रॅफिक ऑडिट केल्यानंतर, टीमच्या निदर्शनास आले की एकूण DNS क्वेरींपैकी ६१% क्वेरी या जाहिरात नेटवर्क डोमेन्सच्या होत्या. पहिल्या पाच क्रमांकावरील डोमेन्स हे प्रोग्रामॅटिक जाहिरात इन्फ्रास्ट्रक्चरचे होते. १.२ दशलक्ष डोमेन्सच्या ब्लॉकलिस्टसह एज DNS फिल्टरिंग तैनात करण्यात आले, ज्यासोबत पोर्ट ५३ आणि DoH प्रदाता IPs ब्लॉक करणारे कडक इग्रेस नियम लागू करण्यात आले.

परिणाम: पीक कॅपॅसिटी दरम्यान स्टेट टेबलचा वापर ३४% पर्यंत खाली आला, सरासरी लेटन्सी २८०ms वरून ९५ms वर आली, आणि पीक दरम्यान WAN बँडविड्थचा वापर २८% वरून १७% वर आला — कनेक्ट केलेल्या उपकरणांच्या संख्येत कोणताही बदल न होता वापरल्या जाणाऱ्या बँडविड्थमध्ये ३९% घट झाली.

केस स्टडी २: आंतरराष्ट्रीय परिषद केंद्र, Hospitality क्षेत्र

१५,००० प्रतिनिधींच्या तंत्रज्ञान परिषदेचे आयोजन करणाऱ्या एका मोठ्या परिषद केंद्रामध्ये, नुकतेच इन्फ्रास्ट्रक्चर अपग्रेड केले असूनही उपस्थितांकडून स्लो WiFi बाबत तक्रारी येत होत्या. या ठिकाणी ४०० एंटरप्राइझ-ग्रेड ॲक्सेस पॉइंट्स आणि ५Gbps WAN सर्किट तैनात करण्यात आले होते.

ट्रॅफिक विश्लेषणातून असे दिसून आले की प्रतिनिधींची उपकरणे — प्रामुख्याने कॉर्पोरेट लॅपटॉप्स ज्यांवर अनेक एंटरप्राइझ ॲप्लिकेशन्स सुरू होते — प्रति उपकरण सरासरी ४५ बॅकग्राउंड कनेक्शन्स तयार करत होती. DNS रिझॉल्व्हर प्रति तास २.३ दशलक्ष क्वेरींवर प्रक्रिया करत होते, ज्यापैकी ६८% क्वेरी जाहिरात नेटवर्क्स आणि ॲनालिटिक्स प्लॅटफॉर्म्ससाठी होत्या.

परिषदेच्या नोंदणी प्रणालीशी जोडलेल्या पॉलिसी इंटिग्रेशनसह एज DNS फिल्टरिंग तैनात केल्यानंतर, या ठिकाणी DNS क्वेरीच्या प्रमाणात ५२% घट, फायरवॉल स्टेट टेबलच्या वापरात ४१% घट आणि सरासरी TCP कनेक्शन प्रस्थापित होण्याच्या वेळेत १८०ms वरून ६२ms पर्यंत सुधारणा दिसून आली. WiFi गुणवत्तेसाठी प्रतिनिधींच्या समाधानाचा स्कोअर ५ पैकी ३.१ वरून ४.६ पर्यंत वाढला.

सर्वोत्तम पद्धती आणि मानके

खालील वेंडर-न्यूट्रल सर्वोत्तम पद्धती हाय-डेन्सिटी WiFi तैनातीसाठी सध्याच्या उद्योग मानकांचे प्रतिनिधित्व करतात:

• IEEE 802.11ax (Wi-Fi 6/6E): Wi-Fi 6 किंवा 6E ॲक्सेस पॉइंट्स तैनात करा. OFDMA आणि BSS कलरिंग वैशिष्ट्ये हाय-डेन्सिटी वातावरणात एअरटाइम स्पर्धा लक्षणीयरीत्या कमी करतात, ज्यामुळे DNS फिल्टरिंगद्वारे साध्य होणाऱ्या ट्रॅफिक कपातीला पूरक मदत मिळते.
• WPA3-Enterprise: संवेदनशील डेटा हाताळणाऱ्या कोणत्याही तैनातीसाठी IEEE 802.1X ऑथेंटिकेशनसह WPA3-Enterprise लागू करा. Retail वातावरणात PCI DSS अनुपालनासाठी ही एक मूलभूत आवश्यकता आहे आणि ती GDPR डेटा मिनिमायझेशन तत्त्वांशी सुसंगत आहे.
• GDPR अनुपालन: Captive Portal च्या सेवा शर्तींमध्ये DNS फिल्टरिंगसह नेटवर्क ऑप्टिमायझेशन साधनांच्या वापराबाबत पारदर्शकपणे माहिती द्या. युजर्सना हे माहित असणे आवश्यक आहे कि नेटवर्क व्यवस्थापन कार्याचा भाग म्हणून DNS क्वेरींवर स्थानिक पातळीवर प्रक्रिया केली जाते.
• मॉनिटरिंग आणि ॲनालिटिक्स: WiFi Analytics चा वापर करून सर्वाधिक विनंती केलेल्या डोमेन्सचे सतत निरीक्षण करा आणि त्यानुसार फिल्टरिंग पॉलिसीज समायोजित करा. जाहिरात नेटवर्क्स ब्लॉकिंग टाळण्यासाठी नियमितपणे नवीन डोमेन्सची नोंदणी करतात; त्यामुळे स्टॅटिक ब्लॉकलिस्ट काही दिवसांतच कालबाह्य होतात.
• सार्वजनिक क्षेत्र उपयोजन (Deployments): सार्वजनिक क्षेत्र आणि स्मार्ट सिटी WiFi उपयोजनांसाठी, Purple च्या सार्वजनिक क्षेत्रातील विस्ताराच्या संदर्भात चर्चा केल्याप्रमाणे, DNS फिल्टरिंग हे स्थानिक प्राधिकरणाच्या आवश्यकतांचे पालन करून हानिकारक सामग्री श्रेणींवरील प्रवेश अवरोधित करून एक सुरक्षात्मक कार्य देखील करते.

त्रुटी निवारण आणि जोखीम कमी करणे (Troubleshooting & Risk Mitigation)

फॉल्स पॉझिटिव्ह (चुकीचे संकेत)

जोखीम: अत्यंत आक्रमक फिल्टरिंगमुळे वैध ॲप्लिकेशन कार्यक्षमता अवरोधित होऊ शकते, जसे की तिकीट ॲप्स, ठिकाण नेव्हिगेशन सेवा किंवा कॉर्पोरेट VPN एंडपॉइंट्स.

उपाययोजना: केवळ-निरीक्षण (monitor-only) बेसलाइन टप्प्यादरम्यान ओळखल्या गेलेल्या अत्यंत महत्त्वाच्या डोमेन्ससाठी एक कठोर परवानगी सूची (allowlist) लागू करा. प्रॉडक्शन वातावरणात थेट अंमलबजावणी मोडवर कधीही जाऊ नका. अंमलबजावणीपूर्वी किमान दोन आठवड्यांचा देखरेख कालावधी ही शिफारस केलेली बेसलाइन आहे.

बॅकग्राउंड ट्रॅफिकद्वारे Captive Portal बायपास

जोखीम: वापरकर्त्याने ब्राउझर उघडण्यापूर्वी बॅकग्राउंड ट्रॅफिकने OS ची Captive Portal शोध यंत्रणा (उदा. Apple ची captive.apple.com तपासणी) समाधानी केल्यास डिव्हाइसेस Captive Portal ट्रिगर करण्यात अयशस्वी होऊ शकतात.

उपाययोजना: Captive Portal शोध आणि प्रमाणीकरणासाठी आवश्यक असलेल्या विशिष्ट डोमेन्सनाच परवानगी देण्यासाठी वॉल्ड गार्डन (walled garden) अधिक कडक करा. वापरकर्ता पूर्णपणे प्रमाणित होईपर्यंत आणि त्यांच्या सत्रावर फिल्टरिंग पॉलिसी लागू होईपर्यंत इतर सर्व ट्रॅफिक अवरोधित केले पाहिजे.

DoH बायपास

जोखीम: DoH वापरणारी डिव्हाइसेस स्थानिक DNS फिल्टरिंगला बायपास करतील, ज्यामुळे त्या क्लायंटसाठी संपूर्ण धोरण कुचकामी ठरेल.

उपाययोजना: DoH प्रदाता IP पत्त्यांची अद्ययावत ब्लॉकलिस्ट ठेवा आणि त्यांना फायरवॉलवर अवरोधित करा. हे एकवेळचे कॉन्फिगरेशन नाही; नवीन DoH प्रदाते नियमितपणे समोर येतात आणि त्यांचा मागोवा घेतला पाहिजे.

ऑफलाइन नकाशा आणि नेव्हिगेशन सेवा

WiFi सोबत इनडोअर नेव्हिगेशन तैनात करणाऱ्या ठिकाणांसाठी — जसे की Purple चे Offline Maps Mode वापरणारे — नकाशा टाइल सर्व्हर आणि नेव्हिगेशन APIs स्पष्टपणे परवानगी सूचीमध्ये (allowlisted) असल्याचे सुनिश्चित करा. या सेवा वापरकर्त्याच्या अनुभवासाठी अत्यंत महत्त्वाच्या आहेत आणि त्या व्यापक जाहिरात-नेटवर्क फिल्टरिंग नियमांमध्ये अडकता कामा नयेत.

ROI आणि व्यावसायिक प्रभाव (ROI & Business Impact)

एज DNS फिल्टरिंगचा व्यावसायिक फायदा अनेक आयामांमध्ये प्रभावी आहे:

WAN कनेक्टिव्हिटीवर दरवर्षी £80,000 खर्च करणाऱ्या आणि £200,000 च्या हार्डवेअर रिफ्रेश सायकलचा सामना करणाऱ्या स्टेडियमसाठी, बँडविड्थमध्ये 35% कपात केल्यास वार्षिक WAN बचतीमध्ये अंदाजे £28,000 ची बचत होते आणि हार्डवेअर रिफ्रेश सायकलचा संभाव्य 18-महिन्यांचा विस्तार होतो — या आकाराच्या स्टेडियमसाठी साधारणपणे £15,000 ते £30,000 च्या अंमलबजावणी खर्चाच्या तुलनेत, तीन वर्षांची एकत्रित बचत £100,000 पेक्षा जास्त होते.

Listen to the Technical Briefing