简介：一份面向无线网络优化与容量保障工程师的专题文档，聚焦5G/4G融合组网下高负荷小区评估与处理。文档以现网多制式、多带宽并存为背景，系统讲解TDD 20M/15M/10M、FDD 20M/15M/10M/5M以及3D-MIMO小区的高负荷识别新标准，并通过新老标准对比、各频段负荷占比变化等数据，帮助读者理解标准修订前后的差异与扩容方向。除核心标准外，还附带载波聚合、系统内外干扰管理、移动性负载均衡（MLB）、FDD电调核查等配套技术要点，形成从负荷判定、原因分析到常规优化处理思路的完整链条。资源包为单份docx文档，大小1.68MB，便于直接阅读、检索或打印。文档已有256人学习下载，适合需要掌握多制式高负荷门限、制定精准扩容与优化方案的一线网优人员。
1. 非20M带宽小区占比近三成，旧高负荷门限正在误判
一个FDD900的5M城区小区，用户反馈上传图片缓慢，后台数据却显示RRC数远没碰到TDD 20M门限；另一个FDD1800的20M大站，晚忙时流量稍有抬升，就直接进了扩容排队名单。两个场景指向同一个问题：拿TDD 20M老标准套多制式、多带宽的现网，窄带小区漏检、宽带小区误检。现网非TDD20M小区占比约26%，A频段15M、E3/F2 10M、FDD900 5M/10M并存，3D-MIMO伴随5带4快速增长，老标准既漏判也误判。这篇文章把修订后的分制式、分带宽高负荷标准和折算逻辑拆开，再把新旧标准切换后的负荷分布变化、MLB负载均衡落地和高负荷小区筛选脚本一并说清楚。
2. 分制式带宽高负荷识别标准与门限参数拆解
2.1 从TDD 20M继承的“大中小包”分类逻辑
高负荷小区首先按业务类型区分，而不是直接套用统一的利用率阈值。小区自忙时平均E-RAB流量被用作业务分类维度：不小于1000KB判定为大包小区，300到1000KB之间判定为中包小区，小于300KB判定为小包小区。这样处理的原因是大包业务占用下行资源更多，同样的RRC数下，对PDSCH利用率的贡献与小包业务完全不同；如果用户数门限按统一口径卡，小包小区会被大量误判成扩容需求。
TDD 20M作为存量最多的频段，门限维持原来的“利用率+RRC数+流量”三维判断。表1列出的这组数据，是后面所有带宽折算的基准，新标准里的15M、10M门限基本都从这里按比例映射出来。
| 小区分类 | 自忙时平均E-RAB流量 | 有数据传输RRC数 | 上行PUSCH利用率 | 下行PDSCH/PDCCH利用率 | 上/下行流量（GB） |
|---|---|---|---|---|---|
| 大包小区 | ≥1000 KB | 10 | 50% | 70% / 50% | 0.3 / 5 |
| 中包小区 | 300~1000 KB | 20 | 50% | 50% / 50% | 0.3 / 3.5 |
| 小包小区 | <300 KB | 50 | 50% | 40% / 50% | 0.3 / 2.2 |
上行利用率在三档中都是50%，说明TDD 20M的上行并不是主要矛盾；下行利用率区分了大包70%、中包50%、小包40%，大包业务对数据信道的占用明显更高。PDCCH利用率固定看50%，避免只盯PDSCH而漏掉控制信道拥塞。实际在使用时，RRC数、PDSCH利用率、下行流量三个条件按“任一命中即标记”的口径先圈出高负荷小区，再结合上下行PRB使用情况做人工复核。
2.2 TDD 15M与10M门限按带宽等比折算
A频段15M小区是旧标准里最容易漏检的一类。15M相对20M少了25%的物理资源，折算系数取15除以20等于0.75；用户数门限和流量门限都按这个系数做等比映射，个别值取整后有细微偏差。表2是A频15M小区的门限明细，RRC数从10/20/50变成了7.5/15/37.5，下行流量也整体乘0.75。
| 小区分类 | 自忙时E-RAB流量 | 有数据传输RRC数 | 上行PUSCH利用率 | 下行PDSCH/PDCCH利用率 | 上/下行流量（GB） |
|---|---|---|---|---|---|
| 大包小区 | ≥1000 KB | 7.5 | 50% | 70% / 50% | 0.23 / 3.75 |
| 中包小区 | 300~1000 KB | 15 | 50% | 50% / 50% | 0.23 / 2.63 |
| 小包小区 | <300 KB | 37.5 | 50% | 40% / 50% | 0.23 / 1.65 |
E3、F2这类10M小区再往下走一档，折算系数是10除以20等于0.5，RRC数变成5/10/25，下行流量变成2.5GB、1.75GB、1.1GB，上行流量统一按0.15GB计，如表3所示。
| 小区分类 | 自忙时E-RAB流量 | 有数据传输RRC数 | 上行PUSCH利用率 | 下行PDSCH/PDCCH利用率 | 上/下行流量（GB） |
|---|---|---|---|---|---|
| 大包小区 | ≥1000 KB | 5 | 50% | 70% / 50% | 0.15 / 2.50 |
| 中包小区 | 300~1000 KB | 10 | 50% | 50% / 50% | 0.15 / 1.75 |
| 小包小区 | <300 KB | 25 | 50% | 40% / 50% | 0.15 / 1.10 |
对比三张表能看出一个规律：RRC数门限和流量门限都跟随物理带宽做线性压缩，但利用率门限基本不随带宽变化，因为利用率本身已经是相对量，带宽越小，同样的绝对流量会更快推高利用率。所以10M小区不要因为RRC门限低就放松流量核查，下行流量达到1.75GB的中包10M小区，在晚忙时已经值得查一遍周边共覆盖。
2.3 FDD 1800与FDD 900单独建标，门限明显高于TDD
FDD1800 20M小区新增了独立标准，这是修订里变化最大的一块。FDD频分双工天然多一套独立的上行信道，无线上行利用率可以放到70%，用户数门限整体高于TDD 20M，流量门限更是高出好几倍。旧标准把FDD1800按TDD口径卡，很多承载能力强的小区被误扣高负荷，恰恰压制了它吸收话务的优势。
| 小区分类 | 自忙时E-RAB流量 | 有数据传输RRC数 | 上行PUSCH利用率 | 下行PDSCH/PDCCH利用率 | 上/下行流量（GB） |
|---|---|---|---|---|---|
| 大包小区 | ≥1000 KB | 15 | 70% | 70% / 50% | 2 / 10.5 |
| 中包小区 | 300~1000 KB | 30 | 70% | 70% / 50% | 2 / 9 |
| 小包小区 | <300 KB | 60 | 50% | 50% / 50% | 2 / 6.5 |
FDD1800还有一部分15M带宽小区，FDD900则主要分为5M和10M两种，它们统一按20M门限乘以带宽比例折算，具体如表5。这里要注意，FDD900 5M小区的RRC大包门限只有3.75，非常容易命中高负荷，修订后FDD900高负荷增长59%基本都来自这部分。
| 制式带宽 | 小区分类 | 有数据传输RRC数 | 上行PUSCH利用率 | 下行PDSCH/PDCCH利用率 | 上/下行流量（GB） |
|---|---|---|---|---|---|
| FDD1800 15M | 大包 / 中包 / 小包 | 11.25 / 22.5 / 45 | 70% / 70% / 50% | 70% / 70% / 50% | 1.5/7.88；1.5/6.75；1.5/4.88 |
| FDD900 10M | 大包 / 中包 / 小包 | 7.5 / 15 / 30 | 70% / 70% / 50% | 70% / 70% / 50% | 1/5.25；1/4.5；1/3.25 |
| FDD900 5M | 大包 / 中包 / 小包 | 3.75 / 7.5 / 15 | 70% / 70% / 50% | 70% / 70% / 50% | 0.5/2.63；0.5/2.25；0.5/1.63 |
FDD系列内部整体保持了“大包和中包上行看70%，小包看50%”的规律，下行PDSCH在大小包都是70%，小包压到50%。相比TDD，FDD对高负荷的容忍度高出不少，这符合FDD资源相对富余、干扰底噪更干净的工程经验。
2.4 3D-MIMO从监控盲区变成独立统计对象
3D-MIMO此前没有纳入高负荷统计，是负荷监控的盲区。修订后单列了一档标准，但它没有沿用RRC数、利用率、流量三件套，只取RRC数和上下行流量两个维度。原因在于3D-MIMO通过大规模天线阵列形成多流传输，用户数承载能力远高于普通宏站，PUSCH、PDSCH利用率统计口径容易失真，流量反而是更可靠的判断依据。
| 小区分类 | 自忙时平均E-RAB流量 | 有数据传输RRC数 | 上/下行流量（GB） |
|---|---|---|---|
| 大包小区 | ≥1000 KB | 50 | 1 / 15 |
| 中包小区 | 300~1000 KB | 50 | 1 / 12 |
| 小包小区 | <300 KB | 55 | 1 / 9 |
三档之间的RRC门限几乎没区别，大包和中包都是50，小包反而放到55，说明3D-MIMO的限制因素不在连接数，而在承载的数据量。处理这类小区时，重点看下行流量有没有突破12GB到15GB，而不是纠结RRC数差几个。
3. 新旧标准切换后的负荷分布变化与优先级重排
3.1 修订后高负荷小区数量变化：有人减负，有人现形
新标准实施后，全网高负荷小区数量整体增加853个，但每个制式走向完全不同。3D-MIMO新增79个，FDD1800减少685个，降幅65%，FDD900增加238个，增幅59%，TDD整体增加1221个，增幅29%。这组数字印证了修订思路：让原本被高估的小区回归正常，把原本被漏掉的小区圈进来。
TDD新增的1221个高负荷小区里，F2/E3 10M贡献了953个，A频段15M贡献了268个，说明低带宽TDD才是此前的重灾区。FDD900新增的238个里，5M增加104个、10M增加134个，两类低带宽小区差不多对半开。FDD1800下降65%不用惊讶，它只是回到了与自身承载能力匹配的位置，不应当被当成优先扩容对象。
3.2 各带宽高负荷占比随时间变化
实施新标准后，低带宽高负荷占比明显抬升。表6摘录了3月16日到3月25日各区间的占比变化，可以看出10M和15M高负荷占比从约5%和6%爬升到16%和11%以上，TDD 20M始终是存量主体，而FDD 20M从31.87%回落到7%以内。
| 日期 | 10M | 15M | TDD 20M | FDD 20M | 3D-MIMO | 5M |
|---|---|---|---|---|---|---|
| 3/16 | 5.31% | 6.29% | 43.54% | 31.87% | 13.00% | 0.00% |
| 3/20 | 18.08% | 11.35% | 61.61% | 5.06% | 3.83% | 0.07% |
| 3/24 | 16.46% | 11.70% | 61.00% | 5.62% | 4.84% | 0.39% |
| 3/25 | 16.18% | 11.48% | 60.09% | 7.16% | 4.55% | 0.54% |
3月20日前后占比出现跳变，更多是后台统计口径切换带来的，不代表网络负荷在一天内剧烈变化。真正值得关注的是长期水平：10M和15M小区合计稳定在27%到30%附近，这与非20M带宽小区26%的占比基本吻合，说明低带宽小区已经在高负荷体系里露出了真实体量。
3.3 从分布变化推导优化优先级
新标准的实际效果是把“低带宽漏检”和“高带宽误检”同时摊开。日常优化时，优先级应调整为：低带宽TDD小区优先核查，FDD900 5M小区逐站确认，FDD1800放宽到流量维度的二次判断，3D-MIMO按流量专项盯防。比例变化表里10M小区占比从5%翻到18%，意味着高频次出现高负荷告警的10M小区，不能只做负载均衡，还要同步核对底噪和干扰，防止低带宽小区因外部干扰被误伤。
4. 高负荷常规处理思路与MLB负载均衡落地
4.1 高负荷处理的整体顺序：均衡优先、扩容兜底
高负荷问题小区的本质是“吸收用户过多”或“小区间负荷不均衡”，处理手段按成本和见效速度排，依次是负载均衡、软扩、硬扩。负载均衡通过参数或天馈调整把用户分担到周边较空闲的小区；软扩通过增加可用物理资源块缓解容量压力；硬扩则是新增载波或新增站址，投入最大。当前日常优化能直接掌控的资源是均衡，所以第一步永远是找到共覆盖小区。
我处理这类问题的顺序一般是：先按新标准拉出高负荷清单，再挑出每个高负荷小区的共覆盖邻区，确认邻区有可转移容量后做MLB参数调整，均衡效果不足再考虑软扩，最后才轮到硬扩和载波聚合。直接跳过均衡去扩容，往往会把原本可以通过参数消化的话务变成持续的资源浪费。
4.2 MLB负载均衡的三个执行阶段
MLB是eNodeB感知小区负载后，把高负载小区里的部分UE转移到低负载小区的机制，分为触发模式、目标小区选择、负载均衡执行三个阶段。触发模式一般看PRB利用率或用户数，目标小区从候选邻区里筛，执行方式决定了转移的是同步态用户还是空闲态用户。
现实中三种执行方式的适配场景差异很明显，如表7：
| 均衡方式 | 转移对象 | 生效速度 | 适用场景 | 容易踩的坑 |
|---|---|---|---|---|
| 异频同步态用户数均衡 | 已连接用户 | 快 | 持续中高负荷、邻区富余 | 切换信令开销上升，乒乓切换增加 |
| 异频同步态用户数均衡（空闲态释放） | 已连接/可释放用户 | 中 | 共覆盖好、用户可回落 | 释放时机不合理会影响感知 |
| 异频空闲态UE预均衡 | 空闲用户 | 慢 | 潮汐效应明显场景 | 对突发业务响应不足 |
配置MLB时，我一般会把“目标小区列表”限定为同覆盖或近距离共站小区，避免把用户均衡到覆盖重叠度不够的小区，造成弱信号。负载交互周期不宜太短，否则信令面开销吃掉收益；高负荷触发门限则要与新标准里的利用率门限对齐，避免标准已经下调、MLB还在用旧门限。
4.3 用脚本把新标准落成高负荷小区清单
新标准参数多，靠人工比对容易漏。我习惯把基站导出的周期负荷数据直接喂给Python脚本，自动判断每个小区属于大包、中包还是小包，再按带宽匹配RRC门限，输出高负荷小区清单。
import pandas as pd # 导入现网负荷数据，字段与后台导出保持一致 df = pd.read_excel("cell_load.xlsx", usecols=["cell_name", "band_bw", "erab_kb", "rrc_num", "pusch", "pdsch", "ul_gb", "dl_gb"]) # 按照自忙时平均E-RAB流量划包型 def pkg_type(erab_kb): if erab_kb >= 1000: return "大包" elif erab_kb >= 300: return "中包" return "小包" # 带宽对应的RRC门限，小数是带宽折算后的结果 rrc_th = { "TDD_20M": {"大包": 10, "中包": 20, "小包": 50}, "TDD_15M": {"大包": 7.5, "中包": 15, "小包": 37.5}, "TDD_10M": {"大包": 5, "中包": 10, "小包": 25}, "FDD_20M": {"大包": 15, "中包": 30, "小包": 60}, "FDD_15M": {"大包": 11.25, "中包": 22.5, "小包": 45}, "FDD_10M": {"大包": 7.5, "中包": 15, "小包": 30}, "FDD_5M": {"大包": 3.75, "中包": 7.5, "小包": 15}, "3D_MIMO": {"大包": 50, "中包": 50, "小包": 55}, } df["pkg"] = df["erab_kb"].apply(pkg_type) df["rrc_limit"] = df.apply( lambda r: rrc_th.get(r["band_bw"], {}).get(r["pkg"], 999), axis=1) # RRC数达到或超过门限即标记为高负荷 df["is_high"] = df["rrc_num"] >= df["rrc_limit"] high = df[df["is_high"]].copy() high.to_csv("high_load_5g.csv", index=False, encoding="utf-8-sig")这段脚本先把每个小区的自忙时E-RAB流量映射成大包、中包、小包，再按band_bw字段匹配对应带宽的RRC门限。参数说明：erab_kb是小区自忙时平均E-RAB流量，用于划分业务包型；rrc_num是有数据传输的RRC数；band_bw必须统一成TDD_20M这样的规范写法，否则取不到门限；rrc_limit取不到时会落到999，保证未知带宽小区不会误判成高负荷。脚本目前只判断了RRC数维度，实际使用中可再补两列，把PDSCH利用率和流量的命中标志也加上，三个条件任一命中就输出，能更贴近“利用率+RRC+流量”的完整口径。
5. 把高负荷新标准变成每周可复核的日常优化动作
5.1 建立按制式带宽分层的负荷台账
新标准推行后，最不建议的做法是把所有高负荷小区继续塞进同一个总表里打包处理。不同带宽的最高优先级动作完全不同，混在一起只会让FDD1800继续抢走低带宽小区的扩容资源。我建议按表8建台账：
| 制式带宽 | 典型问题 | 第一优先级动作 |
|---|---|---|
| TDD 10M / 15M | 门限压低后高负荷明显增多 | 核查共覆盖邻区，优先MLB |
| FDD900 5M / 10M | 新纳入监控，RRC门限很低 | 先看上行感知和干扰，再判断扩容 |
| FDD1800 20M | 承载能力强，误判已缓解 | 不要急着扩容，做流量二次判断 |
| 3D-MIMO | 流量维度新纳入，重点盯大包 | 结合大包流量和CA能力评估 |
每周导出一次高负荷清单，按表8分类，把连续两周命中高负荷的小区挑出来单独建群。这样避免了把一次性瞬时拥塞当成长期问题，也不会因为某周恰好低于门限就把问题小区放掉。
5.2 共覆盖识别是均衡落地的关键前提
MLB效果好不好的关键，在于共覆盖小区找得准不准。找共覆盖时，我通常把MR数据按小区和PCI分组，取平均RSRP差在3dB以内、方向角差小于60度、且两小区间有切换关系的小区作为共覆盖对。把高负荷小区与共覆盖邻区的晚忙时负荷做差值，差值大于20%且邻区流量、RRC均低于门限的，优先作为MLB接纳小区。
共覆盖小区确认后，再同步查一遍FDD侧电调天线配置，确认电子下倾角实际下倾值与后台配置一致，避免参数均衡做完后出现越区或覆盖空洞。这套台账的最终产物是“高负荷小区-共覆盖小区-MLB动作”三列清单，我一般在网优平台里按周跑一遍，把新标准里最容易被漏掉的10M和5M小区逐站过筛，连续一周以上回落的高负荷小区再移出跟踪表。
本文还有配套的精品资源，点击获取
