企业官网建设流程全解析

简介：无线网络优化与基站参数配置是5G工程交付的核心环节，涉及从CU/DU/AAU三层网元的协议栈分工，到PCI、频点、功率、移动性等小区级参数的精细调优。理解参数挂在哪个网元、影响哪一层协议行为，是避免误调的关键。PCI规划需关注模3/模30冲突，功率配置应从覆盖目标反推每RE功率，移动性参数则需权衡A3/A5门限与乒乓切换。PRACH接入失败、MCS限速、BWP与SSB频点错位等典型翻车场景，也往往源于参数归属认知不清。本文从无线参数配置的基本原理切入，结合实际工程中的5G排障案例，梳理一份可落地的参数配置与验收方法，为基站开通调测和网优工程师提供参考。

1. 一份5G无线网络参数配置指导，到底在配什么

刚接手5G基站开通或优化的人，最容易犯的错是把《5G无线网络关键参数配置指导.pdf》当成手册全文通读，结果越读越晕。这份文档不是理论书，它是一张浓缩的参数地图：从小区级PCI、频点、功率，到移动性测量、重选、切换，再到接入层的PRACH和调度器配置，每一类参数对应一个网络行为。真正有用的读法是把它当作配置前必翻的checklist，改任何参数前先查它确认“这个参数在哪个网元、影响什么、推荐区间是多少”。它能解决的核心问题，是让你从“看到参数不知道动还是不动”，变成“知道改什么、改完怎么验证”。适合的读者很具体：做基站开通调测的工程交付人员、优化口子的网优工程师、以及做企业5G专网和室分设计的无线侧从业者。

2. 从空口协议栈到三层网元：参数到底改在哪个黑匣子里

2.1 参数不在一个文件里，而是分布在一台5G基站的三层网元上

5G无线网络关键参数配置的第一道门槛，是搞清楚参数归属。老4G基站一个eNB把所有功能塞在一起，参数全在一张配置表里。5G时代基站被拆成CU、DU、AAU三段，很多刚转5G的人翻半天文档找不到某个参数，其实是因为它在另一个网元的配置页面里。常见做法是CU管RRC、PDCP这类控制面和用户面高层协议，DU管MAC调度、HARQ、RLC和物理层低层处理，AAU管射频发射、波束赋形和天线权值。这份逻辑在《5G设备AAU/DU/CU安装指导书》里画得清清楚楚，参数配置文档则负责告诉你每个网元上能调什么。

把参数按网元分个类，理解会快很多：

实际排障时最常见的场面是：终端接入成功率低，有人跑到CU侧去改RRC定时器，改了半天没用，因为物理层随机接入根本没过。反过来，下行速率慢，有人去AAU把功率拉满，结果SINR更差，因为问题在DU侧的外部干扰和MCS限速上。所以拿到参数指导文档后，第一步是在脑子里建立这个映射：这个参数挂在哪个网元，它的修改会不会跨层传递。跨层的参数最坑，比如SSB频点同时牵涉AAU发射和DU的物理资源配置，两边不一致就是“有信号但上不了网”的经典坑。

2.2 协议栈五层和参数一一对应：改错层等于白改

5G空口协议栈从上到下是RRC、PDCP、RLC、MAC、PHY，5G协议栈详解类资料很多，但到配置层面，大多数人只记得层名，不知道哪层参数管什么事。RRC层负责连接管理，参数集中在测量、重选、切换、无线承载配置；PDCP层负责头压缩、加密和乱序重排，参数如discardTimer，对VoNR和高清视频这类实时业务影响很大；RLC层分UM和AM模式，AM用于数据业务，UM用于语音和实时传输；MAC层是调度中枢，上下行调度、逻辑信道优先级、HARQ进程都在这里；PHY层则是频点、子载波间隔、PRACH、功率控制这些东西。

具体到一个参数改错层的例子。曾有个站点上行弱覆盖，有人直接把AAU功率抬高试图解决。但上行覆盖取决于终端发射功率和基站接收灵敏度，AAU发射功率不影响上行链路预算。后来查配置发现DU侧p0NominalPUCCH设得过低，终端不敢抬功率，导致上行SINR一直很差。这就是典型的改错层。参数文档里若没有说明“影响方向”，至少要能自己判断：覆盖类问题先看PHY层功率和波束，移动性类问题先去CU侧看RRC测量配置，速率类问题去DU侧看MCS和调度器。按照这个思路去读那本指导PDF，参数列表就不再是一堆英文缩写，而是一条条有明确处置路径的技术点。

