企业官网建设流程全解析

做Open RAN项目的朋友应该都深有体会：前传组网和小区规划的复杂程度，往往比射频单元本身的调测还要磨人。最近我把一套室内覆盖方案从“单RRU独立小区”改成“ORAN共享小区的级联FHM模式”，说白了就是把多个远端射频单元串成一条链，通过FHM逐级汇聚回端侧，再让整条链路覆盖的区域共用一个逻辑小区资源。改完之后，光纤用量砍掉一大截，用户走动时不再频繁触发切换，基带处理资源也省了不少。但这个方案也把一组以前根本不用操心的问题摆到台面上：级联时延怎么预算、前传带宽够不够、时钟同步会不会逐级劣化、多TRP上行合并怎么调才能拿到分集增益。这篇文章把我这次项目里的设计思路、计算过程、配置步骤和踩过的坑完整整理出来，给正在做Open RAN组网、室内分布式覆盖或者共享小区优化的同行一个参照。

1. 项目拆解：ORAN共享小区为什么要用级联FHM

1.1 FHM在ORAN架构里到底扮演什么角色

先说清楚FHM是什么。在ORAN的典型功能切分里，O-RU负责射频收发和部分物理层处理，O-DU负责高层物理层、MAC和一部分RLC，O-CU则负责RRC和PDCP等高层协议。这个链条中间会碰到一个很实际的问题：一个O-DU要挂几十个O-RU，尤其是室内分布式场景，总不能每个O-RU都拉一根独立光纤到DU机房，那样弱电井早被光纤塞满了。

FHM（Forwarding Handling Module，前端汇聚模块）就是夹在O-RU和O-DU之间的转发汇聚设备。它不做空口调度，也不解析业务内容，核心工作就是把多个O-RU的前传数据进行汇聚、转发，同时把O-DU下发的数据分发到各个O-RU。如果用一句话描述，它像是一个快递中转站：包裹不拆封，但会根据面单信息把同路的件合流装车，再把到站的件分拣派送。

“级联FHM”则是让这些中转站手拉手串联起来。正常思路是星型组网，每个FHM一根光纤回DU，级联模式变成FHM之间依次串接，最后只有最靠近DU的那个FHM用一根主干光纤接到端侧。形象点讲，星型是每个房间独立拉网线到弱电井，级联是一根网线串起多个房间，最后一个口统一出线。这个拓扑对纵深场景特别友好，比如写字楼走廊、酒店楼层、地下车库这类布线通道紧张的地方。

需要说明的是，不同厂家的FHM在实现细节上会有差异，有的叫pRRU汇聚单元，有的叫远端交换模块，但级联转发的基本逻辑是一致的。做方案时不要被名字带偏，先抓住“汇聚、转发、级联透传”这三个核心能力去评估设备。

1.2 共享小区解决的核心痛点

传统室内覆盖的做法是一个pRRU配置成独立小区，每个房间或每段走廊都是一个小小区。听起来覆盖精细，实际用起来问题不少：用户从房间走到走廊，从一个pRRU覆盖区走到另一个pRRU覆盖区，终端就要在小小区之间做切换。室内环境下RSRP波动快，切换次数猛增，掉话率和时延抖动都会上来。再加上每个小小区都要占用一个PCIO，邻区配置复杂，基带资源也被大量消耗。

共享小区（也叫小区合并或超小区方案）的思路完全不同：把多个O-RU配置成同一个逻辑小区，整片覆盖区域共用一个PCI、一个小区ID、一套系统消息。终端在这个区域里移动时，看不到小区变化，自然也就不需要切换。打个比方，传统方案是每个房间单独开一家小卖部，顾客跨门槛就得重新结账；共享小区是把一排房间打通成一个大型超市，顾客在超市里随便逛，出门才结一次账。

这个模式在高铁站、医院、大型场馆这类连续覆盖、用户移动性强的场景尤其合适。它削掉了大量小区间切换带来的信令开销和失败风险，也减少了基带板资源占用。代价也很明确：整个共享小区叠加起来的用户容量，本质上还是一个小区的容量。如果某个区域用户密度极高、业务量巨大，把所有O-RU合并成一个大区反而会形成容量瓶颈。所以共享小区适合“中低容量、高移动性”的场景，高容量场景还是得分小区，这个判断要在设计之初就做清楚。

1.3 级联是手段，不是目的

