核心要点：客房 IPTV 的容量问题，很少是“整栋楼带宽不够”，而是“同一条频道被独立推送了几百次”。把直播从单播改成 PON 原生组播——OLT 侧 IGMP Proxy + PON 口 IGMP Snooping + 独立组播 VLAN——200 路直播频道在每房间千兆入户下依然稳定，而 OLT 上联只需为每路频道保留一份带宽。本文按复制方式、带宽账、OLT/ONU 配置、业务隔离、分期落地五步，给出一套可以直接交给施工队执行的组播方案。

一、真正的瓶颈是“复制方式”，不是“总带宽”

公寓和酒店的 IPTV 有一个非常典型的规律：入住率越高、晚高峰越集中、投诉越多，但监控显示上联口根本没用满。原因在于，绝大多数所谓“IPTV 方案”用的是单播——每一台机顶盒都与流媒体服务器建立一条独立会话。同一个新闻频道，300 间客房同时在看，就产生 300 条内容完全相同的数据流。

换句话说，客房数量翻一倍，机房出口带宽就要翻一倍，而节目内容一点没变。这不是扩容问题，而是架构问题。

组播的价值就在这里：同一个频道在任意一段链路上只传输一份，只有在需要分叉的节点上才复制。对于客房高度同质化、黄金时段高度重合的场景，这是唯一能同时控制成本与体验的做法。

二、单播、广播与组播：三种下发方式的成本差异

• 单播（Unicast）：一房一会话。300 间客房看同一路频道，出口就要承载 300 份。机房出口压力随客房数线性增长，机顶盒并发上限直接受限于服务器能力。
• 广播（Broadcast）：把频道推给所有终端，不看也要接收。终端规模大时，客房内的 ONU 与 Wi-Fi 会被大量无关流量拖垮。
• 组播（Multicast）：终端按需“订阅”频道，网络只在必要的分支上复制。300 间客房看同一频道，主干上仍然只有一份。

结论很直接：客房密度越高的项目，组播带来的成本差距越大。

三、PON 天然就是一棵“分光组播树”

以太网交换机做组播需要专门设计，而 PON 的分光器本身就是一个物理形态的树状复制结构。OLT 的 PON 口向下一级级分光，同一路组播流在分光器处自然复制，不需要额外配置复制点：

1. OLT 从上行口只接收一份组播流（依赖 IGMP Proxy，避免组播在城域侧泛洪）；
2. PON 口按房间的订阅情况，把该频道复制到有订阅的 ONU 所在分支；
3. ONU 只把房间真正订阅的频道送到机顶盒，其余流量不进入客房线路。

这也是为什么在酒店、公寓、医院病房这类“大量终端、少量频道、强并发”的场景里，PON 的性价比明显高于传统三层交换机堆叠组网。

四、200 路频道的带宽账：一张 PON 到底能不能撑住

把账算清楚，选型就不会拍脑袋。以 300 间客房、200 路 HD 直播频道、平均码率 8 Mbps 为例：

• 单播模型：每间客房独立会话。仅“所有房间都看同一个频道”这一种情况，下行就需要 300 × 8 Mbps = 2.4 Gbps，且实际观看分散时总需求只增不减。
• 组播模型：上联侧最多 200 × 8 Mbps = 1.6 Gbps，且只有被订阅的频道才占用；每条分光支路只承载该支路订阅的频道；每间客房下行始终只占 1 路频道，即约 8 Mbps。

由此得到几条实用结论：

• 频道数在 60–80 路以内、以 HD 为主：单口 GPON（下行 2.5 Gbps）即可承载组播，剩余带宽留给宽带上网。
• 频道数超过 100 路，或包含 4K 频道：建议 PON 口直接上 XG-PON（10 Gbps），把 GPON 留给数据业务，避免直播与上网抢带宽。
• 客房侧不需要担心：每间房同时只解一路频道，千兆入户绰绰有余。

容量选型时，配套 OLT 可按容量梯度递进：小体量公寓（32 口）用 ZH-vOLT32；中型酒店（64 口）用 ZH-vOLT64；频道超过 100 路、需要万兆上行的项目直接上 ZH-VOLTXG64。模块化结构的好处是，前期按实际入住规模投入，后期换模块升级，不必整套换机。

五、OLT 侧配置要点：IGMP Proxy、Snooping 与组播 VLAN

组播能不能稳定，八成取决于 OLT 上这四个开关：

