PON与AON怎么选：光纤接入网选型、光功率预算与运维成本解析

去年冬天跟一个施工队跑老旧小区改造，楼道里那排带小风扇的交换机被拆下来时，积的灰能刮下一层。师傅一边拧螺丝一边嘟囔：这玩意儿一年得换俩风扇，夏天一停电整栋楼跟着断网。三个月后再去，同一位置换成了一个巴掌大的塑料盒，没有电源、没有风扇、只有几根光纤进出——分光器。楼道里从此安静了，机房那边却多了一台设备。这就是光纤到户技术里最典型的两种思路在打架：PON（无源光网络）和AON（有源光网络）。

这两个词在方案评审会上出现的频率极高，但真正能把"什么时候该用哪个"讲清楚的人并不多。我见过把1:64分光器拉到8公里外还拍胸脯说没问题的设计，也见过在只有12户的独栋别墅区硬上PON、结果每户要重新拉一根皮线熔接的施工队。这篇文章不谈虚的，就把PON和AON从物理形态、光功率账本、成本结构、演进路径到施工现场的坑，一层层拆开讲。不管你是刚接触接入网的设计人员、做弱电总包的施工方，还是负责运维的技术支持，看完至少能自己在图纸上把账算明白。

1. 从"楼道里有没有电"说起：PON与AON的真实分野

很多人第一次接触这两个概念，会以为区别在于"光纤到哪儿"——其实不是。FTTH、FTTB、FTTC讲的是光纤终点位置，而PON和AON讲的是从局端到你家的这条链路上，中间有没有需要供电的有源设备。这个区别看似只关乎一个电源插座，实际上把两套完全不同的设计逻辑、成本结构和运维方式都带着走偏了。

1.1 无源分光器省掉的到底是什么

PON的全称是Passive Optical Network，核心就一个词：无源。局端放一台OLT，中间在光交箱或楼道里放一个分光器，末端是ONU/ONT。整条链路里，除了两端设备，中间全是玻璃和塑料——光纤、法兰盘、分光器、接头盒。分光器本身是熔融拉锥或者平面波导做出来的，不需要电、不需要配置、不需要软件版本升级，装上去之后十几年不用管它。

这个"不用管"的价值，在运维成本里被严重低估。我做过一个粗略统计：一个带风扇和电源的楼道交换机，在南方潮湿环境下年平均故障率大概在3%到5%，主要是电源模块和风扇；而无源分光器的年故障率可以低到千分之一量级，绝大多数故障来自施工时的端面污染和光纤弯折。也就是说，一个覆盖500户的小区，AON方案下每年要处理十几起楼道设备故障，PON方案下可能一年碰不到一次。这笔账在设备报价单上是看不到的。

但无源也意味着你看不见它。分光器不会告警，不会上报，光纤断了它就是一段沉默的玻璃。ODN（光分配网络）一旦出问题，只能靠光功率测量和OTDR去反推，这是PON方案最大的软肋，后面会专门讲。

1.2 有源节点换来的能力边界

AON在FTTx语境下通常指点对点（P2P）以太网接入：局端一台交换机，每个用户独占一路光纤和一对光模块，中间可能有源汇聚交换机做级联。这里的"有源"意味着每个汇聚点都要供电、要散热、要管理IP、要升级固件，但同时你也拿到了几样PON给不了的东西。

第一是带宽独享。PON是点对多点，一个PON口下的用户共享下行2.5G或10G，虽然实际收敛比通常在1:4到1:8之间、日常够用，但遇到突发大流量场景（比如同时多路4K回传、园区内大文件分发），共享介质要靠DBA（动态带宽分配）去调度，延迟抖动比独享链路明显。AON下每个用户拿到的是真千兆、真万兆。

第二是故障域隔离。PON一个1:32分光器下面挂32户，主干光纤一断，32户全黑；AON的每一根入户纤是独立的，断一根只影响一户。这个差别在故障处理时效考核里非常致命。

第三是距离和拓扑自由。PON的分光比和传输距离是一对互相挤压的参数，加了分光器就得砍距离；AON点对点没有功率分配的问题，用长距光模块直接把距离拉到10公里、40公里都可以，中间还能灵活跑环网、跑链路聚合。

