SIAM Wireless

ก่อนจะซื้อรถใหม่เราก็เทสไดร์ฟกันใช่ไหมครับ แต่ไหงพอเป็น Wi-Fi เราไม่ทำ POC กัน 🤔

ออกแบบ Wi-Fi แต่ไม่เคยเทสหน้างานจริง…ก็เป็นดาบสองคมได้ 😄

ปกติแล้วการทดสอบสัญญาณ Wi-Fi
และตำแหน่งติดตั้ง Access Point ก่อน deploy จริง
เป็นสิ่งที่ควรทำ

แค่หลายครั้ง…เรา “ไม่ค่อยได้ทำ” เพราะมันเสียเวลา 😅

หลายคนอาจคิดว่า
“ติด AP ก็แค่เสียบ แล้ววางตรงไหนก็ได้”

แต่ของจริงมันไม่ใช่แบบนั้นเสมอไป

เพราะตำแหน่งที่ออกแบบใน simulate มันอาจจะสวย
แต่พอเจอหน้างานจริง
มันดันไม่เป็นแบบนั้น

👉 ถ้าวางผิดตั้งแต่แรก
ต่อให้ config ดีแค่ไหน
ก็ยังมีโอกาสมีปัญหาอยู่ดี

งาน network จริง
ไม่ได้มีแค่ config
แต่ต้องเข้าใจ “หน้างาน” ด้วย

และนั่นแหละ…คือสิ่งที่เราควรทำ
แต่ก็มักจะ “ข้ามมันไป” 😁

