企业官网建设流程全解析

简介：面向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 Grant，TBS对应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能扛多少bit，RB数决定频域上给了多少资源，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凭感觉快得多。

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的聚合速率上限，下行被限制成160Mbps，UE侧空口能力再强也没用。除了看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是单用户GAP，UE一旦进入GAP模式，整个用户面的数据传输都会受影响。也就是说，LTE侧因为异频MR测量触发了GAP，NR侧的业务调度就得跟着让路。

在实际网络里，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先接入LTE，LTE侧的RRC重配置消息会把NR的B1测量控制下发给UE，UE测量到满足条件的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小区配置了相同的PCI，LTE锚点发起SgNB Add请求时目标识别本身就存在歧义，X2消息自然发不出去。类似的陷阱还有锚点站X2链路超过上限值（256条）导致用户无法接入，这是容量维度的边界问题。

规避手段很直接：外部小区配置核查时加一道PCI唯一性校验，把锚点站所有外部小区配置导出后按PCI分组统计，重复的就是可疑对象。我在日常优化中会把PCI核查放到每次新站入网验证的第一步，先跑一遍PCI唯一性校验再谈功能验证，能省下大量排查时间。

5. 5G外场常见问题避坑：现象、原因与解决配套笔记

5.1 速率稳定在160Mbps：先查AMBR限速，别急着调空口参数

现象是下行速率稳定在160Mbps左右，不管怎么换测试位置或调整参数都没有明显变化。根因是核心网下发的下行AMBR被限制为160Mbps，UE侧即使空口条件再好，速率也只能被压在限速值附近。解法是通过路测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侧异频测量触发了GAP，UE在GAP期间无法进行业务数据传输，NR调度随之被压制。解法是调整异频MR触发门限或关闭非必要异频测量，避免LTE侧频繁进入GAP模式。我在外场遇到调度次数周期性掉坑的问题，会先把NR调度曲线与LTE异频测量上报做时间对齐，如果两个周期完全同步，就不用再往NR侧找原因了。

5.4 外部小区PCI重复导致SgNB Add失败

现象是UE上报B1后LTE迟迟不发SgNB Add请求，信令跟踪也看不到L-NR的X2消息，但所有常规配置核查均无异常。根因是锚点站上存在重复的外部小区PCI，LTE无法正确识别目标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序列共同决定PCI，PCI对30取模影响CSI-RS和DMRS的序列初始化，PCI对3取模影响PBCH的DMRS位置。邻区间如果mod3冲突，会造成PBCH的解调干扰；如果mod30冲突，CSI-RS的干扰会让终端上报的信道质量失真。所以在NR站点的PCI规划表里，我会同排优先保证mod30不冲突，再考虑mod3的分布。

从那以后，我每次新站入网或批量加站，都会强制走一遍PCI唯一性校验加mod30冲突扫描的流程，顺手把SSB覆盖数据导出来和规划图层做一次叠图比对。这个习惯帮我拦下了好几次会在外场爆雷的配置问题——等到厂商路测或用户投诉再回头查PCI，时间和人力成本都高出太多。文档里那些看似零散的经验案例，其实多是外场踩过坑之后换来的教训，如果你手头正在做精品路线优化，建议把这份PDF连同本文一起收藏，下次拉网遇到速率不达标或接入失败时，按步骤排查就行。希望帮到你。

本文还有配套的精品资源，点击获取