5G小区高负荷判定：从PRB利用率到RRC用户数的联合门限解析

简介：5G高负荷场景流量与用户数联合判定标准文档，面向通信网络工程师、5G无线优化人员及运营商网络规划运维者，用于解决高负荷小区识别、容量评估与扩容决策等问题。内容给出大、中、小数据包划分依据，并覆盖2.6G/4.9G/700M等频段、宏站/室分/微站/高铁地铁等场景，以及不同通道与带宽下下行和上行高负荷判断阈值；下行综合下行流量、业务或控制信道利用率及RRC平均或激活用户数，上行基于上行流量、上行业务信道利用率与用户数判定，高铁地铁采用独立标准并结合RRC最大连接数和上下行感知速率。资源为单个docx文档，压缩包约213KB，文件类型为技术规范，适合对照网管指标实操应用。已有121人学习下载，文档结构按集团标准与省内标准固化分层，内含RRU设备类型及厂家信息，可帮助读者快速掌握不同场景的差异化门限，支撑参数配置、资源调度与用户体验优化。

1. 高负荷判定为什么不能只看单指标：5G多频段多通道下的联合判定场景

现网5G扩容决策里，最常被问的一句话是“这个小区到底高不高负荷”。如果只看流量，一个2.6G 64TR的宏站忙时跑了60GB，看起来很高，但PRB利用率只有30%，说明资源还很空；反过来，流量只有20GB，PRB利用率却到了85%，用户感知已经开始明显变差。这就是为什么集团标准和省内标准都采用流量、资源利用率、用户数多条件联合判定的原因。

这份材料把判定标准拆成了集团级和省级两套。集团标准以“流量 + PRB利用率（或CCE利用率）”双条件为主，省内标准则在双条件基础上增加了RRC平均用户数，要求三个维度同时满足才判定为高负荷。另外，高铁、地铁单独成体系，用的是RRC最大连接用户数加感知速率的组合，跟普通宏站室分完全不是一套逻辑。以下内容会逐步拆解这套标准的计算口径、参数映射关系和落地实现方式，方便直接对照网管数据复现判定过程。

2. 包类型划分与PRB/CCE资源利用率口径：判定前的基础数据

2.1 大中小包定义的计算口径

所有高负荷判定都先落在“包类型”上，因为不同包类型对应的流量门限差异极大。按照定义，每QoS flow流量 = 总流量 /（QoS flow建立成功次数 + QoS flow切换入次数），然后按区间划分：

• 小包：每QoS flow流量 < 1.5MB
• 中包：1.5MB ≤ 每QoS flow流量 < 3MB
• 大包：每QoS flow流量 ≥ 3MB

这个口径要特别注意分母里的“切换入次数”。切换入的QoS flow也承载了业务数据，如果不计入分母，算出来的每flow流量会偏大，可能导致把中包误判成大包。实际取数时，建议直接使用网管中QoS flow级聚合统计，不要用小区总流量除以总用户数代替。用Python实现分类逻辑非常简单：

def classify_packet_type(total_flow_bytes, setup_cnt, handover_in_cnt): """ 根据每QoS flow流量判断包类型 :param total_flow_bytes: 小区总流量，单位MB :param setup_cnt: QoS flow建立成功次数 :param handover_in_cnt: QoS flow切换入次数 :return: 包类型字符串 """ per_flow = total_flow_bytes / (setup_cnt + handover_in_cnt) if per_flow < 1.5: return "小包" elif per_flow < 3.0: return "中包" else: return "大包"

这里的换算单位需要注意。网管侧流量通常以GB为单位，代码里total_flow_bytes传入的是MB，需要先做一次单位换算：GB数值乘以1024。包类型划分直接影响后续取哪一档门限，所以这个函数是整个判定链路的第一步，建议在数仓ETL阶段就完成分类，避免在报表层反复计算。

2.2 下行四个关键指标的含义