2.3 控制面参数与用户面参数：配置前先分清是“管接入”还是“管数据”

还有一个容易被忽略的分法：控制面参数和用户面参数。控制面参数管的是终端能不能驻留、能不能接入、能不能切走，比如小区禁止状态、接入等级控制、测量配置、切换门限。用户面参数管的是数据传多快、传多稳，比如PDSCH/PUSCH的MCS表、HARQ最大重传次数、上下行配比。

两者的调试逻辑不一样。控制面参数追求“行为正确”：终端在合适时机发起接入、在合适时机触发测量上报、切换不出错。用户面参数追求“效率最优”：同样的无线环境下，MCS能不能从QPSK提升到256QAM，HARQ重传能不能降到1%以内。实际操作中，如果速率上不去，先排查控制面是否限速——很多专网开局为了稳，会把MCS表锁到64QAM，速率上限天然砍掉三分之一。想明白这层后，改参数时才会追问一句：这个参数是防事故的，还是提效率的。防事故的求稳，提效率的求准，两者的节奏完全不同。

3. 小区级参数：PCI、频点、功率与波束，先算后配

3.1 频点、带宽与SCS：先定子载波间隔，再谈其他

小区参数是所有后续参数的地基，而地基的第一块砖是频点。以3.5GHz频段n78为例，100MHz带宽下常见子载波间隔是30kHz。这个选择不是拍脑袋：30kHz的符号时长约33微秒，循环前缀约2.4微秒，对市区多径时延足够；60kHz虽然能扛更高多径但符号开销大，覆盖半径反而变小。所以室外连续覆盖场景，开局第一件事就是把SCS定到30kHz，带宽按可用频谱从60MHz到100MHz之间选。

SSB的子载波间隔和数据BWP可以不同。SA组网下，常见做法是SSB用30kHz、数据BWP也统一用30kHz，避免后续调度和测量上的换算麻烦。但注意到一个不算罕见的配置：运营商把SSB放在30kHz，数据BWP却切成60kHz，结果终端同步上SSB后，下行共享信道在BWP上解调出错，现象是“能搜到信号但速率极低”。频率参数里有两个值必须对齐，一是absoluteFrequencySSB，二是数据BWP的中心频点或起始RB。以常见gNB CLI为例，创建小区时至少需要下面这些字段：

# 创建n78频段NR小区，ARFCN 627264对应3.5GHz附近某个频点 cell add nr-cell 1 band n78 absolute-rf-channel 627264 # 配置数据BWP：SCS 30kHz，带宽100MHz bwp add nr-cell 1 bwp-id 1 bwp-bandwidth 100MHz bwp-scs 30kHz bwp-starting-rb 0 # SSB配置：SSB的子载波间隔和周期 ssb config nr-cell 1 ssb-scs 30kHz ssb-periodicity ms20 ssb-position-burst 3

这段命令里，bwp-starting-rb必须与SSB所在位置错开或精确配合，如果SSB用了非默认频点而BWP从RB 0开始，终端会在BWP边缘丢失SSB信号，出现“低电平却无法接入”的假象。ssb-periodicity默认20ms是安全值，高话务热点可降到10ms以加速终端初始扫描，代价是SSB开销翻倍，路损不大但吞吐损失约1%。调频点阶段最忌讳的是只改ARFCN不动BWP，很多现场翻车都源于此。建议任何频点变更后，先用扫频仪或终端工程模式确认SSB实际位置和BWP一致，再往下走其他参数。

3.2 PCI规划：模3和模30的账，必须提前用脚本算

5G的物理小区标识PCI从0到1007，由PSS（0到2）和SSS（3的倍数序列）组合而成。规划时最常见的坑是只避开同频同PCI，却忽略了模3和模30冲突。SSB占用的RE位置与PCI模3相关，两个PCI模3相同的同频邻区，SSB出现RE级别的重叠，终端在重叠区域测到的SINR直接被拉低几个dB。而DMRS的序列ID与PCI模30相关，模30冲突会导致信道估计互相污染，看起来信号很好，解调却一直出错。

实际规划时，我不会手动推算，直接用脚本把现网PCI扫一遍更稳：

