1. 为什么IAB值得单独拎出来聊
第一次接触IAB这个概念，是在做室内深度覆盖方案评审的时候。当时一个多层写字楼的场景，光纤拉不到每一层，传统方案要么靠大量微站加有线回传，要么靠射频直放站硬撑，前者施工成本高得离谱，后者干扰控制一塌糊涂。会上有人提了一句“能不能让基站自己无线回传”，这才把IAB（Integrated Access and Backhaul，接入回传一体化）重新拉回视野。后来把3GPP相关架构文档翻了几遍，又对着几个仿真环境做了验证，才算把这条链路真正理顺。
IAB要解决的问题其实很朴素：让基站用无线的方式给自己找回传。传统基站的回传是光纤或有线，接入是空口，两者泾渭分明；IAB把这两件事揉到同一套空口资源里，一个节点既给终端提供接入，又通过无线链路把流量送回上游。这个“自己给自己修路”的思路，直接决定了它在密集城区、室内深度覆盖、临时组网、盲区补盲这些场景里的价值。适合谁看？做无线网络规划、做室分方案、做Relay相关产品、或者单纯想搞明白3GPP这套架构怎么落地的人，都能从里面找到自己关心的部分。
这篇文章不打算复述规范条文，而是按一个从业者的视角，把IAB的架构逻辑、关键节点、协议栈切分、资源分配、实操验证和踩坑经验串起来。你会看到为什么架构要这么切、每个选择背后的取舍是什么、实际部署时哪些参数最容易出问题。看完之后，至少能对着一个具体场景判断“这里该不该上IAB、上了之后瓶颈可能在哪”。
2. IAB架构的整体设计与思路拆解
2.1 从“有线回传”到“无线回传”的本质变化
传统蜂窝网络里，回传（backhaul）和接入（access）是两条物理上独立的链路。回传走光纤、微波或者专线，接入走空口，基站内部把两者桥接起来。这种分离带来一个好处：回传带宽稳定、时延可控、规划简单。但代价也很明显——回传的物理可达性成了网络部署的硬约束。光纤到不了的地方，基站就上不了；临时场景拉不了线，覆盖就做不了。
IAB的核心变化是把回传也搬到空口上。一个IAB节点（IAB-node）通过无线链路连到上游节点，上游节点再把流量往核心网送。这样一来，回传的“物理可达性”约束被大幅放松，只要射频能覆盖到，理论上就能布点。但天下没有免费的午餐，无线回传意味着回传和接入要共享同一份空口资源，资源分配、干扰协调、时延控制全部变成新的难题。3GPP的架构设计，本质上就是在解决“共享资源下如何保证两边都不崩”这个问题。
这里有个容易被忽略的点：IAB不是简单的“无线网桥”。网桥是二层转发，不关心上层协议；IAB节点要参与无线资源管理、要维护自己的接入链路和回传链路、要处理调度和QoS映射。它更像一个“半个基站+半个终端”的混合体，这个双重身份直接决定了后面协议栈的切分方式。
2.2 架构选型的核心取舍：为什么是CU/DU分离
IAB架构能成立，前提是CU（Centralized Unit）和DU（Distributed Unit）的分离。这个分离在3GPP里本来是给CU/DU云化部署准备的，IAB把它复用得很巧妙。
具体来说，IAB节点里只放DU和MT（Mobile Termination），CU放在宿主节点（IAB-donor）上。MT负责和上游节点通信，相当于一个“终端身份”；DU负责给自己覆盖下的终端提供接入，相当于一个“基站身份”。CU集中处理PDCP及以上协议，DU处理RLC/MAC/PHY。这样切的好处是：IAB节点不需要完整的基站协议栈，成本和复杂度都降下来了，同时CU集中管理让跨节点的资源协调成为可能。
为什么不把CU也放到IAB节点里？因为那样每个节点都是一个完整基站，节点间的协调、切换、资源分配会退化成分布式决策，在无线回传这种资源紧张的场景下，分布式决策很容易打架。集中式CU相当于一个“总调度”，能站在全局视角分配回传资源，这是IAB能稳定运行的关键。
提示：CU/DU分离不是IAB独有的，但IAB对它的依赖程度远高于普通基站。普通基站CU/DU分离更多是部署灵活性考虑，IAB则是架构成立的必要条件。
2.3 节点角色划分：宿主、中继、终端三层结构
IAB的网络结构可以拆成三层角色。最上游是IAB-donor（宿主节点），它是有线回传的终点，也是CU的落脚点，相当于整个IAB子网的“出口”。中间是IAB-node（中继节点），可以多跳级联，每一跳都通过无线回传连到上游。最下游是普通终端（UE），通过接入链路连到某个IAB节点或宿主。
这个三层结构带来一个重要的架构特征：回传链路是逐跳累积的。一个三跳的IAB链路，最末端节点的流量要经过两次无线回传才能到宿主，每一跳都会引入时延和资源消耗。所以实际规划时，跳数是个必须控制的参数，通常建议不超过两跳，超过之后时延和容量衰减会非常明显。这个结论不是拍脑袋，后面在资源分配那节会给出具体的量级估算。
节点角色还决定了拓扑的灵活性。IAB支持树形拓扑，也支持节点间的一定程度的多连接。树形拓扑简单、管理方便，但单点故障风险高；多连接能提升可靠性，但资源协调复杂度上升。3GPP在架构上留了多连接的口子，实际用不用、怎么用，取决于场景对可靠性的要求。
3. 核心协议栈与关键机制解析
3.1 协议栈切分：MT和DU各自扛什么
把IAB节点的协议栈拆开看，是理解整个架构最直接的方式。IAB节点内部有两套协议栈在跑：一套是MT侧的，一套是DU侧的。
MT侧协议栈和普通终端基本一致，从PHY、MAC、RLC、PDCP一路往上，负责和上游节点（父节点）建立回传链路。区别在于MT承载的是回传流量，QoS要求和普通终端不同，调度优先级也不一样。DU侧协议栈则是基站的那一套，PHY、MAC、RLC往上，给下游终端或下游IAB节点提供接入。
关键在于PDCP这一层。回传链路的PDCP锚定在宿主节点的CU上，也就是说IAB节点MT侧的PDCP对端是宿主CU，中间经过的每一跳只做RLC/MAC转发。这个设计让回传链路有了类似“端到端”的可靠性保障——PDCP的重传和加密在宿主CU和IAB节点MT之间完成，中间跳数不影响可靠性机制。这也是为什么IAB能支持多跳而不会让可靠性随跳数线性下降。
DU侧的PDCP同样锚定在宿主CU上（对于接入链路），IAB节点的DU只处理到RLC。这种“PDCP集中、RLC分布”的切分，是IAB架构的精髓：集中部分保证可靠性和移动性管理，分布部分保证调度实时性。
3.2 回传链路的建立流程：从开机到可用
一个IAB节点从开机到回传链路可用，走的是一个分阶段流程，这个流程的设计逻辑值得细看。
第一阶段是MT侧接入。IAB节点开机后，MT先像普通终端一样搜网、随机接入、建立RRC连接，连到上游节点。这一步用的是终端的流程，目的是先把“无线管道”打通。此时节点还没有DU功能，不能给终端提供服务。
第二阶段是回传链路配置。MT接入成功后，通过RRC信令和宿主CU交互，获取回传链路的配置信息，包括回传承载的建立、路由配置、IP地址分配等。这一步是整个流程的核心，配置错了后面全盘皆输。
第三阶段是DU侧激活。回传链路就绪后，DU侧启动，开始广播系统信息、接受下游终端或下游节点的接入。到这里，一个IAB节点才算真正“上线”。
这个分阶段设计的好处是职责清晰、故障可定位。如果节点起不来，先看MT能不能接入，再看回传配置有没有下发成功，最后看DU有没有正常广播。实际排障时按这个顺序走，能省掉大量瞎猜的时间。
注意：回传链路配置阶段对信令的完整性要求很高，任何一个参数缺失都可能导致DU侧起不来。实际调试时建议把这一阶段的信令日志完整抓下来，后面出问题回看非常有用。
3.3 资源分配：接入和回传怎么分同一块空口
这是IAB最核心也最棘手的问题。接入链路和回传链路共享空口资源，分配策略直接决定网络性能。
3GPP给的框架是时分复用为主、频分复用为辅。时分复用的意思是，同一时刻要么传回传、要么传接入，通过时隙配置来划分。这种方式的优点是实现简单、干扰可控，缺点是资源利用率受限于时隙划分的粒度。频分复用则是把带宽切成两部分，一部分给回传、一部分给接入，优点是能同时传输，缺点是对射频和滤波器的要求高，且频谱利用率不一定高。
实际部署里，时分复用是主流选择，因为它的干扰管理更简单。时隙配置的关键参数是回传时隙和接入时隙的比例。这个比例不是固定的，要根据业务分布动态调整。比如一个节点下游终端多、回传流量大，回传时隙就要多分一些；反之则接入时隙多分。3GPP支持半静态配置和动态调整两种方式，半静态配置简单但不够灵活，动态调整灵活但对调度器要求高。
这里有个实操中的经验：回传时隙的比例不要压得太低。我见过为了给接入让资源，把回传时隙压到20%以下的配置，结果回传链路成为瓶颈，下游终端体验反而更差。一般建议回传时隙不低于30%，具体数值要结合跳数和业务模型算。
3.4 路由与承载映射：流量怎么找到出口
IAB子网内部的路由，走的是基于IP的转发。每个IAB节点和宿主都有IP地址，回传流量通过IP路由逐跳转发到宿主。这个设计的好处是复用了成熟的IP转发机制，不需要定义新的L2路由协议。
但IP路由带来一个问题：QoS怎么保证。IP转发本身不区分业务优先级，如果回传链路上所有流量一视同仁，高优先级业务会被低优先级业务挤占。3GPP的解法是承载映射：把不同QoS的业务映射到不同的回传承载（backhaul bearer）上，每个承载有独立的调度优先级。这样即使走同一条IP路由，不同承载的流量在RLC/MAC层也能得到差异化调度。
承载映射的关键是QoS映射表的配置。终端侧的QoS流（5QI）要正确映射到回传承载，映射错了会导致高优先级业务被降级。实际配置时，建议把映射表打印出来逐条核对，尤其是VoNR这类对时延敏感的业务，映射错误的表现是“能通但音质差”，很容易被误判为射频问题。
4. 实操过程与关键环节实现
4.1 场景建模：先算清楚再动手
动手配IAB之前，先把场景算清楚。我习惯用三个参数做初步判断：覆盖半径、跳数、业务密度。
覆盖半径决定单跳能不能覆盖到目标区域。如果目标区域离宿主太远，单跳覆盖不了，就要考虑多跳。跳数每增加一跳，回传容量大约衰减30%到50%（取决于时隙配置和调制编码），时延增加1到2毫秒（取决于调度周期）。业务密度决定回传需要多少带宽，进而决定时隙比例。
举个具体的估算例子。假设宿主下行总容量是1Gbps，两跳IAB，每跳回传时隙占40%，那么末端节点可用的回传容量大约是1Gbps × 0.4 × 0.4 = 160Mbps。如果末端节点下游有20个终端，平均每个终端能分到8Mbps，这个量级做视频流够用，做大规模下载就紧张了。这个估算很粗，但足够判断方案可行性，避免配到一半发现容量根本不够。
4.2 时隙配置的实操步骤
时隙配置是IAB调优里最需要动手的部分。以常见的TDD帧结构为例，配置流程大致是这样：
第一步，确定帧结构基础参数。包括子载波间隔、时隙长度、上下行转换周期。这些参数要和上游节点保持一致，否则MT侧无法同步。
第二步，划分回传时隙和接入时隙。在帧结构里标记哪些时隙用于回传、哪些用于接入。标记时要留出保护间隔，避免回传和接入之间的干扰。
第三步，配置MT侧和DU侧的时隙使用规则。MT侧只在回传时隙收发，DU侧只在接入时隙服务终端。这一步的配置要严格对应，错一个时隙就可能导致链路起不来。
第四步，验证。配置完成后，用测试终端做接入测试，同时抓回传链路的吞吐和时延。如果吞吐不达预期，回头检查时隙比例；如果时延抖动大，检查保护间隔是否足够。
示例：某TDD帧结构下的时隙划分（示意） 周期：5ms，共10个时隙 时隙0-1：下行接入 时隙2：保护间隔 时隙3-4：下行回传 时隙5：保护间隔 时隙6-7：上行回传 时隙8：保护间隔 时隙9：上行接入这个划分只是示意，实际配置要结合具体帧结构和业务需求调整。关键是保护间隔不能省，省了之后回传和接入之间的交叉干扰会让性能断崖式下跌。
4.3 承载映射配置与验证
承载映射的配置分两步：先在核心网侧配置QoS流到回传承载的映射规则，再在IAB节点侧确认映射表生效。
配置时容易出错的地方是映射方向。上行和下行是两套映射，上行是把终端的上行QoS流映射到上行回传承载，下行反之。如果只配了下行忘了上行，表现是下行正常、上行拥塞，排查时容易误判为上行覆盖问题。
验证方法是逐业务打流。用测试仪表或测试终端，分别发起不同QoS等级的业务（比如会话类、流类、背景类），同时抓回传链路的承载级统计。正常情况下，高优先级承载的调度次数应该明显高于低优先级。如果发现所有承载调度次数差不多，说明映射没生效，回去检查映射表。
4.4 多跳链路的逐跳验证
多跳场景的验证要从宿主往下逐跳做，不能跳着验。先确认第一跳节点的回传链路正常、吞吐达标，再验第二跳，依此类推。跳着验的问题是，末端节点出问题时无法判断是自身配置问题还是上游链路问题。
逐跳验证的具体做法：在每一跳节点上做回传链路的吞吐和时延测试，记录基线值。然后对比相邻跳的衰减是否符合预期。如果某一跳衰减异常大，重点查这一跳的时隙配置和射频环境。我遇到过第二跳衰减比预期多20%的情况，最后查出来是第二跳节点的天线方位角偏了，回传链路信噪比不够，调整方位角后恢复正常。
提示：逐跳验证时把每跳的基线值记下来，后面网络扩容或调整时，这些基线值是判断“有没有变差”的唯一依据。
5. 常见问题与排查技巧实录
5.1 回传链路起不来：按阶段定位
回传链路起不来是最常见的问题，排查时按建立流程的阶段走，效率最高。
| 故障现象 | 可能阶段 | 排查方向 |
|---|---|---|
| MT搜不到网 | MT接入阶段 | 检查上游节点覆盖、频点配置、同步信号 |
| MT接入失败 | MT接入阶段 | 检查随机接入参数、上行功率配置 |
| 回传承载建立失败 | 回传配置阶段 | 检查RRC信令、承载参数、IP配置 |
| DU不广播 | DU激活阶段 | 检查回传链路状态、DU启动条件、系统信息配置 |
这个表看着简单，但实际排障时按阶段走能避免大量无效操作。我见过有人回传起不来就直接去查DU配置，查了半天发现是MT根本没接入成功，白费功夫。
5.2 吞吐不达预期：先分清是回传瓶颈还是接入瓶颈
吞吐问题要先定位瓶颈在哪一段。方法是在回传链路和接入链路上分别打流，对比两段的吞吐。
如果回传链路吞吐就低，问题在回传侧，重点查时隙比例、调制编码、信噪比。如果回传正常但接入低，问题在接入侧，查调度策略、终端能力、干扰。如果两段单独测都正常但端到端低，问题在承载映射或路由，查映射表和IP路由。
这个分段定位法能快速缩小范围。实测下来，回传侧瓶颈最常见的原因是时隙比例配得太保守，接入侧瓶颈最常见的原因是调度器参数没调优。
5.3 时延抖动大：保护间隔和调度周期是重点
IAB的时延抖动比传统基站大，这是无线回传的固有特性。但如果抖动超出预期，重点查两个地方。
一是保护间隔是否足够。保护间隔不够时，回传和接入的时隙切换会产生干扰，表现为时延抖动突然增大。二是调度周期是否过长。调度周期长意味着数据要等更久才能被调度，抖动自然大。把调度周期调短能改善抖动，但会增加信令开销，需要权衡。
实测经验：两跳场景下，端到端时延抖动控制在5毫秒以内是合理的，超过10毫秒就要查配置。这个数值不是标准规定，是从多个场景实测里总结的经验值。
5.4 节点间干扰：回传链路的“隐形杀手”
IAB节点密集部署时，节点间的回传链路可能互相干扰。这种干扰的特点是隐蔽——单看每个节点都正常，但整体性能上不去。
排查方法是做干扰底噪扫描。在回传时隙内扫描各节点的接收底噪，如果某个节点的底噪明显高于其他节点，说明它受到了干扰。解决方式包括调整天线方位角、调整回传时隙的时频资源、或者调整节点位置。
这里有个容易踩的坑：回传链路的干扰和接入链路的干扰要分开看。回传时隙内的干扰影响回传，接入时隙内的干扰影响终端。如果只在接入时隙测干扰，会漏掉回传侧的干扰问题。
5.5 独家避坑清单
- 别在回传时隙上省保护间隔。省下来的资源远不够弥补干扰带来的性能损失。
- 承载映射表配完一定要逐条核对。映射错误的表现太像射频问题，容易带偏排查方向。
- 多跳场景先验单跳再验多跳。单跳都不达标，多跳肯定不行，别浪费时间。
- 时隙比例不要一次调到位。先给一个保守值，跑起来之后再根据实测逐步调整，一次调太激进容易把链路调崩。
- 节点上线后记录基线。没有基线，后面任何性能变化都无法判断是变好还是变差。
6. 我对IAB落地的一点实际体会
IAB这套架构，规范写得清楚，但落地时的复杂度主要集中在资源分配和干扰协调这两块。架构本身是优雅的——CU/DU分离、PDCP集中、IP路由，每一层都有明确的分工。但优雅的架构不等于好用的系统，实际部署时大量的调优工作都在时隙比例、承载映射、天线方位角这些“脏活”上。
我个人在实际操作中的体会是，IAB最适合的场景是有线回传不可达但射频覆盖可及的补盲和扩容，比如室内深度覆盖、临时活动保障、光纤施工困难的区域。不适合的场景是对时延极度敏感且跳数多的业务，两跳以上的IAB做低时延业务要非常谨慎，时延预算很容易超。
最后分享一个小技巧：调试IAB时，把每一跳的回传链路当成一条独立的“无线专线”来对待，单独测它的吞吐、时延、抖动，建立基线。这样整个IAB子网就变成几条可独立观测的链路，排障时逐段定位，比盯着端到端指标瞎猜高效得多。这个思路后续还可以扩展到多连接场景——每个连接都建基线，哪条连接劣化一目了然。