下行高负荷涉及四类指标：下行流量、下行业务信道利用率（PRB占用率）、下行控制信道利用率（PDCCH CCE占用率）、RRC平均用户数。前两个反映业务负载，第三个反映控制面压力，第四个在省内标准中作为用户维度约束加入。

PRB占用率是物理资源块在时频资源上的占用比例，体现的是业务信道承载压力。CCE占用率则是PDCCH信道上控制信道元素的占用比例，反映的是调度信令的消耗程度。在某些场景下，业务PRB不高但CCE很高，比如大量小包用户频繁调度，此时控制信道会成为瓶颈，因此集团标准将“流量+PRB利用率”和“流量+CCE利用率”作为两条并列的判定路径，任一路径满足即认定为下行高负荷。这一点在实际网络分析中很容易被忽略，但恰恰是小包场景下最需要关注的判定路径。

2.3 上行指标与频段、通道、带宽的映射关系

上行判定相对简单，只涉及上行流量、上行业务信道利用率和用户数三个维度。但它的门限表更强调频段、通道数、带宽三者的组合关系。同一个2.6G频段，64TR 100M小区的上行流量门限是10GB，而32TR 60M小区是4.2GB，差值超过一倍。这意味着在系统设计时，不能把判定标准写死成一张常量表，而必须按小区属性动态匹配。

材料中还列出了700M频段宏站4通道30M小区的上下行门限，下行流量大中小包分别为28GB/22GB/16GB，上行流量2GB。700M覆盖广但容量有限，门限显著低于2.6G/4.9G，需要单独配置。微站的判定维度还需要结合RRU类型确认通道数，材料末尾列出了华为、中兴、爱立信的微站RRU型号，其中绝大多数是4T4R，但中兴R9154/R9154E是8T8R，门限应匹配8通道档位。

3. 集团标准落地：下行流量与上行流量的双条件实现

3.1 下行高负荷的门限表结构与动态匹配逻辑

集团下行标准的核心是“流量 + 业务信道利用率”或“流量 + 控制信道利用率”两条路径。以2.6G宏站32TR 60M小区为例，大包场景下要求下行流量≥36GB且PRB占用率≥80%，或者下行流量≥36GB且CCE占用率≥60%。门限表按频段、场景、通道数、带宽四维组合组织，共有4个频段/场景分类：2.6G宏站、2.6G室分、4.9G宏站、微站、700M宏站。

表格规律很清晰：相同通道数下，带宽越小，流量门限等比例降低，但PRB和CCE利用率门限基本不变。这意味着容量门限本质上是“资源量 × 利用率门槛”的乘积关系。64TR 100M的大包流量门限80GB，32TR 100M则降到60GB，通道减半并不等于流量门限减半，因为不同通道数对应的调度效率和频谱效率不同。

实现时最合理的做法是把门限表存为配置表，按小区属性逐级匹配。下面给出一个按维度匹配门限的实现思路：