# 挑出现网所有同频小区的PCI，检查模3和模30冲突 cells = [ {"name": "A", "pci": 12, "freq": 100}, # freq为频点标识 {"name": "B", "pci": 42, "freq": 100}, # 同频不同站 {"name": "C", "pci": 72, "freq": 100}, ] conflict_mod3 = [] conflict_mod30 = [] for i in range(len(cells)): for j in range(i + 1, len(cells)): if cells[i]["freq"] != cells[j]["freq"]: continue if cells[i]["pci"] % 3 == cells[j]["pci"] % 3: conflict_mod3.append((cells[i]["name"], cells[j]["name"], cells[i]["pci"] % 3)) if cells[i]["pci"] % 30 == cells[j]["pci"] % 30: conflict_mod30.append((cells[i]["name"], cells[j]["name"], cells[i]["pci"] % 30)) print("模3冲突：", conflict_mod3) print("模30冲突：", conflict_mod30)

脚本逻辑很简单：同频小区间，先比对PCI除以3的余数，再比对除以30的余数。余数相同就列入冲突候选，去现场核实是否真的存在邻区关系。注意不是所有模3冲突都致命，两个小区如果隔得远、信号到不了对方覆盖区，影响有限。但如果它们有切换邻区关系，或者同站不同小区共站址，那就要改。改PCI不是随便挑一个新数字，我一般先在候选区间排除已用PCI、排除与所有邻区模3/模30冲突的PCI，再考虑PCI与小区方向角的对应关系。批量改PCI时还要注意，外部邻区表里所有引用该小区的记录都要同步更新，否则切换目标直接报“未知小区”。这步常被漏掉，是切换失败的一个重要隐藏原因。

3.3 功率参数：从RRU最大功率反推每RE功率

5G功率配置与LTE有个明显区别：LTE常按“小区最大功率+参考信号功率”直接填，5G则一定要区分信道类型。SSB的参考信号功率决定了覆盖，PDSCH的功率由下行功率分配参数和实际调度RB共同决定。很多新手上来直接把小区最大发射功率填满，SSB功率也填46dBm，结果邻区干扰爆炸。正确的做法是先定覆盖目标，再反推每RE功率。rmsi、SSB功率与PDSCH功率的差值，在协议里用一个叫“功率偏置”的字段控制。

以100MHz/30kHz、273个RB的典型配置为例，计算过程如下：若RRU单通道标称功率是40W，换算为46dBm；单RB的RE数在常规CP下为12个，全带宽总RE数为273乘12。每RE功率等于总功率减去10倍log10(总RE数)。算出来大约是46减35.2，约10.8dBm。这个值是PDSCH每RE功率的参考，SSB功率通常会单独设置，因为SSB只占部分符号，可以并通常确实要比PDSCH高一点，但要控制在2到3dB以内。以下是常用来做功率预算的小脚本：

# 根据RRU总功率和RB数算每RE功率，单位dBm import math total_power_dbm = 46 # RRU标称40W rb_count = 273 # 100MHz/30kHz满配PRB数 re_per_rb = 12 # 每个RB的RE数 total_re = rb_count * re_per_rb per_re_power_dbm = total_power_dbm - 10 * math.log10(total_re) ssb_power_dbm = per_re_power_dbm + 2 # SSB通常比PDSCH高2dB print(f"每RE功率: {per_re_power_dbm:.1f} dBm") print(f"建议SSB功率: {ssb_power_dbm:.1f} dBm")

换到室内分布式场景或家庭5G网络布线覆盖场景，思路完全不同。室内每台pRRU覆盖半径只有10到20米，总功率一般5W都不到，照搬室外宏站的功率参数，反而造成室内外干扰和频繁切换。室内场景更值得花时间调的是波束权值和天线口功率均衡，5G天线参数的选型也集中在波束数量、垂直/水平半功率角这些维度。室外选大功率是为了覆盖距离，室内选低功率是为了小区边界清晰。功率参数没有一个通用的“推荐值”，只有基于覆盖目标反推出来的“合适值”。改完功率后，路测要重点看切换带是否移位，很多覆盖优化做完，速率掉点也跟着出现，就是因为切换带被功率改得贴到室分边缘了。

4. 移动性参数：测量、重选与切换的三个必调门限

4.1 测量配置：GAP和A3/A5事件，先做减法再做加法