1.3 两种物理形态的对照

下表是我在方案评审时常用的一张对照，把两者的物理形态和工程特征摊开：

这张表里我个人最看重的是最后两行。PON把供电压力全部集中在机房，AON则把供电需求撒到了整个接入网。在老旧小区、乡村、野外这些取电困难的场景，这一条几乎能一票决定选型。

2. 光功率预算：PON设计里最容易翻车的一笔账

如果说PON方案有一个地方最容易出错，那一定是光功率预算。它不像带宽可以靠后期扩容补救，链路损耗一旦超了，要么换光模块、要么减分光比、要么加中继，每一种都是返工。我见过太多方案在纸面上"大概能通"，装完实测收光-30dBm，ONU死活起不来。

2.1 分光比、插入损耗与余量的叠加

先明确一个基本盘：PON系统的光功率预算由光模块等级决定。Class B+ 标称28dB，Class C+ 标称32dB，这个数字的意思是从OLT发光口到ONU收光口之间，允许的总损耗上限。超出这个值，ONU收不到或者误码率飙升；低于下限（通常是-8dBm左右的过载点），光探测器饱和，同样会出问题。

链路上消耗预算的东西有这几类，每一类都要单独列出、逐项相加：

• 光纤衰减：1310nm窗口按0.35dB/km算，1490nm按0.25dB/km算。注意上下行波长不同，两个方向要分别算。实际施工中光纤老化、弯曲半径不足都会让这个值变大，按标准值算完必须留余量。
• 分光器插入损耗：这是最大的一块，不同分光比的典型值差异极大。
• 熔接点损耗：每个热熔接点按0.1dB，冷接子按0.3dB左右。一个小区从机房到入户经过七八个接头盒很正常。
• 活接头损耗：每个法兰盘按0.5dB，OLT侧、光交箱、分纤箱、ONU侧，四个起步。
• 设计余量：一般留3dB，链路越长、接头越多，余量要留得越大。

分光器的损耗数据建议直接背下来，评审时非常有用：

提示：均匀性偏差这一列经常被忽略。1:32的分光器标称17.5dB是平均值，实际最差的那个支路可能到19dB。做预算时要用"标称值+均匀性偏差"来做保守计算，否则总有几个用户刚好卡在临界点上。

2.2 一段脚本把预算算死

手工列表容易漏项，我习惯用一段小脚本把整条链路的预算跑一遍，参数改起来也快。下面这段可以直接拿去改：

# 光功率预算计算（以GPON Class B+ 为例） FIBER_LOSS = {1310: 0.35, 1490: 0.25, 1550: 0.22} # dB/km SPLITTER_LOSS = {2: 3.6, 4: 7.3, 8: 10.7, 16: 14.0, 32: 17.5, 64: 21.0} SPLITTER_UNIFORMITY = {2: 0.4, 4: 0.6, 8: 0.8, 16: 1.0, 32: 1.5, 64: 2.0} def budget(olt_tx_dbm, onu_sens_dbm, feeder_km, drop_km, split_ratio, splice_count, connector_count, wavelength=1490, margin_db=3.0): fiber = (feeder_km + drop_km) * FIBER_LOSS[wavelength] splitter = SPLITTER_LOSS[split_ratio] + SPLITTER_UNIFORMITY[split_ratio] splice = splice_count * 0.1 connector = connector_count * 0.5 total_loss = fiber + splitter + splice + connector + margin_db rx = olt_tx_dbm - total_loss ok = rx >= onu_sens_dbm return { "光纤损耗": round(fiber, 2), "分光器损耗": round(splitter, 2), "熔接损耗": round(splice, 2), "活接头损耗": round(connector, 2), "设计余量": margin_db, "总损耗": round(total_loss, 2), "ONU预计收光(dBm)": round(rx, 2), "是否满足": "通过" if ok else "不通过，需调整" } # 例：1:32分光，馈线3km，配线0.8km，6个熔接点，5个活接头 print(budget(olt_tx_dbm=3.0, onu_sens_dbm=-27.0, feeder_km=3.0, drop_km=0.8, split_ratio=32, splice_count=6, connector_count=5))

