简介这是一份面向5G网络优化工程师的实战型技术文档核心讲解高负荷小区的新识别标准及常规处理思路解决现网TDD/FDD不同带宽、3D-MIMO场景下负荷评估口径不一、扩容与优化难以精准施策的问题。文档按TDD 20M/15M/10M、FDD 20M/15M/10M/5M及3D-MIMO分类给出大中小包门限、利用率与上下行流量判断标准并结合各频段高负荷占比变化分析新旧标准差异帮助识别易漏判和易误判的小区类型提升扩容精准度同时整理了载波聚合开启步骤与A5测量事件开关、系统内外干扰排查、移动性负载均衡MLB配置、FDD/GSM电调核查等关键方法便于网优人员对照执行。资源为单个docx文件大小1.68MB内容结构完整适合从事容量规划、日常负荷整治及4G/5G协同优化的工程师作为参考手册已有256人学习下载。1. 高负荷新标准不是换门限它改变了识别高负荷小区的起点晚上八点半全网KPI看板一片绿用户投诉却集中在体育场馆周边。翻话统发现单小区RRC连接用户数冲到两百多PDSCH PRB利用率只有四成上下——按老标准它压根不算高负荷可用户就是刷不动视频。5G网络优化里这类现象特别典型高负荷新标准把判定从单指标改成多指标联合把统计粒度从全天平均细化到十五分钟目的就是把这种“看着不忙、实际在淤积”的小区先揪出来。这篇围绕怎么读懂新标准、怎么把常规处理思路落到参数和流程上展开适合刚接手5G高负荷优化、以及习惯还停在旧门限上的网优工程师。2. 拆解高负荷新标准从单指标到多维联合判定的指标与门限老标准很好懂忙时PRB利用率超了、峰值用户数超了哪个超了就列入高负荷清单然后走扩容。新标准一出来不少人第一反应是找新门限表结果发现门限数字的调整幅度并不大真正改动的是判定逻辑——它把“一个指标超限”改成“多个指标联合、并叠加统计口径约束”。这一步改动直接影响你后面是安排扩容还是先调参数所以值得花力气先拆清楚。2.1 老标准为什么不够用单看PRB利用率会漏掉控制信道与感知用户感知差的时候无线侧往往不是数据信道先打满而是控制信道先撑不住。PRB利用率反映的是PUSCH/PDSCH的数据面占用它衡量“有没有足够的物理资源块搬运业务数据”但调度这些资源块靠的是PDCCH和PUCCH上的CCE资源。一个小区如果在线用户多、业务以小包为主比如扫码、消息、网页浏览数据信道PRB占用不高CCE却会因为频繁调度迅速耗尽。CCE一旦耗尽用户调度请求发不上去、随机接入和切换信令被丢弃表现为时延上升、速率抖动甚至明明信号满格却连不上。我处理过一个园区场景工作日中午12点半到1点用户数最高PDSCH PRB利用率全天都不高按旧标准它从没上过高负荷清单实际用户投诉却很集中。后来按新标准把RRC用户数和CCE利用率一起看问题立刻清楚了用户数过百后CCE利用率冲到60%以上整个小区处在“接入忙、数据闲”的奇怪状态。这种场景如果还盯着PRB利用率优化方向一定会走偏比如去做下行速率调优结果越调越没用。为什么感知类指标也要进标准因为无线侧指标和用户体验之间不是线性关系。PRB利用率到50%时可能只是部分用户速率下降当CCE拥塞、调度时延上来时即使PRB利用率不高用户也会觉得卡顿。新标准把下行平均速率或空口时延这类感知指标作为可选叠加项本质是逼着优化人员从“资源利用率视角”切换到“用户调度视角”别再看单指标拍板。2.2 新标准的四大判定指标与统计口径新标准虽然各家的命名和门限不太一样但框架基本落在四个维度无线连接用户数、下行PRB利用率、上行PRB利用率、CCE利用率部分还会叠加感知类指标。下面是常见参考口径各省份和设备商网管会有差异实际请以你现网的最新策略配置为准。判定指标统计内容常见门限参考反映的问题无线连接用户数RRC平均/最大连接用户数忙时峰值80100以上接入面拥挤信令开销大下行PRB利用率PDSCH PRB平均占用率忙时50%60%以上用户面下行吞吐受限上行PRB利用率PUSCH PRB平均占用率忙时30%50%以上直播、上传类业务受限CCE利用率PDCCH控制信道资源占用忙时50%以上调度能力下降接入/切换成功率受影响感知类指标可选下行平均速率、空口时延低于感知门限前几项的综合结果门限只是参考更关键的是统计口径。新标准一般要求以15分钟为统计粒度一天96个点连续3个以上粒度超门限才算“忙”而不是把全天平均后看一个数。忙时选取也要稳定最好用连续3天话统自己命中的忙时段别直接套晚8点。此外联合判定通常要求多个指标同时超限才列入高负荷单指标严重超限比如PRB利用率长期70%以上会作为兜底条件直接判为高负荷避免漏掉极端场景。统计粒度为什么定为15分钟原因很实用5G的忙时效应比4G更尖锐体育馆演唱会、写字楼午休、景区夜游这些场景负荷可能半小时内快速冲高又回落。15分钟粒度能抓住峰值而不至于被小时均值稀释。24小时话统里你看全天均值看不出问题但按15分钟粒度看连续几个点冲高会很清楚。所以我在网管侧建立自定义模板的时候先把统计周期改成“15分钟”再跑联合判定这个顺序不能反。2.3 理解“联合判定”的门限组合逻辑联合判定是这轮新标准最容易误解的地方。常见组合逻辑是下行PRB利用率大于50%且无线连接用户数大于80且CCE利用率大于50%同时连续N个15分钟粒度成立才把小区标记为高负荷。用“且”而不是“或”目的是区分两类不同场景少数大流量用户把PRB拉高和大量小流量用户把CCE挤满两者都不是单指标能覆盖的。我在导出话统时有个习惯直接在网管侧按“忙时15分钟粒度”切片不取小时级平均。小时级平均会把峰值抹平比如一个小区八点到九点之间前30分钟爆满、后30分钟空闲平均完PRB利用率可能只有40%高负荷就被吞掉了。另外联合判定里的门限值要和你现网策略配置保持一致不同基站版本对CCE利用率的统计口径有差异有的按调度次数算有的按资源占用算直接跨省抄参数容易翻车。联合判定逻辑落地到网管策略时往往涉及“判定门限值、判定时间窗、生效时段”三个配置项。有些网管平台还支持对高负荷小区自动输出告警或触发工单建议把门限调整和生效时段都做成模板不同地市按负荷特征微调。这里有个容易忽略的点门限值是百分比还是绝对值要看网管统计口径。比如CCE利用率有的版本按“占用CCE数/总可用CCE数”有的按“被调度次数/可调度次数”同一个百分数背后完全不是同一回事。跨版本对比时先核对统计口径否则你看到的高负荷可能只是统计口径变了。3. 高负荷常规处理思路先分软硬再按流程落地调参识别出高负荷小区只是第一步接下来才是重点怎么处理。常规思路不是把某个参数调一格就完事而是一套有顺序的流程。我习惯先把手段分成软硬两类再按流程走避免一上来就写扩容申请——那是把思路偷懒成了单选题。3.1 把处理手段分两类软调参、硬扩容决策顺序很重要软调参不增加硬件通过切换、调度、接入控制、功率和波束参数改变负荷分布。典型动作包括MLB移动负载均衡、CIO偏置调整、PUCCH资源配置、SRS周期调整、DRX参数、波束减配等。硬扩容则是新增载波、新增小区或小区分裂本质是增加可用资源。两者的适用边界很清楚小区整体资源不够扩容资源够但分布不均软调整。决策顺序上我会先判断“资源不够”还是“分布不均”。判断依据有三个一是邻区负荷如果邻区还有余量说明有空间做均衡二是覆盖结构如果本小区覆盖范围大、用户扎堆MLB能起作用三是负荷形态如果PRB、CCE、用户数全面超限软调整腾不出多少容量直接走扩容流程。这一步是先算账再动手账算错了后面全是白做。具体选型时给一个简单规则用户数高但单用户流量低属于控制面瓶颈用接入/PUCCH类参数用户数中高且单用户流量也高属于数据面瓶颈MLB可以先上PRB利用率高但用户数不高是少数大流量用户导致考虑定向波束或扩容用户数高且PRB、CCE全部顶满不做太多软调整直接扩容。这些规则不需要每次都推导跑一遍数据就能套上。3.2 高负荷小区处理的七步流程常规处理流程可以收敛成七步每步都有明确的输入和输出。第一步取数。导出高负荷小区连续3天的15分钟粒度话统指标至少包含RRC用户数、上下行PRB利用率、CCE利用率、上下行流量、时延同时拉MR覆盖数据和上行干扰电平。除了话统还要关注MR里“RSRP低于-110dBm占比”和“SSB SINR低于0dB占比”这两个数直接决定你后面按容量处理还是按覆盖处理。第二步分类。把小区归为容量型、控制面型或覆盖型PRB和CCE都高、用户数大是容量型PRB不高但CCE高、用户数多是控制面型弱覆盖采样占比高、用户感知差是覆盖型。分类时有个经验值弱覆盖采样占比超过20%先按覆盖处理否则扩容后用户感知仍旧差指标好看但投诉不见少。第三步软调整。按类型选参数容量型优先MLB控制面型优先调PUCCH/PDCCH参数覆盖型先处理覆盖问题。这一步只动一处别一次性把一堆参数全部调掉后面没法判断是哪个动作起效。第四步复核。调完参数后连续观察3天忙时话统看指标有没有回落。要注意回弹参数调整后的头一天指标可能明显回落但后两天又缓缓涨回来说明均衡空间已经被吃透要准备扩容。第五步扩容申请。如果软调整后仍持续超门限输出扩容评估数据包。数据包至少包含连续7天忙时话统截图、MR覆盖图、软调整记录、邻区负荷对比缺一样评审都会被退回。第六步扩容实施。按现场条件选择新增载波、小区分裂或新增补点。新增载波适合覆盖不变、容量不够的场景分裂适合用户空间上扎堆明显的小区新增补点适合覆盖边缘同时有容量缺口的情况。第七步验证。扩容完成后继续观察忙时话统、切换成功率和投诉量。流程的核心是“软调整先行、扩容兜底”。我见过不少同事跳过软调整直接扩容结果扩容后负荷压下来了但邻区被推过去一堆用户全局指标并没有变好。反过来该扩容时死磕参数把MLB门限压到极低用户被切到弱覆盖区投诉反而增加。3.3 输入数据怎么读三种常见的高负荷画像读话统时我把高负荷小区归成三种画像每种对应的处理路径完全不同。画像一是典型容量型PRB利用率、CCE利用率和用户数全部站在高位流量也大。这种不必抱侥幸心理软调整只能临时缓解扩容是最终出路。画像二是控制面拥塞型PRB利用率不高CCE利用率高用户数偏多流量却不大。这种优先处理调度和接入配置比如调整SR周期、增加PUCCH资源、优化CCE聚合等级再用MLB压一压用户数扩容排在后面。画像三是干扰型PRB利用率虚高但流量与用户数不匹配上行干扰电平偏高。这种先定位干扰源清完干扰再看负荷回不回落很多时候干扰一清高负荷清单自己就消失了。画像PRB利用率CCE利用率用户数流量处理方向容量型高高高高扩容优先MLB缓解控制面拥塞型不高高偏高不高调调度/接入参数再MLB干扰型虚高中不高不高先清干扰再复评读MR数据时把用户分布叠到小区覆盖图上看能判断“用户是扎堆在近点还是散布在边缘”。近点扎堆说明业务集中扩容有效边缘散布说明覆盖延伸太远盲目的容量规划会让基站的覆盖半径继续扩大负荷反而更差。高负荷优化和覆盖优化的分界线就在这里先确认覆盖是对的再做容量动作。这步省了后面所有参数调整都会被覆盖问题拖累。4. 高频处理手段实操MLB与参数调整的落地步骤与参数说明高负荷处理手段很多实际出场率最高的是MLB和PUCCH/PDCCH这组调度接入参数。这一章给一组可以照着做的落地步骤和参数方向参数值只作为示例以你现网设备商的建议值和策略配置为准。4.1 MLB移动负载均衡的典型调参流程与参数表MLB的原理是通过切换和重选把用户从高负荷小区引导到低负荷邻区属于软调整里最常用的一组。启动MLB前要确认三个前置条件邻区关系完整、存在与高负荷小区重叠覆盖的异频/同频低负荷小区、邻区本身有容量余量。条件不满足就强行调门限结果大概率是用户被切到覆盖空洞里。落地步骤一般是这样先在小区级开启MLB功能然后核查邻区列表接着调整异频切换事件的触发门限再叠加CIO偏置最后观察切换成功率和均衡效果。下面表格列出了几个核心参数参数项作用调整方向示例风险A4/A5事件门限触发异频切换的信号条件门限适当调低让高负荷小区更容易切出切到弱覆盖区速率下降CIO小区个体偏移改变单个邻区的判决偏向对容量富裕邻区调正值用户更容易切过去乒乓切换、误切切换迟滞避免边缘抖动触发频繁切换调大减少乒乓均衡响应变慢MLB负载阈值触发MLB的存量级门限和建议的高负荷门限对应阈值过小导致频繁触发我一般会给一个原则同一轮调整里只动高负荷小区“往外切”这一侧不要同时把相邻低负荷小区的接入门限也改掉否则两边一起调很容易形成乒乓切换成功率掉下来后问题就从负荷问题变成质量问题。MLB调完最好关注一下切换话统里的乒乓率指标乒乓率上升通常意味着CIO偏置过了先回落一个档位。4.2 用脚本筛出真正该处理的高负荷小区手工在网管侧一个个点太费劲我会先用一段小脚本在话统数据上做联合判定把候选小区先筛出来再人工复核。下面这段Python代码适用于从CSV话统里筛选满足“多指标同时超限且连续N个15分钟粒度”的小区。import pandas as pd # 字段cell_id 小区ID, time 统计时间, prb_dl 下行PRB利用率, # rrc_users 无线连接用户数, cce_util CCE利用率 df pd.read_csv(busy_hour_stats.csv, parse_dates[time]) # 按你现网的新标准改这三个门限 prb_thr 50 # 下行PRB利用率门限单位% rrc_thr 80 # 无线连接用户数门限 cce_thr 50 # CCE利用率门限单位% # 锁定晚忙时这里取20点到22点 busy df[(df[time].dt.hour 20) (df[time].dt.hour 22)] # 连续多少个15分钟粒度同时超限才算高负荷 window 3 def flag_high_load(group): # 生成布尔掩码并按小区分组判断连续性 over ( (group[prb_dl] prb_thr) (group[rrc_users] rrc_thr) (group[cce_util] cce_thr) ).astype(int) group[high_load] over.rolling(windowwindow).min().fillna(0) return group result busy.groupby(cell_id, group_keysFalse).apply(flag_high_load) high_cells result[result[high_load] 1][cell_id].unique() print(f初筛高负荷小区数{len(high_cells)}) print(high_cells)这段脚本的逻辑是先把忙时数据过滤出来再在每个小区内部判断“PRB、用户数、CCE同时超限”这个条件。把布尔掩码转成0/1后用rolling的min函数做连续窗口判断只要窗口内有任何一个点为0min就是0只有连续window个点全是1才会输出1。这里window取3对应45分钟持续高负荷比单点偶发更接近真实瓶颈。参数上要注意三点第一门限值必须换成你现网新标准里的数字不要照抄示例第二忙时时段要从话统里实际命中直接写死20点可能漏掉中午忙时的园区场景第三脚本只能做初筛最终处理决策还是要结合MR覆盖和干扰数据人工复核。脚本的价值是帮人省掉重复的Excel透视省下来的时间应该花在复核上不是直接拿着名单去调参数。4.3 PUCCH与接入参数控制信道拥塞时先调什么当小区画像属于控制面拥塞型时调MLB不一定是最优解因为MLB本身就是靠切换信令实现的控制信道已经忙不过来的时候再频繁触发切换反而会加重信令负荷。这时候优先调整调度和接入侧参数。第一是SR调度请求周期。把SR周期从20ms调短到10ms用户能更快把调度请求发上来但代价是PUCCH开销上升。第二是PUCCH资源量。为更多在线用户预留上行控制资源能缓解用户数增长带来的控制面压力但不能无限制扩PUCCH占多了会挤压PUSCH的可用PRB。第三是PDCCH符号数。在系统带宽有余量的前提下把PDCCH符号数从1个扩到2个控制信道容量直接翻倍。第四是CCE聚合等级。如果当前用的是固定高聚合等级可以改为自适应让小包业务用低聚合等级释放CCE给切换和接入信令。参数项场景调整方向示例观察项SR周期调度请求频繁20ms调至10msPUCCH开销、上行PRB利用率PUCCH资源配置在线用户多提升资源组数PUSCH是否被挤压PDCCH符号数控制信道容量不足1个扩至2个空口开销、下行速率CCE聚合等级小包业务占调度固定改为自适应CCE利用率、接入成功率提示这类参数都属于小区级联动参数改完会影响整站的上下行资源分配。我的习惯是每次只动一个维度观察24小时再决定下一步不要四个参数同时改否则出了问题根本定位不到是哪个调整引起的负荷变化。控制信道拥塞还有一个排查点容易被忽略接入成功率指标本身。如果CCE利用率高但接入成功率还在正常范围说明拥塞还没到临界可以先观察一旦接入成功率开始抖动参数动作就必须立刻跟上。这个先后顺序能避免过度调参把本来正常的小区弄出副作用。5. 高负荷优化的避坑清单5个让老手也翻车的处理误区高负荷优化做得越多越发现大多数人踩坑不在原理而在细节。这5条都是实际处理里反复出现的问题按“现象-原因-解决”拆开写照着避。5.1 只看PRB利用率没发现CCE先满了现象小区用户数很高PRB利用率只有四成上下按旧标准不算高负荷但用户已经觉得卡。原因CCE利用率才是控制面的瓶颈小包业务多、调度频繁时控制信道先于数据信道耗尽。接入成功率或切换成功率掉下来、但PRB利用率正常时先查PDCCH符号数和CCE聚合等级很多设备默认只配了1个PDCCH符号忙时小包用户一多就扛不住。解决把CCE利用率纳入每日高负荷复核用户数过80就顺手看一眼CCECCE超过50%且接入成功率下滑时优先调PDCCH符号数和PUCCH资源而不是先去动MLB。5.2 MLB把用户推到弱覆盖邻区投诉反而变多现象高负荷小区PRB降下来了但邻区边缘用户投诉变多速率掉得很明显。原因MLB调门限时只看了A4门限没有核对邻区的MR覆盖采样弱覆盖区域也被当成了均衡目标。用户切过去之后信号质量差业务反而更难传。解决调整MLB前按邻区拉一遍覆盖采样只允许用户切换到“覆盖连续且有余量”的邻区弱覆盖邻区可在MLB参数里做黑名单排除。调完还要盯乒乓率乒乓率上升说明偏置给过了先回落一个档位再看。5.3 用全天平均门限看高负荷忙时峰值被“平均”掉现象全天平均PRB利用率40%怎么看都不像高负荷但晚忙时峰值其实已经破70%。原因统计周期太粗小时级或天级平均把峰值抹平了。尤其是5G业务突发性强半小时的演唱会散场就能把负荷打满平均值根本反映不出来。解决强制用15分钟粒度切片按连续3天话统命中忙时再看连续N个点超限的情况。你甚至可以跑一遍4.2里的脚本用rolling min看连续性比肉眼盯均值靠谱。如果只想快速看忙时可以自定义一个忙时模板只统计话统自动命中的Top忙时前3个小时。5.4 高负荷和上行干扰同时出现先扩容却越扩越差现象扩容完工后负荷指标短暂回落但第二天又反弹流量和用户数没涨多少上行干扰电平反而在涨。原因干扰导致重传升高、PRB被无效业务占用本质上是质差问题不是容量问题。扩容只是多分了PRB干扰不除重传依旧扩出来的资源照样被吃掉。判断干扰型看两个数上行干扰电平和调制编码方式分布。MCS明显偏低但信号强度不差大概率是干扰或重传虚高。解决处理前先拉上行干扰带统计干扰电平异常时先定位干扰源清完干扰再复测负荷真到扩容那一步也要把干扰状态写进评估报告。5.5 扩容完成后参数没回退小区负荷被严重低估现象扩容后看到PRB利用率明显回落以为优化成功过段时间发现实际忙时用户还是多新扩容小区没被充分用起来。原因扩容前调的MLB门限、CIO偏置还停留在“把用户往外推”的激进状态扩容后本小区容量已经翻倍参数却还在赶人走。解决扩容实施后24小时内把所有软调整参数回退到基准值保留参数快照回退后重新观察72小时负荷表现才真实。参数回退前打快照是为了事后能还原回退后别马上出结论系统需要时间把用户重新分布至少观察一个完整忙时周期。6. 验证高负荷优化有没有效话统、路测、感知三层复盘优化做完不等于结束验证决定这个方案能不能沉淀成标准动作。我习惯用三层复盘每层各看各的。第一层话统复盘看无线侧关键指标是否回落、是否存在反弹趋势。拿出优化前后的忙时15分钟粒度曲线重点比PRB利用率、CCE利用率、RRC用户数、切换成功率四项。下降幅度超过20%且连续3天稳定算第一层通过。第二层路测复盘在忙时对高负荷小区和周边邻区做定点遍历测试测下载/上传速率和切换点确认MLB推出去的用户在邻区没有遭遇弱覆盖。第三层感知复盘把投诉量和边缘用户平均速率放进来边缘速率有提升、投诉量下降才算终端用户真的买账。验证维度主要指标通过标准参考话统PRB/CCE利用率、RRC用户数忙时峰值回落20%以上连续3天切换质量切换成功率、乒乓次数切换成功率不低于95%路测忙时定点上下行速率边缘速率提升无新增弱覆盖点感知投诉量、边缘用户平均速率投诉量下降边缘速率改善我现在做高负荷优化有个习惯调参前先拍一张参数快照调完把前后话统放到同一张图里连续对比三天不急着下结论。下一轮负荷再波动时这张快照就是后悔药。验证不只是给评审交差更是给自己留数据底账这套三层复盘跑下来方案到底有没有效拿数字说话最稳。希望帮到你。本文还有配套的精品资源点击获取