有人会问，既然要组共享小区，FHM用星型连接不也能合并小区吗？为什么非要级联？实际原因是布线条件和建设成本。

我这次做的项目是一栋五层的办公楼改造，每层需要4个O-RU做连续覆盖。如果全部星型回端，至少需要从端侧敷设几十芯光纤到弱电井，而且每层得配一台汇聚交换机或多个光模块，光模块和主干光纤的成本很快就会失控。采用级联FHM后，每层只需在弱电井里放一个FHM，层与层之间用一根光纤串联，最后只在端侧出一根主干光纤到DU，整体光纤用量和光模块数量都大幅减少。

但级联模式也有明显短板：链路是单点串联的，任何一个中间节点断电或光模块故障，它后面的所有O-RU都会脱管。此外，每级FHM的转发处理都会引入额外时延，级联得越多，时延积累越大，对同步和前传链路的要求就越苛刻。所以级联从来不是为了“看起来高级”，而是在布线资源受限的前提下，用可靠性换成本的一种工程取舍。判断要不要级联，先问三个问题：主干光纤资源是否真的紧张？级联级数能不能控制在6级以内？中间节点断电对业务影响是否可接受？三个问题答案都合适，再做级联方案。

2. 设计要点：级联时延、前传带宽与同步这三本账怎么算

2.1 从7-2x功能切分看FHM的转发逻辑

ORAN最常见的功能切分是7-2x：O-RU完成FFT变换、CFR、DPD等处理，把频域IQ数据通过前传接口送到O-DU，剩余的编解码、调制解调、MAC调度全部在O-DU侧完成。在这个切分模式下，前传接口上跑的是高带宽的IQ数据流，接口协议一般用eCPRI承载，控制面消息也在同一套前传链路上传输。

FHM在级联链路里最忌讳的是自作聪明。它不能对IQ数据做深度缓存、插值或重排，必须做透明透传和快速转发。eCPRI定义了三个平面：U平面传IQ用户数据，C平面传波束赋形权重、调度指令等实时控制信息，S平面传同步和配置管理消息。FHM要用不同优先级队列处理这三个平面的报文，尤其C平面报文必须走快路径，不能被大流量U平面报文堵在后面。

配置FHM时有一个容易被忽视的点：级联口既要透传U平面的高吞吐数据，又要保证C平面低时延。实际操作中，我会把C平面和S平面划到独立的VLAN，并为它们设置高优先级队列，U平面设置普通队列。这样即使某段链路出现短时拥塞，实时控制消息也能优先通过，避免因为个别大包挤占队列导致O-RU收不到控制指令而掉链路。这个细节在级联多级以后尤其重要，单级星型拓扑可能感受不到，串到4级以上就明显了。

2.2 级联时延预算：一级一级加起来会超预算

级联最核心的技术约束就是时延。每级FHM的转发处理时延通常在3到8微秒之间，这取决于芯片架构和报文处理方式；光纤每米引入约5纳秒时延，一段100米的光纤就是0.5微秒。如果做一个8级级联，每段光纤按80米计算，每级总时延大约是FHM处理时延5us加光纤0.4us，单程累加接近43微秒。

43微秒意味着什么？5G NR在30kHz子载波间隔下，普通循环前缀（CP）大约只有4.7微秒。如果同一共享小区的不同O-RU到O-DU的传播时延差超过CP长度，OFDM符号之间的正交性就会被破坏，终端解调性能急剧恶化。这也是新手做级联方案最容易翻车的地方：只计算了整条链路的绝对时延，却忽略了一个关键事实——O-DU可以做整体时延调整，真正要命的是同一个小区内不同O-RU的到达时间差。

具体到系统实现，O-DU会给每个O-RU配置独立的上行定时提前量或时延补偿值，把所有O-RU的天线接收时刻对齐到同一个帧边界。只要级间时延差能通过补偿控制在合理范围内，绝对时延大一些反而是可以被容忍的。但补偿能力不是无限的，不同O-RU到达时间差一旦超过CP窗口，就会出现符号间干扰。工程经验是，级联级数控制在6到8级以内，超过6级就要谨慎评估，超过8级基本不建议。另一个办法是调整拓扑，把一条长链拆成两条较短的链，各自独立回端，这样时延预算和链路冗余都能改善。

