31/08/2026
เตือนก่อนว่าบทความยาวมากกก 55
ป.ล. พึ่งสังเกตว่ามีรูปตัวเองอยู่บนโปสเตอร์ 😅
Thanaris Field Note | Wi-Fi Capacity (ยาวเหมือนเดิม 555+)
“AP 1 ตัว รับได้กี่คน?”
เป็นคำถามที่ผมว่าได้ยินกันบ่อยมากเวลาคุยเรื่อง Wi-Fi
แล้วถ้าจะตอบแบบง่ายที่สุด ก็คงประมาณว่า...
เปิด Datasheet ขึ้นมา ดู Maximum Clients แล้วตอบไปว่า
“รุ่นนี้รับได้เท่านี้ครับ 200 Clients, 500 Clients” จบ 😆
-----
แต่ถ้างาน Wi-Fi มันง่ายแค่นั้น
พวกเราคงไม่ต้องมานั่งทำ Capacity Design กันครับ 555
ใครไปงาน ThaiFi Day #2 มี Demo ช่วงท้ายหนึ่งที่ผมว่าน่าสนใจมาก
ซึ่งให้ผู้เข้าร่วมงานค่อย ๆ เชื่อมต่อ Wi-Fi ผ่าน Access Point ตัวเดียว
จากนั้นให้ทุกคนเข้า Microsoft Teams พร้อม ๆ กัน แล้วค่อย ๆ เพิ่มจำนวนคนเข้าไป
โจทย์ของ Demo ไม่ได้ต้องการหาว่า
“AP ตัวนี้จะรับ Client ได้สูงสุดกี่เครื่อง?”
หรือจะเอาไป Benchmark ว่า
“AP รุ่นนี้เปิด Teams ได้กี่คน”
แต่เราอยากให้เห็นอีกเรื่องหนึ่ง คือเมื่อ Active Client เพิ่มขึ้นเรื่อย ๆ
เมื่อไหร่เสียงจะเริ่มกระตุก
เมื่อไหร่ภาพจะเริ่มค้าง
เมื่อไหร่ Video Conference จะเริ่มไม่ Smooth
สิ่งที่น่าสนใจคือ
ตอนที่ User เริ่มรู้สึกว่าการใช้งานแย่ลง
AP ก็ยังไม่ได้ Down (CPU, Memory ก็ไม่สูง)
Wi-Fi ก็ยังต่ออยู่
Client ใหม่ก็ยัง Associate เข้า AP ได้
Internet ก็ยังไม่ได้หายไปไหน
แล้วถ้า AP ยังทำงานได้อยู่...
แล้วอะไรคือปัญหา?
หนึ่งในคำตอบที่สำคัญมากก็คือ "Airtime ครับ"
-----
เราทราบกันอยู่แล้วว่า Wi-Fi เป็น Shared Medium
พูดง่าย ๆ คือทุกคนที่อยู่บน Channel เดียวกัน
ต้องแบ่งกันใช้ “เวลา” บนอากาศ
สมมุติเรามีห้องประชุมหนึ่งห้อง ถ้าถามว่า “ห้องนี้รับคนได้กี่คน?”
ก็อาจจะตอบได้ว่า 500 คน
แต่ถ้า 500 คน อาจจะแน่นเกินไปก็ได้ ทำให้เราอาจจะจัดทีนั่งได้แค่ 300-400 คน
Wi-Fi ก็คล้าย ๆ กัน
AP อาจสามารถ Associate Client ได้เป็นร้อยเครื่อง
แต่ไม่ได้หมายความว่า
Client หลายร้อยเครื่องจะสามารถใช้งาน Application พร้อม ๆ กัน
แล้วทุกคนยังได้ User Experience ที่ดีเหมือนเดิม
ตรงนี้เองที่เราต้องแยกให้ออกระหว่าง
Maximum Client
กับ
Usable Capacity
-----
ลองเอาตัวเลขมาคิดเล่น ๆ กันครับ
สมมุติว่าในการประชุม Microsoft Teams ครั้งหนึ่ง
แต่ละ User ใช้ Traffic โดยเฉลี่ยประมาณ
Downlink 1.5 Mbps
Uplink 1.5 Mbps
รวมง่าย ๆ ประมาณ 3 Mbps ต่อ User
ตรงนี้เป็นตัวเลขสมมุติเพื่อใช้ในการอธิบาย Concept นะครับ
ของจริงจะเปลี่ยนไปตาม Video Resolution, Codec, Screen Sharing, จำนวน Participant และรูปแบบการใช้งาน
ถ้ามี 10 คน = 10 x 3 Mbps ประมาณ 30 Mbps
ถ้ามี 30 คน = 30 x 3 Mbps ประมาณ 90 Mbps
ถ้ามี 50 คน = 50 x 3 Mbps ประมาณ 150 Mbps
มาถึงตรงนี้หลายคนอาจคิดว่า... “150 Mbps เอง?”
“AP สมัยนี้ Link Rate เป็น Gigabit กันแล้ว สบาย ๆ สิ”
ถูกครับ... แต่ก็ไม่ถูกทั้งหมด 😆
เพราะ PHY Rate ที่เราเห็นบน Wi-Fi
ไม่ได้เท่ากับ Application Throughput ที่เอาไปใช้ได้จริง
และต่อให้เรารู้ Application Throughput แล้ว
ก็ยังไม่ได้แปลว่าเรารู้ว่า Traffic เหล่านั้นใช้ Airtime ไปเท่าไหร่
-----
ลองดูกันต่ออีกนิดครับ
สมมุติว่า Radio ตัวนี้
ภายใต้สภาพแวดล้อมหนึ่ง
สามารถให้ Effective Throughput ได้ประมาณ 250 Mbps
ถ้ามี 30 Users Application Traffic รวมประมาณ 90 Mbps
ถ้าคิดแบบง่ายมาก ๆ
90 ÷ 250 = 36%
ดูเหมือนยังเหลืออีกตั้งเยอะเลยใช่ไหมครับ
แต่โลก Wi-Fi ไม่ได้มีแค่ Payload ที่เราต้องการส่งครับ
มันยังมีทั้ง
ACK
Contention
Backoff
Interframe Space
Beacon
Management Frames
Retransmission
รวมถึง Client แต่ละเครื่องที่ต้อง Contend เพื่อหาจังหวะส่งข้อมูลของตัวเอง
พูดง่าย ๆ คือ...
เราไม่ได้มีถนนโล่ง ๆ แล้วขับกันอย่างเดียว
มีไฟแดง
มีทางแยก
มีรถช้า
บางคันส่งไม่ผ่านก็ต้องย้อนกลับมาส่งใหม่อีก 😆
ดังนั้น Application Traffic 90 Mbps ไม่ได้หมายความว่าเราจะใช้ Wireless Resource แค่ 36% แบบตรง ๆ
-----
ทีนี้ลองเพิ่มเป็น 50 Users Traffic รวมประมาณ 150 Mbps
150 ÷ 250 = 60%
ตรงนี้เริ่มน่าสนใจแล้วครับ
เพราะเมื่อรวม Overhead, Contention, Retry รวมถึง Traffic อื่น ๆ เข้าไปด้วย
Channel Utilization จริงอาจสูงกว่าที่เราคำนวณจาก Application Traffic เยอะ
และที่สำคัญ...
สำหรับ Application แบบ Real-time อย่าง Microsoft Teams
เราไม่จำเป็นต้องรอจน Channel เต็ม 100%
แล้ว User ถึงจะเริ่มบ่นครับ
เพราะ Application ประเภทนี้ไม่ได้สนใจแค่ Bandwidth
แต่มันยังสนใจ Latency, Jitter, Packet Loss ด้วย
ดังนั้นบางครั้ง Channel ยังดูเหมือน “มีที่เหลือ” แต่ User Experience เริ่มแย่ไปก่อนแล้ว
-----
อีกเรื่องหนึ่งที่ผมว่าคนมักมองข้ามคือ
Client ทุกเครื่องไม่ได้กิน Airtime เท่ากัน
ลองคิดแบบง่าย ๆ ครับ
สมมุติมีข้อมูลประมาณ 12,000 bits ที่ต้องส่ง
Client เครื่องหนึ่งมี PHY Rate 600 Mbps
ถ้าคิดเฉพาะเวลาส่งข้อมูลแบบง่ายที่สุด
12,000 ÷ 600,000,000
ประมาณ 20 microseconds
แต่ถ้า Client อีกเครื่องหนึ่งส่งได้แค่ 60 Mbps
12,000 ÷ 60,000,000
ประมาณ 200 microseconds
ข้อมูลเท่ากัน
แต่ใช้เวลาบนอากาศต่างกันประมาณ 10 เท่า
แน่นอนว่าตัวเลขนี้เป็นการคำนวณแบบ Simplified เพื่อให้เห็น Concept เท่านั้น
ของจริงยังมีทั้ง PHY และ MAC Overhead อีกหลายส่วน
แต่สิ่งที่ผมอยากให้เห็นคือ...
ข้อมูลเท่ากัน ไม่ได้แปลว่าใช้ Airtime เท่ากัน
Client ที่อยู่ไกล AP
Signal ไม่ดี
PHY Rate ต่ำ
หรือมี Retry เยอะ
จะต้องใช้เวลาอยู่บน Wireless Medium นานขึ้น
และปัญหาคือ...
มันไม่ได้ทำให้แค่ตัวเองช้า
แต่มันกินเวลาที่ Client เครื่องอื่นต้องใช้ร่วมกันด้วย
นี่แหละครับความสนุกของ Shared Medium 😅
หลายครั้งเราจึงเจอสถานการณ์แบบนี้
Internet Link ก็ยังเหลือ
Switch Port ก็ยังไม่ตัน
AP CPU ก็ดูปกติ
Traffic รวมก็ไม่ได้สูงมาก
แต่ User บอกว่า... “Wi-Fi ช้ามาก”
ถ้าเรามองแต่ Mbps ก็อาจจะงงว่า ทำไมถึงช้า
แต่ถ้ามองเรื่อง Airtime, Channel Utilization และ Retry ภาพจะเริ่มชัดขึ้น
-----
แล้วถ้า Airtime เริ่มไม่พอ เราจะแก้ยังไง?
เรื่องนี้ไม่มีคำตอบเดียวครับ
เพราะ Capacity ของ Wi-Fi เป็นผลรวมจากหลายเรื่อง
ทั้ง RF
Spectrum
Channel
Client
Traffic
และ Design
แนวทางที่ควรพิจารณาก็ประมาณนี้ครับ
1. เพิ่ม AP เพื่อเพิ่ม Capacity แต่ต้องเพิ่มให้ถูกวิธี
คำตอบแรกที่หลายคนนึกถึงคือ “งั้นเพิ่ม AP สิ”
ก็ถูกครับ
แต่ถ้าเพิ่ม AP แล้วทุกตัวไปอยู่ Channel เดียวกันหมด
เราไม่ได้สร้าง Airtime เพิ่มขึ้นจริง ๆ
บางครั้งอาจกลายเป็นเพิ่มคนเข้ามาแย่ง Medium เดิมอีกด้วย
ดังนั้นการเพิ่ม AP เพื่อเพิ่ม Capacity ต้องดูร่วมกับ
Channel Planning
Transmit Power
Cell Size
Channel Reuse
เป้าหมายไม่ใช่แค่ทำให้มี AP เยอะขึ้น
แต่ต้องทำให้แต่ละ Radio สามารถใช้ Spectrum ได้อย่างมีประสิทธิภาพด้วย
2. กระจาย Client ไปใช้ 5 GHz และ 6 GHz
ในมุม Capacity สิ่งที่มีค่าไม่ได้มีแค่ PHY Rate ที่สูงขึ้นแต่คือ Spectrum ที่เรามีให้ใช้
ถ้าเรามี Channel มากขึ้น
และสามารถกระจาย Client ออกไปอยู่คนละ Channel ได้
เราก็กำลังเพิ่ม Radio Resource จริง ๆ
นี่เป็นหนึ่งในเหตุผลที่ 6 GHz น่าสนใจมากสำหรับ High-density Wi-Fi
ไม่ใช่แค่เพราะ “เร็วกว่า” แต่เพราะเรามี Spectrum ให้บริหารมากขึ้นด้วย
3. อย่าใช้ Channel Width กว้างเกินความจำเป็น
80 MHz หรือ 160 MHz อาจจะทำให้เราได้ Datarate สูง
แต่ใน High-density Environment
บางครั้ง 20 MHz หรือ 40 MHz กลับเหมาะกว่า
เพราะ Channel Width ที่แคบลง
ทำให้เรามี Channel สำหรับ Reuse ได้มากขึ้น
เวลาออกแบบ Capacity เป้าหมายไม่ใช่ทำให้ User คนหนึ่ง Speedtest ได้ 1 Gbps แล้วอีก 80 คนนั่งดูวงกลมหมุนอยู่ข้าง ๆ 😆
เป้าหมายคือให้ User จำนวนมาก
ได้ Performance ที่เหมาะสมกับ Application ของเขา
4. จัดการ Client ที่ PHY Rate ต่ำ
Client ที่อยู่ไกล AP หรือมี Signal ไม่ดี PHY Rate มักจะลดลง
พอ Data Rate ต่ำลง
ข้อมูลปริมาณเท่าเดิมก็ต้องใช้ Airtime มากขึ้น
ดังนั้นเรื่องเหล่านี้จึงเกี่ยวกับ Capacity โดยตรง
AP Placement
Coverage
Transmit Power
Minimum Data Rate
Roaming Behavior
RF Design ไม่ได้มีไว้แค่ทำให้ทุกจุดมีขีด Wi-Fi เต็มครับ
แต่ยังมีผลต่อประสิทธิภาพในการใช้ Airtime ด้วย
5. ลด Retry และ Interference
ทุกครั้งที่ Frame ถูกส่งออกไปแล้วไม่สำเร็จ เราต้องส่งใหม่
Airtime รอบแรกก็เสียไปแล้ว
รอบต่อไปก็ต้องใช้อีก
ถ้า RF Environment ไม่ดี
Capacity สามารถหายไปกับ Retransmission ได้เยอะมาก
ดังนั้นเวลา Troubleshoot อย่าดูแค่ Throughput
ควรดูร่วมกับ
Retry Rate
Channel Utilization
Noise
Co-channel Interference
Adjacent-channel Interference
Non-Wi-Fi Interference
บางครั้ง User ไม่ได้เยอะเลยครับ แต่ Airtime หายไปกับ Retry หมดแล้ว
6. ใช้ QoS ให้ถูกต้อง
Microsoft Teams, Webex, Zoom หรือ Voice
ควรได้รับการจัด Priority ที่เหมาะสมผ่าน WMM/QoS
เพราะ Traffic พวกนี้ Sensitive ต่อ Delay
แต่มีเรื่องหนึ่งที่ต้องเข้าใจให้ตรงกันครับ
QoS ไม่ได้สร้าง Airtime เพิ่ม
ถนนมีสามเลน QoS ช่วยให้รถพยาบาลได้ไปก่อน แต่มันไม่ได้เสกเลนที่สี่ขึ้นมาครับ 😆
ถ้า Capacity ไม่พอจริง ๆ
สุดท้ายก็ยังต้องกลับมาแก้ที่ RF และ Capacity Design อยู่ดี
7. ดู Client ต่อ Radio และต่อ Channel ไม่ใช่ดูแค่ต่อ AP
สมมุติ AP ตัวหนึ่งมี Client 60 ตัว
กรณีแรก
Radio A = 30
Radio B = 30
กับอีกกรณี
Radio A = 50
Radio B = 10
รวมแล้วเป็น 60 Client เหมือนกัน
แต่ Load ของระบบไม่ได้เหมือนกัน
เพราะ Airtime ถูกใช้ที่ Radio และ Channel
ดังนั้นเวลา Troubleshoot อย่าดูแค่ว่า
“AP นี้มี Client กี่ตัว?”
แต่ต้องดูต่อว่า
“Client ไปกองอยู่ Radio ไหน และ Channel ไหน?”
8. อุปกรณ์ที่ไม่จำเป็นต้องใช้ Wi-Fi ก็ไม่ต้องฝืน
อันนี้อาจจะฟังดูย้อนยุคนิดหนึ่ง 😆
แต่ถ้าเป็น Device ที่อยู่กับที่
ต้องการ Throughput สูงต่อเนื่อง
ต้องการ Latency ที่ Stable
และไม่ได้ต้องการ Mobility
Ethernet ก็ยังเป็นคำตอบที่ดีครับ
Wi-Fi มีจุดเด่นเรื่อง Mobility และ Convenience
ไม่ได้หมายความว่าเราต้องเอาอุปกรณ์ทุกอย่างขึ้น Wireless ให้หมด
บางครั้งการเอา Load บางส่วนออกจาก Wireless Medium
ก็เป็น Capacity Improvement ที่ตรงไปตรงมาที่สุดเหมือนกัน
-----
ทั้งหมดนี้เลยทำให้คำว่า
“เพิ่ม Wi-Fi Capacity”
ไม่ได้แปลว่า
ซื้อ AP รุ่นแรงกว่าเดิมอย่างเดียว
บางครั้ง AP ตัวเดิมก็ยังทำงานได้ดีครับ
แต่ Design รอบ ๆ มันต่างหากที่ต้องปรับ
ไม่ว่าจะเป็น
Channel
Power
Cell Size
Spectrum
Client Distribution
Minimum Data Rate
QoS
หรือ RF Environment
สุดท้ายแล้วทุกอย่างก็ย้อนกลับมาที่ Resource สำคัญตัวหนึ่ง
Airtime
-----
กลับมาที่คำถามแรกครับ “AP ตัวนี้รับได้กี่คน?”
ก็ต้องถามกลับก่อนว่า...
“แล้วแต่ละคนทำอะไรครับ?” 😆
เพราะ 100 คนที่ต่อ Wi-Fi ทิ้งไว้เฉย ๆ
กับ 100 คนที่เปิด Microsoft Teams Video พร้อมกัน
คำว่า “100 คน” เหมือนกัน
แต่เป็นคนละโจทย์เลยครับ
สิ่งที่ Demo ในงาน ThaiFi Day #2 อยากให้เห็น
จึงไม่ใช่ว่า “AP รุ่นนี้เปิด Teams ได้สูงสุด XX คน”
เพราะแค่เปลี่ยน Client
เปลี่ยน RF Environment
เปลี่ยน Channel Width
เปลี่ยน Application Behavior
หรือเปลี่ยนตำแหน่งที่ User นั่ง
ตัวเลขก็เปลี่ยนแล้ว
สิ่งที่สำคัญกว่าคือ Concept ว่า...
AP ยังรับ Client เพิ่มได้
ไม่ได้แปลว่า Wireless Network ยังมี Capacity เหลือ
และ Maximum Client ที่เขียนอยู่บน Datasheet
ก็ไม่ได้บอกเราว่า User กี่คนจะสามารถใช้งาน Application พร้อมกันได้ดี
-----
เวลาผมมอง Wi-Fi Capacity
ผมจึงชอบเปลี่ยนคำถามจาก “AP ตัวนี้รับได้กี่ User?”
มาเป็น
“เราต้องการให้กี่คน ใช้อะไร พร้อมกัน และต้องการ User Experience แบบไหน?”
พอเปลี่ยนคำถามแบบนี้
เราจะเริ่มมองไปที่
RF
Spectrum
Channel
Airtime
Client Capability
Traffic Pattern
และ Application Requirement
แทนที่จะมองแค่ตัวเลข Maximum Client บน Datasheet
-----
Thanaris Takeaway
Maximum Clients ไม่ได้เท่ากับ Usable Capacity
PHY Rate ไม่ได้เท่ากับ Application Throughput
และ Throughput ก็ไม่ได้บอก Airtime Consumption ทั้งหมด
Wi-Fi Capacity Design จึงไม่ใช่แค่ จำนวน User ÷ Maximum Client ใน Datasheet
แต่เป็นการออกแบบให้ RF + Spectrum + Airtime + Client + Application ทำงานร่วมกันได้อย่างเหมาะสม
เพราะสุดท้ายแล้ว...
AP อาจยังไหว
Uplink อาจยังเหลือ
Internet อาจยังวิ่งสบาย
แต่ Airtime อาจกำลังบอกเราเบา ๆ ว่า...
“พอเถอะครับ เต็มแล้ว ไม่ไหวแล้ว” 😆
