企业官网建设流程全解析

1. 无线接口架构的整体框架与设计逻辑

做5G无线接入网这一行，不管是搞协议、搞测试还是搞优化，无线接口架构都是最底层的“骨架”。它定义了手机（UE）和基站（gNB）之间通过空口怎么通信、数据怎么流动、信令怎么交互。很多同学看协议栈第一眼就被SDAP、PDCP、RLC、MAC、PHY这一堆缩写劝退，其实换个角度来看，它就是一套完整的分工协作体系：每一层只干一件事，层与层之间通过标准化的服务接口交互，日子久了你会发现这套分层的思想从LTE时代一直延伸到5G，几乎没变过——变的是每一层内部新增的能力和场景适配。

1.1 无线接口在5G系统里到底指哪一段

先说清楚定义。5G无线接入网从整体上可以简化为：终端（UE）接入基站（gNB），基站再连接核心网（AMF/UPF）。其中UE和gNB之间的这段空中接口，规范里叫Uu接口，也就是本篇要讨论的“无线接口”。它上承NAS层（非接入层）或应用层数据，下接物理层的无线资源。LTE时代对应的接口叫LTE-Uu，5G NR的Uu接口在空口技术上做了大量演进：引入了灵活的子载波间隔、大规模天线阵列、波束管理，以及全新的信道设计。

但值得注意的是，“无线接口架构”并不等于“物理层技术”，它是一整套逻辑框架，覆盖了从上层业务数据进来之后如何被分段、加密、复用、映射到物理资源上的全过程。换句话说，你手机里跑着微信视频、网页下载、语音通话，这些五花八门的业务怎么被打包成可以在空气里传输的信号，就是无线接口架构在负责调度和管理。理解了这一层，后面你去看波束管理、去看LDPC编码、去看BWP切换，都会有“原来它是挂在架构里这个位置上的”的感觉。

1.2 为什么5G要把控制面和用户面拆得这么清楚

谈到无线接口架构，无法回避的就是控制面（Control Plane，CP）和用户面（User Plane，UP）的分离。LTE时代已经有这个思路，5G时代把这件事做得更加彻底，甚至直接影响到了核心网侧的控制与转发分离（CUPS）。终端侧空口协议栈分两个平面：

• 控制面协议栈：NAS → RRC → PDCP → RLC → MAC → PHY，跑的是信令，比如小区选择、连接建立、切换、测量配置等。
• 用户面协议栈：SDAP → PDCP → RLC → MAC → PHY，跑的是用户业务数据，比如视频、文件、VoNR语音包等。

很多人会问：用户面为什么没有RRC层？因为RRC只负责“控制”，用户面数据不需要参与连接管理，直接通过网络层下来的IP包或QoS流，交给SDAP做映射，再走底层的传输管道。而控制面最上层还有NAS层，它实际上是UE和核心网AMF之间的信令，空口只是“透传”通道，RRC层会在AS层面做透传封装。

这个分离的架构带来的实际好处在于：控制和数据可以按需独立调度、独立配置安全参数、独立做优化。比如在做视频业务优化时，你可以只盯着用户面的速率、时延、丢包；而在做信令风暴整治时，你可以只关注控制面的RRC连接数、NAS信令负荷，彼此不干扰。我在日常网络优化时，分析用户速率瓶颈往往会先看用户面协议栈各层有没有拥塞，而排查弱覆盖和切换问题时则直接绕开用户面，去看RRC测量报告和系统消息，分层定位的效率比“一把抓”高得多。

2. 协议栈逐层拆解：SDAP到PHY每一层到底干什么

猜猜看，5G协议栈里被讨论得最少、但实际引入价值很高的层是哪个？你可能想不到，答案是SDAP。因为大家一讲5G就盯着毫米波、波束、LDPC，反而忽略了空中接口在用户面架构上一个非常重要的变化：5G用户面在PDCP之上新增了SDAP层，用于完成QoS流到DRB（数据无线承载）的映射。这一层在R16版本之后还引入了反射式QoS映射等机制，让业务流与承载之间的对应关系更加灵活。下面从顶到底逐层展开。

2.1 SDAP：5G新增的QoS流到DRB映射层