做设计方案时，不要拍脑袋估时延，一定要去查FHM规格书里的“转发时延”参数，并留出至少20%的余量。不同厂家的芯片方案处理时延差好几倍，同一个厂家不同型号也可能不同。

2.3 前传带宽计算：别让汇聚口变成瓶颈

级联FHM的流量是逐级累加的：靠近端侧的上行FHM，汇聚的IQ数据流量是它下游所有O-RU的总和。前传带宽账算不齐，后面配置再好也白搭。

前传IQ速率有一个基础公式：单天线流速率 = 采样率 × 2 × IQ位宽。采样率和带宽有关，比如20MHz LTE是30.72Msps，100MHz 5G NR是122.88Msps；这里的“2”是I和Q两个分量；IQ位宽通常是16bit，使用压缩方案时可能降到12bit或9bit。再乘上天线流数，就是总的前传净速率。最后还要加上eCPRI报文头、以太网帧头等开销，工程上一般按5%到10%估算。

为了直观，我列了一张常用配置的估算表，单位是Gbps，未开启压缩：

这是单个O-RU的数据。如果一个FHM下面挂了4个100MHz 4T4R的O-RU，那这个FHM的上行口至少要提供约62.9Gbps的转发能力。实际工程中，这个量级单靠一个25G光口扛不住，必须用100G光口或4×25G链路聚合，或者启用IQ压缩、降低天线流数来压缩速率。这也是很多项目做级联时最容易预算失误的地方：前期只按单O-RU速率算，忽略了FHM逐级汇聚后的倍增效应。

我个人的建议是，做级联组网规划时，先用Excel拉一张全链路流量表，每个FHM列出下挂O-RU数量和单机速率，逐级累加到主干端口，确认每一级的上行口速率都够用。标注好哪些端口可以启用压缩，哪些端口必须裸传。流量表拉完，端口选型基本就定下来了，后面不用改来改去。

2.4 时钟同步在级联链路里的逐级劣化问题

共享小区对多个发射点的时间对齐要求非常严格。同一小区内的多个TRP如果发射时间偏差过大，终端收到的各路信号就会像合唱时有人慢半拍，OFDM解调窗口直接乱掉。按照3GPP对多TRP/多小区MBSFN场景的要求，空口时间偏差一般要控制在±1.5微秒以内，工程上通常会留更大余量，建议端到端时间偏差控制在±0.5微秒甚至更低。

前传链路上的时钟同步通常用IEEE 1588v2（PTP）配合SyncE同步以太网来实现。SyncE负责恢复频率，1588负责恢复相位和对齐时间。级联模式下，1588报文要逐级穿过每个FHM，每一级都引入驻留时延。如果某级FHM配置成边界时钟模式，它会终结上游1588报文，自己作为主时钟向下游发布新报文，这种模式能阻止错误累积，但要求该级FHM自身时钟质量过硬；如果配置成透传时钟模式，报文直接穿过，速度更快，但每级驻留时延会累加，需要设备支持修正驻留时间。

从工程习惯来看，我一般建议级联链路上的FHM统一配置为透传时钟模式，并开启SyncE恢复频率，这样既能减少逐级处理带来的抖动，也能把频率锁定到上游高精度时钟源。一个常被忽略的问题是，不能在同一级链路上混用BC和TC模式，否则1588选主逻辑会乱套，引起级联后段的节点反复在master和slave之间跳变。

排查同步问题也有一个实操技巧：登录每一级FHM查看PTP状态，从最靠近DU的那一级开始逐级往下看，找到第一个显示未锁定或者时间偏差异常大的节点，故障点大概率就在它和上一级之间的链路上。同步问题往往是隐性的，表现不是直接断站，而是误块率逐步上升、VOLTE语音断续、切换成功率下降，排查时要有这个意识。

2.5 共享小区的上行合并与下行同发机制

共享小区的核心处理发生在O-DU侧，而不是FHM侧。下行方向上，O-DU产生一份下行数据，复制并分发给所有参与共享的O-RU，让它们在相同的时间频率资源上同时发射。终端看到的是多径信号叠加，天然享受软合并增益。上行方向上，同一个终端的信号被多个O-RU收到，各自把IQ数据上报给O-DU，O-DU对不同TRP的信号做最大比合并（MRC）或者干扰抑制合并（IRC），恢复出更高质量的上行业务数据。