THRESHOLD_TABLE = { ("2.6G", "宏站", 64, 100): {"大包_流量": 80, "大包_PRB": 80, "大包_CCE": 60}, ("2.6G", "宏站", 32, 100): {"大包_流量": 60, "大包_PRB": 80, "大包_CCE": 60}, ("2.6G", "宏站", 32, 60): {"大包_流量": 36, "大包_PRB": 80, "大包_CCE": 60}, # 其余组合按原始表完整录入 } def match_threshold(freq, scene, channel, bandwidth): key = (freq, scene, channel, bandwidth) if key not in THRESHOLD_TABLE: raise KeyError(f"未找到匹配的门限配置: {key}") return THRESHOLD_TABLE[key]

表格要完整建好，因为漏配一个组合就会导致该小区无法参与高负荷判定。实际工作中我一般会在配置表加载后加一道自检，统计所有唯一小区属性组合是否能命中配置，把未命中的小区单独输出告警。

3.2 上行高负荷判定实现

上行判定的门限表相对简单，但流量绝对值要比下行数据小很多。以2.6G/4.9G频段为例，64TR 100M小区的上行流量门限10GB、利用率60%；32TR 60M小区流量门限4.2GB。值得注意的是，8通道以下小区上行利用率门限降为50%，说明低通道小区的上行资源本身受限，判定门槛要相应放宽。

具体到数据实现，可以用SQL在Hive或ClickHouse中直接完成判定，下面是一个标准的SQL判定逻辑：

SELECT cell_id, freq_band, channel_cnt, bandwidth, uplink_flow_gb, uplink_prb_rate, rrc_avg_users, CASE WHEN uplink_flow_gb >= 4.2 AND uplink_prb_rate >= 60 AND rrc_avg_users >= 82 THEN '上行高负荷' ELSE '正常' END AS load_level FROM cell_daily_stats WHERE freq_band = '2.6G' AND channel_cnt = 32 AND bandwidth = 60;

SQL里的4.2GB对应32TR 60M的大包场景，60是上行业务信道利用率，82是RRC平均用户数门限。实际使用时应把门限值用参数表JOIN进来，不要写死在SQL里。另外上行流量在网管里统计口径有“小区上行PDCP字节数”和“RLC层吞吐量”两种，规范里说的上行流量指的是PDCP层数据量，取数时不要用错。

3.3 双条件判定中的边界情况处理

双条件判定存在一个边界问题：流量刚过门限但利用率差一点，或利用率过门限但流量差一点，此时按集团标准都不算高负荷。这种设计是有意的，因为单一指标突增可能只是瞬时拥塞或个别大流量用户造成，不代表小区持续处于高负载状态。省内标准增加的RRC用户数条件则进一步排除了“高流量低用户数”的干扰场景。

判定时还需要注意统计周期。规范里的流量和利用率口径默认是忙时均值，建议取一天中最忙的连续60分钟数据，而不是全天平均值。全天平均会把闲时数据稀释掉，导致高负荷小区被漏判。

4. 省内固化标准：RRC用户数门限如何引入联合判定

4.1 三条件同时满足的判定逻辑

省内标准在集团双条件基础上增加RRC平均用户数，判定逻辑从“或”变成了“且”。具体规则是：下行流量≥36GB、下行PRB利用率≥80%、RRC平均用户数≥82，三个条件同时满足才算下行高负荷。CCE路径同理，但CCE利用率门限降到60%。

用户数门限与包类型强相关。以2.6G宏站32TR 60M为例，大包对应的RRC平均用户数门限为82，中包为90，小包为98。逻辑上也说得通：小包用户单位流量低，要达到同等级流量门限就需要更多用户并发。8TR大包用户数门限是57，远低于32TR的82，因为通道数减少导致单用户可分配资源变小，用户承载能力随之下降。从表格里还能看到，64TR 100M 4.9G宏站的大包用户数门限是186，几乎是8TR宏站的三倍，这间接反映了5G Massive MIMO在高并发场景下的容量优势。

4.2 从RRC平均用户数到激活用户数的演进

材料中有个重要备注：RRC平均用户数待基站版本升级后使用激活用户数。两张用户数门限在表格中并列给出，例如2.6G宏站64TR 100M大包，RRC平均用户数门限186，激活用户数门限65，比例大约在2.8比1。这是因为RRC连接态用户包含了一部分有连接但无数据传输的用户，激活用户则是真正在调度资源的用户。

从工程角度看，直接用激活用户数判定更贴近真实负载，但前提是基站版本支持输出该指标。如果网管系统尚未升级，仍应使用RRC平均用户数做判定。在做平台设计时，建议两张表都保留，通过一个“版本标识”字段切换，避免后期基站版本升级后又要重写一套判定逻辑。

4.3 Python实现三条件联合判定

def judge_uplink_high_load(freq_band, channel_cnt, bandwidth, packet_type, flow_gb, prb_rate, rrc_users): """ 上行高负荷判定：流量、利用率、用户数三条件同时满足 """ threshold_map = { ("2.6G/4.9G", 32, 60): {"大包": (4.2, 60, 82)}, ("2.6G/4.9G", 64, 100): {"大包": (10.0, 60, 186)}, ("700M", 4, 30): {"大包": (2.0, 50, 91)}, } flow_limit, prb_limit, user_limit = threshold_map[ (freq_band, channel_cnt, bandwidth)][packet_type] return (flow_gb >= flow_limit and prb_rate >= prb_limit and rrc_users >= user_limit)

三条件的判定比双条件严格得多，这也意味着省内高负荷小区数量会比集团标准识别出的少。实际优化工作中，我一般会同时跑两套口径：先按集团标准筛出“候选高负荷小区”，再用省内标准确认优先级，避免直接把资源投放到集团标准下较高但省内标准不满足的小区上。

4.4 用户数门限与场景的关联

室分场景的用户数门限普遍低于宏站。2.6G室分4通道100M大包RRC平均用户数门限80，宏站8通道是96，差异主要在于室分的覆盖范围有限，用户数承载天然受限。这类差异在扩容决策中意义重大：一个室分小区达到高负荷门限所代表的用户体感恶化程度，可能比宏站更严重，因为室分的容量极度依赖回传和射频资源。

5. 高铁地铁独立门限与判定参数校准技巧

5.1 感知速率指标的计算与门限

高铁和地铁场景不采用流量+利用率模式，而是改用RRC最大连接用户数加用户感知速率。高铁场景100M小区要求RRC最大连接用户数>600且上行感知速率<0.5M或下行感知速率<5M；60M小区则把用户数门槛降到400。地铁场景是100M>500、60M>300，上下行速率门槛分别是1M和5M。

这里的感知速率计算有一个容易踩坑的地方：规范写的“上行感知速率=上行用户平均速率（MBPS）/8”，单位换算后是MB/s。例如感知速率0.5M指的是0.5Mbps除以8，即62.5KB/s。如果在网管里直接取Mbps数值而没有除以8，判定结果会完全失真。

5.2 非100M和60M小区的处理

材料备注明确指出，非100M和60M小区沿用原规则。这里“原规则”指的是省内普通场景的流量+利用率+用户数判定逻辑。这意味着高铁地铁场景实际可能存在两套标准共存：一套针对标准带宽小区，一套针对异形带宽配置。在设计判定平台时，需要先判断小区是否属于高铁地铁场景，再判断带宽是否在100M或60M，如果带宽是其他值则回退到普通场景标准。

5.3 网管指标一致性校验的三步技巧

最后给出一个实际调参时常用的校验方法。拿到一批小区的高负荷判定结果后，先用三个步骤确认数据可靠性，再决定是否进入扩容流程。

第一步，核对门限匹配到的通道数是否与基站配置一致。微站设备可能上报配置与实际不一致，特别是更换RRU后配置数据未同步。用以下SQL反查一次配置是否成对出现：

SELECT cell_id, COUNT(DISTINCT channel_config) AS config_cnt, COUNT(DISTINCT channel_actual) AS actual_cnt FROM cell_config_snapshot GROUP BY cell_id HAVING config_cnt != actual_cnt;

第二步，对比RRC平均用户数和最大用户数的曲线形态。两个指标的忙时趋势应当基本同向，如果RRC平均用户数很低但最大用户数异常高，说明小区存在瞬间涌入的潮汐流量，此时应参考峰值时段的利用率而非全天平均值。

第三步，检查CCE占用率与PDCCH符号数的配置匹配关系。PDCCH符号数配得越多，CCE资源越充足，高负荷门限对应的用户体感也不同。部分基站默认配了2符号PDCCH，扩容前可考虑先调整为3符号，观察CCE利用率是否回落，再决定是否需要硬件扩容。这类优化动作成本低、见效快，适合在高负荷判定完成后作为优先处置手段。

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