SDAP（Service Data Adaptation Protocol，服务数据适配协议）是5G NR新引入的层，位置在IP层和PDCP之间。它的核心职责很清晰：负责把来自核心网的不同QoS流映射到对应的DRB上。我们可以这样理解——核心网给一个PDU会话分配了多个QoS流，有的流是GBR（保证比特速率），有的流是Non-GBR，每个流可能对应不同的时延、丢包、优先级需求。空口侧不可能为每一个QoS流都单独建一条无线承载，那样资源开销太大，所以需要SDAP把需求相近的QoS流“合并”到同一条DRB上，同时保证合并之后业务质量不被打折。

SDAP在做映射的时候，需要参考packet的QFI（QoS Flow ID，QoS流标识）以及gNB下发的映射规则。对于下行数据，gNB在SDAP头里可以携带QFI指示；对于上行数据，终端根据RRC配置的映射规则来决定把某个QoS流的数据放到哪条DRB上。这里面有两点经验值得分享：

• 不建议把太多不同类型业务映射到同一条DRB，尤其是视频和普通上网数据混在一起，容易导致大流量业务抢占小流量业务的资源，时延敏感型业务容易受损。实际项目中要结合业务类型和QoS参数，逐步微调映射关系。
• R16的反射式QoS映射是一种很实用的机制，核心网和基站可以不事先配置映射表，而是根据下行包里的QFI自动学习并反向建立上行映射。在动态业务场景下能省掉很多预配置工作，但对终端实现要求更高。

SDAP本身没有重传、没有分段、没有加密，它只是一个适配层，所以在优化时不太需要关注它自身的门限，更多是看它配置的“映射规则”是不是合理。

2.2 PDCP：加密、完整性保护和头压缩

PDCP（Packet Data Convergence Protocol，分组数据汇聚协议）是LTE时代就有的老朋友，在5G NR里继续承担三大职责：IP头压缩（ROHC）、加密（ciphering）、完整性保护（integrity protection），另外还有为RLC AM模式提供重排序和重复包检测，以及在切换场景下提供按序递交和PDCP PDU恢复等功能。

头压缩这一块，VoNR（5G语音）就非常依赖ROHC。语音包载荷通常只有几十字节，但RTP/UDP/IP头加在一起就有40字节，如果不做压缩，空口资源浪费很严重。实际开启ROHC后，头可以从40字节压缩到大约5字节左右，体验上最明显的就是VoNR通话的容量提升了。但ROHC也挑场景，如果链路质量太差或者上下文经常重建，ROHC解压失败会引发丢包甚至语音卡顿。我记得有一次排查VoNR通话质量，最后定位到是基站开启了ROHC但切换目标小区配置不一致，语音包解压连续失败丢包，关掉ROHC后问题立刻消失。所以在强化覆盖和算法的同时，ROHC的参数配置（profile、context重建周期、鲁棒性参数）也值得花时间细调。

加密和完整性保护这两个动作，5G的要求比LTE更细致。在LTE里，加密和完整性保护都开启得很早；而5G RRC引入了“安全和完整性保护”的呈现方式差异：用户面的完整性保护是可选特性，控制面则必须开启完整性保护。实际网络在配置用户面时，会基于“是否需要完整性保护”来选择加密算法和完整性算法组合。泄漏一点经验：很多测试终端默认情况下如果检测到完整性保护算法配置异常，会直接导致RRC连接建立失败，排查时要先去核对公共消息里播报的安全算法列表是否与终端支持的集合有交集。

2.3 RLC：TM/UM/AM三种模式怎么选

RLC（Radio Link Control，无线链路控制）这一层是专门负责将上层PDCP PDU“适配”到MAC层传输块上的，关键动作包括分段/重组、ARQ（自动重传请求）、重复检测，以及按序递交。RLC有TM（透明模式）、UM（非确认模式）、AM（确认模式）三种模式，很多人一上来就背概念，记不住区别，我用生活中的场景来类比：