跑出来的结果大致是：光纤损耗0.95dB，分光器19.0dB（含均匀性），熔接0.6dB，活接头2.5dB，余量3dB，总损耗26.05dB，ONU预计收光-23.05dBm。这个值在B+的-27dBm灵敏度之上，但已经不算宽裕——如果实际施工中多两个熔接点、或者皮线光缆拐了几个急弯，很容易滑到-26dBm附近。

同样的链路如果换成1:64分光器，损耗直接变成29.55dB，收光-26.55dBm，基本贴着灵敏度边缘，只要有一点点偏差就掉线。这时候要么上C+光模块（预算32dB），要么把分光比降回1:32。这就是为什么很多"百兆入户"的老小区改千兆时，第一件事是去光交箱把1:64换成1:32。

2.3 距离和分光比是一对跷跷板

PON系统里有一条隐形的公式：分光比大一档，可用距离就少一截。1:32的分光器吃掉17.5dB，相当于5公里左右的1310nm光纤衰减；1:64吃掉21dB，等于再砍掉1公里多。很多方案图上画得漂亮，机房在城东、小区在城西，直线距离6公里，再加1:64分光，纸面算下来能通，实际装完一半用户注册不上。

我的经验判据是：馈线距离超过5公里，分光比不要超过1:32；超过10公里，老老实实1:16甚至1:8。如果用户密度确实高、非要大分光比，那就在中间加一级1:2或1:4的级联分光，把总损耗摊开，同时把第一级分光器尽量往用户侧挪。级联听起来复杂，实际就是把一个1:32拆成1:4加1:8，损耗是7.3+0.6+10.7+0.8=19.4dB，比单个1:32只多了不到0.5dB，但布线灵活度高得多。

3. 有源点对点的适用土壤：AON什么时候反而更值

行业里有一种默认叙事：PON便宜、AON贵，所以FTTH就该用PON。这个结论在住宅小区场景基本成立，但一旦离开这个场景，结论经常反过来。我在园区、工业现场、酒店和专线接入这几类项目里，见过太多次PON方案算下来并不便宜的情况。

3.1 点对点链路的技术账

AON的物理形态很朴素：局端一台交换机的一块光口板，一根光纤直通用户侧的光收发器，中间不经过任何分光器件。这条链路的光功率预算非常宽裕——商用1000BASE-LX模块的预算通常在8dB以上，对应10公里单模传输；长距模块拉到40公里也不稀奇。因为没有分光器吃掉十几个dB，链路的抗老化、抗弯折能力天然强很多。

带宽上是真独享。一个24口千兆交换机板卡，24个用户各拿1Gbps，互不干扰，也不需要DBA调度。对于需要稳定低时延的场景——比如工业视觉检测回传、园区内监控视频汇聚、医院影像调阅——这种确定性比"峰值也能跑到千兆"要有价值得多。

代价也很清楚：端口密度低、单位成本高。一台48口交换机占1U机架位，PON的一台OLT在同样1U里能带几千户。这个差距在用户密集的住宅区是致命的，但在用户稀疏、单点带宽要求高的场景里，反而无所谓——反正你也不需要那么多端口。

3.2 园区和工业现场的典型形态

我参与过一个制造园区的网络改造，厂区跨度接近2公里，分布在七八栋厂房里，每栋厂房需要的接入点不多，但每个点都要传高清质检视频和PLC数据，对抖动很敏感。最初的方案是PON，一台OLT放中心机房，各厂房放分光器和ONU。

问题很快暴露：厂区里的光纤走桥架、穿管井，环境温度高、震动大，熔接点做得不够精细，几个月后有几个点的收光掉到了-26dBm以下，视频开始卡顿。更麻烦的是，这几个点分布在不同的分光器支路上，排查要一根一根拔纤测光，每次停机半小时。后来改成AON：每栋厂房放一台工业级汇聚交换机，用环网连回中心，各接入点直接点对点。改造后单个点位故障不影响其他点，交换机端口状态在网管上一眼可见，排查时间从半天缩短到十分钟。