移动性参数里最先要面对的，是测量配置。终端在RRC连接态会按基站下发的measConfig周期性测量邻区，然后按事件条件上报。常见事件就是A3和A5。A3是邻区质量好于当前小区一定偏置就触发，用于同频切换；A5是当前小区差于门限1且邻区好于门限2才触发，通常用于异频或异系统切换。参数文档里最容易被乱调的是A3的offset、hysteresis和timeToTrigger，三个值共同决定切换是激进还是保守。offset设2dB意味着邻区只需好过当前小区2dB就触发测量上报，hysteresis再往上报方向加1到2dB防止抖动，timeToTrigger设320ms是通用起点。

异频测量还涉及GAP参数。终端只有一套收发机，测量异频频点时要让基站暂时不调度自己，这就是measurement gap。GAP pattern有40ms和80ms两种配置，gapOffset决定在无线帧哪个位置开测量窗。如果gap配置得太密，比如40ms周期、6ms时长，测量变频繁但下行吞吐掉得明显；配得太稀，终端来不及完成异频测量，切换时机被拖后。我的习惯是先按协议默认的40ms/6ms开局，等切换成功率和测量时延指标出来后再放宽。少动比多动好，测量参数最忌“什么都想抓在手里”，同时开多个事件、多种gap，终端测量负担上去了，主服务小区信号反而可能漏测。

4.2 重选参数：S准则与Qoffset，室分场景别用宏站默认值

空闲态驻留靠小区选择与重选参数。驻留到哪个小区、什么时候重选去邻区，由S准则和R准则决定。Srxlev代表小区接收电平是否够格，低于0dB就不能驻留。计算公式是Srxlev = Qrxlevmeas - (Qrxlevmin + Qrxlevminoffset) - Pcompensation。Qrxlevmin在ANR和开局数据里通常按运营商规划填，比如-120dBm到-124dBm。问题往往出在室分和宏站重叠覆盖的区域：终端在室内明明能收到室分信号，但因为宏站信号也强，按照R准则，如果宏站电平算出来还略高，终端就驻留在宏站上。结果用户显示信号不错，一上网就断流掉速。

解决方向是调两个参数：一是把室分小区的Qrxlevmin抬高，比如从-124改到-110dBm，让终端在室分边缘更早触发重选；二是给室分小区配置更高的重选优先级，让支持5G的终端优先回到5G室分。参数对比如下：

这里要特别提醒：q-RxLevMin抬高后，要验证室分边缘是否仍然满足接入电平，否则终端重选回室分后上不了网，比驻留在宏站更糟。t-Reselection调大是为了防止用户在室分门口来回重选，但从用户体验看，重选延时从1秒变3秒，中间那段可能就会刷不出视频。所以室分参数必须结合楼层、电梯、地下车库的实际信号分布微调，不能整片统一。5G网络里，终端大多支持网络签名式重选，网管上能看到重选次数和平均耗时，调完用这些指标验证比人工扫楼更有说服力。

4.3 切换参数：乒乓切换和切换失败的门限调整

连接态切换常出两类问题：乒乓切换和切换太迟导致掉线。乒乓切换的典型现象是终端在两个小区边界来回切换，信令面频繁重配置，用户感知就是速率先降后升、通话断续。此时应该加大hysteresis和cellIndividualOffset，而不是去动TTT。cellIndividualOffset是A3事件里的小区级偏置，只针对特定邻区生效，很适合用来惩罚性地拉开某个边界。另一种思路是让切换带避开人流密集区，靠调整天线倾角、功率而不是纯靠参数硬压，参数能解决的是“让切换不要发生在同一点上”，解决不了“切换带本身覆盖很差”。

切换太迟的问题表现是“切换请求发了，但目标小区迟迟没准备好”，或者终端在源小区已到弱覆盖区还没触发切换。参数上要把A3的offset往小调，从3dB收到1到2dB，TTT从320ms降为160ms，让终端早一点上报。高铁和汽车测试场景里，TTT常用160ms，宏站低速城区用320ms是常态。这里有个底线：TTT过短会带来不必要的测量上报和切换尝试，反而增加失败次数，所以调TTT要配合切换成功率一起来看，不要只看“切得勤不勤”。另一个极容易被忽略的参数是UE定时器里的T304，它控制切换执行阶段终端的等待时长。如果目标小区随机接入迟迟没完成，而T304已超时，终端就会回源小区并触发RLF。很多切换失败在信令上看不到失败原因，最后查出是T304设了默认值1000ms，但在弱场下重同步过程要更久，改到1500ms后成功率立刻上来。这类定时器在参数指导文档里通常只是表格里的一行，但实际决策价值很大。