การตัดสินใจซื้อหรืออัพเกรดระบบ Wi-Fi ในองค์กรไม่ใช่เรื่องง่าย เพราะมันคือการตัดสินใจที่เราจะต้องอยู่กับมันไปอีก 5–7 ปี (บางที่อาจจะ 10 หรือจนกว่า EOL 😅) และถ้าเลือกผิด ไม่ใช่แค่ระบบที่พัง แต่เก้าอี้นั่งอยู่อาจสั่นคลอนตามไปด้วย
บทความนี้อยากจะแชร์ประสบการณ์ในมุมของผู้ซื้อ ว่าต้องดูอะไร ระวังอะไร ก่อนตัดสินใจเซ็นเช็ค 7-8 หลักที่เราอาจจะเสียใจภายหลัง
# # Brand และ Spec Sheet สำคัญน้อยกว่าที่คิด
นโยบายการเลือกซื้อแต่ละองค์กรก็ต่างกัน บางที่ยึด brand เป็นหลัก บางที่เอาราคานำ ส่วนบางคนเลือกจาก spec sheet รุ่นเรือธง ใหม่สุด ล้ำสุด และก็มีหลายที่เลือกตาม SI ที่ไว้ใจ แน่นอนว่า SI แต่ละเจ้าก็เชียร์แบรนด์ที่ตัวเองขาย ซึ่งเป็นเรื่องปกติ อาจจะมีขิงกันบ้างเล็กน้อย 55 แต่จากประสบการณ์ตรง Wi-Fi ระดับ enterprise หรือแม้แต่กลุ่ม SME ในมุมของ performance จริง ๆ แทบไม่ต่างกัน ถ้า *** design ติดตั้ง และ config ถูกต้องตามหลักการ *** เรื่อง brand จึงเป็นสิ่งที่น่าเป็นห่วงน้อยที่สุด
# # สิ่งที่คุณซื้อจริง ๆ ไม่ใช่แค่ AP
แต่เรื่องที่หลายคนมองข้าม คือเราไม่ได้แค่ซื้อ AP แต่เรากำลังซื้อ ecosystem ทั้ง controller, cloud sub, support MA, license รายปี บางแบรนด์ดูราคาถูกในวันที่ซื้อ แต่พอรวม license 5 ปีเข้าไป คือมีร้อง และถ้าวันนึงอยากเปลี่ยน vendor ไม่ใช่แค่สลับ AP ใหม่ แต่ต้องรื้อ platform แล้วเริ่มต้นใหม่ทั้งหมด
# # เคสจริง: Config ผิด vs Design ผิด
ปัญหาที่เจอหลังจากสั่งซื้อ ไม่เคยเป็นเรื่อง feature แต่เกิดจากการออกแบบและ config ที่ไม่ถูกต้อง
มีลูกค้าเจ้าหนึ่งมีปัญหา Wi-Fi ช้า เป็น ๆ หาย ๆ มาหลายปี SI แก้ยังไงก็แก้ไม่หายขาด อ้างว่าเป็นข้อจำกัดของ technology จนท้ายที่สุดลูกค้าทนไม่ไหวเปลี่ยน SI เจ้าใหม่เข้ามารื้อแก้ config ใหม่ สุดท้ายใช้งานได้ดี นิ่ง ไม่งอแง ถ้าเทียบ before after คือฟ้ากับเหว และที่สำคัญคือเราใช้ AP ชุดเดิมทั้งหมด ไม่ได้เพิ่มหรือเปลี่ยน AP ซักตัว คือโชคดีที่ design เดิมสัญญาณค่อนข้างครอบคลุม แต่ปัญหาเดิมคือใช้ channel selection ไม่ดีจนสัญญาณตีกันกระจุย พอเข้าใจปัญหาเราก็แก้ที่ต้นเหตุระบบก็วิ่งได้ปกติ
แต่ก็ไม่ใช่ทุกเคสที่จะโชคดีแบบนี้ ถ้าเป็นปัญหาเชิง design เช่นเลือก AP ผิดประเภทหรือการวางตำแหน่ง AP ส่วนใหญ่จบไม่สวย
ลูกค้าอีกเจ้าติด Omnidirectional AP ในคลังสินค้าเพดานสูง 12 เมตร เพื่อใช้กับ handheld barcode scanner แต่พอลูกค้าเซ็น PO ติดตั้งเสร็จ ก็หวานเจี๊ยบครับ สัญญาณแทบจะไม่เหลือถึงพื้น SI แก้แล้วแก้อีก เพิ่ม Tx power ก็แล้ว เปลี่ยน channel ก็แล้วก็ยังไม่ดีขึ้น
IT เลยขอให้ผมเข้าไปดูให้ ผมสอบถามว่าทำไมถึงเลือกติด omni ที่ความสูงขนาดนี้ ลูกค้าบอกว่าเป็นข้อจำกัดของพื้นที่ แต่ SI แนะนำว่าติดได้เพราะ AP ยี่ห้อนี้เพราะเสามันเก่งสามารถ beam สัญญาณหา client ได้ในพื้นที่ยาก ๆ (แต่ลืมนึกไปว่า client ก็ต้องส่งกลับมาหา AP ได้ ยิ่งความสามารถของ barcode scanner ที่ใช้เสา 1x1 แทบไม่ต่างอะไรกับ IoT)
ในหัวผมก็ได้แต่คิดว่าจะบอกลูกค้ายังไงดีว่า “ship…แล้ว” แบบ soft ที่สุดเพราะเค้าเพิ่งเปลี่ยนมา 3 เดือน
พอลูกค้าถามว่าแก้ยังไงได้บ้าง ผมก็ได้แค่ตอบตรง ๆ ว่าเปลี่ยน AP ใหม่ให้เป็น directional ลูกค้าก็ช็อคนิ่งไปหลายวิ ผมอธิบายไปว่าถึงเสาจะเก่งหรือฉลาดแค่ไหนมันก็เป็น dipole omni ที่กระจายสัญญาณในแนวนอน การแก้ไข config ไม่สามารถ หักล้าง physics ของ RF ได้ มีวิธีเดียวเท่านั้นคือเปลี่ยนมาใช้ directional antenna หรือเลื่อน AP ให้ต่ำลงมา แต่มันก็จะไปขวาง forklift ตอนยืดขึ้นอีก
จริง ๆ เรื่องแบบนี้จะไม่เกิดขึ้นถ้าลูกค้าทำ POC ก่อนติดตั้ง ยิ่งพื้นที่ยาก ๆ แต่สำคัญมากกับ operations แบบนี้ งานนี้ผมไม่รู้จบยังไงเพราะเราไม่ได้เข้าไปทำต่อ แต่บทเรียนนี้ชัดเจนมาก -> POC ก่อน ลงทุนทีหลัง
# # สรุป
ในมุมของผู้ซื้อเราก็ต้องทำการบ้าน ตั้ง requirements ที่ชัดเจน คิดถึง TCO ระยะยาว เลือกทีม SI ที่มีความรู้ ความชำนาญ มีการทำ site survey มีแผนทำ POC ซึ่งฟังดูอาจจะจุกจิก แต่มันจะป้องกันปัญหาที่จะเกิดขึ้นตามมา
การเลือก Wi-Fi ที่ดีไม่ได้เริ่มจากการเลือก brand มันเริ่มจากการเข้าใจสภาพแวดล้อม ความต้องการ และข้อจำกัดของตัวเองก่อน
ใครมีประสบการณ์ติดตั้งระบบ WLAN แล้ว failed มาแชร์กันได้ครับ
หรือถ้าท่านมีแพลนเปลี่ยน Wi-Fi อยากได้คำปรึกษาหรืออยากได้มุมมองเพิ่มเติมทาง SIAM Wireless ยินดีช่วยเหลือครับ