1. IGMP Proxy：让 OLT 代表所有终端向上游统一申请组播组，上游只看到一条成员关系，而不是几百条。不做这一步，组播流量会在城域侧大面积泛洪。
2. PON 口 IGMP Snooping：必须开启，否则组播会在 PON 口向所有 ONU 泛洪，等于退化成广播。
3. 独立组播 VLAN：直播频道走专用 VLAN（例如 VLAN 100），与上网、语音彻底分开。这样直播流不占数据 VLAN，也便于单独做 QoS 和排障。
4. 快速离开（Fast Leave）：换台时立刻停止原频道，避免“换台要等 2–3 秒”。频道数量越多，这个开关越重要。

另外建议固定使用 IGMPv2 与机顶盒对接，兼容性最好；并在 OLT 上为组播 VLAN 配置高于数据业务的 802.1p / DSCP 优先级，让直播流在拥塞时优先转发。

六、ONU 与房间侧：从光猫到机顶盒的正确接法

OLT 配好了，客房侧接错一样会出问题。规范的房间侧做法是：

• 端口与 VLAN 绑定：ONU 的 IPTV 口绑定组播 VLAN，机顶盒只接这个口，不要和上网口混插。
• 开启组播转单播（Multicast-to-Unicast）：如果客房用 Wi-Fi 接入机顶盒或智能电视，务必在 ONU 上开启组播转单播。Wi-Fi 传输组播时会强制降到最低基础速率，300 间客房同时组播足以拖垮整层 AP。
• 组播带宽限速：给 IPTV 口设置合理的组播带宽上限（如 20 Mbps），防止异常订阅占满线路。
• 保留有线优先：机顶盒有网口时优先走有线，直播体验远比无线稳定。

七、让 IPTV、Wi-Fi、语音与客控共用一张光网

客房全光网最怕“一套业务一张网”，那样成本和排障复杂度都会失控。正确做法是一张 PON、多业务 VLAN 隔离：

• 数据业务：独立 VLAN，走桥接或路由模式；
• 直播频道：组播 VLAN，最高转发优先级；
• 客房语音：独立语音 VLAN，保证呼叫不受直播影响；
• 客房智能控制（RCU / 客控系统）：单独 VLAN，与上网隔离，避免被终端扫描；
• Wi-Fi 覆盖：AP 与 ONU 同网段管理，SSID 与业务 VLAN 一一对应。

这样做的好处是，任何一个业务出问题都不会牵连其他业务；扩容时也只是在 OLT 上新增一个 VLAN，不必重新布线。

八、分期落地：从样板层到全楼覆盖

1. 样板层验证（约 20 间房）：先上线一层，重点测三件事——换台时延是否低于 1 秒、晚高峰丢包率、ONU 组播转单播后的 Wi-Fi 表现。
2. 机房与上联确认：核对频道数与上联带宽模型，确认是否需要 XG-PON 上行，组播源与 OLT 之间保持同城低时延链路。
3. 逐层扩展：按楼层分批割接，每层完成后抽测 3–5 间客房，避免一次性变更带来难以定位的故障。
4. 运维移交：把组播 VLAN、频道清单、ONU 端口模板、常见告警处理方式整理成一份文档交给工程队，后续新增楼层直接套用。

九、常见误区清单

• 机顶盒直接接在数据 VLAN 上，直播走单播，上联悄悄被跑满。
• OLT 未开 IGMP Proxy，组播在运营商侧泛洪，被上游限速或投诉。
• ONU 未开 IGMP Snooping，组播在 PON 口泛洪到每一间客房。
• 客房 Wi-Fi 直接用组播承载直播，速率被拉到最低，整层体验一起崩。
• 换台慢却去查服务器，而实际原因是没开 Fast Leave 或缺 IGMP 查询器。
• 只按“平均带宽”算容量，没有按频道数 × 并发订阅数去核算组播复制点带宽。

结语

酒店与公寓的 IPTV，本质上不是视频服务器的问题，而是“一张网络如何高效复制同一份内容”的问题。把复制方式改成组播、把组播 VLAN 与业务隔离做干净、把 OLT 与 ONU 的 IGMP 开关一次配到位，200 路直播频道可以在一张 PON 上跑得很稳，而且客房数量继续增加时，机房出口不需要成比例扩容。

从 32 口的公寓项目，到 64 口的酒店项目，再到需要万兆上行的多业务园区，模块化 vOLT 的思路是一致的：先按当前规模落地，再按容量梯度平滑升级。如果您正在规划酒店或公寓的 IPTV 与全光网方案，欢迎把客房数量、频道数和业务清单发给我们，我们可以先把带宽账和 VLAN 规划一起算清楚。

联系我们

• 邮箱：zhenghui.xu@sczhgx.com
• WhatsApp：+86 17612849559
• 官方商城：shop.sczhgx.com