简介5G高负荷场景流量与用户数联合判定标准文档面向通信网络工程师、5G无线优化人员及运营商网络规划运维者用于解决高负荷小区识别、容量评估与扩容决策等问题。内容给出大、中、小数据包划分依据并覆盖2.6G/4.9G/700M等频段、宏站/室分/微站/高铁地铁等场景以及不同通道与带宽下下行和上行高负荷判断阈值下行综合下行流量、业务或控制信道利用率及RRC平均或激活用户数上行基于上行流量、上行业务信道利用率与用户数判定高铁地铁采用独立标准并结合RRC最大连接数和上下行感知速率。资源为单个docx文档压缩包约213KB文件类型为技术规范适合对照网管指标实操应用。已有121人学习下载文档结构按集团标准与省内标准固化分层内含RRU设备类型及厂家信息可帮助读者快速掌握不同场景的差异化门限支撑参数配置、资源调度与用户体验优化。1. 高负荷判定为什么不能只看单指标5G多频段多通道下的联合判定场景现网5G扩容决策里最常被问的一句话是“这个小区到底高不高负荷”。如果只看流量一个2.6G 64TR的宏站忙时跑了60GB看起来很高但PRB利用率只有30%说明资源还很空反过来流量只有20GBPRB利用率却到了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宏站。频段场景通道带宽(MHz)大包流量(GB)大包PRB(%)大包CCE(%)2.6G宏站641008080602.6G宏站321006080602.6G宏站32603680604.9G宏站64100808060700M宏站430307050表格规律很清晰相同通道数下带宽越小流量门限等比例降低但PRB和CCE利用率门限基本不变。这意味着容量门限本质上是“资源量 × 利用率门槛”的乘积关系。64TR 100M的大包流量门限80GB32TR 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或下行感知速率5M60M小区则把用户数门槛降到400。地铁场景是100M500、60M300上下行速率门槛分别是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利用率是否回落再决定是否需要硬件扩容。这类优化动作成本低、见效快适合在高负荷判定完成后作为优先处置手段。本文还有配套的精品资源点击获取 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%说明资源还很空反过来流量只有20GBPRB利用率却到了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宏站。频段场景通道带宽(MHz)大包流量(GB)大包PRB(%)大包CCE(%)2.6G宏站641008080602.6G宏站321006080602.6G宏站32603680604.9G宏站64100808060700M宏站430307050表格规律很清晰相同通道数下带宽越小流量门限等比例降低但PRB和CCE利用率门限基本不变。这意味着容量门限本质上是“资源量 × 利用率门槛”的乘积关系。64TR 100M的大包流量门限80GB32TR 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或下行感知速率5M60M小区则把用户数门槛降到400。地铁场景是100M500、60M300上下行速率门槛分别是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利用率是否回落再决定是否需要硬件扩容。这类优化动作成本低、见效快适合在高负荷判定完成后作为优先处置手段。本文还有配套的精品资源点击获取