简介面向5G网优外场测试与优化工程师的PDF技术资料聚焦拉网测试中下行平均速率1Gbps难以达成的典型问题提供从指标公式到根因定位的系统分析。资源共1个PDF文件大小约902KB内容精炼覆盖外场速率低、接入失败、小区选择等常见难题适合路测数据分析与精品路线优化场景。目前已有731人学习文档从吞吐率定义与计算公式入手给出调度次数、RB数、Rank、MCS、BLER等达成1Gbps的关键门槛并结合实际案例展示覆盖质量、调度状态、误码率、RB资源占用等排查顺序。同时梳理了核心网限速、LTE异频GAP测量、射频电源告警、频繁切换、D4/D5/D1/D6干扰、PCI重复等非用户面因素以及NSA接入与小区搜索流程可帮助工程师快速缩小问题范围形成可复用的外场排障思路。1. 5G网优外场为什么你的拉网速率卡在1Gbps以下做5G外场优化的同行应该都有过这种经历精品路线拉网测下来覆盖不差、SINR不差、MCS也踩上去了可下行平均速率就是卡在七八百兆死活上不了1Gbps。后台指标一看调度次数、Rank、IBLER全在正常范围最后翻到RB资源才发现均值只有131——正常应该260以上资源直接少了一半。这份《5G网优外场常见问题分析》PDF就是围绕这类问题写的把我这些年外场常踩的速率、接入、干扰、PCI冲突问题都归拢成了可对照排查的案例。它适合刚接手5G精品路线优化的网优工程师也适合后台KPI分析和路测分析岗拿来当排查手册按图索骥定位根因而不是凭感觉换参数碰运气。2. 1Gbps目标速率的达成条件先拆公式再定排查优先级2.1 吞吐率公式拆解调度次数、TBS与IBLER的关系文档里把下行MAC层吞吐率拆成了三个因子的乘积PDCCH DL Grant下行调度次数、PDSCH TBS传输块大小与MCS、RB、Rank相关、以及1-BLER%。这个公式是理解整个速率问题的总纲所有外场排查动作最终都要回到这三个因子上去。上行同理只是把Grant换成UL方向的PDCCH UL GrantTBS对应PUSCH。我在外场看这个公式时习惯先把它转成一个可计算的脚本方便对比理论峰值和实际路测值的差距def dl_throughput_mac(grant_count, tbs_bytes, ibler): 下行MAC层吞吐率估算 grant_count: PDCCH DL Grant调度次数每秒 tbs_bytes: 平均TBS字节/次调度 ibler: 平均初传IBLER百分比如10表示10% return grant_count * tbs_bytes * (1 - ibler / 100) * 8 / 1e6 # Mbps # 典型1Gbps场景的参数组合 print(dl_throughput_mac(1550, 85000, 10)) # 约948.6 Mbps接近目标 print(dl_throughput_mac(1550, 100000, 10)) # 约1116 Mbps达标这里TBS是个汇总值实际分析时要拆开看MCS、RB数和Rank三个分量。MCS决定每个RE能扛多少bitRB数决定频域上给了多少资源Rank决定有几条并行流。三个因子相乘再乘以调度次数才是最终的吞吐率。文档给出的1Gbps达成条件很明确调度次数大于1550次调度RB数大于260个Rank大于3且Rank与MCS的乘积大于72平均初传IBLER收敛到10%。参数之间是乘性关系任何一个因子掉链子其他因子补不回来。比如Rank从4掉到2即使RB和MCS拉满吞吐率也会直接腰斩。所以排查速率问题时不要只看单一指标要按公式逐项核对才能锁定真正拖后腿的因子。2.2 路测数据五步核查法从RSRP到RB资源逐项排除文档里给出了一套很实用的DT数据核查流程我按自己的使用习惯整理成了五步法。第一步看覆盖。SSB RSRP平均值达到-82dBm属于中等偏上的覆盖水平不是速率低的直接原因。如果RSRP低于-90dBm就要先解决覆盖问题再谈速率。第二步看调度。NR_PDCCH_DL_Grant_Count均值要接近满调度文档案例中是1558次说明调度次数没有问题。第三步看MCS和Rank。文档案例中平均MCS为20.78阶平均Rank为3.61按经验值这个组合理论上应该能跑到1Gbps。第四步看IBLER均值8.5%在目标10%以内。第五步看RB资源NR_DL_RB均值只有131正常应该是260~270这就是关键的异常点。这套方法的核心价值在于按顺序排除干扰项。前四项都正常问题基本就锁定在RB资源上。RB减半吞吐率也约等于减半这与路测结果高度吻合。我一般会用表格把五个核查项的通过标准列出来外场跑完直接对照填数定位效率比翻log凭感觉快得多。核查项通过标准文档案例实测值判定SSB RSRP均值大于-82dBm-82dBm正常中点附近PDCCH DL Grant均值大于1550次1558次满调度平均MCS越高越好20.78阶正常平均Rank大于33.61正常平均IBLER收敛于10%8.5%正常下行RB均值大于260131异常主因2.3 速率低不等于覆盖差RB资源减半的深层原因RB资源只有一半表面上看是调度器没给足资源但根因往往藏在更底层。常见原因包括射频单元输入电源能力不足导致基站侧功率受限、小区配置了过大的PDCCH占用符号数挤占PDSCH资源、以及SSB波束配置导致的开销过大。文档特别提到一个经验拉网线路建议全部配置为宽波束。宽波束相对8波束能减少SSB的开销把更多资源留给业务信道。这一点很多优化工程师容易忽略只顾着把波束配宽来保覆盖却没想到SSB开销对吞吐率的影响。1Gbps覆盖标准方面文档给出的参考是SSB RSRP的95%大于-80dBm站间距不超过800米且边缘无同频LTE干扰。从功率分配的角度看当射频单元输入电源不足时基站会降低发射功率或限制资源分配来保护硬件这就会导致RB分配减少。遇到RB减半的情况应该先查基站告警确认是否存在电源能力不足的告警再检查波束配置和PDCCH符号数。这套排查顺序在文档中是有明确指向的按RB→告警→波束→PDCCH配置的顺序推进基本能覆盖绝大多数RB不足的场景。3. 下行速率低的实战定位四个经典案例与对应解法3.1 核心网限速灌包速率稳定在160Mbps的AMBR排查外场最隐蔽的速率问题之一就是核心网限速。现象很典型不管路测位置怎么换SINR多好下行速率稳定在160Mbps左右上不去了。很多人第一反应是空口问题反复调整参数却毫无效果其实是走错了方向。这类问题要从路测log的attach accept消息里找答案。文档明确指出下行AMBR聚合最大比特率为160Mbps上行1000Mbps这就是限速的直接证据。AMBR是核心网下发给UE的聚合速率上限下行被限制成160MbpsUE侧空口能力再强也没用。除了看attach accept还可以通过S1口跟踪S1AP_INITIAL_CONTEXT_SETUP_REQ消息或者通过X2口查看SgNB_Add_Req消息来确认限速值。遇到速率刚好卡在一个整数附近160Mbps、300Mbps、1Gbps等优先怀疑限速不要先折腾空口参数。让核心网同事核查签约数据和AMBR配置比在基站侧调半天参数效率高得多。这个案例提醒我们速率问题的排查一定要从端到端的视角看用户面路径上任何一个环节都可能成为瓶颈不能默认空口就是瓶颈所在。3.2 锚点LTE异频GAP测量调度次数被压制的机制与识别锚点LTE侧做了异频测量也会间接压低NR侧的调度次数这个问题的隐蔽性很强。机制上按照3GPP 37.340的定义E-UTRA侧的GAP是单用户GAPUE一旦进入GAP模式整个用户面的数据传输都会受影响。也就是说LTE侧因为异频MR测量触发了GAPNR侧的业务调度就得跟着让路。在实际网络里LTE开启异频MR后UE被通知启动GAP此时NR侧的PDCCH DL Grant会周期性掉坑。识别方法比较直接把NR的调度次数和LTE的异频测量上报时间做时间对齐观察调度次数掉坑的周期性是否与GAP周期吻合。如果吻合基本可以确认是异频GAP在捣乱。解法上主要有三个方向一是核查异频MR的触发门限避免在LTE覆盖良好的区域频繁触发异频测量二是评估是否可以关闭非必要异频频点的MR测量三是与LTE侧协商GAP的周期和长度配置把对NR调度的影响降到最低。这里要留意时隙级的对齐GAP长度一般是6ms、8ms等周期从40ms到480ms不等精确到毫秒级别才能看出规律。3.3 射频单元电源能力不足告警RB分配减半的基站侧根因射频单元输入电源能力不足告警是RB资源分配减半的常见基站侧原因。这个告警触发后基站为了确保硬件安全会主动限制射频单元的发射功率和资源调度能力直观表现就是RB分配数骤降。排查时先到网管上确认是否存在RRU或AAU的输入电源能力不足告警。这类告警往往与站点供电链路有关比如电源模块配置容量不够、引入了额外负载导致电压跌落等。外场测试时如果同时遇到RB分配不足和告警上报优先处理告警告警恢复后RB分配通常能自动回到正常水平。需要注意的是告警恢复不等于问题解决。如果多次出现电源能力不足告警要检查站点供电设计是否留有足够的冗余特别是拉网测试过程中AAU功耗较高时更容易暴露。我们这边遇到过一个站点白天测试正常夜间开启更多载波后出现电源告警最后通过扩容电源模块才彻底解决。3.4 频繁切换与干扰场景Rank骤降与D4/D5干扰的判定流程Rank低直接限制多流传输吞吐率很难上来。文档中提到的经验很有参考价值选择与天线有遮挡且SINR良好大于28的地点测试才能验证Rank的真实水平。这个前提很关键——Rank是在SINR条件足够好的前提下终端能够支持的最大并行流数。SINR差时终端宁可降Rank保误码率也不会硬撑着用高阶MCS。频繁切换场景下切换过程中的测量间隙和重配流程会打断数据传输Rank在切换前后往往会被重置或降低。结合测量报告看切换次数与Rank变化的对应关系能快速确认是不是切换导致Rank掉坑。D4/D5/D1/D6干扰的判定流程文档给出了四个步骤第一步确认速率掉坑时RSRP良好排除覆盖问题第二步确认其他区域测试无SINR和速率波动排除设备问题第三步在SINR差的点做定点测试确认SINR极差说明路段周边存在干扰源第四步监控精品路线周边站点的干扰情况若前100RB干扰较强怀疑为D4/D5系统间干扰。这套流程本质上是排除法先排除覆盖和设备因素再通过定点测试压缩干扰源范围最后用RB级干扰统计确认具体频段。4. 5G接入与NSA添加从B1测量控制到SCG添加的全流程排查4.1 接入流程拆解UE能力、测量控制与SgNB添加的关系NSA用户的接入过程本质上是一条LTE锚点与NR小区的协作链路。UE先接入LTELTE侧的RRC重配置消息会把NR的B1测量控制下发给UEUE测量到满足条件的NR小区后上报B1事件LTE再通过X2接口向目标NR小区发起SgNB添加请求最终完成SCG添加。文档列出了LTE能够正常下发5G B1测量控制的五个前提条件这五条缺一不可。第一条是UE能力上报中包含R15的UE能力终端不支持NSA就无从谈起。第二条是核心网未禁止该用户的NSA能力签约数据中如果禁用了NSA即使终端和基站都支持也没用。第三条是UE的默认承载QCI未占用LTE的专用QCI如果默认承载已经占用了QCI 1-5或QCI 65/66这些专用承载LTE就没办法再为NR添加专用承载。第四条是LTE侧NSA开关和NR邻频点配置正确配置错了UE就收不到测量控制。第五条是LTE小区本身具备NSA能力部分老旧的LTE单板硬件不支持NSA功能这条容易被忽略。从定位角度看如果UE始终收不到B1测量控制按这五条逐个核对基本不会漏。特别是第三条和第五条一个是核心网签约侧的check一个是硬件能力侧的check都容易被当成空口配置问题反复折腾。4.2 B1测量上报后的条件判断从邻区配置到X2状态UE上报B1测量后LTE侧判断是否发起SCG添加主要看两个条件NR邻区配置是否准确4/5G邻区关系要配好X2链路状态是否正常。这两个条件不满足LTE就不会向NR发起SgNB Add请求用户就会一直停留在4G单连接状态。文档给出的定位过程很规范先检查基站告警无异常再检查4/5G小区状态正常建立接着检查X2链路正常建立然后检查锚点相关配置包括频点和邻频点最后跟踪X2、UU、S1信令确认是否有L-NR的X2消息。这个顺序是从静态配置到动态信令的递进过程每一步都验证一个层面的问题。实际操作中我习惯先看X2链路是否正常建立因为X2状态是所有后续信令交互的基础。X2断了后面的一切都是空谈。信令跟踪时重点看SgNB_Add_Req是否发出、是否有响应以及响应中是否携带了失败原因。如果连SgNB_Add_Req都没发出问题大概率在LTE侧锚点配置或邻区关系上。4.3 外部小区PCI重复一个看似配置无错却无法添加的经典陷阱文档最后给出的案例非常典型所有配置看起来都正确告警无异常、小区状态正常、X2链路正常、频点和邻频点也都核对无误但信令跟踪始终看不到L-NR的X2消息。最后核对5G外部小区配置才发现锚点站上配置了重复的物理小区标识PCI。PCI重复这个问题的隐蔽性在于常规的配置核查很少会专门检查不同5G站点之间是否存在PCI冲突。两个不同的5G小区配置了相同的PCILTE锚点发起SgNB Add请求时目标识别本身就存在歧义X2消息自然发不出去。类似的陷阱还有锚点站X2链路超过上限值256条导致用户无法接入这是容量维度的边界问题。规避手段很直接外部小区配置核查时加一道PCI唯一性校验把锚点站所有外部小区配置导出后按PCI分组统计重复的就是可疑对象。我在日常优化中会把PCI核查放到每次新站入网验证的第一步先跑一遍PCI唯一性校验再谈功能验证能省下大量排查时间。5. 5G外场常见问题避坑现象、原因与解决配套笔记5.1 速率稳定在160Mbps先查AMBR限速别急着调空口参数现象是下行速率稳定在160Mbps左右不管怎么换测试位置或调整参数都没有明显变化。根因是核心网下发的下行AMBR被限制为160MbpsUE侧即使空口条件再好速率也只能被压在限速值附近。解法是通过路测log的attach accept消息或S1口信令确认AMBR值然后联系核心网修正签约数据或AMBR配置。从那以后我再遇到速率刚好卡在整数的情况会先花10分钟确认限速配置再做空口排查。5.2 下行RB均值只有131查电源告警与波束配置现象是拉网路测中调度次数、MCS、Rank、IBLER全部正常唯独下行RB均值只有131远低于260的期望值。根因大概率是射频单元输入电源能力不足导致RB分配受限或拉网线路波束配置不合理导致SSB开销过大挤占业务资源。解法是先查基站是否有电源告警再检查波束配置拉网线路建议统一配置宽波束以减少SSB开销。RB资源这个维度值得细查真正满配的理想状态基本是260~270一旦发现RB均值只有一半优先怀疑基站侧资源受限而不是先动MCS或Rank相关参数。5.3 锚点异频GAP导致NR调度次数周期性掉坑现象是NR调度次数在某个时间点开始周期性下降与LTE侧异频MR测量的周期吻合。根因是LTE侧异频测量触发了GAPUE在GAP期间无法进行业务数据传输NR调度随之被压制。解法是调整异频MR触发门限或关闭非必要异频测量避免LTE侧频繁进入GAP模式。我在外场遇到调度次数周期性掉坑的问题会先把NR调度曲线与LTE异频测量上报做时间对齐如果两个周期完全同步就不用再往NR侧找原因了。5.4 外部小区PCI重复导致SgNB Add失败现象是UE上报B1后LTE迟迟不发SgNB Add请求信令跟踪也看不到L-NR的X2消息但所有常规配置核查均无异常。根因是锚点站上存在重复的外部小区PCILTE无法正确识别目标NR小区导致添加流程中断。解法是导出锚点站所有外部小区配置按PCI做唯一性分组统计把重复项修正后重测。这个案例给到的最重要教训是外部小区核查必须加入PCI唯一性校验不能只看单个小区的配置参数是否完整。5.5 切换频繁导致Rank降低现象是路测中频繁切换路段的下行速率明显低于稳定路段Rank也从3以上掉到2甚至更低。根因是切换过程中的测量GAP、信令交互和数据中断导致终端降低Rank以免在信道条件不稳定时产生过多的误码重传。解法是优化切换参数减少非必要切换同时把Rank掉坑的位置与切换事件做关联分析来确认主因。对于SINR大于28且远点场景的定点测试我会专门避开高楼遮挡和密集车流否则Rank数据很容易失真。6. SSB覆盖与PCI规划验证外场数据如何反哺邻区配置修正SSB覆盖的评判标准应该直接用路测数据来验证。文档给出的1Gbps覆盖标准是SSB RSRP的95%大于-80dBm站间距不超过800米且边缘无同频LTE干扰。我一般会在拉网结束后单独统计SSB RSRP的累积分布函数而不是只看平均值这个习惯帮我抓出过不少局部覆盖空洞——平均值看着还行但某个方向上的边缘SSB RSRP已经掉到-90dBm以下用户实际感知早就变差了。如果边缘区域还同时存在同频LTE干扰NR的SINR会进一步恶化这时候即使调度、MCS都正常速率也仍然跑不起来。具体操作上我会把路测数据按网格化处理生成SSB RSRP的分布热力图再叠加NR小区PCI的分布图层重点检查两类位置一类是SSB RSRP大于-80dBm但速率不达标的区域优先怀疑是否存在干扰或邻区配置问题另一类是SSB RSRP边缘区域出现PCI mod3冲突的站点标记为待核查对象优先做天线调整或PCI重规划。前面提到的D4/D5/D1/D6干扰排查本质上也依赖这套基于位置的数据关联——光看SINR平均值没意义要把时间、位置、干扰强度三个维度对齐才能定位。PCI规划方面NR一共有1008个物理小区ID。我先做一个PCI唯一性批量校验脚本按小区维度扫描外部小区配置把重复项直接输出避免人工核对时漏掉角落里的站点。def check_pci_duplicates(cell_list): cell_list: [(cell_id, pci), ...] 返回重复PCI对应的小区列表 from collections import defaultdict groups defaultdict(list) for cell_id, pci in cell_list: groups[pci].append(cell_id) return {pci: cells for pci, cells in groups.items() if len(cells) 1}PCI规划除了关注mod3问题还要看mod30的对应关系。NR的PSS序列和SSS序列共同决定PCIPCI对30取模影响CSI-RS和DMRS的序列初始化PCI对3取模影响PBCH的DMRS位置。邻区间如果mod3冲突会造成PBCH的解调干扰如果mod30冲突CSI-RS的干扰会让终端上报的信道质量失真。所以在NR站点的PCI规划表里我会同排优先保证mod30不冲突再考虑mod3的分布。从那以后我每次新站入网或批量加站都会强制走一遍PCI唯一性校验加mod30冲突扫描的流程顺手把SSB覆盖数据导出来和规划图层做一次叠图比对。这个习惯帮我拦下了好几次会在外场爆雷的配置问题——等到厂商路测或用户投诉再回头查PCI时间和人力成本都高出太多。文档里那些看似零散的经验案例其实多是外场踩过坑之后换来的教训如果你手头正在做精品路线优化建议把这份PDF连同本文一起收藏下次拉网遇到速率不达标或接入失败时按步骤排查就行。希望帮到你。本文还有配套的精品资源点击获取