上行合并的前提是各路IQ采样必须对齐，这又回到了2.2节讲的时延补偿。如果两个O-RU上报的信号到达O-DU的时间差落在合并窗口之内，MRC合并增益明显；超出窗口，合并增益急剧下降，甚至两个信号互相抵消。所以现场遇到共享小区上行速率反常，第一个要查的就是DU侧每个TRP的到达时间差。

MRC合并的增益能达到多少？理论上，两路独立衰落信号做MRC，信噪比增益接近3dB，更多路TRP增益还能继续累积。但实际室内密集环境里，多个O-RU接收的信号相关性很高，天线间距又不一定满足独立衰落条件，实测增益往往没有理论值那么漂亮。我这次项目里两路强信号区域实测合并增益在2到3dB左右，三路以上重叠区域的增益更有限。做网络指标预期时，别把合并增益想得太理想，重点还是放在覆盖连续性和切换减少上。

下行同发有一个配置细节：各个O-RU的下行发射功率不要一开始就调成不同值，先统一功率跑一遍测试，再根据路测结果微调。多TRP同发的场景下，功率差异过大会导致某个TRP覆盖边缘的终端收到强信号里的“远距离回波”，SINR不升反降。

3. 落地实操：从拓扑规划到共享小区开通调测

3.1 拓扑规划与硬件连接

这次项目的实际拓扑是一条五级级联链：端侧O-DU接一级FHM，一级FHM放在二层弱电井，通过一根主干光纤串联到三层、四层、五层、六层的FHM，每层FHM下挂两个O-RU，覆盖左右两翼走廊。所有O-RU配置成同一个共享小区，共10个TRP参与合并。

硬件连接上，FHM的级联口要区分上行和下行方向。上行口接上一级FHM或端侧设备，下行口接下一级FHM。接反了轻则告警，重则直接在链路上形成环路，把前传网络打瘫。施工时还要特别注意光纤的收发交叉，A端发对应B端收，弱电井里成端跳纤时最容易在这里出错。

光模块选型上，主干链路段建议统一使用与接口速率匹配的模块，不要为了省成本在中间混插不同速率的光模块。速率不匹配的设备会自动协商降速，表面上链路能通，但带宽已经悄悄缩水，只有打到峰值流量时才发现吞吐不够。

3.2 FHM级联配置项

不同厂家的配置命令不一样，但核心配置项是一致的。我整理了一份示意配置，字段名称以实际设备为准，关键是看明白每一类参数在做什么：

cascade: id: 3 # 本FHM在级联链中的序号 role: middle # 枚举: head/middle/tail uplink-port: eth0 # 25G，接上一级FHM或DU downlink-port: eth1 # 25G，接下一级FHM port-role: cascade # 标识下行口为级联口，不是普通O-RU口 eCPRI: u-plane-vlan: 100 # IQ数据平面VLAN c-plane-vlan: 101 # 实时控制平面VLAN s-plane-vlan: 102 # 同步与管理平面VLAN queue-priority: c-plane: high # C平面走高优先级队列 s-plane: high u-plane: normal sync: mode: TC # 透传时钟模式 synce: enable # 开启同步以太网恢复频率

几个关键点展开说一下。级联ID用于端侧识别链路上各FHM的顺序，规划时一定要和物理位置一一对应，现场标签写清楚，不然后期排查时根本不知道哪个ID对应哪层楼。VLAN划分不强制，但做了之后排查问题会方便很多，抓包时可以按VLAN直接过滤出对应平面的报文。同步模式前面说过，统一用TC，不要混合BC。

配置完成后有一个简单验证方法：在端侧O-DU上应能看到所有下级O-RU注册成功，并能通过读取各FHM的端口状态确认端口速率协商结果。如果某个FHM下面的O-RU注册不上，先回查这台FHM的级联配置和光模块状态，不要直接怀疑O-RU坏了。

3.3 共享小区参数配置示例

共享小区的核心是把多个TRP绑到同一个逻辑小区下。下面是项目里用到的小区级配置示意：

shared-cell: cell-id: 1001 pci: 501 nr-band: n78 bandwidth: 100M scs: 30kHz trp-list: [0,1,2,3,4,5,6,7,8,9] # 对应10个O-RU uplink-combining: mrc # 上行合并算法 time-offset-us: trp0: 0.0 trp1: 1.1 trp2: 2.3 trp3: 4.6 trp4: 5.2 trp5: 7.8 trp6: 8.3 trp7: 10.1 trp8: 11.5 trp9: 13.0