• TM模式：不额外加RLC头、不做分段、不重传，数据透明地透传下去。它只用在不该引入额外开销的场景，比如系统消息广播（BCCH）和随机接入过程中的RRC消息（CCCH）。
• UM模式：支持分段、拼接、重排序，但不做重传。适合对时延敏感但允许少量丢包的实时业务，比如VoNR的话音包在线路质量好的时候可以直接走UM。
• AM模式：在UM基础上增加了ARQ重传机制，对端会反馈ACK/NACK，发送端根据反馈决定重传。适合对完整性要求高的业务，比如普通上网数据和TCP业务。AM模式还有一个重要作用是支持PDCP层的按序递交——因为RLC一旦重传，底层顺序可能打乱，需要PDCP结合RLC的状态报告做重排序。

从我处理过的网络问题看，RLC模式配错往往是最隐蔽的坑之一。比如有些设备商默认把SRB1/SRB2配成UM，这在RRC信令量大的场景下会导致信令丢失引发掉线，正确做法是SRB1和SRB2走AM模式，确保信令可靠递交。还有一种情况是VoNR配置了AM模式但AM的RLC重传参数没调到位（比如MaxRetxThreshold配得太大），出现大量ARQ交互时时延直接拉满，通话质量反而更差。

2.4 MAC：调度、HARQ和逻辑信道优先级

MAC（Medium Access Control，媒体接入控制）层相当于空口资源的“交通指挥员”，负责在整个无线帧上为各逻辑信道分配传输块，执行动态调度、HARQ（混合自动重传请求）、逻辑信道优先级处理、传输格式选择、状态BSR（Buffer Status Report）上报等。MAC层和上面几层的最大区别在于：它直接面对物理资源，调度结果直接决定时频资源给谁用。

HARQ是MAC层最重要的机制之一，属于“快速重传+软合并”的变种。每传一个数据包，接收端会回ACK或NACK，如果收到NACK，发送端重传，接收端可以把两次接收到的信号合并起来译码。这种合并增益在实践中非常可观，尤其是在小区边缘、信道快速衰落的场景下，HARQ能让BLER表现稳定在目标值以内。实际优化时要重点关注HARQ的重传率。一般来说，单用户下行HARQ重传率超过10%~15%就说明信道质量或MCS选择偏激进，这时候不该一味加功率，应该调整MCS、下探CQI偏置或优化波束方向。

再讲逻辑信道优先级。空口上不同类型的数据（控制信令、语音、普通数据）混在一起排队时，MAC层依靠LCP（Logical Channel Prioritization）机制来动态调整优先级。典型配置里SRB信令优先级最高，然后是按QoS优先级排序的DRB。这里有一个比较常见的调优场景：如果有大量在线小包业务抢占高优先级信道，而VoNR的包反而拿不到资源，就需要调整LCP参数里各逻辑信道的prioritisedBitRate，保证语音承载有最低资源保障。

2.5 PHY：OFDM参数集、波束、CSI和BWP

PHY层是物理层，承担编码调制、多天线处理、波束管理、信道测量和反馈等最底层的工作。5G NR物理层相比LTE引入了一个非常颠覆的设计：灵活参数集（Numerology）。子载波间隔可以是15kHz、30kHz、60kHz、120kHz甚至更高，对应的符号长度、时隙长度都随之变化。不同参数集的出现，是为了在同一个系统里同时服务覆盖优先场景（低频频段、大覆盖）和时延优先场景（高频段、小时隙）。实际做小区规划时，低频FR1一般用15kHz或30kHz，中高频FR2则用120kHz，你会看到同样的物理层框架，参数配置完全不同。

波束管理是5G高频段的“灵魂”。FR2频段上gNB通过大规模天线阵形成多个窄波束，下发波束参考信号（CSI-RS/SSB），终端测量波束质量并上报波束索引和RSRP，基站据此选择合适的收发波束。这个机制在移动性管理上非常关键：如果波束切换跟不上终端的移动速度，数据就会瞬间断开。经验是在高层楼宇、体育场馆这类多波束场景，要重点核查波束配置的覆盖重叠度和CSI-RS周期，很多“信号满格但速率低”的问题根源就在波束选择错误。

CSI反馈（信道状态信息反馈）和BWP（部分带宽）也是物理层的重点。CSI反馈包含CQI、PMI、RI，直接决定调度器如何选择MCS和秩。BWP则是5G为了终端能耗和调度灵活性引入的带宽子集概念，可以在不改变整个小区带宽的情况下为不同终端配置不同的激活BWP。如果某一个BWP内的用户突然反馈速率低，要检查是不是跨BWP切换太频繁导致调度时隙空档，或者在非激活BWP时段内CSI测量有丢失。

