做Open RAN项目的朋友应该都深有体会前传组网和小区规划的复杂程度往往比射频单元本身的调测还要磨人。最近我把一套室内覆盖方案从“单RRU独立小区”改成“ORAN共享小区的级联FHM模式”说白了就是把多个远端射频单元串成一条链通过FHM逐级汇聚回端侧再让整条链路覆盖的区域共用一个逻辑小区资源。改完之后光纤用量砍掉一大截用户走动时不再频繁触发切换基带处理资源也省了不少。但这个方案也把一组以前根本不用操心的问题摆到台面上级联时延怎么预算、前传带宽够不够、时钟同步会不会逐级劣化、多TRP上行合并怎么调才能拿到分集增益。这篇文章把我这次项目里的设计思路、计算过程、配置步骤和踩过的坑完整整理出来给正在做Open RAN组网、室内分布式覆盖或者共享小区优化的同行一个参照。1. 项目拆解ORAN共享小区为什么要用级联FHM1.1 FHM在ORAN架构里到底扮演什么角色先说清楚FHM是什么。在ORAN的典型功能切分里O-RU负责射频收发和部分物理层处理O-DU负责高层物理层、MAC和一部分RLCO-CU则负责RRC和PDCP等高层协议。这个链条中间会碰到一个很实际的问题一个O-DU要挂几十个O-RU尤其是室内分布式场景总不能每个O-RU都拉一根独立光纤到DU机房那样弱电井早被光纤塞满了。FHMForwarding 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-2xO-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.72Msps100MHz 5G NR是122.88Msps这里的“2”是I和Q两个分量IQ位宽通常是16bit使用压缩方案时可能降到12bit或9bit。再乘上天线流数就是总的前传净速率。最后还要加上eCPRI报文头、以太网帧头等开销工程上一般按5%到10%估算。为了直观我列了一张常用配置的估算表单位是Gbps未开启压缩配置单天线流速率天线流数组合前传净速率20MHz LTE 2T2R0.9821.97100MHz NR 4T4R3.93415.73100MHz NR 8T8R3.93831.46这是单个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 1588v2PTP配合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-DUO-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.0time-offset这一组参数也就是每个TRP的上行定时补偿值不要手动拍脑袋填。标准流程是O-DU在O-RU注册完成后通过前传链路自动测量各TRP的环回时延再自动计算并下发给各O-RU。我在这里展示的是测量完成后最终生效的数值用来直观展示级联链路逐级时延累积的实际情况从trp0到trp9时延补偿值从0微秒一路增加到13微秒正好反映了信号从端侧到最末端O-RU之间多穿越了多级FHM和光纤段。如果设备支持自动测量一定让它自己算手动填容易因为笔误引入灾难性的时延失配。邻区规划上共享小区覆盖范围大周边的邻区关系尽可能配置完整。共享小区边缘的切换失败最常见的原因就是邻区漏配。另外在引入共享小区后原独立小小区之间的邻区关系可以删除但共享小区与外围宏站、周边室分系统的邻区必须逐条核对。3.4 开通调测流程按什么顺序调测决定了出问题时能不能快速定位。我这次项目的操作顺序如下每一步的检查点也一并列出光纤链路检查使用光功率计测试每段光纤收发光确认在模块接收灵敏度范围内检查误码率长时间ping大包或DU侧看端口CRC错误计数。链路层检查各FHM级联口状态upLLDP能学到对端设备信息端口速率协商正确。同步检查确认每级FHM的PTP状态为slave且已锁定时间偏差在可接受范围内确认SyncE锁定无告警。前传注册检查O-DU上能看到全部O-RU注册成功无IQ数据异常告警。时延补偿确认DU自动测量各TRP环回时延回填time-offset确认各TRP到达时间对齐。小区状态检查小区进入服务状态无载波不可用、同步丢失等告警。业务验证用测试终端接入验证附着、ping时延、上下行灌包速率。覆盖验证沿走廊步测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共享小区项目这几个计算表和排查思路可以直接拿去用。