5. 接入、调度与TDD配比参数：5个典型翻车配置避坑实录

5.1 PRACH配置：终端发了前导，基站就是不回RAR

现象：接入成功率低，空口信令里终端反复发Msg1，基站侧却收不到有效的preamble ID，RAR迟迟不下发。

原因：这是prachConfigurationIndex和帧结构不匹配导致的。5G的PRACH分多种格式，format 0占用一条短上行时隙，format 1和2要跨多个时隙。如果TDD配比里上行时隙较少，而prachConfigurationIndex指向的时域位置恰好落在下行或灵活时隙，基站物理层在预定位置检测不到任何前导，当然不回RAR。另一个常见诱因是PRACH掩码，它限制前导在哪些无线帧上发送，配错后终端被允许发送的时刻和基站检测时刻错开。

解决：在DU侧重新核对prachConfigurationIndex与时隙表。常见做法是先打开基站物理层日志，找“prach receive”或“no preamble detected”这类记录，确认检测窗口；再用终端侧日志对比实际发送的时域位置。如果两者错位，把prachConfigurationIndex对应的格式和TDD上下行配比重新对齐，例如DDDSU配比下format 0要落在最后一个上行时隙，不能放在S时隙的UpPTS里还期望它完成整个前导发送。改完观察接入成功率时，要区分“RRC建立成功率”和“随机接入成功率”，前者是高层指标，后者才是PRACH是否真正修好的证据。

5.2 上行速率上不去：SINR很好，但MCS卡在16QAM

现象：用户反馈上行视频传不动，测试终端显示SINR接近20dB，但PUSCH的MCS始终在10附近，也就是16QAM边缘，上不去64QAM或256QAM。

原因：两个方向排查。第一是TDD配比的上行时隙数量太少，比如用了DDDDD的极端下行配比，上行容量被压缩，调度器即便想给更多资源也没有时隙可给。第二是MCS表被限速，部分开局模板为了贪图稳健，把PUSCH的mcsTable锁成qam64甚至qam16，导致高SINR环境下终端无法上报更高的CQI。还有一种隐蔽情况是DMRS配置端口数太少，比如只配了单端口DMRS，信道估计在高阶MCS下不够准确，基站收到的误码率居高不下，调度器自动降MCS。

解决：先看PUSCH的MCS分布统计，如果MCS在弱场和强场几乎不变，基本可断定被限速。把mcsTable改为qam256并重启小区后，再看CQI上报值是否随SINR变化。TDD配比这块，既然要上行速率，就得把配比从DDDDD改成DDDSU，多给一个上行时隙。但注意改TDD配比是全小区动作，所有用户的上下行时隙同步切换，必须避开业务高峰并在修改窗口内完成。改完做一次上行灌包测试，速率如果翻倍，说明之前的瓶颈就是时隙配置，而不是频段本身的问题。

5.3 终端显示5G信号满格，却“断流”ping不通

现象：终端状态栏显示5G满格，但网页打不开、ping网关丢包，有时数据业务完全中断，重启终端或者开关飞行模式又恢复一阵。

原因：这类“无线网络断流怎么测试”的经典案例，多数不是射频覆盖问题，而是SSB所在频点与数据BWP不一致。终端同步SSB后，在BWP里做PDCCH盲检，如果BWP的起始RB和带宽与SSB所在的频域资源对不上，控制信道就解不出来。另一种原因是默认承载的QFI映射或UPF路由配置错误，无线侧正常但用户面数据从gNB到核心网的路由断了，表现也是满信号无数据。

解决：先把问题拆成无线侧和核心网侧。无线侧验证用网管查看gNB的PDCCH盲检次数和DL数据丢包率，如果盲检持续失败，大概率是BWP配置问题，立刻核对absoluteFrequencySSB与BWP起始RB。核心网侧验证看UPF的N3接口是否有数据包到达，如果gNB有下行数据但UPF收不到上行包，就是路由或QoS流映射问题，调5QI和默认承载的映射关系。这个坑最气人的地方在于，参数表面都合法、信令也能建立，只有实际业务跑不通。所以每次改完频域参数，都要做一次真实的端到端ping测试，不能只看RRC状态。