time-offset这一组参数，也就是每个TRP的上行定时补偿值，不要手动拍脑袋填。标准流程是O-DU在O-RU注册完成后，通过前传链路自动测量各TRP的环回时延，再自动计算并下发给各O-RU。我在这里展示的是测量完成后最终生效的数值，用来直观展示级联链路逐级时延累积的实际情况：从trp0到trp9，时延补偿值从0微秒一路增加到13微秒，正好反映了信号从端侧到最末端O-RU之间多穿越了多级FHM和光纤段。如果设备支持自动测量，一定让它自己算，手动填容易因为笔误引入灾难性的时延失配。

邻区规划上，共享小区覆盖范围大，周边的邻区关系尽可能配置完整。共享小区边缘的切换失败，最常见的原因就是邻区漏配。另外在引入共享小区后，原独立小小区之间的邻区关系可以删除，但共享小区与外围宏站、周边室分系统的邻区必须逐条核对。

3.4 开通调测流程

按什么顺序调测，决定了出问题时能不能快速定位。我这次项目的操作顺序如下，每一步的检查点也一并列出：

1. 光纤链路检查：使用光功率计测试每段光纤收发光，确认在模块接收灵敏度范围内；检查误码率，长时间ping大包或DU侧看端口CRC错误计数。
2. 链路层检查：各FHM级联口状态up，LLDP能学到对端设备信息，端口速率协商正确。
3. 同步检查：确认每级FHM的PTP状态为slave且已锁定，时间偏差在可接受范围内；确认SyncE锁定无告警。
4. 前传注册检查：O-DU上能看到全部O-RU注册成功，无IQ数据异常告警。
5. 时延补偿确认：DU自动测量各TRP环回时延，回填time-offset，确认各TRP到达时间对齐。
6. 小区状态检查：小区进入服务状态，无载波不可用、同步丢失等告警。
7. 业务验证：用测试终端接入，验证附着、ping时延、上下行灌包速率。
8. 覆盖验证：沿走廊步测RSRP/RSRQ/SINR，重点观察共享小区内部信号平滑过渡，无突变点。

这个顺序的原则是从物理层逐步往上检查。很多新手一上来就看小区状态，哪一级O-RU没注册就去换设备，结果换了好几台发现是光纤收发接反了。先解决物理层和链路层，再谈协议层，能省大量无用功。

3.5 覆盖与合并效果验证

小区开起来以后，要用实测数据验证共享小区的效果，不能只看设备侧没有告警就收工。

覆盖方面，用路测软件沿整个覆盖区打点测试。共享小区内部的RSRP应该是一个平滑覆盖曲线，不同TRP之间的交界处可能出现RSRP轻微抬升或波动，但没有断崖式下跌。如果某个TRP覆盖边缘出现明显信号塌陷，先检查该O-RU的发射功率和天馈连接，其次检查该TRP是否在时延补偿后仍然没有对齐。

上行合并效果方面，到O-DU侧查看每个TRP的上行接收电平和合并后信噪比统计。选择两个TRP重叠覆盖的区域，让测试终端做上行灌包，对比单TRP接收时的信噪比和MRC合并后的信噪比。如果合并增益明显偏低，优先核对time-offset是否准确，其次是检查参与合并的TRP是否有驻波或射频通道异常。测试时建议多取几个位置，避免单个位置的测量偏差影响判断。

4. 跑现场必看：级联FHM共享小区常见问题排查实录

4.1 小区反复建立失败或闪断

这个现象在项目初期最容易出现。排查思路是“先物理层后协议层”。先在FHM上确认级联口和O-RU端口都是up状态，收发光正常。再在O-DU上看O-RU的注册状态，确认eCPRI链路已经建立。如果注册成功但小区建立失败，查看C平面是否有告警，例如IQ位宽不匹配、天线数配置不一致等。

我遇到过一次比较隐蔽的情况：某级FHM的U平面VLAN和C平面VLAN配置反了，O-RU能注册上，但小区起不来，因为控制消息没有走正确的VLAN到达DU。这种情况下抓包最容易看出来，先在FHM级联口抓eCPRI报文，确认C平面和U平面报文各自都带着正确的VLAN标签，再顺着链路逐级排查。

4.2 同步告警反复出现

