
1、总体思路
LTE网络扩容主要基于用户感知,受业务模型、用户速率、小区速率能力、用户数、PRB利用率、流量等因素的影响。
1、基于现网业务模型(在无线侧反应为”每RAB流量”),业务感知基线获得”用户保障速率”
2、“空口质量”(CQI)和”业务模型”(每RAB流量)共同决定”小区速率能力”(小区满载速率)
3、为了保证”用户速率”不低于”用户保障速率”,按照”小区速率能力”计算小区可承载的”用户数”或对应负荷的”PRB利用率”
4、基于”小区速率能力”和”PRB利用率”就可以计算小区在一定负荷下承载的”流量”
5、“用户速率下限”和相应的”小区流量上限”就是”感知和负荷”的平衡点,即:扩容门限
业务模型:IM:WEB:Streaming业务占比,映射为每RAB流量,即为简化的业务模型。
业务组成
| IM:WEB:Streaming | 业务场景 | 每RAB流量 |
| 50%:30%:20% | 小包业务 | <0.2MByte |
| 30%:50%:20% | 中包业务 | [0.2,1)MByte |
| 20%:30%:50% | 大包业务 | ≥1MByte |
| 业务场景业务模型 | 场景特征 | 用户速率 | 流量 | KPI | 频谱效率 | 用户数 | 信道利用率 | 受限场景/信道(指标) | 扩容门限建议 | 提升建议 |
| 大包业务场景每RAB流量>1MB | 速率敏感型 | √ | √ | - | √ | √ | √ | 1.用户速率 2.流量 3.频谱效率 | 用户速率 | 1.频谱效率低:通过空口优化和加站解决; 2.业务需求高:进行载波扩容 |
| 中包业务场景每RAB流量[0.2,1]MB | 速率敏感型 | √ | √ | - | √ | - | √ | 1.用户速率 2.流量 3.频谱效率 | 用户速率 | 1.频谱效率低:通过空口优化和加站解决; 2.业务需求高:进行载波扩容; 3、用户数过载:小区或载波扩容 |
| 小包业务场景每RAB流量<0.2MB | KPI敏感性 | - | - | √ | √ | √ | - | 1.用户数 2.KPI | 用户数>P3 | 1.用户数过载:小区或载波扩容; 2.KPI低于基线:通过空口质量提升(例如RF优化,小区)手段解决 |
扩容标准基线数据源
用户保障速率
简化的业务模型映射用户保障速率,小包场景:2.8Mbps中包场景:3.5Mbps大包场景:5Mbps
业务组成
| IM:WEB:Streaming | 业务场景 | 每RAB流量 | 业务占空比 | 用户保障速率 |
| 50%:30%:20% | 小包业务 | <0.2MByte | 1%~2% | 2.8mps |
| 30%:50%:20% | 中包业务 | [0.2,1)MByte | 2%~6% | 3.5mps |
| 20%:30%:50% | 大包业务 | ≥1MByte | 10%~20% | 5mps |
室分小区CQI优于宏站,室分小区速率能力30mbps,宏站小区20mbps
PRB利用率
按照不同场景的用户保障速率确认对应的用户感知拥塞门限
| 业务场景 | 保障速率 | PRB利用率门限 |
| 大包 | 5mbps | 32% |
| 中包 | 3.5mbps | 34% |
| 小包 | 2.8mbps | 40% |
针对大中包场景,用户数受限之前就会出现感知受限,因此主要针对小包业务进行用户数讨论
小区平均连接用户数超过100,由于空口质量变差呼叫成功率和掉线率变差,小区平均连接用户数超过200,空口资源拥塞导致接入失败剧增。
流量
根据下行PRB利用率-流量曲线得出中大包的扩容门限为3GB
业务组成
| IM:WEB:Streaming | 业务场景 | 用户保障速率 | 小区速率能力(CQI=9) | 在线用户数 | PRB利用率 | 流量(MB) |
| 50%:30%:20% | 小包业务 | 2.8mps | 20 | 100 | 40% | 3600 |
| 30%:50%:20% | 中包业务 | 3.5mps | 20 | - | 34% | 3060 |
| 20%:30%:50% | 大包业务 | 5mps | 20 | - | 32% | 2880 |
按照不同业务场景基于“用户体验”和“网络性能”进行容量评估:
(1)大包、中包业务场景基于“流量”进行扩容评估
(2)小包业务场景基于“用户数”进行扩容评估
(3)“小区速率能力”(频谱效率)是区分“空口质量问题”和“容量问题”的关键
3、现网数据验证
提取洛阳4月5/6/7三天的数据,提取相关评估指标进行扩容分析:
| 指标ID | 指标 | 指标描述 |
| 1526727378 | L.Traffic.User.Avg | 小区内的平均用户数 |
| 1526727379 | L.Traffic.User.Max | 小区内的最大用户数 |
| 1526728261 | L.Thrp.bits.DL | 小区PDCP层所发送的下行数据的总吞吐量 |
| 1526728259 | L.Thrp.bits.UL | 小区PDCP层所接收到的上行数据的总吞吐量 |
| 1526728262 | L.Thrp.Time.DL | 小区PDCP层所发送的下行数据的总时长 |
| 1526728260 | L.Thrp.Time.UL | 小区PDCP层所接收到的上行数据的总时长 |
| 15267297 | L.Thrp.Time.Cell.DL.HighPrecision | 小区下行有数据传输总时长(1ms精度) |
| 15267298 | L.Thrp.Time.Cell.UL.HighPrecision | 小区上行有数据传输总时长(1ms精度) |
| 1526726740 | L.ChMeas.PRB.DL.Used.Avg | PDSCH PRB资源使用的平均个数 |
| 1526726737 | L.ChMeas.PRB.UL.Used.Avg | 上行PRB资源使用的平均个数 |
| 1526728762 | L.ChMeas.PRB.UL.DrbUsed.Avg | PUSCH DRB的PRB资源使用个数 |
| 1526728763 | L.ChMeas.PRB.DL.DrbUsed.Avg | PDSCH DRB的PRB资源使用的平均个数 |
| 1526728433 | L.ChMeas.PRB.DL.Avail | 下行可用的PRB个数 |
| 1526728434 | L.ChMeas.PRB.UL.Avail | 上行可用的PRB个数 |
洛阳数据分析概况(小区自忙时数据分析结果)
场景分布情况:
| 场景 | 5号 | 6号 | 7号 | |||
| 大包(每PRB流量大于1M) | 9270 | 84.46% | 9165 | 83.20% | 9016 | 81.14% |
| 小包(每PRB流量小于0.2M) | 503 | 4.58% | 569 | 5.17% | 659 | 5.93% |
| 中包(每PRB流量0.2~1M) | 1202 | 10.95% | 1281 | 11.63% | 1437 | 12.93% |
小区速率情况统计:
| 5号 | 6号 | 7号 | |
| 大于20M小区 | 2557 | 2673 | 2505 |
| 总小区 | 10975 | 11015 | 11112 |
| 占比 | 23.30% | 24.27% | 22.54% |
用户速率情况统计:
| 5号 | 6号 | 7号 | |
| 小于3.5M小区 | 170 | 199 | 242 |
| 总小区 | 10975 | 11015 | 11112 |
| 占比 | 1.55% | 1.81% | 2.18% |
根据小区速率和用户速率计算公式,结合现网数据结果,两者成正比关系,同时满足小区速率大于20M,用户速率小于3.5M的小区不存在。
PRB利用率(下行)
| 5号 | 6号 | 7号 | |
| 大于35%小区 | 33 | 27 | 27 |
| 总小区 | 10975 | 11015 | 11112 |
| 占比 | 0.30% | 0.25% | 0.24% |
流量
| 5号 | 6号 | 7号 | |
| 大于3G小区 | 1668 | 1615 | 1503 |
| 总小区 | 10975 | 11015 | 11112 |
| 占比 | 15.20% | 14.66% | 13.53% |
用户数
| 5号 | 6号 | 7号 | |
| 大于100小区 | 48 | 36 | 25 |
| 总小区 | 10975 | 11015 | 11112 |
| 占比 | 0.44% | 0.33% | 0.22% |
集团高负荷待扩容评估标准
当小区满足以下任一条件时,则符合“高负荷待扩容”条件:
条件一:在系统忙时,上行PRB平均利用率或下行PRB平均利用率大于50%,且有效RRC连接平均数大于30,且小区忙时吞吐量大于门限(上行1G、下行5G任一)时;
条件二:当有效RRC连接最大数大于200时。