5.4 切换目标一切正常，外部邻区里却查不到

现象：邻区关系已经配置，切换请求也发到了目标站，但目标站回切换失败，查看信令是“unknown cell identity”。

原因：外部邻区表里的小区标识与实际目标小区不匹配。5G切换信令里带的是NR CGI，包括PLMN、小区ID和可能的跟踪区信息。如果开局数据里手填的NR CGI少了一位，或者PCI对了但频点写错，目标基站解析后根本认不出这个小区。ANR自动邻区功能能缓解此问题，但很多专网场景因为安全要求关闭了ANR，全靠人工维护，出错的概率直线上升。

解决：用网管的邻区核查工具，把外部邻区的NR CGI、PCI、ARFCN、带宽四个字段和现网小区做一次全量比对。对于问题站点，先把外部邻区删掉重新配置，再手动触发一次切换测试。如果切换成功，大概率是旧数据里有残留错误。另一个细节是从源站拿到的测量报告里会有目标小区的物理标识，要在外部邻区表里反查这条记录是否存在，别只看有没有配邻区，还要看邻区里的频点和带宽是不是和新开通的小区一致。5G基站扩容后，这个检查尤其重要，因为新开小区往往只配了自动邻区，外部邻区是在后台异步生成的，存在时间差。

5.5 参数改完指标不升反降，想回退却找不到基线

现象：某次参数调整后，KPI掉了一截，想回滚到之前的配置，发现网管上只有当前值，历史值没存档，只能凭记忆挨个改回来。这种事在竣工前赶工期时尤其常见。

原因：没有在改动前做配置基线导出。无线参数牵一发动全身，PCI、频点、功率、切换门限之间互相耦合，单看某个参数方向都对，合在一起可能就冲突。比如A3门限收紧减少了乒乓切换，但代价是切换带变窄，弱场切换失败率上升。没有基线，任何回退都靠猜测，等于是把网络往黑匣子里推。

解决：养成每次操作前导出网元整包配置的习惯，存成带时间戳的XML文件，放到git或网盘里做版本管理。改动时只改一个参数族，不要一次动功率又动切换又动TDD配比，这样出问题时能快速定位是哪个参数引起的。网管支持修改记录查询的，把修改前后diff打出来保存。我个人的做法是把配置文件目录按站点和日期组织，每次变更写一行变更说明，出了问题10分钟内切回上一个版本。这个习惯看着不起眼，却是在现网试错时的唯一后悔药。

6. 参数验收入门：用信令跟踪和速率验算证明配置有效

6.1 用信令跟踪确认流程走到位

参数改完不能只看网管不告警，关键要看端到端信令是否完整走通。从终端发起RRC Setup Request开始，到RRC Setup、RRC Setup Complete、建立默认承载，再到UPF回包，每一步都有对应信令。如果配置的是SSB频点或BWP参数，重点看RRC Setup消息里下发的BWP配置是否和预期一致；如果调的是切换参数，就用路测软件在切换带反复跑，确认A3测量报告触发时的电平和时间是否符合预期。信令跟踪是最直接的“参数有没有生效”的证据。

6.2 用峰值速率验算判断性能边界

另一个快速验证手段是速率验算。无线侧配了多少带宽、多少层、什么MCS、多少上行时隙，理论上峰值速率是能算出来的。下面脚本用来估算理论峰值：

# 估算单用户下行峰值速率，Mbps scs_khz = 30 bw_mhz = 100 rb_count = 273 symbols_per_ms = 14 * (1000 / (scs_khz / 15)) # 每毫秒符号数 layers = 4 # 4流 mcs_bits = 6 # 64QAM约6bit，256QAM为8bit efficiency = 0.85 # 编码开销和调度开销 slots_per_second = 1000 * (15 / scs_khz) rate_mbps = (rb_count * 12 * symbols_per_ms * layers * mcs_bits * efficiency * slots_per_second) / 1e6 print(f"理论峰值: {rate_mbps:.0f} Mbps")

实测速率能到理论值的一半到七成就算合理，低太多就要回头检查MCS限速、HARQ重传率和TDD配比。这套流程做完，参数配置才算真正收口。

最后留一句我自己的教训：调无线参数最怕“看着没问题就上线”，每一项改动都要能说出“改前什么现象、改后什么指标说明有效”。有了这个习惯，配5G基站就和修普通设备一样踏实了，希望帮到你。

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