3. 承载与信道映射：三级映射关系才是接口的精髓

很多时候看协议栈光看每层职能还是不够，无线接口架构真正精妙的地方在于“承载”和“信道”这两套体系的映射关系。一个业务数据进入空口之后，不是从SDAP直接一路向下就到天线发射，而是经过逻辑信道、传输信道、物理信道这三级映射，每一层都对应不同的处理机制和资源调度策略。这一节就把这三层映射关系彻底讲透。

3.1 SRB和DRB：信令与数据的两套“车道”

无线承载（Radio Bearer）分为两大类：信令无线承载（SRB，Signalling Radio Bearer）和数据无线承载（DRB，Data Radio Bearer）。SRB里面又细分：

• SRB0：承载CCCH信道上的RRC消息，主要用于随机接入过程中的RRC连接请求、小区重选等早期消息。此时还没有专用无线资源，所以只能走公共信道。
• SRB1：承载DCCH信道上的RRC消息和部分NAS消息，RRC连接建立之后的主要信令通道，包含重配、测量控制、切换命令等。SRB1是整个控制面调度和可靠性的核心。
• SRB2：承载NAS消息，通常优先级低于SRB1，并在SRB1建立之后才配置。在5G里，SRB2还可配置LTE和NR双连接场景下的split SRB，实现跨系统的信令冗余。
• SRB3：NSA网在EN-DC双连接时，直接承载UE与辅节点（SN）之间的RRC消息，在5G时代尤其常见。排查NSA网络的SCG失败时，很多问题都发生在SRB3上。

DRB则承载用户面业务数据，每一条DRB对应一个RLC实体、一个PDCP实体和一套MAC逻辑信道配置，以及一套QoS参数。实际项目中常看到“DRB数量被配得越来越多”的趋势，其实不推荐无限拆分DRB，因为每增加一条DRB，MAC调度复杂度、PDCP/RLC上下文开销都会上升，导致切换、重配时延变长。一般设计原则是尽量让QoS属性相近的业务复用同一条DRB，DRB数量控制在个位数。

3.2 逻辑信道、传输信道、物理信道的三级映射

无线接口上数据的传递可以理解为三层“管道嵌套”：

• 逻辑信道：位于RLC层和MAC层之间，描述“传什么类型的信息”——例如BCCH传广播消息、PCCH传寻呼、CCCH传公共控制消息、DCCH传专用控制消息、DTCH传专用业务数据。逻辑信道是按内容语义划分的。
• 传输信道：位于MAC层和PHY层之间，描述“怎么传”——例如下行用BCH传广播块、DL-SCH传下行数据、PCH传寻呼；上行用RACH传随机接入前导、UL-SCH传上行数据。传输信道关注的是传输格式、调制编码方式、HARQ行为等。
• 物理信道：位于物理层，描述“实际占用的资源”——例如PDCCH传调度控制信息、PDSCH传下行数据、PUCCH传上行控制信息、PUSCH传上行数据、PRACH传随机接入前导、PBCH传主信息块。

用一个交通类比来理解：逻辑信道是“这趟车拉的是乘客还是货物”，传输信道是“这辆车走高速还是走国道”，物理信道是“这辆车实际占了哪条车道哪个时段”。

在实际项目里，三级映射最典型的查问题场景是“MIB/SIB读取失败”。终端开机后要依次完成小区搜索（读PBCH上的MIB）、读取SIB1（走DL-SCH/PDSCH）、随机接入（走PRACH/RACH/UL-SCH/PUSCH），任何一个环节的映射关系不匹配都会卡死。比如覆盖边缘PBCH的BCH编码增益不够，终端可能一直驻留失败；又比如SIB1调度的PDCCH搜索空间配置异常，就算PBCH解出来也拿不到SIB1位置。排查这种问题就得从物理信道一步步往回追，而不是直接怀疑核心网。

3.3 QoS流与DRB承载的对应：一张表说清楚

