简介这是一份面向通信行业管理及技术人员的专业课件系统讲解如何利用大数据技术开展家庭宽带整体规划。课件围绕计划、网络、市场、财务、客服等多部门需求梳理了宽带发展成本监控缺失、资费欺诈识别难、客户价值提升困难等突出问题并给出从数据接入、能力封装到平台应用的完整技术架构。内容涵盖接入层网元信息标准化、物理小区映射、宽带战略地图构建以及网络质量偏离度模型、扩容预警、投诉归集分析等具体方案可帮助读者理解跨部门协作下的宽带规划方法论。资源为1个pptx文件共27页压缩包大小约2.3MB已有92人学习浏览适用于运营商、通信规划设计人员及大数据相关专业师生的课程参考与方案设计。1. 大数据进入家宽总规的第一张图先讲一个反直觉的案例某小区年初按人口密度预测新增1000户按传统经验系数扩容了分光器半年后开通率不到30%而一街之隔的老小区因为“初步够用”没立项投诉翻了倍。这种故事在家庭宽带总体规划里很常见根源不是设计能力不足而是规划依据太粗——用整片城区的人口增长率代替楼栋级真实需求用历史装机均值代替忙时流量曲线。大数据应用要做的是把网管、CRM、装维工单里已经存在的数据变成“楼栋维度需求预测”和“容量投资排序表”让分光比、OLT位置、上联带宽这些物理网络参数真正跟着用户行为走。本篇围绕这类PPT课件要交付的主线展开覆盖数据源、建模、落地和验证适合网规网优、宽带运营和规划支撑的工程师。2. 先定数据家宽规划的大数据源与采集链路家庭宽带总规的多数翻车点不在算法而在数据“拿不到、拿不准、对不齐”。规划型大数据应用和实时风控不一样它不追求毫秒级响应但要求所有历史数据在同一个坐标系下可比。所以第一步不是建模型而是把可用数据源画成一张清单再决定采集频率和数据平台形态。2.1 数据源清单课件里最有含金量的一张表一张完整的数据源表应该同时写清楚来源系统、关键字段和在规划中的作用而不是只堆系统名称。我一般会把数据分成网络、用户、体验、空间四类数据域来源系统关键字段在总规中的作用网络拓扑OLT网管/资源系统OLT名称、PON口、分光器层级、ONU注册状态还原存量光路覆盖范围定位可复用端口流量性能网管/流量采集平台PON口忙时峰值速率、上联口利用率、带宽占用率判断容量饱和度识别隐藏拥塞点用户经营CRM/BSS开户时间、退网时间、当前套餐速率、在网状态计算净增趋势预测未来开通规模服务质量OSS/客服工单光衰告警、弱光投诉、阻断工单、处理时长定位质差网格补充需求热力空间地理GIS/房产测绘楼栋坐标、层数、户数、建成年代把网络指标落到物理位置做网格划分没有GIS数据的团队可以先用装维地址库做楼栋匹配没有工单数据的可以先用光衰告警替代但要在规划报告里标注该维度的置信度。这张表本身可以作为课件里“数据基础”章节的目录页每一行展开就是一小节内容。2.2 采集链路怎么调通从设备接口到数据平台不同厂家的家宽设备开放能力差异很大常见做法是走厂商网管的北向接口或直接对接资源管理系统。对OLT这类慢变量设备每天同步一次拓扑和注册信息即可对PON口流量这类周期数据建议按小时采集保留近24个月原始数据否则忙时特征会被日均值抹平。采集脚本最容易犯的性能错误是写一个逐PON口循环去查网管接口导致大量短连接请求形成典型的N1问题。正确的写法是先分页拉取OLT设备列表再按设备ID二次拉取PON口详情单台请求数从几百次降到几次import requests from requests.adapters import HTTPAdapter session requests.Session() session.mount(https://, HTTPAdapter(max_retries2)) offset 0 page_size 50 olt_devices [] # 按分页批量获取整网OLT避免单设备逐个请求造成N1 while True: resp session.get( https://ngbss-server/api/v2/olt/devices, params{limit: page_size, offset: offset, fields: id,name,pon_count}, timeout5, ).json() batch resp.get(data, []) olt_devices.extend(batch) if len(batch) page_size: break offset page_size # 再按OLT批量拉PON口状态仍走分页 for dev in olt_devices: resp session.get( fhttps://ngbss-server/api/v2/olt/{dev[id]}/pon-ports, params{limit: 200, offset: 0}, timeout5, ).json() # 写入本地缓冲表落库时统一加时间戳这段代码里的关键点有三个一是limit和offset分页适合大多数REST风格接口遇到不支持分页的厂商要改成按端口索引遍历二是对每个OLT发起二次请求但不再是每个PON口发起一次三是采集任务写完后要加失败重试和增量时间戳避免断点后全量重采。2.3 数据入仓与质量处理数据落地选型上我一般建议优先用列式存储或带GIS扩展的关系库比如ClickHouse或PostgreSQL加PostGIS。家庭宽带规划的数据量级在几千万行到几亿行之间维度稳定、聚合模式固定完全不需要为了这个场景单独扩展大数据集群。如果企业已有大数据平台把流量明细进Hive也自然但要注意分区策略按“省份月”切避免小文件过多。真正耗时的是质量清洗同一个小区在CRM里叫“金色家园”在工单里叫“金色嘉园”在GIS里叫“金桂花园”三套系统对不上楼栋ID聚类结果就会漂移。常见做法是维护一张统一楼栋字典以GIS围栏结果为主键再把CRM和OSS的地址字串按“小区名楼栋号”做模糊匹配。清洗规则写成SQL或Python脚本后建议在课件里放一张“清洗前后样例对比”的表让读者直观看到多源数据对齐的意义。提示数据质量版本要和规划版本绑定。每次总规迭代都应在数据仓库里保留一份当时使用的清洗后快照否则三个月后无法复算指标验证环节就会失去锚点。3. 用Python做需求聚类和增长预测数据就绪后进入模型部分。家宽总规中“需求”不是一个单一数值而是包含用户规模、带宽水平、增长趋势的复合体。先把网格变成特征行再聚类最后做忙时峰值预测这是课件里最顺的教学路径。3.1 特征把网格变成一行行数字网格划分建议结合物理覆盖来定一个光交箱覆盖范围大约300到500户比纯行政社区更贴近网络边界。每个网格提取如下特征特征字段口径说明示例值house_num网格内住宅户数来自GIS或房产数据320account_num当前在用宽带账号数来自CRM198port_occupied_rate已占用PON端口占比反映存量占用0.62peak_bandwidth_gbps忙时PON口聚合峰值取近30天P953.8high_pkg_ratio500M及以上套餐用户占比0.31complaint_rate每千户月均投诉工单量4.2这里的高价值特征其实是peak_bandwidth_gbps因为其他字段解决的是“有没有用户”忙时流量解决的是“用户到底用不用”。很多课件会把平均流量当月均值这是不对的带宽规划看的是忙时瞬时压力均值会掩盖装满端口。3.2 聚类把区域分成热、温、冷三类用KMeans把特征聚成4类即可类别太多对投资排序没有意义。聚类前必须做标准化因为不同特征量纲差异太大否则house_num会主导距离计算import pandas as pd from sklearn.preprocessing import StandardScaler from sklearn.cluster import KMeans df pd.read_csv(grid_demand.csv) feature_cols [ house_num, port_occupied_rate, peak_bandwidth_gbps, high_pkg_ratio, complaint_rate, ] X StandardScaler().fit_transform(df[feature_cols]) km KMeans(n_clusters4, random_state42, n_init10) df[cluster] km.fit_predict(X)n_init10是让KMeans从10个不同初始点开始迭代取最优结果避免落入局部最优。选k时不用太依赖肘部法则直接看聚类结果的业务可解释性比如高占用率高增长是一类低占用率低增长是一类能讲清楚就是合理的。聚类结果要映射成动作例如高占用率加高增长类网格优先扩容高占用率但低增长类只做端口调配低占用率高投诉类则优先查光衰而非新建。课件在这一页放一个“聚类结果落到地图”的特写比放算法讲解更有说服力。3.3 对总规起作用的不是均值是忙时趋势聚类给了空间维度需求还要给时间维度增长。取每个PON口近12到24个月的忙时峰值带宽按月聚合后做对数线性回归预测未来12个月的忙时峰值。课件演示往往可以带一段这样的代码import numpy as np from sklearn.linear_model import LinearRegression # monthly_peak: 按月排列的忙时峰值带宽值单位 Gbps monthly_peak np.array([2.1, 2.3, 2.5, 2.8, 3.0, 3.3, 3.6, 3.8, 4.1, 4.4, 4.7, 5.1]) t np.arange(len(monthly_peak)).reshape(-1, 1) model LinearRegression().fit(t, np.log(monthly_peak)) next_peak float(np.exp(model.predict([[len(monthly_peak)]]))) growth_12m next_peak / monthly_peak[-1] - 1 print(f预测下一年忙时峰值 {next_peak:.1f} Gbps年增幅 {growth_12m:.0%})对峰值取对数再拟合是把“按百分比稳定增长”的假设线性化因为带宽增长通常是指数形态而不是线性形态。growth_12m可以当作该网格的年需求增长率用于后续容量计算。实际数据如果出现明显拐点比如新开通大型园区造成的跳变应把跳变点之后的月份重新建模而不是硬套全序列。4. 从预测到家庭宽带总规分光比、容量和投资排序预测结果要变成网络设备的参数才有价值。这一章是课件后半部分的主体也是和传统规划方法论交汇的地方核心是三个决策分光比怎么选、OLT上联带宽怎么算、建设优先级怎么排。4.1 把需求换算成分光比分光比决定了1个PON口下面挂多少个ONU直接影响单用户可用带宽和端口利用率。常见做法是按下表选择分光比单PON口带宽池适用场景1:16高高档小区、大带宽套餐占比高、预测并发率高的区域1:32中常规FTTH家庭宽带最常用的开局方案1:64低低渗透率区域、农村用户、并发比低的场景分光比和覆盖能力不是简单的“越多越好”1:64在GPON下虽然能覆盖更多户但单户可用带宽被摊薄一旦出现视频直播类高并发业务容量立即吃紧。规划时用这个简单的容量公式估算PON口数量import math users 720 # 规划期末预计开通户数 avg_plan 300 # 户均签约带宽 Mbps concurrent 0.25 # 忙时并发系数 redundancy 1.2 # 冗余系数 pon_port_cap 10000 # 10G-PON单口标称带宽 Mbps aggregated users * avg_plan * concurrent * redundancy port_count math.ceil(aggregated / pon_port_cap) print(f忙时聚合带宽需求 {aggregated/1000:.1f} Gbps) print(f建议配置 {port_count} 个具备 10G 能力的PON口)忙时并发系数按用户套餐分布来取低于100M套餐的取0.15到0.2200M到500M取0.2到0.3千兆用户取0.3到0.4。冗余系数1.2是给突发流量留的余量如果该片区有明确的大规模直播或云游戏需求可以提高到1.5。这里算出的PON口数量是容量侧约束最终规划还要叠加覆盖侧约束两者取大值。4.2 OLT和上联带宽怎么配OLT上联带宽是家宽总规里最容易低估的一层。很多人只看PON口数量忽略上联口瓶颈。上联带宽核算逻辑和PON口一样公式为上联带宽 开通用户数 × 户均签约速率 × 忙时并发系数 × 收敛系数。举个例子某OLT覆盖1200户规划期末预计开通900户户均套餐速率250M忙时并发系数0.25则900×250×0.2556.25Gbps。考虑1.3倍峰值冗余约需要73Gbps配置8个10G上联口比较稳妥同时预留2个端口做负载保护。如果现网设备只有千兆上联就要在规划报告里单独列“上联扩容”条目否则即使分光比合理用户感知依然会因为上联拥塞而劣化。4.3 把规划产出落成一图一表总规最终交付物应包括网格需求等级图、PON口缺口清单、分光器更换清单、OLT上联扩容建议和投资排序表。课件通常会把这五项归纳成三层逻辑资源层做端口盘点网络层做PON口和上联扩容投资层按“需求等级高、缺口大、单位投资效益高”排序。投资优先级建议用“需求紧迫度”而非“缺口绝对值”来排。一个1000户网格缺口30个端口和一个200户网格缺口15个端口前者缺口绝对值更大但后者缺口占比75%用户已开始受拥塞影响理应先立项。排序公式可以写成优先级得分 0.4×端口占用率 0.3×忙时带宽增幅 0.3×投诉率用这个得分对整个候选清单做降序排列。5. 规划后验证用90天数据校核预测准确率总规交付不等于结束规划模型必须在下一轮迭代前做一次回测。最直接的做法是取规划报告发布前的历史数据作为训练集预测最近90天的忙时峰值再和真实采集值对比偏差控制在正负30%以内算模型可用超过则回看是哪项参数失真。回测关注两个指标一是峰值带宽偏差率公式为实际忙时峰值-预测忙时峰值/预测忙时峰值二是端口占用预测偏差重点看预测高于实际的“过热网格”这通常意味着并发系数或渗透率假设偏大。90天内若实际值连续两月低于预测值20%以上就把该网格状态从“待扩容”改为“观察”避免投资浪费。最后给一个可视化校验技巧。用ECharts做一个按PON口聚合的容量热力地图把“端口占用率”和“忙时峰值带宽”放在同一个地图的两个图层上设置三档图例绿色代表占用率低于40%黄色代表40%到70%红色代表高于70%。这样一眼就能看出预测热度高的网格到底是“端口装满了”还是“流量已经超标”两者对应的整改动作完全不同。课件里如果能用一段真实打码数据演示这个地图读者对“大数据驱动总规”的理解会比任何公式都直观。本文还有配套的精品资源点击获取 大数据驱动家庭宽带总体规划：从数据源到容量投资排序
简介这是一份面向通信行业管理及技术人员的专业课件系统讲解如何利用大数据技术开展家庭宽带整体规划。课件围绕计划、网络、市场、财务、客服等多部门需求梳理了宽带发展成本监控缺失、资费欺诈识别难、客户价值提升困难等突出问题并给出从数据接入、能力封装到平台应用的完整技术架构。内容涵盖接入层网元信息标准化、物理小区映射、宽带战略地图构建以及网络质量偏离度模型、扩容预警、投诉归集分析等具体方案可帮助读者理解跨部门协作下的宽带规划方法论。资源为1个pptx文件共27页压缩包大小约2.3MB已有92人学习浏览适用于运营商、通信规划设计人员及大数据相关专业师生的课程参考与方案设计。1. 大数据进入家宽总规的第一张图先讲一个反直觉的案例某小区年初按人口密度预测新增1000户按传统经验系数扩容了分光器半年后开通率不到30%而一街之隔的老小区因为“初步够用”没立项投诉翻了倍。这种故事在家庭宽带总体规划里很常见根源不是设计能力不足而是规划依据太粗——用整片城区的人口增长率代替楼栋级真实需求用历史装机均值代替忙时流量曲线。大数据应用要做的是把网管、CRM、装维工单里已经存在的数据变成“楼栋维度需求预测”和“容量投资排序表”让分光比、OLT位置、上联带宽这些物理网络参数真正跟着用户行为走。本篇围绕这类PPT课件要交付的主线展开覆盖数据源、建模、落地和验证适合网规网优、宽带运营和规划支撑的工程师。2. 先定数据家宽规划的大数据源与采集链路家庭宽带总规的多数翻车点不在算法而在数据“拿不到、拿不准、对不齐”。规划型大数据应用和实时风控不一样它不追求毫秒级响应但要求所有历史数据在同一个坐标系下可比。所以第一步不是建模型而是把可用数据源画成一张清单再决定采集频率和数据平台形态。2.1 数据源清单课件里最有含金量的一张表一张完整的数据源表应该同时写清楚来源系统、关键字段和在规划中的作用而不是只堆系统名称。我一般会把数据分成网络、用户、体验、空间四类数据域来源系统关键字段在总规中的作用网络拓扑OLT网管/资源系统OLT名称、PON口、分光器层级、ONU注册状态还原存量光路覆盖范围定位可复用端口流量性能网管/流量采集平台PON口忙时峰值速率、上联口利用率、带宽占用率判断容量饱和度识别隐藏拥塞点用户经营CRM/BSS开户时间、退网时间、当前套餐速率、在网状态计算净增趋势预测未来开通规模服务质量OSS/客服工单光衰告警、弱光投诉、阻断工单、处理时长定位质差网格补充需求热力空间地理GIS/房产测绘楼栋坐标、层数、户数、建成年代把网络指标落到物理位置做网格划分没有GIS数据的团队可以先用装维地址库做楼栋匹配没有工单数据的可以先用光衰告警替代但要在规划报告里标注该维度的置信度。这张表本身可以作为课件里“数据基础”章节的目录页每一行展开就是一小节内容。2.2 采集链路怎么调通从设备接口到数据平台不同厂家的家宽设备开放能力差异很大常见做法是走厂商网管的北向接口或直接对接资源管理系统。对OLT这类慢变量设备每天同步一次拓扑和注册信息即可对PON口流量这类周期数据建议按小时采集保留近24个月原始数据否则忙时特征会被日均值抹平。采集脚本最容易犯的性能错误是写一个逐PON口循环去查网管接口导致大量短连接请求形成典型的N1问题。正确的写法是先分页拉取OLT设备列表再按设备ID二次拉取PON口详情单台请求数从几百次降到几次import requests from requests.adapters import HTTPAdapter session requests.Session() session.mount(https://, HTTPAdapter(max_retries2)) offset 0 page_size 50 olt_devices [] # 按分页批量获取整网OLT避免单设备逐个请求造成N1 while True: resp session.get( https://ngbss-server/api/v2/olt/devices, params{limit: page_size, offset: offset, fields: id,name,pon_count}, timeout5, ).json() batch resp.get(data, []) olt_devices.extend(batch) if len(batch) page_size: break offset page_size # 再按OLT批量拉PON口状态仍走分页 for dev in olt_devices: resp session.get( fhttps://ngbss-server/api/v2/olt/{dev[id]}/pon-ports, params{limit: 200, offset: 0}, timeout5, ).json() # 写入本地缓冲表落库时统一加时间戳这段代码里的关键点有三个一是limit和offset分页适合大多数REST风格接口遇到不支持分页的厂商要改成按端口索引遍历二是对每个OLT发起二次请求但不再是每个PON口发起一次三是采集任务写完后要加失败重试和增量时间戳避免断点后全量重采。2.3 数据入仓与质量处理数据落地选型上我一般建议优先用列式存储或带GIS扩展的关系库比如ClickHouse或PostgreSQL加PostGIS。家庭宽带规划的数据量级在几千万行到几亿行之间维度稳定、聚合模式固定完全不需要为了这个场景单独扩展大数据集群。如果企业已有大数据平台把流量明细进Hive也自然但要注意分区策略按“省份月”切避免小文件过多。真正耗时的是质量清洗同一个小区在CRM里叫“金色家园”在工单里叫“金色嘉园”在GIS里叫“金桂花园”三套系统对不上楼栋ID聚类结果就会漂移。常见做法是维护一张统一楼栋字典以GIS围栏结果为主键再把CRM和OSS的地址字串按“小区名楼栋号”做模糊匹配。清洗规则写成SQL或Python脚本后建议在课件里放一张“清洗前后样例对比”的表让读者直观看到多源数据对齐的意义。提示数据质量版本要和规划版本绑定。每次总规迭代都应在数据仓库里保留一份当时使用的清洗后快照否则三个月后无法复算指标验证环节就会失去锚点。3. 用Python做需求聚类和增长预测数据就绪后进入模型部分。家宽总规中“需求”不是一个单一数值而是包含用户规模、带宽水平、增长趋势的复合体。先把网格变成特征行再聚类最后做忙时峰值预测这是课件里最顺的教学路径。3.1 特征把网格变成一行行数字网格划分建议结合物理覆盖来定一个光交箱覆盖范围大约300到500户比纯行政社区更贴近网络边界。每个网格提取如下特征特征字段口径说明示例值house_num网格内住宅户数来自GIS或房产数据320account_num当前在用宽带账号数来自CRM198port_occupied_rate已占用PON端口占比反映存量占用0.62peak_bandwidth_gbps忙时PON口聚合峰值取近30天P953.8high_pkg_ratio500M及以上套餐用户占比0.31complaint_rate每千户月均投诉工单量4.2这里的高价值特征其实是peak_bandwidth_gbps因为其他字段解决的是“有没有用户”忙时流量解决的是“用户到底用不用”。很多课件会把平均流量当月均值这是不对的带宽规划看的是忙时瞬时压力均值会掩盖装满端口。3.2 聚类把区域分成热、温、冷三类用KMeans把特征聚成4类即可类别太多对投资排序没有意义。聚类前必须做标准化因为不同特征量纲差异太大否则house_num会主导距离计算import pandas as pd from sklearn.preprocessing import StandardScaler from sklearn.cluster import KMeans df pd.read_csv(grid_demand.csv) feature_cols [ house_num, port_occupied_rate, peak_bandwidth_gbps, high_pkg_ratio, complaint_rate, ] X StandardScaler().fit_transform(df[feature_cols]) km KMeans(n_clusters4, random_state42, n_init10) df[cluster] km.fit_predict(X)n_init10是让KMeans从10个不同初始点开始迭代取最优结果避免落入局部最优。选k时不用太依赖肘部法则直接看聚类结果的业务可解释性比如高占用率高增长是一类低占用率低增长是一类能讲清楚就是合理的。聚类结果要映射成动作例如高占用率加高增长类网格优先扩容高占用率但低增长类只做端口调配低占用率高投诉类则优先查光衰而非新建。课件在这一页放一个“聚类结果落到地图”的特写比放算法讲解更有说服力。3.3 对总规起作用的不是均值是忙时趋势聚类给了空间维度需求还要给时间维度增长。取每个PON口近12到24个月的忙时峰值带宽按月聚合后做对数线性回归预测未来12个月的忙时峰值。课件演示往往可以带一段这样的代码import numpy as np from sklearn.linear_model import LinearRegression # monthly_peak: 按月排列的忙时峰值带宽值单位 Gbps monthly_peak np.array([2.1, 2.3, 2.5, 2.8, 3.0, 3.3, 3.6, 3.8, 4.1, 4.4, 4.7, 5.1]) t np.arange(len(monthly_peak)).reshape(-1, 1) model LinearRegression().fit(t, np.log(monthly_peak)) next_peak float(np.exp(model.predict([[len(monthly_peak)]]))) growth_12m next_peak / monthly_peak[-1] - 1 print(f预测下一年忙时峰值 {next_peak:.1f} Gbps年增幅 {growth_12m:.0%})对峰值取对数再拟合是把“按百分比稳定增长”的假设线性化因为带宽增长通常是指数形态而不是线性形态。growth_12m可以当作该网格的年需求增长率用于后续容量计算。实际数据如果出现明显拐点比如新开通大型园区造成的跳变应把跳变点之后的月份重新建模而不是硬套全序列。4. 从预测到家庭宽带总规分光比、容量和投资排序预测结果要变成网络设备的参数才有价值。这一章是课件后半部分的主体也是和传统规划方法论交汇的地方核心是三个决策分光比怎么选、OLT上联带宽怎么算、建设优先级怎么排。4.1 把需求换算成分光比分光比决定了1个PON口下面挂多少个ONU直接影响单用户可用带宽和端口利用率。常见做法是按下表选择分光比单PON口带宽池适用场景1:16高高档小区、大带宽套餐占比高、预测并发率高的区域1:32中常规FTTH家庭宽带最常用的开局方案1:64低低渗透率区域、农村用户、并发比低的场景分光比和覆盖能力不是简单的“越多越好”1:64在GPON下虽然能覆盖更多户但单户可用带宽被摊薄一旦出现视频直播类高并发业务容量立即吃紧。规划时用这个简单的容量公式估算PON口数量import math users 720 # 规划期末预计开通户数 avg_plan 300 # 户均签约带宽 Mbps concurrent 0.25 # 忙时并发系数 redundancy 1.2 # 冗余系数 pon_port_cap 10000 # 10G-PON单口标称带宽 Mbps aggregated users * avg_plan * concurrent * redundancy port_count math.ceil(aggregated / pon_port_cap) print(f忙时聚合带宽需求 {aggregated/1000:.1f} Gbps) print(f建议配置 {port_count} 个具备 10G 能力的PON口)忙时并发系数按用户套餐分布来取低于100M套餐的取0.15到0.2200M到500M取0.2到0.3千兆用户取0.3到0.4。冗余系数1.2是给突发流量留的余量如果该片区有明确的大规模直播或云游戏需求可以提高到1.5。这里算出的PON口数量是容量侧约束最终规划还要叠加覆盖侧约束两者取大值。4.2 OLT和上联带宽怎么配OLT上联带宽是家宽总规里最容易低估的一层。很多人只看PON口数量忽略上联口瓶颈。上联带宽核算逻辑和PON口一样公式为上联带宽 开通用户数 × 户均签约速率 × 忙时并发系数 × 收敛系数。举个例子某OLT覆盖1200户规划期末预计开通900户户均套餐速率250M忙时并发系数0.25则900×250×0.2556.25Gbps。考虑1.3倍峰值冗余约需要73Gbps配置8个10G上联口比较稳妥同时预留2个端口做负载保护。如果现网设备只有千兆上联就要在规划报告里单独列“上联扩容”条目否则即使分光比合理用户感知依然会因为上联拥塞而劣化。4.3 把规划产出落成一图一表总规最终交付物应包括网格需求等级图、PON口缺口清单、分光器更换清单、OLT上联扩容建议和投资排序表。课件通常会把这五项归纳成三层逻辑资源层做端口盘点网络层做PON口和上联扩容投资层按“需求等级高、缺口大、单位投资效益高”排序。投资优先级建议用“需求紧迫度”而非“缺口绝对值”来排。一个1000户网格缺口30个端口和一个200户网格缺口15个端口前者缺口绝对值更大但后者缺口占比75%用户已开始受拥塞影响理应先立项。排序公式可以写成优先级得分 0.4×端口占用率 0.3×忙时带宽增幅 0.3×投诉率用这个得分对整个候选清单做降序排列。5. 规划后验证用90天数据校核预测准确率总规交付不等于结束规划模型必须在下一轮迭代前做一次回测。最直接的做法是取规划报告发布前的历史数据作为训练集预测最近90天的忙时峰值再和真实采集值对比偏差控制在正负30%以内算模型可用超过则回看是哪项参数失真。回测关注两个指标一是峰值带宽偏差率公式为实际忙时峰值-预测忙时峰值/预测忙时峰值二是端口占用预测偏差重点看预测高于实际的“过热网格”这通常意味着并发系数或渗透率假设偏大。90天内若实际值连续两月低于预测值20%以上就把该网格状态从“待扩容”改为“观察”避免投资浪费。最后给一个可视化校验技巧。用ECharts做一个按PON口聚合的容量热力地图把“端口占用率”和“忙时峰值带宽”放在同一个地图的两个图层上设置三档图例绿色代表占用率低于40%黄色代表40%到70%红色代表高于70%。这样一眼就能看出预测热度高的网格到底是“端口装满了”还是“流量已经超标”两者对应的整改动作完全不同。课件里如果能用一段真实打码数据演示这个地图读者对“大数据驱动总规”的理解会比任何公式都直观。本文还有配套的精品资源点击获取