这个案例里AON贵吗？设备成本确实高了三成左右，但省下来的排查工时和停机损失，半年就回本了。AON的价值不在设备单价，在于它把"不确定性"变成了"可观测性"。

3.3 故障域大小决定的运维节奏

我常用一个指标来衡量选型：单次故障的平均影响户数。住宅小区里，PON一个分光器下挂32户，主干断纤影响32户，这个影响面在可接受范围内，因为住宅用户对短时中断的容忍度相对高，而且抢修优先级容易判断。但在企业客户、医院、学校这类场景，一次断网可能意味着一条产线停产或者一场考试中断，影响面必须压到最小。

AON在这方面是天然优势：一根纤、一个端口、一个用户，故障边界清晰。配合交换机的端口告警和光功率监测（很多企业级交换机支持DDM数字诊断），可以在用户报障之前就发现问题。PON的ONU虽然也支持光功率上报，但那是"末端可见、中间不可见"，分光器以前的部分仍然是黑盒。

4. 成本结构拆解：报价单上没写的那些数字

做方案比价时最常见的一个错误，是只比设备报价。PON的OLT比AON的交换机贵，但一台OLT能带几千户；AON的交换机便宜，但每户都要占一个端口加一对光模块。这么一比，PON在密度上碾压。可如果只算到这一步，就会漏掉后面几笔真正的大钱。

4.1 机房、电费与空调的隐性支出

AON的每一个有源汇聚点都要电。一个带24口光口的汇聚交换机，整机功耗大概在60到100瓦，加上风扇和可能的空调，一个点位一年电费在几百到上千元不等。听起来不多，但如果有50个汇聚点，一年就是几万元，而且这是持续性支出，十年下来相当可观。PON把这些全部收归机房，机房本身的电费确实会增加，但集中管理的效率高得多，也不会出现"某个楼道夏天跳闸导致整栋楼断网"这种事故。

机房空间也是钱。AON的局端需要为每个用户预留端口，用户数增长就要加板卡、加机架、扩机房；PON的OLT扩容是加PON口，一个口带64户，扩容颗粒度大得多。在寸土寸金的城市机房，这个差别很实际。

4.2 装维效率决定的是人力成本

这一项经常被忽略，但它往往占总成本的很大一块。PON的入户施工是"一个分光器带一片"，施工队一次到楼，把分光器装好、皮线光缆布放到各户门口，后续开通只需要在分纤箱跳纤。AON的入户是"一户一根纤"，从局端或汇聚点一路拉到用户家，中间经过的每个接头盒都要熔接，光纤用量和熔接工时都是PON的数倍。

我算过一个粗略的对比：同样100户的新建住宅，PON方案的主干光纤用量大约是AON的六分之一到八分之一，熔接点数量大约是三分之一。按当前的人工和材料价格，这部分差价足以抵消PON设备本身贵出来的部分。

但反过来，在用户分散、距离远的场景，PON的分光器位置很难选。放远了，皮线光缆拉得太长、损耗大；放近了，主干光纤又要多铺。AON反而是"一根纤拉到底"，施工逻辑简单粗暴。

4.3 一张全生命周期成本对照

把上面这些摊到一张表里，结论会更清楚：

这张表没有给出"谁更便宜"的绝对答案，因为答案取决于用户密度、距离、故障容忍度和运维人力这四个变量。任何脱离场景谈成本的结论都不靠谱。

5. 代际演进：PON一路跑到50G，AON怎么跟

选型不能只看当下，还要看这条技术路线五年后、十年后还剩多少空间。PON这一侧的演进路线非常清晰，几乎每代都是十倍速的跨越；AON这一侧则是跟着以太网速率线性升级，逻辑简单但代价直接。

5.1 PON的代际参数对照

从最早的APON/BPON，到大规模商用的EPON和GPON，再到现在的10G时代和正在推进的50G时代，PON的每一代都在解决同一个问题：在保持无源ODN不变的前提下，把带宽提上去。

