运营商OLT上方酒店无线认证系统集中部署方案

在运营商光纤到房间的架构下，多家酒店可能共用一个OLT设备。传统的酒店本地部署认证网关方案在这种场景下不适用——每家酒店各放一台网关，既浪费设备，也不便于运营商统一管理。运营商OLT上方集中部署方案就是为这种场景设计的：在运营商机房的OLT之上部署一台大型认证网关，多家酒店的流量通过独立VLAN透传到网关，统一做认证和日志审计。

这种方案的适用场景很明确：运营商管辖范围内有10到50家中小型酒店，单酒店房间数在100间以下，共用一个OLT。运营商想统一提供WiFi认证增值服务，降低单酒店的设备采购和运维成本，同时把认证服务作为带宽之外的增值收入。如果是单家大型酒店、或者酒店自己有独立机房和IT团队，本地部署方案更合适，自主性更强。

架构上，OLT把每家酒店的流量打上独立VLAN标签，透传到运营商机房的认证网关。认证网关识别VLAN标签，区分不同酒店的流量，分别做认证、计费、日志记录。每家酒店的认证页面可以独立定制，推各自的品牌LOGO和服务信息，但底层认证平台是统一的。日志数据按酒店独立分类存储，上报网监时可以精准关联到对应酒店主体，满足分级监管要求，不会出现A酒店的日志混到B酒店里的情况。

认证方式在集中部署方案里通常统一用短信认证。住客和访客都走PORTAL短信认证，输入手机号收验证码。因为是多酒店共用平台，PMS对接不太现实——每家酒店的PMS品牌和版本都不一样，集中对接成本高、维护难。短信认证不依赖PMS，实施简单，所有酒店统一流程，客人不管住哪家店体验一致。员工和办公设备用白名单免认证，但记录日志。如果某家酒店确实需要PMS对接，可以在该酒店侧单独部署小型认证网关，和集中平台并行，但这就偏离了纯集中部署的模式。

集中部署的最大优势是规模化运维。运营商运维人员通过一个统一后台就能监控所有酒店的设备状态、网络流量、认证成功率。日志异常、设备故障、认证失败率升高都会自动告警，远程排查为主，现场维护为辅。不需要每家酒店配一个管理员，也不需要跑现场处理日常问题。对于管理几十家酒店的运营商来说，这种集中运维的效率提升很明显，人力成本可以降低一半以上。

成本上，集中部署把认证网关、认证系统、日志服务器的投入分摊到所有酒店。单酒店不需要采购本地认证设备，只需要保证AP和接入网络正常。运营商统一采购大型网关和服务器，规模采购成本更低，机房资源也可以复用。但要注意，集中部署对网关的性能要求更高——几十家酒店的认证请求同时打到一台网关上，并发量不小，需要根据总用户数和峰值认证需求选型。V7系统的Portal每秒认证4000次以上、Radius每秒4000次以上，但具体性能取决于硬件规格、网络拓扑和并发模型，需要项目级压测验证，不能直接套用标称值。

除了多酒店共用大型网关的模式，还有一种单酒店独立部署小型审计网关的模式。在OLT之上、对应酒店的VLAN链路上部署一台轻量化审计网关，只负责这家酒店的认证和日志上报。这种模式适合单酒店房间数较多（比如超过100间）、或者对数据隔离有更高要求的场景。小型审计网关配置简单，酒店工作人员可以自主操作后台，不依赖运营商运维，但每家酒店都要采购设备，成本比集中模式高。两种模式可以混合使用，大型酒店独立部署、中小型酒店集中部署。

VLAN配置是集中部署的关键。每家酒店必须有独立VLAN，流量不能混在一起。VLAN标签从OLT到认证网关全程透传，中间不能被剥离或改写。认证网关根据VLAN标签区分酒店，下发对应的认证策略和日志规则。如果VLAN配置错误，A酒店的流量可能被算到B酒店头上，日志溯源就会出错，公安检查时是严重问题。实施时要逐酒店验证VLAN隔离有效性，用测试终端在不同酒店接入，确认日志归属正确。

网监上报在集中部署下由认证网关统一处理。网关通过标准接口和省公安网监平台对接，把各酒店的日志按主体分类上报。蓝海卓越在网监对接方面有实施经验，会全程配合联调。但具体对接流程、数据格式、上报频率取决于当地网监平台的要求，需要在项目实施阶段确认。有些地区要求每家酒店独立注册上报主体，有些允许运营商统一上报，要提前和网监沟通清楚。

集中部署也有局限性。一是依赖运营商机房条件，需要有机柜空间、稳定电源、足够的上行带宽。二是所有酒店共用一台网关，如果网关故障，所有酒店的认证都会受影响——建议配置双机热备或冗余网关，主网关故障时自动切换。三是定制化能力有限，所有酒店用统一的认证流程和页面模板，个别酒店的特殊需求难以满足。四是数据集中存储，如果云端或机房出问题，所有酒店的日志查询都会受影响。选型时要权衡集中管理的效率和单店定制的灵活性，以及集中故障的风险。