Comprehensive Guide to Enterprise WiFi Planning, Deployment, and Operations – Practices from Ctrip

Introduction

With the rapid development of mobile Internet, WiFi has become an essential infrastructure for enterprise office networks, creating strict quality requirements. Many deployments fall short because delivery and operation are not properly executed. This article shares practical experience to empower WiFi deployment and operation, focusing on methodology and capability improvement.

1. Ctrip WiFi Platform Overview

Since 2015 Ctrip’s headquarters has deployed over 600 APs covering more than 100,000 m², serving 7,000 daily active devices with peak downlink throughput exceeding 1 Gbps.

Figure 1: Logical topology

2. Opening Chapter

The opening stage includes network planning and delivery, analogous to laying a building’s foundation; only a solid foundation can support a high‑rise. Main challenges for large‑scale enterprise WiFi are full coverage, balancing capacity and interference, and internal network security threats.

2.1 Full Coverage

Coverage depends on AP placement, capacity, building structure, penetration loss, and cabling. The link‑budget formula is: Received signal = AP transmit power + AP antenna gain – distance loss – obstacle loss + terminal antenna gain. Recommended signal levels: >‑65 dBm for key areas, >‑75 dBm for normal areas. Suggested AP coverage radius: <20 m for open sparse areas, 5‑8 m for dense open areas, 8‑12 m for moderate obstacles, and dedicated APs for heavily obstructed spaces.

2.2 Channel Optimization

Dense AP deployment can cause channel interference. Ctrip adopts a dual‑band honeycomb coverage and cross‑reuse principle (see Figure 2) to ensure channels do not interfere with each other. The WiFi system uses 2.4 GHz and 5 GHz bands; in high‑density scenarios, 2.4 GHz should be suppressed to avoid low‑speed traffic affecting overall performance.

Figure 2: Dual‑band honeycomb coverage

2.3 Internal Network Security Threats

Terminals within the same VLAN or across VLANs should be isolated to prevent bandwidth waste and data leakage, thereby ensuring office security and efficiency.

3. Operations Chapter

Long‑term WiFi quality requires continuous optimization throughout the system lifecycle. Pain points include numerous configuration parameters, difficulty collecting user‑experience data, and reliance on wired‑network operational practices.

3.1 Planning Effective KPI Parameters

Ctrip defines global and local KPI dimensions for authentication servers, ACs, APs, and RF, covering metrics such as server status, CPU/memory utilization, interface traffic, AP coverage radius, client success rate, channel utilization, and noise level. The KPI table (see original) guides comprehensive monitoring.

3.2 Quantifying System Baseline and User Experience

Lack of quantitative data hampers troubleshooting; establishing baseline metrics and user‑centric KPIs bridges the gap between technical measurements and perceived performance.

3.3 Deploying Probes to Establish Baselines

Ctrip uses Raspberry Pi‑based probes to simulate user HTTP access, measuring DNS resolution time, TCP connection time, download speed, etc., and presents the results in a “baseline analysis” module.

3.4 Quantifying User Experience Values

An internal “self‑test” tool allows users to trigger measurements from their devices, reporting signal samples and web download speeds to the backend, thus converting subjective complaints into objective data (see Figure 5).

Figure 5: User‑initiated WiFi self‑test

4. Troubleshooting Chapter

WiFi troubleshooting faces two major difficulties: (1) failures are hard to reproduce, and (2) WiFi is often blamed for all connectivity issues, even when the root cause lies elsewhere. Retaining user traffic packets is key to solving these problems.

4.1 Building User Traffic Packet Tracing

Inspired by wired‑network packet capture, Ctrip deploys “traffic collectors” at wired‑wireless convergence points to record packets close to the user side while respecting encryption. This provides valuable samples for both historical analysis and fault reproduction.

Figure 6: Traffic collector deployment

5. Case Studies

Case 1 – PTK Compatibility Issue

A user reported intermittent loss of connectivity on iPhone XS. Packet traces showed normal signal but a break in communication between AC and terminal. Analysis revealed the iPhone’s BCM chip does not support periodic PTK key updates; disabling PTK periodic updates resolved the issue.

Case 2 – Cross‑AP Roaming Problem

A user experienced WiFi interruption during roaming across APs. KPI scores indicated overall network health, but packet traces showed downlink frames still being sent to the previous AC after roaming. The root cause was inconsistent MAC/ARP tables across ACs, exacerbated by a switch’s limited CPU‑CAR buffer. Optimizations included adjusting AP topology, tuning CPU‑CAR, deploying MAC‑linked ARP, and port isolation.

Figure 8: Network topology for roaming case

6. Outlook

WiFi optimization should be data‑driven rather than intuition‑driven. Future work will leverage machine learning to detect KPI changes, close the loop between metrics and user experience, and enable intelligent, automated operation for “wireless office” environments.