CTS 127: Stadium Wi-Fi Implementation
Clear To Send: Wireless Network Engineering - A podcast by Rowell Dionicio and François Vergès
Categorie:
Ensuring the stadium Wi-Fi implementation goes according to the design. Stadium Wi-Fi Implementation Chris Reed joins the show to follow up on his stadium Wi-Fi design episode to discuss the implementation portion. He joined us back on Episode 123 where he went into the design of Wi-Fi within large public venues or stadiums. A wireless network is more than just Wi-Fi. Improperly sized, configured, or issues will cause “The Wi-Fi isn’t working” Doesn’t matter if you don’t own these, understand their layout, and ask the questions to make sure it’s not going to bite you. Understand the associated network functions that go into a proper network implementation, beyond the Wi-Fi. Things such as Internet bandwidth, wired infrastructure, DNS, and DHCP. Documentation is always a critical piece of the design and implementation. You should have the output from your design software to hand off and to use for your validation. This includes some sort of visualization of different install models for cable installers. Walkthroughs are a must for stadium Wi-Fi implementation. Walk through with your installer, every space. This is their chance to speak up, ask questions, and for you to get things clarified. It’s up to you to make sure installers are following your standards. There are lots of bad Wi-Fi engineers, and these installers may have been working with them. You can find these at badfi.com. Run through the “why?” of your design. Why is it important the angle is right, why is it important they aren’t near the DAS antenna? And also very important, where are the antenna leads supposed to be connected to? When it comes to configuration, are you still using the GUI? Let’s assume 1,400 APs, and there are 5 settings / functions to configure – name, description, channel, antennas, power. Assume a 1% error rate (you’re pretty good at this). You’re going to get 70 configuration settings wrong Oh, and now the customer wants to change the naming convention. Have fun 🙂 This should be scripted. If you aren’t able to, hire someone to script it. Understand what you are tweaking and tuning before you make changes. RXSOP, or probe suppression, or RSSI based disassociation, or airtime fairness are all vendor specific. Understand what the feature actually does vs what it says it does. There may be client limitations to features that you’ll blow through. Validation is more than validating configuration and design. It’s also about validating the user experience. Don’t forget about: * The noise floor increase that will occur with people there * Butts in the seats if you’re doing under seat and the attenuation you’ll get * Your survey adapter is better than the target clients Do you have any comments or questions? Let us know down below in the comments section.