OSSLab 接到一場直播比無線網路規劃，做這種WLAN規劃，第一部就是算流量，詢問直播APP開發方表示，每個 client 直播所佔用的Upload 頻寬約 1Mb/s，到場約100人 由於現場場地限制只能申請到100M/40M線路，加上準備時間很少.
因此規劃上 每組
Fortigate 60C +Unifi Cloud Key (Wifi 控制器) + Unifi AC Pro AP， 中華電信 100M/40M 的光纖，總共三組
另外二組則使用Vigor設備.Cloud Key 外部認養
配置圖如下：
WLAN 設定基本功
- 盡量使用5G 少用2G
- 相鄰頻道切開
- 均衡AP的連線數
直播連線比賽前做的策略是以前三台 AP 為主，每台配置 30 人左右，不足的再分流至後面兩個 AP。
不過實際比賽開始之後，發現有 AP 開始連線情況不佳，經過檢查發現有使用者的上傳流量極為異常，累積使用量上升的非常高速，後來將其阻擋之後 2 號 AP 回復正常運作，不久後發生連續封包掉落，無法遠端控制，決定強制重啟重新建立連線，之後沒有再發生異常斷線過。
幫在場使用者調度不同的基地台以取得更好的連線品質，把些狀況整理下：
- 設備最好要有充足時間進行過真正的模擬測試：因為這是以往沒有過的高壓力網路使用情況，理想狀況上要真正用足夠數量的裝置去安裝要使用的軟體做真正的連線壓力測試才能確保沒有環節出錯，因為就像現場收集到的使用量，跟一開始推測的 1Mb/s 有一段差距，有時用量會高達 1MB/s，這對於需要多少設備才能撐住現場使用量的估算會產生極大的誤差。
- 系統配置的記錄：需要將每個設備的命名規則更簡化，因為雖然自己知道是怎麼設定的，但是需要協同處理狀況時會讓別人無法明白狀況而無法快速上手，這部份需要改進。現場要有一份詳細網路設定的文件
- 場地現場有許多隱藏的 2G 頻段 SSID，頻道有許多覆蓋跟干擾，有的裝置無線晶片比較好的干擾會比較少，但是無法限制參加者使用的裝置，這部份會有效能上的影響，再有類似環境的話要盡量請場地方關掉這些WLan。
改進方法
- 架構上的更換， AP還是使用單一控制器認養，比較好管理
- 更多數量的AP
- 更換802.11ac MU MIMO AP 並且對Switch 做link aggregation
- 盡量使用單一高上傳線路 ,如果多線路的話分別對應做VLAN TAG
- 設定Guest Wlan.
- AP要開最小功率，Roaming不打開.(但是為了技術挑戰看狀況會想打開嘗試)
改進用的設備
- Unifi AC HD Pro Wave 2 AP * 10
- Unifi Cloud 控制器 *1
- Unifi 48 port Poe Switch *1
- NAT 設備 OptiPlex 7020SFF i5-4590 8G 64G SSD , pfsense soft Router (搭配5 1000M Lan , 2 10GbE SFP+) 以10GbE 跟Unifi 48 Port Switch相連
- 500M/250M ,1000M/600M線路* 2~4
這樣應該可以應付到400人規模直播應用.
附註筆記
將 AP 回收之後，打算將 log 取出進行檢查，根據官方文件有寫可以透過 SSH 去存取 AP 內的資料取得 log，不過當再次通電之後，發現 log 已被洗空，因此如果要取出 AP 內的資料，必須在斷電之前取出，不過因為有配備控制器的架構，因此可以從控制器取得 log，兩者的位置如下：
AP 上的路徑：
/var/log/messages
控制器上的路徑：
Windows: C:\Users\<username>\Ubiquiti UniFi\logs\
Mac OS X: /Users/<username>/Library/Application\ Support/UniFi/logs/
UniFi Cloud Key and Debian/Ubuntu Linux*: /usr/lib/unifi/logs/
可透過 SCP 指令將 log 取出至電腦。