5G端到端的QoS架构里，一个PDU会话（PDU Session）内部有多个QoS流，每个QoS流有一个QFI。从核心网到基站（NG接口）下发的是QoS流的数据包，从基站到终端（Uu接口）走的是DRB。QoS流和DRB之间由SDAP层负责映射，一个QoS流只能映射到一条DRB，但一条DRB可以承载多个QoS流。

排障时很常见的一种问题：核心网配置的QoS参数和基站侧DRB的传输参数不一致，导致“速率上不去”“时延偏高”。我的做法是先从NG接口的PDU Session Resource Setup Request消息里看QoS流的5QI、GBR/Non-GBR参数，再对到空口RRC Reconfiguration里下发的DRB配置（LCID、RLC模式、优先级、PBR等），两边对不上时优先调整基站的QoS映射表，而不是盲目调MCS和功率。

4. 实操视角：从空口消息看架构的“现场”

讲完协议栈和信道映射，我们再切换成“现场操作”视角。搞无线的人手上一定会接触信令分析平台、网管、路测工具。可以说，无线接口架构只有结合信令流程来看，才是真正“活”的。空口上的每一条信令、每一个数据包，其实都在反映协议栈各层、每一条承载、每一个信道的工作状态。这一节我以一次典型的RRC连接建立过程为例，把接口架构怎么“跑起来”完整串一遍。

4.1 以RRC连接建立流程为主线，逐层看调用关系

我们先模拟一个终端从待机态发起呼叫或上网的过程。此时终端已经完成了小区搜索和系统消息读取，知道了小区的随机接入资源配置。当用户发起业务时，空口侧的第一步是随机接入（Random Access）。终端在PRACH上发送随机接入前导（对应逻辑信道CCCH，传输信道RACH，物理信道PRACH）。基站检测到前导后，在RAR（Random Access Response）中给终端分配临时C-RNTI和上行授权。RAR消息通过DL-SCH传输，由PDSCH承载，物理层用RA-RNTI加扰。

接下来终端通过SRB0上的RRC Connection Request发起初始接入。这条消息在空中走CCCH逻辑信道，经过RLC TM模式、MAC、PHY，在PUSCH上发送。基站收到后回复RRC Connection Setup，分配SRB1资源，配置专用逻辑信道DCCH。注意这里承载的“升级”就直观体现出来了：从SRB0/CCCH切换到SRB1/DCCH，意味着终端从公共信道资源切换到专用资源，后续信令和数据都在专属“车道”上跑了。终端回复RRC Connection Setup Complete后，SRB1正式投入使用。

信令建立完成后，如果业务是用户面数据，NAS层会触发PDU会话建立。基站收到核心网下发的PDU Session Resource Setup Request后，会通过RRC Connection Reconfiguration给终端配置DRB和SDAP层映射规则。终端完成配置后在SRB1上回复RRC Connection Reconfiguration Complete。此时数据面才真正打通：应用层数据→SDAP（按QFI映射到DRB）→PDCP（加密+头压缩）→RLC（按AM/UM分段）→MAC（按调度结果组包）→PHY（调制发射）。这一个完整过程就是无线接口架构在真实网络里的一次完整“彩排”。

4.2 信令抓包与协议栈日志怎么配合分析

日常排障，我最常做的是在关键节点同时拉取“基站侧信令跟踪”和“终端侧日志”。基站侧的设备商会提供信令跟踪工具，能从NG接口、Uu接口提取RRC、NAS消息；终端侧的Modem日志（比如QC Logger、三星/华为测试终端的协议栈日志）能看到终端侧各层的收发细节。两边比对才能完整还原无线接口上的每一次交互。

抓包时要重点关注的节点包括：

• Random Access流程是否成功：前导发送次数、RAR是否收到、竞争冲突是否发生。
• RRC Setup消息里的AS配置：包括SRB1/DRB的PDCP/RLC/MAC配置是否合理、是否携带了SpCell配置、BWP配置是否匹配终端能力。
• 安全模式配置：加密算法和完整性算法是否协商成功，失败会导致连接直接被释放。
• DRB建立时SDAP映射规则：QoS流和DRB ID的映射表是否能对应上核心网的QFI。

