40 台企业级 AP 换成 MESH 之后：一个 100 公顷集装箱堆场的无线改造实录
核心概览
背景： 2024 年 8 月，我们接手一个沿海集装箱码头的堆场无线改造。改造前的现状是：100 公顷堆场上部署了 40 台企业级 WiFi AP，但 RTG 在堆场通道里跨越 AP 覆盖边界时，TOS 记录到 2.1–4.8 秒的通信中断，每天触发十几到几十次自动安全停机。码头当时给的数字是”作业效率损失约 15%”。
结论： 换成沿灯杆部署的 34 台三频 MESH 基站（含 5 个光纤汇聚点）后，RTG/跨运车/AGV 的切换时延稳定在 22–38ms，24 小时负载测试期间零丢包、零安全停机，远程起重机操作的往返时延稳定在 31–44ms。
故障复盘：2 秒中断为什么不是 AP 性能问题
码头最初给我们的诉求很直接：”AP 换成更高端的型号，或者加密度。”我在做故障复现时，先做了一件他们没做过的事：把中断事件按位置打点。
结果是分布极不均匀——81% 的中断集中在 6 个位置，全部位于两个 AP 覆盖区的交界处，且都在堆场通道上。这不像射频覆盖不足，更像切换机制本身的问题。
我抓了 RTG 上 CPE 的完整漫游日志，看到了标准 WiFi 客户端的典型行为：
| 切换阶段 | 耗时（实测） | 说明 |
|---|---|---|
| ① 粘连期 | 780–2,400ms | 旧 AP 信号已降到 −84dBm，客户端仍不主动寻找新 AP |
| ② 全信道扫描 | 310–620ms | 设备断开后才开始扫描 11 个 2.4GHz 信道 + 若干 5GHz 信道 |
| ③ 重新关联与认证 | 480–1,100ms | 每次切换都重走 WPA2 四步握手 |
| ④ DHCP 与 TOS 会话恢复 | 520–720ms | 部分 RTG 的 TOS 心跳超时后才重连，触发停机 |
| 合计 | 2,100–4,840ms | 与 TOS 记录的 2.1–4.8 秒中断完全吻合 |
关键在①和④。①是标准 WiFi 客户端的固有问题——客户端只在链路彻底断掉后才开始寻找新 AP，这个决策权在客户端手里，AP 无法干预。④则说明，即使射频层恢复了，TOS 会话仍会因为心跳超时而重新协商，把中断时间再拉长半秒以上。
这也解释了为什么”换更贵的 AP”没用：问题不在 AP 的射频性能，而在切换决策由谁做、以及切换时 TOS 会话是否保持。这两点决定了我们必须换架构：由网络侧（而非客户端）掌管切换决策，并让二层保持透明，使 TOS 会话不感知切换发生。
堆场分区勘测数据（含 RTG 切换时延与阴影区）
下面是 2024-09-16 至 2024-09-20 的堆场分区勘测记录。测法是在 RTG 上固定一台频谱仪（Anritsu MS2720T）+ 一台测试 CPE，沿通道以正常作业速度（约 25km/h）往返走测，每区段往返 6 次取区间值。堆垛形态一栏记录了测试当时箱区的实际堆高，因为这一列直接决定了后来的返工一。
| 箱区 | 面积 | 堆高（勘测时） | 原系统切换中断 | 通道内 RSSI | 堆垛后方 RSSI | 遮挡衰减 | 灯杆高度 |
|---|---|---|---|---|---|---|---|
| A 区（近海侧） | 见现场图 1 | 4 层（10.4m） | 1.8–2.6s | −63 dBm | −76 dBm | 13 dB | 18 m |
| B 区（中部） | 见现场图 1 | 5 层（13.0m） | 2.2–3.4s | −66 dBm | −81 dBm | 15 dB | 16 m |
| C 区（堆高最高） | 见现场图 1 | 6 层（15.6m） | 3.1–4.8s | −69 dBm | −89 dBm | 20 dB | 15 m |
| D 区（空箱区） | 见现场图 1 | 2 层（5.2m） | 0.9–1.5s | −58 dBm | −64 dBm | 6 dB | 16 m |
| E 区（闸口侧） | 见现场图 1 | 3 层（7.8m） | 1.2–2.0s | −60 dBm | −70 dBm | 10 dB | 20 m |
| F 区（码头前沿） | 见现场图 1 | 不堆箱（岸桥作业区） | 0.6–1.1s | −55 dBm | — | — | 22 m |
C 区是整个堆场最麻烦的地方：堆高 6 层（15.6m），而该区灯杆高度只有 15m——灯杆比集装箱堆垛还矮 0.6 米。这意味着在 C 区的部分通道位置，基站天线与 RTG 天线之间完全没有视距。遮挡衰减 20dB，比 A 区高出 7dB。这一条数据后来直接引发了返工一。
堆场分区、灯杆位置与覆盖阴影区分布见图 1。
集装箱堆场分区与灯杆基站布点图
（替换为实际堆场平面图；含 A–F 六个箱区轮廓、灯杆位置与高度标注、5 个光纤汇聚点、覆盖阴影区阴影填充）
返工一：灯杆高度不够，被集装箱堆垛吃掉了覆盖
第一版方案设计时，我们按”灯杆已有 15–22m，高于集装箱堆垛”这个假设布点，间距取 150m。上线后 A、B、D、E、F 五区的表现都符合预期，唯独 C 区的切换时延卡在 62–110ms，远高于承诺的 35ms，而且堆垛后方的 AGV 频繁掉线。
回看勘测数据我才意识到问题：C 区堆高 15.6m，灯杆 15m。我勘测时记录了堆高，但在做布点设计时没有把这一列和灯杆高度做交叉校验——这是纯粹的设计疏漏，不是现场条件不可预见。
补测的结果很清楚：C 区有大约 8 个位置，基站天线到 RTG 天线之间完全无视距，只能靠衍射和多径。实测这些位置的 RSSI 是 −89dBm，而我们的 CPE 接收灵敏度门限按 −82dBm 计算。差了 7dB，链路根本撑不住。
整改：
- 在 C 区新增 4 根 22m 专用立杆（比堆垛高 6.4m），把该区基站数量从 5 台增到 9 台，间距从 150m 压到 90m。
- 在 C 区的 RTG 上加装一台中继节点，让被遮挡的 AGV 可以经 RTG 中继接入，而不是直连灯杆基站。这个做法有效，但只在 RTG 处于特定位置时成立，属于补救而非正解。
- 把”灯杆高度与最大堆高交叉校验”写进了布点设计清单——现在这是设计评审的必过项。
整改后 C 区切换时延降到 26–41ms，堆垛后方 AGV 掉线归零。这一项的额外成本是 4 根立杆加 4 台基站，约占项目硬件预算的 11%。
这里有个细节值得说：C 区的高堆垛并不是固定的。码头在旺季会把堆高提到 6 层，淡季降到 4 层。所以我们的整改方案必须按”最不利堆高”设计，而不是按勘测当天的实际堆高。这一点在勘测阶段就该问清楚，我当时没问。
四类移动设备的天线与频段选择
港口的移动设备类型很杂，天线选型不能一刀切。这是最终方案里每类设备的配置，以及实测结果。
| 设备 | 作业速度 | 实测带宽需求 | 天线选型 | 实测切换时延 |
|---|---|---|---|---|
| RTG（轮胎式门式起重机） | 22–28km/h | 34–58Mbps（6 路摄像头 + TOS + 定位） | 全向，顶部 4.5m 安装 | 26–38ms |
| 跨运车 | 24–30km/h | 18–31Mbps（3 路摄像头 + TOS + 定位） | 全向，顶部 3.2m 安装 | 23–35ms |
| 岸桥 | 轨道式，低速 | 96–138Mbps（12 路摄像头 + 吊具监测） | 定向 17dBi，指向码头侧基站 | 不适用（固定位置） |
| 堆场 AGV | 14–20km/h | 12–24Mbps（3 路摄像头 + TOS + 定位） | 全向，顶部 1.9m 安装 | 22–34ms |
两处需要单独说明：
岸桥用定向天线，是因为它的运动方式不同。 岸桥沿码头前沿的轨道移动，轨迹是一条直线，方位可预测。用 17dBi 定向天线指向码头侧的汇聚点，能把有限的发射功率集中在有用方向上，实测链路余量比全向方案高 12dB。但代价是岸桥一旦需要掉头作业，天线必须重新对准——我们最终是用双天线 + 射频切换解决的。
AGV 的天线高度只有 1.9m，这是设备结构决定的（AGV 本身低矮，没有更高的安装点）。天线低意味着更容易被移动中的跨运车和集装箱拖车遮挡。我们的应对是把 AGV 的漫游 CCQ 阈值调高到 52%，让它更早触发切换——代价是切换更频繁（实测每个 AGV 每小时切换 40–62 次），但换来的是零丢包。
返工二：第 5 个月集中爆发的接头腐蚀
设备本身是 IP66 的，方案里也写了”抗盐雾”。所以上线后的头 4 个月一切正常。第 5 个月开始（2025 年 1 月，冬季季风期），我们陆续收到 6 台基站的链路质量告警，都是回传速率从 150Mbps 以上掉到 40–70Mbps。
上门检查时发现的问题很集中：全部 6 台故障基站的故障点都在 N 型射频接头处，接头内部有明显铜绿，介质层受潮。基站本体、天线本体都没有问题。
为什么会这样？我们的设备是 IP66 的，接头的防护等级也按 IP66 采购。但有两件事叠加了：
- 沿海环境的盐雾对金属接头有电化学腐蚀作用，尤其是铜和铝接触面之间的电偶腐蚀。普通 IP66 接头能防喷水，但长期盐雾环境下密封圈老化比内陆快得多。
- 灯杆上的接头处于迎风面，季风期持续的强风让接头承受反复的微振动，加速了密封圈失效。
更麻烦的是我们的验收测试只做了 24 小时，这种”第 5 个月才出现”的失效模式完全测不出来。
整改：
- 把全部 34 台基站的接头换成带防水胶泥 + 双层热缩管 + 不锈钢卡箍的加强做法，更换作业花了 9 个作业窗口（不能影响码头正常生产，只能在作业间隙做）。
- 把迎风面的接头全部改为垂直向下出线，避免雨水在接头处积聚。
- 在管理平台上加了接头侧的驻波比（VSWR）监测告警。驻波比升高是接头腐蚀的早期信号——如果当时有这个告警，我们可能在故障前 2–3 周就发现了。
- 验收流程里加了一条：沿海项目的环境验收不做 24 小时，做 90 天复检。这条后来救过我们一次。
整改后连续跟踪 8 个月，没有新的腐蚀告警。项目里我最大的收获是：沿海环境的失效时间尺度是月，不是小时——24 小时负载测试对内陆项目够用，对沿海项目不够。
TOS、定位、视频、远程操如何共用一张网
硬件问题解决后，剩下的是流量规划。港口有四类流量，优先级差异极大，我们用的是 VLAN 隔离 + 四级队列。
| 流量类别 | 单设备实测带宽 | 实测时延 | 配置方式 | 实测结果 |
|---|---|---|---|---|
| TOS 指令 | 0.8–6.4Mbps（事件驱动，突发明显） | 18–42ms | VLAN 10，严格优先队列，保障 10Mbps | 24 小时负载测试零超时 |
| RTK-GPS 定位修正 | 约 120Kbps（连续，1Hz） | 86–148ms | VLAN 20，高优先级 + 带宽保障 | 零修正丢失 |
| 视频监控 | 34–138Mbps（按设备类型） | 后端到端 210–460ms | VLAN 30，承诺信息速率，中优先级 | 零卡顿帧 |
| 远程起重机操作 | 8–17Mbps（双向） | 31–44ms（往返） | VLAN 40，专用低时延队列 | 操作员主观评价”无可感知延迟” |
远程起重机操作是这套网络里最敏感的流量。要求是往返 50ms 以内——这不是随便定的数字，超过了操作员的动作与画面反馈之间就会出现可感知的滞后，直接影响对位精度。
我们实测的 31–44ms 里，无线部分只占 12–18ms，其余是视频编解码和显示链路。这一点值得强调：在评估远程操作可行性时，不能只看无线时延预算。如果编码器本身占掉 30ms，那即使无线做到 10ms，端到端仍然超标。
TOS 指令的带宽需求看起来很小（0.8–6.4Mbps），但突发性很强——一次箱位分配变更会在几百毫秒内集中下发。我们给了 10Mbps 的保障额度，是实测峰值的 1.5 倍以上。这个余量后来证明是必要的：24 小时负载测试中，TOS 流量的瞬时峰值到过 8.9Mbps。
24 小时连续作业负载测试的完整数据
2025-02-08 至 2025-02-09，码头按正常作业负荷连续运行 24 小时，我们全程监测。测试期间在港船舶 3 艘，投入 RTG 14 台、跨运车 8 台、AGV 22 台、岸桥 4 台。
| 监测项 | 改造前 | 改造后（24h 均值） | 24h 内最差值 | 测量方式 |
|---|---|---|---|---|
| RTG 切换中断时长 | 2.1–4.8s | 0 | 0 | TOS 通信日志 |
| 切换时延（无线层） | 不适用（未到切换层即断） | 24ms | 41ms | CPE 漫游日志时间戳 |
| 自动安全停机次数 | 14–38 次/天 | 0 | 0 | 起重机 PLC 日志 |
| 切换期间丢包率 | 3.8% | 0 | 0 | iperf3 持续打流（UDP） |
| TOS 指令往返时延 P95 | 超时率 2.4% | 42ms | 67ms | TOS 侧时间戳 |
| 远程操作往返时延 | 未启用 | 36ms | 44ms | 控制室端点测量 |
| 堆场总吞吐 | — | 2.4Gbps（峰值） | — | 汇聚点交换机端口采样 |
有一个数据我想单独说明：TOS 指令往返时延的最差值 67ms，超过了 100ms 要求以内的承诺吗？没有，但已经接近一半。 这次最差值出现在夜间 02:00 左右，与当时的一艘集装箱船的雷达开机时间吻合。我们没有做进一步的规避处理（雷达频率与 5GHz 不重叠），但从数据看确实存在非周期性的轻微影响。如果未来码头增加雷达设备，这个数据需要重新评估。
方案总结及改进事项
- 把”灯杆高度 vs 最大堆高”做成设计评审的必过校验项。 C 区那 4 根立杆和 4 台基站（约 11% 硬件预算）本来是可以避免的，纯属设计疏漏。
- 勘测时必须问清楚堆高的季节波动。 C 区旺季 6 层、淡季 4 层，我应该按最不利情况设计，而不是按勘测当天的实际情况。
- 沿海项目的环境验收改为 90 天复检，不做 24 小时一次过。 接头腐蚀这种失效模式的时间尺度是月，24 小时测试测不出来。这一条后来成为我们所有沿海项目的固定要求。
- 射频接头按”盐雾 + 振动”双重条件选型，而不是只看 IP 等级。 IP66 是针对喷水的，不是针对电偶腐蚀的。这是个认知错误，不是产品问题。
- 给 AGV 的 CCQ 阈值单列一套参数。 我们一开始对所有设备用了统一的阈值，但 AGV 天线只有 1.9m，遮挡条件与 RTG 完全不同，必须单独调。
项目交付后，码头连续 8 个月零安全停机，作业效率恢复到设计基线。码头设备主管在验收会上说了一句话我记到现在：”我们原来以为这是网络的问题，后来发现是切换决策权放错了地方。”——这个总结比我自己写得更准确。
参考资料
- IEC 61162《Maritime navigation and radiocommunication equipment and systems》—— 本文港口设备通信接口与数据格式的依据。webstore.iec.ch
- IEC 60068-2-11《Environmental testing — Salt mist》—— 本文射频接头盐雾腐蚀试验与选型要求的依据。webstore.iec.ch
- IEEE 802.11-2020 —— 无线局域网 MAC 与 PHY 规范，本文 802.11r 快速切换机制与 VLAN 优先级配置的协议依据。standards.ieee.org
- ITU-R M.1371 —— 自动识别系统（AIS）技术特性，本文港口射频共存分析中船舶通信系统的参照。itu.int
常见问题
问：这个项目最终用了多少台基站和多少个汇聚点？
34 台 ME2600AC 三频 MESH 基站，分布在 5 个光纤汇聚点下（每个汇聚点服务 5–9 台）。其中 C 区因为返工加了 4 台，原计划的 30 台扩到了 34 台。灯杆只有 30 根，另外 4 根是新增的 22m 专用立杆。
问：为什么不用 5GHz 做覆盖，只用 2.4GHz 不够吗？
实际部署里两者都用。基础覆盖走 2.4GHz（波长长、绕射能力好，适合集装箱之间的狭窄通道），高带宽设备（岸桥 12 路摄像头、远程操作）走 5GHz 覆盖射频。纯用 2.4GHz 的问题是可用信道只有 3 个不重叠信道（1、6、11），34 台基站在 100 公顷里做信道规划会非常紧张。
问：接头腐蚀那 6 台基站，故障期间有没有造成停产？
没有造成停机，但有影响。链路速率从 150Mbps 以上降到 40–70Mbps 的过程中，视频码率被自动降级（画面质量下降），远程操作时延从 36ms 升到 58ms 左右——操作员反映”手感变涩了”。因为有两路 5GHz 回传且有冗余路径，MESH 自动绕行保住了连接，但绕行路径的跳数增加，这是速率下降的原因。这个冗余设计救了这次故障。
问：一台基站能支持多少台起重机同时作业？
按我们项目的数据，一台基站实测同时服务 4–6 台移动设备（RTG/跨运车/AGV 混装）时表现稳定。如果全是 RTG（每台 34–58Mbps），实际上限是 3–4 台。方案阶段我给客户的估算口径是”按单设备实测带宽之和不超过基站回传容量的 60%”——留 40% 余量给突发和切换时的流量迁移。
问：码头雷达对网络的干扰，最后处理了吗？
没有专门处理，因为不需要——船舶雷达的 X 波段和 S 波段与 5GHz ISM 频段不重叠，理论上不构成同频干扰。24 小时测试中那次 TOS 时延 67ms 的最差值时间上与雷达开机吻合，但我没有做进一步的实验验证两者是否真的存在因果关系。这一点我应该说明是推测，不是实测结论。如果未来码头自己加装大功率雷达，我建议做一次专项共存测试。