这里有个很重要的工程事实：这些代际可以共用同一套ODN。XGS-PON和GPON的波长规划是错开的，前者下行用1577nm、上行用1270nm，后者下行1490nm、上行1310nm，通过波分复用可以在同一根光纤、同一个分光器上同时跑。这意味着从GPON升级到XGS-PON，理论上只需要在局端加板卡、在用户侧换ONU，中间的光纤和分光器一根不用动。

这是PON路线最值钱的地方，也是AON做不到的。AON从千兆升级到万兆，意味着局端交换机换板卡、用户侧光模块全换、部分场景还要重新评估光纤链路质量（万兆对链路损耗和色散更敏感）。升级是"逐点替换"，工作量随用户数线性增长。

5.2 共存升级时的实操要点

虽然理论上可以共存，实际升级时有几个坑必须提前避开。

第一是分光器带宽。老小区里的分光器可能是十年前装的，标称支持1260到1650nm全波段，但廉价器件的实际工作波段可能只覆盖1310/1490。上XGS-PON要用1577nm，如果分光器不支持，损耗会异常增大。升级前建议抽样测一下1577nm的插损，别等到装完才发现。

第二是光功率预算重新算。XGS-PON的Class N1预算约29dB、Class N2约31dB，和GPON的B+不完全一样，而且10G速率的接收灵敏度对噪声更敏感。原来GPON收光-25dBm能跑，换成XGS-PON可能就不够了。升级方案里必须按新速率重算一遍，别拿老数据套。

第三是ODN的反射和端面清洁。10G以上速率对回波损耗和端面污染极其敏感。我遇到过升级后部分用户频繁掉线，最后查出来是分纤箱里几个法兰盘端面有油污，擦干净就好了。这种问题在GPON时代不明显，在10G时代会被放大。

5.3 AON升级的代价是线性的

AON的升级路径其实就是以太网速率升级：百兆到千兆、千兆到万兆、万兆到25G/100G。技术本身很成熟，但没有"共用基础设施"这个杠杆。用户数翻倍，端口就要翻倍；速率升一档，光模块和交换机板卡就要全换。

它更适合的场景是用户数稳定、单点带宽需求持续走高的地方，比如数据中心互联、园区骨干、专线接入。在这些场景，AON的可预测性和确定性比PON的"共享+调度"更有价值。但如果是一个用户数持续增长的住宅区，AON的扩容成本曲线会越来越陡。

6. 施工与运维踩坑实录

理论讲完，说说现场。这一节里的每一条，都是我或者身边同行真实踩过的，代价从几千块返工费到整片区断网都有。

6.1 分光器位置选错，整条链路推倒重来

最典型的一次：某新建小区，设计图上把1:32分光器放在了中心机房，理由是"集中管理方便"。结果施工到一半发现，从机房到最远那栋楼的馈线距离接近4公里，加上1:32的17.5dB损耗，预算直接超了。补救方案只有两个：要么把分光器下移到小区光交箱（需要重新熔接上百芯），要么把1:32改成两级1:4+1:8级联（需要额外机箱位置）。

正确的做法是分光器尽量靠近用户侧。分光器放得越靠前，共享的馈线光纤越短、被分光器吃掉的预算影响的距离越少；放得越靠后，虽然皮线光缆变长，但皮线光缆通常距离短、接头少，损耗可控。业内的经验法则是：分光器放在楼栋或单元的光分纤箱里，馈线用大芯数光缆集中拉，配线用皮线光缆入户。

还有一个小坑：分光器盒的安装位置要考虑后续跳纤的操作空间。见过把分光器塞在只有20厘米深的弱电井里，运维人员手都伸不进去，每次跳纤要拆半个箱子。

6.2 光模块和光纤类型对不上

单模和多模混用是老生常谈，但实际项目里还是经常出。最隐蔽的一种是BIDI光模块的波长配对错了。BIDI模块用一根纤跑双向，局端和用户端的波长必须配对，比如局端发1310收1550，用户端就得发1550收1310。如果两端装成同波长，链路直接不通，而且光功率计测出来还有光，很容易误判成"链路正常但设备故障"。