有一次遇到“用户频繁掉话但覆盖良好”的案例，厂家工程师拉着L3信令查了半天没结论。后来我让他把RRC Release消息里的释放原因拿出来看，发现每个都带“User Inactivity”超时释放，但业务明明在跑。最后定位到是基站配置的DRB Inactivity Timer太短，MAC层长时间没检测到UL/DL数据就把承载释放了。这种问题如果不看协议栈层和MAC调度活动状态，完全想不到是参数老化配置引起的。

4.3 协议栈参数与路测指标怎么对照

在线优化中常见的“速率不达标”问题，通常要同时看多个维度才能把问题收敛。假设某扇区下载速率从800Mbps掉到200Mbps，单看物理层CQI和MCS下来还不够，还要结合架构各层参数定位：

• PHY层维度：确认下行MCS、CQI、RI变化趋势。如果MCS被压得很低，说明信道质量上报差；再看CSI-RS波束和终端反馈的波束索引，排查是否存在波束失配。
• MAC层维度：看每TTI调度到的PRB数、HARQ重传率、BSR上报是否及时。如果PRB调度不满但用户Buffer无限大，那可能是调度器CCI（小区内干扰协调）或者LCP限制了。
• PDCP层维度：看下行PDCP吞吐量、丢包率、时延。如果PDCP层吞吐已到极限但业务速率依旧不行，可能需要检查RLC AM的窗口参数或者ROHC上下文状态。
• SDAP/核心网维度：看NG口的用户面速率和QoS Flow的GBR保障值。有些时候问题根本不在空口，而是UPF的上行限速策略把速率卡住了。

做这一行久了，你会养成一个习惯：任何“速率上不去”的问题，先不要急着改功率或天线倾角，先把整套协议栈指标记录下来，逐层排查。大多数时候无线接口架构的某一层配置存在隐性短板，而不是射频覆盖不行。

5. 常见问题排查与避坑清单

协议栈架构知识学完之后，最终要落到“解决实际问题”上。前端时间我梳理了一批学生和初入行的同事最常踩的坑，挑出5个代表性的问题整理成排查清单，可能会帮大家省去不少弯路。

5.1 RRC连接建立成功率低的经典排查路径

现象是手机打电话或上网时经常提示“无法连接网络”，后台统计RRC建立成功率掉到90%以下。排查路径建议按以下顺序走：

• 先看随机接入是否成功。统计PRACH前导发送次数、竞争冲突率。如果前导检测不到或者对端无RAR，大概率是覆盖或者PRACH配置问题（比如prach-ConfigurationIndex和小区帧结构不匹配）。
• 再看RRC Connection Request是否到达基站。RRC连接请求走SRB0/CCCH，如果基站侧能收到但终端收不到RRC Setup，大概率是下行覆盖非对称（下行弱于上行）或者CCCH信道参数配置错误。
• 继续看RRC Setup Complete是否被基站收到。如果终端发了但基站没收到，多半是上行干扰、MCS选择过高、PUSCH功率不足，或者是SRB1配置后首传失败。
• 最后再观察安全模式流程。SMC失败直接导致RRC连接释放，重点检查基站和终端的加密算法交集、PDCP安全参数配置。

这里面最容易忽略的是“随机接入前导格式与小区半径的匹配”。我记得有个站点覆盖距离超过普通宏站半径，但PRACH前导格式配得太短，循环前缀扛不住大时延，边缘用户随机接入永远失败。后来把prach-ConfigurationIndex换成支持长序列的格式，RRC建立成功率立刻恢复了。这种问题光看KPI是看不到的，必须结合协议栈的随机接入参数和覆盖场景来回对照。

5.2 切换成功率低，先从源和目标两头抓信令

5G切换类型包括基于测量报告的gNB内切换、Xn接口切换、NG接口切换。排查时我的习惯是既抓源侧信令也抓目标侧信令，重点核查这几个信号点：