级联链路的同步告警，九成以上出在中间某级FHM的配置上。比较典型的是某级FHM被误配成边界时钟模式，而其他级都是透传时钟，导致下游节点不停选主。还有的情况是SyncE在某一级没有开启，频率没有逐级锁定，下游节点的晶振偏差逐渐累积，最终时间误差超出阈值。

排查时按级联顺序逐级查看PTP状态和offset值。从最靠近DU的第一级开始，如果某一级显示offset突然变大，比如从几十纳秒跳到几百纳秒甚至微秒级，问题就锁定在这级FHM到上一级之间的链路或配置上。再用网管看这级FHM的1588报文收发计数，确认报文是否被丢弃或延迟过大。

4.3 共享小区上行速率异常

共享小区上行速率偏低，最常见的三个原因按概率排序：时延补偿不准、参与合并的某个TRP通道异常、FHM上行口拥塞。

先看DU侧每个TRP的到达时间差，找出偏离均值较大的TRP，检查它的时延补偿值是否回填正确。再看告警，确认没有TRP存在驻波比过高或射频通道关闭。最后看FHM端口的流量统计，如果端口流量接近上限且出现丢包计数，那就是带宽预算没做够。前两个原因可以通过参数调整解决，第三个原因是硬伤，只能靠压缩IQ、减少下挂O-RU数量或升级光口速率来缓解。这里也要强调一句：带宽不足不能靠调参数蒙混，必须在设计阶段算清楚。

4.4 共享小区边界切换失败

共享小区覆盖范围大，边缘一旦切换失败，用户业务直接中断，比小区内的小区切换失败更明显。排查时先确认边缘覆盖区域的邻区是否全部配置，最好用扫频终端在边缘走一圈，抓取实际可见的邻区PCI，和配置表逐一核对。再确认邻区PCI没有冲突，如果周边两个不同小区配置了相同PCI，终端测量报告上报后会让基站困惑。

还有一个容易忽略的配置：共享小区的位置区码或跟踪区码不要设置得过大。如果覆盖范围跨越了几个TA边界，寻呼开销会明显增加，虽然不一定直接导致切换失败，但会影响网络整体性能。共享小区跨TA配置时，先确认核心网侧的TA列表和寻呼策略能接受。

4.5 中间节点断电引发的断链

级联结构的天生弱点是单点故障扩散。FHM断电，它下游所有FHM和O-RU全部脱管，而且因为链路是串联的，故障表现是整个后半段断站，不是单个节点掉线。

处理方式分两层。施工层面，每级FHM的电源尽量接在独立空开上，并做断电告警接入网管，确保节点掉电后第一时间能感知。设计层面，如果对可靠性要求高，可以考虑双链冗余或把长链拆成两条较短链，但代价是光纤和光模块用量增加。这个取舍在方案评审阶段就要和甲方谈清楚，不要等项目上线后再补。

排查断链还有一个实用技巧：从最末端FHM开始逐级向上断开再恢复，观察每级O-RU的注册状态变化，可以快速定位到底是哪一段光纤或哪个节点出了问题。这个“从后往前”的逐级排查法，比盲猜节省大量时间。

4.6 一个小习惯：配置备份比什么都重要

级联FHM的配置项不算多，但耦合关系复杂。级联ID、VLAN、同步模式、时延补偿字段，任何一个改错都可能引发连锁故障。我的习惯是每次调整前先导出全量配置，调整后对比变更内容；出了问题回滚比重新配置快得多，特别是time-offset这类和现场环境强相关的参数，恢复起来非常费劲。

另外，项目交付时一定要把整条级联链路的拓扑图、每级FHM的级联ID与物理位置对照表、光纤成端信息、配置备份统一归档。这套资料在后续故障排查和扩容时都是最宝贵的资产，比任何技术文档都管用。

最后再分享一个小经验：级联FHM共享小区这个方案，省光纤、省切换、省基带资源的效果都是实打实的，但前期必须把时延、带宽、同步这三本账算清楚，否则后面现场排查的代价，往往会远超省下来的成本。我个人在任何级联改造项目启动前，都先在表格里拉一遍每级FHM的时延贡献和流量汇聚值，确认全部落在指标窗口内，再动第一根光纤。这套方法我用了很多次，每次都让我少熬几个夜。如果你也在做类似的Open RAN共享小区项目，这几个计算表和排查思路可以直接拿去用。