另一种是光模块的接收灵敏度等级不匹配。PON的ONU光模块分B+、C+、C++等不同等级，价格差不少。有些施工队为了省钱，在长距离链路末端装B+模块，结果收光刚好卡在-27dBm边缘，晴天能用、雨天衰减一大就掉线。这类故障最难查，因为它是"间歇性"的。

提示：每批光模块进场时抽测一下发光功率和接收灵敏度，做个记录。看起来麻烦，但能省掉后面大量扯皮。我现在的习惯是让施工方在竣工资料里附一张每个点位的实测收光表，低于-24dBm的要标注原因。

6.3 标签和资源管理的欠账

PON的ODN是无源的，这意味着除了标签，没有任何东西能告诉你这根纤通向哪里。而标签恰恰是最容易被忽略的环节。我接手过一个运行三年的小区，光交箱里的法兰盘上贴着"1""2""3"，分纤箱里也贴着"1""2""3"，两边对不上，查一个用户要拔遍整个分光器的32个端口。

现在我的做法是强制要求三级标签：光交箱侧标"机房-光交箱-端口号"，分纤箱侧标"光交箱-分光器编号-支路号"，用户端标"分纤箱-支路号-房号"。同时要求施工方提交一份Excel资源表，和标签一一对应。这份表在后续扩容、故障排查、拆机时的价值，远超做表的那几个小时。

AON虽然可以在网管上看到端口状态，但物理端口的对应关系同样依赖标签。交换机端口23对应哪一户，如果没人记录，一样要现场拔线试。

7. 选型判断：我按这个顺序做决定

最后说说我自己的判断流程。这些年做过的项目多了，发现选型这件事其实不需要背太多参数，关键是按一个合理的顺序把问题问对。顺序错了，很容易一上来就陷进"PON便宜还是AON便宜"的争论里，而这个问题本身是没有答案的。

7.1 先定故障容忍度，再谈带宽

第一个要问的问题不是"要多少兆"，而是"断了会怎样"。如果是一般住宅用户，断网两小时能接受，那PON的成片故障风险是可以承受的；如果是生产线、急诊室、考场、交易柜台，一次中断就是事故，那AON的故障域隔离价值就压倒一切成本考量。

这个判断必须在方案初期就做，因为它决定了后面所有的架构选择。我见过一个方案，前期按住宅标准设计了PON，后期甲方说其中一栋楼是研发中心、不能断网，结果只能单独给那栋楼拉一路AON，形成两套系统并存的尴尬局面。

7.2 用户密度和距离的交叉判断

第二个问题是密度和距离的组合。我习惯用一张二维的判断表：

这张表的核心逻辑是：PON的优势来自"共享"，共享的前提是用户密集且距离不远；一旦用户稀疏或距离拉长，共享的杠杆就失效了，反而变成损耗和故障域的负担。

7.3 取电条件和既有资源是最后一道闸

第三个问题是现场约束。很多方案在纸面上完美，一到现场就卡壳：老小区楼道没有公共电源，装不了有源交换机；工业园区有现成的光纤环网，直接拿来跑AON更省事；某些场景已经有PON的ODN存量，再上AON等于重复建设。

这一条最没有技术含量，但往往是决定性的。我的建议是：技术方案定下来之后，一定要带着图纸去现场走一遍，看看每个汇聚点有没有电源、有没有机柜位置、桥架能不能走线。这几趟路走下来，能改掉一半的方案错误。

至于我个人的偏好，说实话是偏PON的——不是因为它技术更先进，而是因为在大多数住宅和普通商用场景里，它把复杂度收进了机房，留给现场的只有玻璃和塑料，这对运维友好得太多。但只要场景里出现"不能断""要独享""距离远""取电难"中的任意两条，我就会认真考虑AON。

还有一个小经验：不管是PON还是AON，竣工时一定要把每个点位的实测收光值记录下来，做成基线。运行一两年后如果出现掉线，拿实测值和基线一比，是光纤老化、端面污染还是设备故障，基本能判断个八九不离十。这张基线表，比任何网管告警都实在。