• 测量报告触发是否合理：终端上报的A3事件测量报告里，邻区PCI、RSRP、RSRQ是否真实。如果邻区漏配或者测量配置的异频邻区列表过期，切换根本不会触发。
• 切换准备阶段：源gNB向目标gNB发送Handover Request时，目标gnb是否成功预留资源。失败原因经常是目标侧负荷过高、DRB资源数受限、漫游限制。
• 切换命令下发与执行：RRC Reconfiguration里包含的target cell配置（比如BWP、CSI-RS、PRACH资源）是否完整，终端是否能在目标小区完成随机接入。
• 切换完成后上行同步：终端发送RRC Reconfiguration Complete和上行数据后，目标小区是否成功调度。这里常见的坑是TA（Timing Advance）更新失败，导致上行失步，需要检查PRACH专用资源和TA定时器。

有一次我调一个跨Xn切换成功率低的问题，看信令发现每次Handover Request里带的QoS Flow信息都能成功，但目标侧就是回Handover Preparation Failure，原因是目标小区和源小区的slice配置不一致，终端请求的Network Slice在目标侧不受支持。调整slice策略映射后问题解决。切Slcie这种边缘参数往往不被重视，恰恰容易成为跨站切换的拦路虎。

5.3 参数配置里容易踩的坑

整理几个我在工程实践里反复遇到的参数坑，做成速查表供参考：

说一个“反直觉”的坑：PDCP层的discardTimer。有人为了让超时数据快点丢、降低时延，把discardTimer调得很小，结果TCP业务全乱套。原因是RLC AM模式下，PDCP如果丢弃了大量包，TCP无法正确排序导致拥塞窗口猛降，端到端速率反而更差。后来把discardTimer调大到几百毫秒并配合SDU重发机制，整体性能才恢复正常。类似这种跨层联动的问题，单看某层参数是很难规避的。

5.4 空口质量的链路预算与覆盖盲区校正

无线接口架构再完善，覆盖盲区总归是存在的问题。结合链路预算来看覆盖，通常要关注：

• 上行链路预算：终端发射功率（UE Power Class）、上行PRACH/PUSCH的目标SINR、人体损耗、穿透损耗是否留了余量。
• 下行链路预算：基站发射功率、天线增益、波束增益、终端接收灵敏度、分集增益。
• 干扰余量：邻区干扰、PUCCH/PUSCH间干扰、DMRS碰撞对SINR的影响。

如果路测发现某区域RSRP达标但SINR很低，大概率是干扰不是覆盖。这时去调“天线倾角”不如先做干扰溯源——查PCI混淆、查SSB波束是否被邻区同频污染、查室内外信号交错是否触发频繁切换。有一次处理一个商场室分覆盖问题，路测数据明显显示楼层之间信号交错剧烈，用户终端的平均切换次数从每分钟2次飙到10几次，业务体验极差。后来调整了不同楼层室分天线的功率和邻区优先级，切换次数降下来后感知立竿见影。

6. 个人操作心得与后续建议

做了这些年无线网络优化，最大的体会是：纸上谈兵的架构永远不难，难的是把它和现场现象对上号。刚学协议栈时我也曾把SDAP、PDCP、RLC、MAC、PHY每一层的PDU头格式背得滚瓜烂熟，但在实际排障中依然一头雾水。后来转变了学习方法——不为背协议而背协议，而是带着问题去读协议，比如“为什么VoNR用ROHC效果差？”“为什么某厂家的调度器在DRB重配时会瞬间掉速？”每解决一个问题，对无线接口架构的理解就深了一层。

如果你也想深入掌握无线接口架构，我的建议是先抓三条主线：一是把SRB/DRB、逻辑信道/传输信道/物理信道这套映射关系理解到“闭着眼睛能画出来”的程度；二是要有一个“协议栈分层定位”的思维框架，遇到任何现象先判断是PHY、MAC、RLC、PDCP还是SDAP哪一层的问题，再逐层细化；三是要经常看真实信令，没有条件看真实信令的话，就看规范里的信令流程文本，把每个流程的触发原因、涉及的承载、信道、关键参数都吃透。

接下来这个系列我还会继续写5G NR的小区搜索流程、随机接入、调度与时延分析、波束管理等方向。每一篇都会保持这种“架构+流程+排障”的思路，争取让读者读完就能拿来对照自己的工作场景。无线接口架构就像一栋大楼的承重结构，表面看是一堆协议条文，真正钻进项目里你才会发现，每一层都藏着数不清的细节博弈。知道得越多，排障时心里的底气就更足一些。