เราสามารถเช็ค Wi-Fi channel utilization กับ station count ได้ไว ๆ ไม่ต้องเข้า controller โดยดูจาก QBSS ใน Beacon Frame ครับ
บทความนี้เราจะมาทำความรู้จักกับ QBSS กัน
QBSS หรือ QoS Basic Service Set เป็น feature ที่เพิ่มมาใน 802.11e เมื่อเปิดใช้งาน AP จะ embed ข้อมูลชุดหนึ่งเรียกว่า QBSS Load Element ไว้ใน beacon frame ประกอบด้วยสามค่าหลัก:
1. Station Count คือจำนวน client ที่ associate อยู่กับ AP ณ เวลานั้น
2. Channel Utilization ความหนาแน่นของ channel วัดเป็นตัวเลข 0–255 (255 = 100% utilized)
3. Available Admission Capacity คือความจุที่เหลือ (อันนี้ผมก็ไม่แน่ใจว่ามีไว้ทำไม 555)
ลอง Wi-Fi Scanner ส่อง beacon ดูจะเห็นค่า QBSS ใน Element ที่ 11 (ใน WiFi Explorer Pro จะใช้ชื่อ BSS Load) แสดงผล BSSID แต่ละตัวมี client เกาะกี่ตัว และ utilization เท่าไหร่ ส่วน Controller และ RRM ก็อาจจะใช้ข้อมูลนี้ช่วยในการตัดสินใจปรับ Tx power เพื่อลด channel interference หรือเปลี่ยน channel เมื่อ utilization สูงเกิน threshold
Client ที่รองรับ 802.11k Neighbor Report คืออีกกลุ่มที่ได้ประโยชน์จาก QBSS เพราะ AP สามารถส่งรายชื่อ neighbor AP พร้อม BSS Load ให้กับ client เพื่อใช้ตัดสินใจในการ roam แต่วิธีนี้ไม่ได้เป็นข้อบังคับใน 802.11 Standards และไม่ใช่ทุก vendor จะรองรับการส่งข้อมูล QBSS ใน neighbor report
AP ส่วนใหญ่จะเปิด QBSS ไว้เป็น default แต่ก็มีบางที่มองว่าข้อมูลนี้เป็นความลับไม่ต้องการให้ใครเห็นค่า load ก็อาจเลือกที่จะปิดไว้ แต่ส่วนตัวผมแนะนำให้เปิดไว้เพราะมันง่ายที่จะเช็คสถานะผ่าน Wi-Fi Scanner โดยไม่ต้องไปเปิดดูใน controller
ส่วนวิธีการดู channel utilization ถ้า AP ตัวไหนแสดงค่าเกิน 70–80% เป็นสัญญาณว่า AP นั้น overloaded หรือมี interference สูง (อย่าลืมว่า 100% คือ 255 ฉะนั้น ถ้าเราได้เป็น raw data ที่ยังไม่ได้แปลง เราต้องหารด้วย 2.55 เช่น utilization ที่ 122 คือ 125/2.55 = 49%)
ส่วน station count ก็บอกแค่จำนวน client ที่เกาะ BSSID นั้น ๆ ถ้าตัวเลขนี้สูง เราก็พอเดาได้ว่า channel utilization ก็สูงเช่นกัน แต่ก็อาจจะเป็นไปได้ว่า client แค่เกาะแต่ไม่ได้ส่ง data ก็ได้เช่นกัน