简介面向通信网络优化、无线运维与规划人员的5G高负荷判定标准技术文档系统定义了大、中、小数据包的划分依据并给出不同频段2.6G、4.9G、700M、不同场景宏站、室分、微站、高铁地铁等、不同通道数与带宽条件下的上行、下行高负荷判断阈值。内容在集团标准基础上结合省内固化要求进行细化下行高负荷需同时满足流量指标、业务/控制信道利用率以及RRC平均用户数后续版本将过渡为激活用户数要求上行高负荷则综合上行流量、上行业务信道利用率与用户数量共同判定针对高铁与地铁场景还设置了独立标准并附有支持微站的RRU设备类型及厂家清单。资源为1个docx文件压缩包大小213KB结构清晰适合用于网络容量评估、扩容决策、性能监控及优化策略制定。当前已有121人浏览学习通信工程师可直接对照阈值表识别高负荷小区并据此调整基站参数配置、资源调度策略提升用户体验。1. 5G高负荷判定不是看流量为什么必须“流量用户数资源利用率”三者联合前阵子处理一个2.6G频段32通道60M带宽的宏站单日下行流量冲到了38GB按“流量高就该扩容”的老思路早该下单加板卡了。但把这份5G高负荷标准翻出来它压根不够格PRB占用率不到55%RRC平均用户数只有40多三项条件差两项。真正识别5G高负荷不是单看流量而是把流量、上下行资源利用率和用户数联合起来按频段、场景、通道数、带宽、包类型去查门限。这篇笔记把这套标准里的判定逻辑、查表方法和省内差异拆开再给一个批量筛选的脚本思路适合通信网络工程师、5G无线优化人员和运营商运维在容量评估与扩容决策时直接落地。2. 先把口径理清大中小包划分与上下行高负荷的判定要素判定高负荷之前必须先统一两个口径包类型怎么算、上下行分别看哪些指标。很多人直接拿总流量去套门限结果包类型定错整个判定翻车。这一章把基础逻辑过一遍后面查表才不会错。2.1 大中小包怎么算每QoS流的平均流量是分界线大中小包的划分依据是“每QoS流平均流量”不是小区总流量也不是单用户流量。标准里的公式写得很清楚每QoS流流量 小区总流量 /QoS flow建立成功次数 QoS flow切换入次数分母要把切换入次数加进来是因为切换入的QoS流同样承载了用户数据。如果只除以建立成功次数分母偏小平均流量会被抬高中包可能被误判成大包最后套错门限。包类型边界如下包类型每QoS流流量小包小于1.5MB中包大于等于1.5MB且小于3MB大包大于等于3MB举个例子某小区时间粒度内总下行流量12000MBQoS flow建立成功次数6000次切换入次数2000次那么每QoS流流量 12000 / (6000 2000) 1.5MB。这个值落在“大于等于1.5MB”区间所以判定为中包而不是小包。实操中这个值取出来后要保留一位小数以上避免边界附近误判。为什么按包类型分门限因为大包用户单个流量大占用PRB资源多但控制信道占用相对少小包用户信令交互频繁CCE资源消耗占比高。如果所有包类型共用一套门限小包场景容易被漏判大包场景又可能被过度扩容。标准把下行流量、PRB占用率、CCE占用率都按大中小包拆开就是为了适应不同业务模型。2.2 下行高负荷判定业务信道利用率与控制信道利用率是“或”下行高负荷的集团标准是一个“且里面套着或”的结构下行流量达到门限并且下行业务信道利用率达到门限或者下行控制信道利用率达到门限。写成判定式就是下行高负荷 下行流量 ≥ 门限 且PRB占用率 ≥ 门限 或 PDCCH的CCE占用率 ≥ 门限注意这里业务信道和控制信道是“或”的关系不是“且”。原因是用户面数据信道和PDCCH控制信道任何一个资源饱和都会导致用户感知下降所以只要其中一个达到门限就算资源侧压力大。举标准里的原例2.6G频段、32TR、60M带宽小区业务类型为大包则需要满足下行流量≥36GB且下行业务信道利用率≥80%或者下行控制信道利用率≥60%。也就是说只要流量够了以后PRB到80%或者CCE到60%就触发下行高负荷。这里有一个容易看花眼的细节CCE占用率在标准表里是不分包类型的一列PRB占用率才分大中小包。以下摘几行集团下行标准做示例频段场景通道带宽大包流量(GB)中包流量(GB)小包流量(GB)PRB大/中/小(%)CCE(%)2.6G宏站6410080705080/60/50602.6G宏站326036302480/60/50602.6G室分210025151070/50/4050以第一行为例如果小区是大包下行流量到80GB且PRB到80%或CCE到60%就是下行高负荷如果是中包流量到70GB且PRB到60%或CCE到60%就是下行高负荷。读表时先定包类型再取对应数值。2.3 上行高负荷判定没有控制信道选项逻辑更简单上行高负荷的集团标准比下行少一个维度只看上行流量和上行业务信道利用率没有CCE这一项。判定式是上行高负荷 上行流量 ≥ 门限 且 上行业务信道利用率 ≥ 门限例如2.6G/4.9G频段32通道60M带宽小区上行流量≥4.2GB上行业务信道利用率≥60%即判定为上行高负荷。台内不考核上行控制信道是因为上行调度和功率控制机制与下行不同控制信道压力远没有下行显著。上行标准不分包类型统一一个流量门限。部分典型值如下频段通道带宽上行流量(GB)上行业务信道利用率(%)2.6G/4.9G6410010.0602.6G/4.9G32604.260700M4302.050上行门限比下行低一个量级因为上行用户平均流量远小于下行资源利用率门限也整体偏低。这块在系统设计时要把下行表和上行表分开建模字段不一样不能共用一个规则函数。3. 按场景查表频段、通道数、带宽如何决定门限高低高负荷门限不是拍脑袋定的它有明显规律通道数越多越能扛带宽越大流量门限越高室分和微站门限普遍低于宏站700M单独成行。掌握规律后即使不背表也能快速判断一个站会不会超标。3.1 查表五步法频段→场景→通道→带宽→包类型实际操作中查表顺序可以固定成五步避免漏参数确认小区频段2.6G、4.9G还是700M。确认场景宏站、室分、微站是否属于高铁或地铁路线小区。确认通道数常见1TR、2TR、4TR、8TR、32TR、64TR。确认带宽100M、80M、60M700M固定30M。取小区包类型对应查流量、PRB、CCE门限。以下摘几行典型下行集团门限作为查表练习频段场景通道带宽大包流量(GB)大包PRB(%)中包流量(GB)中包PRB(%)小包流量(GB)小包PRB(%)CCE(%)2.6G宏站64100808070605050602.6G宏站3260368030602450602.6G室分2100257015501040504.9G宏站6410080808080808060微站410020702070207050注意4.9G那行大中小包的流量门限全部是80GBPRB全部是80%因为4.9G在标准里只有64TR宏站配置容量能力一致。微站那行流量门限也都是20GB不区分包类型但PRB和CCE仍然区分。查表时最忌讳用“上一行”的数据往下套每个交叉点都要回到标准原文。3.2 通道数和带宽对门限的影响64TR的门限凭什么比4TR高这么多通道数直接决定空分复用能力。64TR可以做更精细的波束赋形和多用户多输入多输出同一套频谱资源能同时服务更多用户所以它能承受更高的流量门限。2.6G宏站100M带宽大包门限64TR是80GB32TR是60GB8TR直接降到35GB。室分1TR只有15GB差异来自覆盖范围和天线能力的天壤之别。带宽的影响也直观。32TR、2.6G、大包100M门限60GB80M门限48GB60M门限36GB基本是等比缩放。这个比例关系可以用来校验数据有没有读错如果带宽60M却抄了100M的门限流量指标可能直接低一半。不过PRB门限不随带宽变100M、80M、60M都是同一套PRB门限因为PRB占用率本身就是相对比例和带宽绝对值无关。3.3 700M与微站的特殊性低频补覆盖微站不区分包类型700M只列了一条配置宏站4TR、30M带宽。下行大包流量门限只有8GBPRB门限70%CCE门限50%上行流量门限2.0GB上行业务信道利用率50%。低频段覆盖半径大、穿透强但频谱窄、容量小所以门限设计得比2.6G低很多。省内标准里700M的门限被单独上调过这一点到第四章再展开。微站4TR的流量门限也很有特点100M、80M、60M三种带宽下下行流量门限分别固定为20GB、16GB、12GB不按包类型区分。原因是微站覆盖范围小、接入用户少大包和小包在绝对流量上的差异不明显统一用一个门限反而好执行。实际按微站通道数识别设备时可以用到标准附录里的RRU类型清单华为AAU5241、AAU5245、RRU5266E中兴R9105 S26、R9115 M1826等这些都是4T4R设备支持4TR微站场景。4. 省内标准把用户数加进来高铁地铁单独立规则集团标准只考核流量加资源利用率省内标准在集团基础上增加了“RRC平均用户数/激活用户数”条件并把700M门限单独上调。实际优化执行以省内标准为准否则很容易被省公司审核通报为漏判。4.1 省内下行高负荷RRC平均用户数成为“一票否决”条件省内下行高负荷判定式变成三个条件同时满足下行流量 ≥ 门限 且PRB占用率 ≥ 门限 或 CCE占用率 ≥ 门限且 RRC平均用户数 ≥ 门限例如2.6G宏站32TR、60M带宽、大包小区下行流量≥36GB下行业务信道利用率≥80%或CCE利用率≥60%RRC平均用户数≥82个。与集团标准相比多了一个“RRC平均用户数≥82”的条件而且这个用户数条件是“一票否决”的不满足就不能算高负荷。为什么加用户数只盯流量和利用率会漏掉两类情况一类是少数大流量用户把资源占满用户数很少但感知可能还没崩另一类是用户数很多但流量不算高RRC连接本身已经形成压力。把用户数加进来后容量压力更接近真实情况。标准里还专门列了“激活用户数”列例如32TR 60M大包对应RRC平均用户数82、激活用户数30。RRC平均用户数包括处于连接态但可能暂无业务传输的用户激活用户数更贴近实际调度用户省公司注明“待基站版本升级后使用激活用户数”也就是说未来会切换到激活用户数口径。省内下行标准典型值摘录频段场景通道带宽包类型流量(GB)PRB(%)CCE(%)RRC平均用户数激活用户数2.6G宏站3260大36806082302.6G宏站3260中30606090332.6G宏站3260小2450609836700M宏站430大2870509129注意700M这行集团标准大包流量门限是8GB省内标准直接调高到28GBPRB门限仍是70%CCE门限50%。这就是文中开头说的“调整700M门限已固化在平台”的含义。实际建系统时要把集团标准和省内标准作为两个版本分开维护不然版本切换容易混乱。4.2 上行高负荷省内标准同样叠加用户数上行高负荷省内标准同样要叠加用户数条件上行流量 ≥ 门限 且 上行业务信道利用率 ≥ 门限 且 RRC平均用户数 ≥ 门限以2.6G/4.9G 32TR 60M为例上行流量≥4.2GB上行业务信道利用率≥60%RRC平均用户数≥82个三个条件同时满足才算上行高负荷。上行标准里RRC平均用户数不分包类型一行一个值不像下行那样按大中小包拆三列。取数时不要把下行的包类型字段带到上行规则里。4.3 高铁地铁从“容量门限”切换到“感知门限”高铁和地铁场景不套用普通宏站门限全部走单独规则。涉及路线小区、站台、候车室等场景按以下标准判断场景带宽RRC最大连接用户数上行感知速率下行感知速率高铁100M6000.5M 或5M高铁60M4000.5M 或5M地铁100M5001M 或5M地铁60M3001M 或5M判定逻辑是RRC最大连接用户数超过阈值且上行或下行感知速率低于阈值任一速率不达标即触发。这里的感知速率已经做过换算上行感知速率 上行用户平均速率(Mbps) / 8下行同理。除以8之后单位变成MB/s所以标准里写小于0.5M、5M、1M指的就是MB/s级别的字节速率。为什么高铁地铁不用流量门限高铁用户大进大出小区用户数在几分钟内剧烈波动15分钟平均流量根本体现不了瞬时拥塞RRC最大连接数能抓住瞬间峰值感知速率直接反映用户体验。实际运营中如果一个高铁小区同时也在城区覆盖范围内也要优先按高铁规则判断不能因为它流量不高就放过去。5. 避坑指南这些误判和错漏我全踩过标准读一百遍不如踩一次坑。以下几条来自实际网管核查和扩容审核中翻过车的地方按现象、原因、解决三个步骤写。5.1 判定逻辑和统计口径的坑坑1把“PRB利用率或CCE利用率”当成“PRB且CCE都要满足”。现象一个小区流量已经超标PRB利用率也超过门限但CCE只有40%有人判定它不够高负荷条件。原因把下行判定式里的“或”误读成“且”。解决严格按“流量≥门限 且PRB≥门限 或 CCE≥门限”执行只要PRB和CCE有一条达标即可。PRB和CCE代表不同资源域任何一个饱和都说明容量紧张。坑2用RRC最大连接用户数去套“RRC平均用户数”门限。现象网管报表里只导出了最大RRC连接数某小区最大连接数达到600平均用户数只有60套平均用户数门限82时直接误判为不达标。原因统计粒度不对最大连接数是瞬时峰值平均用户数是时间维度的均值两者没有可比性。解决从网管按15分钟粒度取RRC平均用户数如果部分老旧基站取不到平均值以激活用户数做参考但要在报告中标注口径。5.2 场景选择与频段外推的坑坑3高铁地铁小区按普通宏站门限审核。现象某高铁沿线100M小区高峰期RRC最大连接数超过700下行感知速率只有4MB/s如果按普通宏站查下行流量流量没到门限就会漏判。原因没有先识别“路线小区”属性直接进了普通宏站查表流程。解决在工参里维护场景标签凡是被标记为高铁、地铁、站台、候车室的小区一律走高铁地铁标准不再走流量门限流程。坑4把700M门限按带宽比例线性外推。现象有人拿2.6G 100M的门限按比例折算700M 30M推算出大包流量门限约24GB但省内标准是28GB结果把一批700M小区误判成高负荷。原因700M的干扰模型、覆盖半径和业务模型与2.6G差异很大门限是独立制定的。解决按标准表里700M那一行直接取值禁止跨频段插值省内标准如果已经调整过门限以最新固化的平台版本为准。5.3 数据包分类和取数的坑坑5漏算QoS flow切换入次数导致包类型算大。现象某小区总下行流量15000MBQoS flow建立成功次数5000次切换入次数3000次。如果只除以5000得到3MB判定为大包实际除以8000得到1.875MB属于中包。两种算法出来的门限完全不同流量和PRB门限都会变。原因公式分母是“建立成功次数切换入次数”切换入的流同样承载了流量。解决取数时同时查QoS flow建立成功计数器和切换入计数器两者相加做分母写SQL时要用COALESCE(null,0)把缺失值补成0避免漏加。6. 把标准固化成脚本批量筛选高负荷小区并排序扩容优先级一张张查表太慢我一般把标准表做成一个配置字典用脚本批量算。下面给一个简化版Python思路核心是“判定函数扩容优先级”照着能跑但生产环境需要接数据库。# 高负荷判定脚本输入小区指标输出判定结果与扩容优先级 RULES [ # 标准行结构频段,场景,通道,带宽,包类型,下行流量GB,PRB,CCE,RRC平均用户数 {band:2.6G,scene:宏站,chan:32,bw:60,pkt:大, dl_flow:36,prb:80,cce:60,rrc:82}, {band:2.6G,scene:宏站,chan:32,bw:60,pkt:中, dl_flow:30,prb:60,cce:60,rrc:90}, # 实际使用时把整个标准表按此结构录入下行和上行分两个表 ] def find_rule(band, scene, chan, bw, pkt): for r in RULES: if (r[band]band and r[scene]scene and r[chan]chan and r[bw]bw and r[pkt]pkt): return r return None def check_cell(c, rule): # c: 小区指标字典包含下行流量、PRB、CCE、RRC平均用户数 flow_ok c[dl_flow] rule[dl_flow] util_ok c[prb] rule[prb] or c[cce] rule[cce] user_ok c[rrc] rule[rrc] return flow_ok and util_ok and user_ok def priority(c, rule): score 0 if c[prb] rule[prb]: score 1 if c[cce] rule[cce]: score 1 if c[rrc] rule[rrc]: score 1 return score # 3分代表三个维度全部超限优先级最高 # 示例2.6G宏站32TR 60M大包小区 cell {dl_flow:40, prb:85, cce:55, rrc:100} rule find_rule(2.6G,宏站,32,60,大) if rule and check_cell(cell, rule): print(高负荷扩容优先级, priority(cell, rule)) else: print(非高负荷)这段脚本里RULES列表是标准表的程序化表达每行对应一个判定规则。find_rule按五要素定位规则行查不到返回None能避免用错规则。check_cell实现“流量且(PRB或CCE)且用户数”的联合判定。priority给了一个简单的扩容优先级满足三个维度越多越靠前如果分数相同再比较流量超出比例。实际使用时上行高负荷要单独建一个规则表字段换成上行流量、上行业务信道利用率和用户数高铁地铁场景则要单独写一个基于最大连接数和感知速率的判定函数。验证方法很重要拿三个历史已确认的高负荷小区和三个非高负荷小区回测让脚本跑一遍对照人工判定结果。我习惯把每个小区的流量、PRB、CCE、用户数与门限的差值打印出来这样对不上的时候能一眼看出差在哪个维度。标准每次更新都要把旧数据按新标准重跑一遍确认没有把已扩容小区漏掉也没有把新小区误加进来。从那以后我每次更新门限版本都会强制走一遍回归验证流程这个习惯帮我挡过好几次标准版本切换的翻车。希望帮到你。本文还有配套的精品资源点击获取
5G高负荷判定与扩容决策：流量、PRB、CCE及用户数联合分析
简介面向通信网络优化、无线运维与规划人员的5G高负荷判定标准技术文档系统定义了大、中、小数据包的划分依据并给出不同频段2.6G、4.9G、700M、不同场景宏站、室分、微站、高铁地铁等、不同通道数与带宽条件下的上行、下行高负荷判断阈值。内容在集团标准基础上结合省内固化要求进行细化下行高负荷需同时满足流量指标、业务/控制信道利用率以及RRC平均用户数后续版本将过渡为激活用户数要求上行高负荷则综合上行流量、上行业务信道利用率与用户数量共同判定针对高铁与地铁场景还设置了独立标准并附有支持微站的RRU设备类型及厂家清单。资源为1个docx文件压缩包大小213KB结构清晰适合用于网络容量评估、扩容决策、性能监控及优化策略制定。当前已有121人浏览学习通信工程师可直接对照阈值表识别高负荷小区并据此调整基站参数配置、资源调度策略提升用户体验。1. 5G高负荷判定不是看流量为什么必须“流量用户数资源利用率”三者联合前阵子处理一个2.6G频段32通道60M带宽的宏站单日下行流量冲到了38GB按“流量高就该扩容”的老思路早该下单加板卡了。但把这份5G高负荷标准翻出来它压根不够格PRB占用率不到55%RRC平均用户数只有40多三项条件差两项。真正识别5G高负荷不是单看流量而是把流量、上下行资源利用率和用户数联合起来按频段、场景、通道数、带宽、包类型去查门限。这篇笔记把这套标准里的判定逻辑、查表方法和省内差异拆开再给一个批量筛选的脚本思路适合通信网络工程师、5G无线优化人员和运营商运维在容量评估与扩容决策时直接落地。2. 先把口径理清大中小包划分与上下行高负荷的判定要素判定高负荷之前必须先统一两个口径包类型怎么算、上下行分别看哪些指标。很多人直接拿总流量去套门限结果包类型定错整个判定翻车。这一章把基础逻辑过一遍后面查表才不会错。2.1 大中小包怎么算每QoS流的平均流量是分界线大中小包的划分依据是“每QoS流平均流量”不是小区总流量也不是单用户流量。标准里的公式写得很清楚每QoS流流量 小区总流量 /QoS flow建立成功次数 QoS flow切换入次数分母要把切换入次数加进来是因为切换入的QoS流同样承载了用户数据。如果只除以建立成功次数分母偏小平均流量会被抬高中包可能被误判成大包最后套错门限。包类型边界如下包类型每QoS流流量小包小于1.5MB中包大于等于1.5MB且小于3MB大包大于等于3MB举个例子某小区时间粒度内总下行流量12000MBQoS flow建立成功次数6000次切换入次数2000次那么每QoS流流量 12000 / (6000 2000) 1.5MB。这个值落在“大于等于1.5MB”区间所以判定为中包而不是小包。实操中这个值取出来后要保留一位小数以上避免边界附近误判。为什么按包类型分门限因为大包用户单个流量大占用PRB资源多但控制信道占用相对少小包用户信令交互频繁CCE资源消耗占比高。如果所有包类型共用一套门限小包场景容易被漏判大包场景又可能被过度扩容。标准把下行流量、PRB占用率、CCE占用率都按大中小包拆开就是为了适应不同业务模型。2.2 下行高负荷判定业务信道利用率与控制信道利用率是“或”下行高负荷的集团标准是一个“且里面套着或”的结构下行流量达到门限并且下行业务信道利用率达到门限或者下行控制信道利用率达到门限。写成判定式就是下行高负荷 下行流量 ≥ 门限 且PRB占用率 ≥ 门限 或 PDCCH的CCE占用率 ≥ 门限注意这里业务信道和控制信道是“或”的关系不是“且”。原因是用户面数据信道和PDCCH控制信道任何一个资源饱和都会导致用户感知下降所以只要其中一个达到门限就算资源侧压力大。举标准里的原例2.6G频段、32TR、60M带宽小区业务类型为大包则需要满足下行流量≥36GB且下行业务信道利用率≥80%或者下行控制信道利用率≥60%。也就是说只要流量够了以后PRB到80%或者CCE到60%就触发下行高负荷。这里有一个容易看花眼的细节CCE占用率在标准表里是不分包类型的一列PRB占用率才分大中小包。以下摘几行集团下行标准做示例频段场景通道带宽大包流量(GB)中包流量(GB)小包流量(GB)PRB大/中/小(%)CCE(%)2.6G宏站6410080705080/60/50602.6G宏站326036302480/60/50602.6G室分210025151070/50/4050以第一行为例如果小区是大包下行流量到80GB且PRB到80%或CCE到60%就是下行高负荷如果是中包流量到70GB且PRB到60%或CCE到60%就是下行高负荷。读表时先定包类型再取对应数值。2.3 上行高负荷判定没有控制信道选项逻辑更简单上行高负荷的集团标准比下行少一个维度只看上行流量和上行业务信道利用率没有CCE这一项。判定式是上行高负荷 上行流量 ≥ 门限 且 上行业务信道利用率 ≥ 门限例如2.6G/4.9G频段32通道60M带宽小区上行流量≥4.2GB上行业务信道利用率≥60%即判定为上行高负荷。台内不考核上行控制信道是因为上行调度和功率控制机制与下行不同控制信道压力远没有下行显著。上行标准不分包类型统一一个流量门限。部分典型值如下频段通道带宽上行流量(GB)上行业务信道利用率(%)2.6G/4.9G6410010.0602.6G/4.9G32604.260700M4302.050上行门限比下行低一个量级因为上行用户平均流量远小于下行资源利用率门限也整体偏低。这块在系统设计时要把下行表和上行表分开建模字段不一样不能共用一个规则函数。3. 按场景查表频段、通道数、带宽如何决定门限高低高负荷门限不是拍脑袋定的它有明显规律通道数越多越能扛带宽越大流量门限越高室分和微站门限普遍低于宏站700M单独成行。掌握规律后即使不背表也能快速判断一个站会不会超标。3.1 查表五步法频段→场景→通道→带宽→包类型实际操作中查表顺序可以固定成五步避免漏参数确认小区频段2.6G、4.9G还是700M。确认场景宏站、室分、微站是否属于高铁或地铁路线小区。确认通道数常见1TR、2TR、4TR、8TR、32TR、64TR。确认带宽100M、80M、60M700M固定30M。取小区包类型对应查流量、PRB、CCE门限。以下摘几行典型下行集团门限作为查表练习频段场景通道带宽大包流量(GB)大包PRB(%)中包流量(GB)中包PRB(%)小包流量(GB)小包PRB(%)CCE(%)2.6G宏站64100808070605050602.6G宏站3260368030602450602.6G室分2100257015501040504.9G宏站6410080808080808060微站410020702070207050注意4.9G那行大中小包的流量门限全部是80GBPRB全部是80%因为4.9G在标准里只有64TR宏站配置容量能力一致。微站那行流量门限也都是20GB不区分包类型但PRB和CCE仍然区分。查表时最忌讳用“上一行”的数据往下套每个交叉点都要回到标准原文。3.2 通道数和带宽对门限的影响64TR的门限凭什么比4TR高这么多通道数直接决定空分复用能力。64TR可以做更精细的波束赋形和多用户多输入多输出同一套频谱资源能同时服务更多用户所以它能承受更高的流量门限。2.6G宏站100M带宽大包门限64TR是80GB32TR是60GB8TR直接降到35GB。室分1TR只有15GB差异来自覆盖范围和天线能力的天壤之别。带宽的影响也直观。32TR、2.6G、大包100M门限60GB80M门限48GB60M门限36GB基本是等比缩放。这个比例关系可以用来校验数据有没有读错如果带宽60M却抄了100M的门限流量指标可能直接低一半。不过PRB门限不随带宽变100M、80M、60M都是同一套PRB门限因为PRB占用率本身就是相对比例和带宽绝对值无关。3.3 700M与微站的特殊性低频补覆盖微站不区分包类型700M只列了一条配置宏站4TR、30M带宽。下行大包流量门限只有8GBPRB门限70%CCE门限50%上行流量门限2.0GB上行业务信道利用率50%。低频段覆盖半径大、穿透强但频谱窄、容量小所以门限设计得比2.6G低很多。省内标准里700M的门限被单独上调过这一点到第四章再展开。微站4TR的流量门限也很有特点100M、80M、60M三种带宽下下行流量门限分别固定为20GB、16GB、12GB不按包类型区分。原因是微站覆盖范围小、接入用户少大包和小包在绝对流量上的差异不明显统一用一个门限反而好执行。实际按微站通道数识别设备时可以用到标准附录里的RRU类型清单华为AAU5241、AAU5245、RRU5266E中兴R9105 S26、R9115 M1826等这些都是4T4R设备支持4TR微站场景。4. 省内标准把用户数加进来高铁地铁单独立规则集团标准只考核流量加资源利用率省内标准在集团基础上增加了“RRC平均用户数/激活用户数”条件并把700M门限单独上调。实际优化执行以省内标准为准否则很容易被省公司审核通报为漏判。4.1 省内下行高负荷RRC平均用户数成为“一票否决”条件省内下行高负荷判定式变成三个条件同时满足下行流量 ≥ 门限 且PRB占用率 ≥ 门限 或 CCE占用率 ≥ 门限且 RRC平均用户数 ≥ 门限例如2.6G宏站32TR、60M带宽、大包小区下行流量≥36GB下行业务信道利用率≥80%或CCE利用率≥60%RRC平均用户数≥82个。与集团标准相比多了一个“RRC平均用户数≥82”的条件而且这个用户数条件是“一票否决”的不满足就不能算高负荷。为什么加用户数只盯流量和利用率会漏掉两类情况一类是少数大流量用户把资源占满用户数很少但感知可能还没崩另一类是用户数很多但流量不算高RRC连接本身已经形成压力。把用户数加进来后容量压力更接近真实情况。标准里还专门列了“激活用户数”列例如32TR 60M大包对应RRC平均用户数82、激活用户数30。RRC平均用户数包括处于连接态但可能暂无业务传输的用户激活用户数更贴近实际调度用户省公司注明“待基站版本升级后使用激活用户数”也就是说未来会切换到激活用户数口径。省内下行标准典型值摘录频段场景通道带宽包类型流量(GB)PRB(%)CCE(%)RRC平均用户数激活用户数2.6G宏站3260大36806082302.6G宏站3260中30606090332.6G宏站3260小2450609836700M宏站430大2870509129注意700M这行集团标准大包流量门限是8GB省内标准直接调高到28GBPRB门限仍是70%CCE门限50%。这就是文中开头说的“调整700M门限已固化在平台”的含义。实际建系统时要把集团标准和省内标准作为两个版本分开维护不然版本切换容易混乱。4.2 上行高负荷省内标准同样叠加用户数上行高负荷省内标准同样要叠加用户数条件上行流量 ≥ 门限 且 上行业务信道利用率 ≥ 门限 且 RRC平均用户数 ≥ 门限以2.6G/4.9G 32TR 60M为例上行流量≥4.2GB上行业务信道利用率≥60%RRC平均用户数≥82个三个条件同时满足才算上行高负荷。上行标准里RRC平均用户数不分包类型一行一个值不像下行那样按大中小包拆三列。取数时不要把下行的包类型字段带到上行规则里。4.3 高铁地铁从“容量门限”切换到“感知门限”高铁和地铁场景不套用普通宏站门限全部走单独规则。涉及路线小区、站台、候车室等场景按以下标准判断场景带宽RRC最大连接用户数上行感知速率下行感知速率高铁100M6000.5M 或5M高铁60M4000.5M 或5M地铁100M5001M 或5M地铁60M3001M 或5M判定逻辑是RRC最大连接用户数超过阈值且上行或下行感知速率低于阈值任一速率不达标即触发。这里的感知速率已经做过换算上行感知速率 上行用户平均速率(Mbps) / 8下行同理。除以8之后单位变成MB/s所以标准里写小于0.5M、5M、1M指的就是MB/s级别的字节速率。为什么高铁地铁不用流量门限高铁用户大进大出小区用户数在几分钟内剧烈波动15分钟平均流量根本体现不了瞬时拥塞RRC最大连接数能抓住瞬间峰值感知速率直接反映用户体验。实际运营中如果一个高铁小区同时也在城区覆盖范围内也要优先按高铁规则判断不能因为它流量不高就放过去。5. 避坑指南这些误判和错漏我全踩过标准读一百遍不如踩一次坑。以下几条来自实际网管核查和扩容审核中翻过车的地方按现象、原因、解决三个步骤写。5.1 判定逻辑和统计口径的坑坑1把“PRB利用率或CCE利用率”当成“PRB且CCE都要满足”。现象一个小区流量已经超标PRB利用率也超过门限但CCE只有40%有人判定它不够高负荷条件。原因把下行判定式里的“或”误读成“且”。解决严格按“流量≥门限 且PRB≥门限 或 CCE≥门限”执行只要PRB和CCE有一条达标即可。PRB和CCE代表不同资源域任何一个饱和都说明容量紧张。坑2用RRC最大连接用户数去套“RRC平均用户数”门限。现象网管报表里只导出了最大RRC连接数某小区最大连接数达到600平均用户数只有60套平均用户数门限82时直接误判为不达标。原因统计粒度不对最大连接数是瞬时峰值平均用户数是时间维度的均值两者没有可比性。解决从网管按15分钟粒度取RRC平均用户数如果部分老旧基站取不到平均值以激活用户数做参考但要在报告中标注口径。5.2 场景选择与频段外推的坑坑3高铁地铁小区按普通宏站门限审核。现象某高铁沿线100M小区高峰期RRC最大连接数超过700下行感知速率只有4MB/s如果按普通宏站查下行流量流量没到门限就会漏判。原因没有先识别“路线小区”属性直接进了普通宏站查表流程。解决在工参里维护场景标签凡是被标记为高铁、地铁、站台、候车室的小区一律走高铁地铁标准不再走流量门限流程。坑4把700M门限按带宽比例线性外推。现象有人拿2.6G 100M的门限按比例折算700M 30M推算出大包流量门限约24GB但省内标准是28GB结果把一批700M小区误判成高负荷。原因700M的干扰模型、覆盖半径和业务模型与2.6G差异很大门限是独立制定的。解决按标准表里700M那一行直接取值禁止跨频段插值省内标准如果已经调整过门限以最新固化的平台版本为准。5.3 数据包分类和取数的坑坑5漏算QoS flow切换入次数导致包类型算大。现象某小区总下行流量15000MBQoS flow建立成功次数5000次切换入次数3000次。如果只除以5000得到3MB判定为大包实际除以8000得到1.875MB属于中包。两种算法出来的门限完全不同流量和PRB门限都会变。原因公式分母是“建立成功次数切换入次数”切换入的流同样承载了流量。解决取数时同时查QoS flow建立成功计数器和切换入计数器两者相加做分母写SQL时要用COALESCE(null,0)把缺失值补成0避免漏加。6. 把标准固化成脚本批量筛选高负荷小区并排序扩容优先级一张张查表太慢我一般把标准表做成一个配置字典用脚本批量算。下面给一个简化版Python思路核心是“判定函数扩容优先级”照着能跑但生产环境需要接数据库。# 高负荷判定脚本输入小区指标输出判定结果与扩容优先级 RULES [ # 标准行结构频段,场景,通道,带宽,包类型,下行流量GB,PRB,CCE,RRC平均用户数 {band:2.6G,scene:宏站,chan:32,bw:60,pkt:大, dl_flow:36,prb:80,cce:60,rrc:82}, {band:2.6G,scene:宏站,chan:32,bw:60,pkt:中, dl_flow:30,prb:60,cce:60,rrc:90}, # 实际使用时把整个标准表按此结构录入下行和上行分两个表 ] def find_rule(band, scene, chan, bw, pkt): for r in RULES: if (r[band]band and r[scene]scene and r[chan]chan and r[bw]bw and r[pkt]pkt): return r return None def check_cell(c, rule): # c: 小区指标字典包含下行流量、PRB、CCE、RRC平均用户数 flow_ok c[dl_flow] rule[dl_flow] util_ok c[prb] rule[prb] or c[cce] rule[cce] user_ok c[rrc] rule[rrc] return flow_ok and util_ok and user_ok def priority(c, rule): score 0 if c[prb] rule[prb]: score 1 if c[cce] rule[cce]: score 1 if c[rrc] rule[rrc]: score 1 return score # 3分代表三个维度全部超限优先级最高 # 示例2.6G宏站32TR 60M大包小区 cell {dl_flow:40, prb:85, cce:55, rrc:100} rule find_rule(2.6G,宏站,32,60,大) if rule and check_cell(cell, rule): print(高负荷扩容优先级, priority(cell, rule)) else: print(非高负荷)这段脚本里RULES列表是标准表的程序化表达每行对应一个判定规则。find_rule按五要素定位规则行查不到返回None能避免用错规则。check_cell实现“流量且(PRB或CCE)且用户数”的联合判定。priority给了一个简单的扩容优先级满足三个维度越多越靠前如果分数相同再比较流量超出比例。实际使用时上行高负荷要单独建一个规则表字段换成上行流量、上行业务信道利用率和用户数高铁地铁场景则要单独写一个基于最大连接数和感知速率的判定函数。验证方法很重要拿三个历史已确认的高负荷小区和三个非高负荷小区回测让脚本跑一遍对照人工判定结果。我习惯把每个小区的流量、PRB、CCE、用户数与门限的差值打印出来这样对不上的时候能一眼看出差在哪个维度。标准每次更新都要把旧数据按新标准重跑一遍确认没有把已扩容小区漏掉也没有把新小区误加进来。从那以后我每次更新门限版本都会强制走一遍回归验证流程这个习惯帮我挡过好几次标准版本切换的翻车。希望帮到你。本文还有配套的精品资源点击获取
