生产级 TR-069 与 TR-369 ACS —— 与订户共处同一张数据图。
Netxol ACS 随 NMM 一并交付。它同时承载面向传统 CPE 的 CWMP、面向现代设备的 USP(TR-369,支持 MQTT / WebSocket)、TR-181 设备建模、TR-143 速率测试、按服务档次的零接触开通,以及带灰度发布与自动回滚的固件仓库。因为它就活在共享的数据图上,一次 CPE 变更与一次订户套餐变更就是同一场对话。
正在把独立 ACS 与平台内嵌 ACS 做对比的 FTTH / WISP 运营商 —— 从 GenieACS、Incognito、HDM 或厂商绑定 ACS 迁移。
多年以来,ISP 行业一直把 ACS 当作一个独立应用来对待 —— 有自己的数据库、自己的登录、与 NMS、CRM、计费工具并列。这种割裂就是零接触至今仍难以落地的原因:ACS 认识 CPE,却不知道客户是谁、买了哪个套餐、落在哪个 OLT 端口上。
Netxol ACS 是 NMM 的一等公民。它在生产级质量上实现了 TR-069(CWMP)与 TR-369(USP),并以 MQTT 与 WebSocket 作为传输,把 USP 交互从轮询驱动改为事件驱动。TR-181 设备模型得到尊重;厂商私有扩展通过适配器框架来处理,新增一款 CPE 型号只是一个插件,而不是一次发版。
商业上的回报,是把零接触真正做对。发到订户手里的设备主动向 ACS 呼叫,完成认证,取到自己的服务档次,下载配置并投入运行 —— 通常在开箱后 15 分钟内 —— 无需上门。固件活动按 canary → 1% → 100% 的节奏推进,健康信号一旦劣化即自动回滚。
而且,因为 CPE、订户、账单与 OLT 端口都指向共享数据图上的同一个身份,任何 ACS 动作默认就带上下文。一次固件活动发现了坏批次,会自动点名受影响的客户;订户打电话给客服时,CPE 状态即刻可见,不需要中间集成桥接。
四个动作。
开启 TR-069 与 TR-369
CWMP 面向传统 CPE,USP(MQTT / WebSocket)面向现代设备 —— 都住在同一台服务器里。
把零接触接到服务档次
CPE 认证 → 读取 CRM 套餐 → 应用模板化配置 → 设备上线。没有手工步骤。
让固件活动稳妥落地
canary → 1% → 100% 的灰度发布,健康信号劣化即自动回滚,每一步都可审计。
让客服与计费共享同一张图
CPE 与 CRM、计费所看到的,是同一条订户记录 —— 没有桥、没有导出、没有漂移。
每一台 CPE、每一个协议、每一家厂商。
Netxol ACS 不是套在开源 ACS 引擎外面的一层薄壳。它是 NMM 内部的一等模块 —— 同时实现 TR-069 与 TR-369、TR-181 设备建模、TR-143 诊断、按厂商的适配器框架、带分阶段发布活动的固件仓库,以及一套多租户模型:多家运营商品牌跑在同一台服务器上。以下各节把每一块讲清楚。
TR-069(CWMP)—— 你已经在用的每一台老 CPE
Netxol 实现宽带论坛 TR-069 / CWMP 协议(客户端 / 服务器),包含所有标准 RPC:Inform、GetParameterValues、SetParameterValues、GetParameterNames、GetParameterAttributes、SetParameterAttributes、AddObject、DeleteObject、Download、Upload、Reboot、FactoryReset、ScheduleInform、ChangeDUState、ScheduleDownload,以及 Autonomous Transfer 通知。会话池处理重连流量,不打爆 ACS 侧带宽。只讲 CWMP 的传统 CPE 第一天就能跑,不用改代码。
- 所有标准 CWMP RPC 已实现
- 支持 TR-069 修订 1 到 6
- 为超大存量的会话池
- HTTPS 传输 + TLS 1.3
- Connection request 走 TR-069 或 STUN
TR-369(USP)—— 现代继任者,事件驱动
TR-369(User Services Platform)是 TR-069 的继任者。Netxol 完整实现 USP Agent / Controller 模型,以 MQTT 与 WebSocket 为传输,CPE 因此可以按订阅推送事件,而不是被轮询 —— 对大存量来说这是一份实打实更好的信号,因为每分钟去 poll 每台 CPE 根本不可行。内置 MQTT broker;为轻量 CPE 提供 WebSocket 支持。USP 通知实时喂进共享图。
- 完整 USP Agent + Controller 模型
- 内置 MQTT broker(兼容 Mosquitto)
- 为轻量 CPE 的 WebSocket 传输
- 事件驱动 —— 不再有轮询风暴
- STOMP / CoAP 在路线图上
TR-181 数据模型 + 厂商适配器
TR-181 数据模型(Device:2 根对象)是标准词汇 —— LAN 接口、WAN 接口、Wi-Fi 射频、以太端口、IP 转发表、DNS 解析器、DHCP 服务器、QoS 策略、VoIP。Netxol 实现完整发布过的那棵树,并通过按厂商的适配器框架扩展它:华为专属扩展进入华为适配器插件,而不是进入 ACS 核心发行。新增一个讲私有参数树的 CPE 型号,是一次插件投放,不是一次源码打补丁。
- 完整 TR-181(Device:2)实现
- 按厂商的适配器插件框架
- 预装主流厂商的适配器
- TypeScript 写的定制适配器
- 适配器市集在路线图上
TR-143 诊断 —— 从 CPE 拿到速度与延迟
TR-143 的诊断 RPC 让 NMM 能够从任意一台 CPE、按需或定时地跑测速、UDP echo、TCP 吞吐与 ping 测试。结合 NMM 已经在采的 OLT / edge 侧数据,这一步把订户体验诊断闭环:订户来电"我这慢"时,诊断从他的 CPE 打向你的 edge —— 而不是打向某台随机的公网服务器。
- 下载 / 上传 吞吐测试
- UDP echo 与 TCP 吞吐
- ping / IP ping / traceroute
- 定时或按需
- 结果落到订户记录上
零接触开通 —— 运营层面的回报
一台发到订户手里的设备打电话给 ACS,凭预登记库存(序列号 + MAC + 制造商 OUI)完成认证,从共享图上的 CRM 记录读出订户所购服务档次,下载模板化配置(SSID、PSK、VLAN、QoS、VoIP 凭据、TR-069 URL),然后上线 —— 通常在开箱后 15 分钟内,无需上门。成熟运营商那里,零接触是默认装机通路;上门装机是例外。
- 序列号 + MAC + OUI 预登记
- 从 CRM 拉出服务档次
- 按档次模板化配置
- 自动生成 Wi-Fi SSID / PSK
- VoIP 凭据在同一流程中开通
固件活动 —— canary、爬坡、回滚
每家运营商都被坏固件烫过手。Netxol 把固件分发当作一次活动来做:选一版候选 build;ring 0 是实验室里的十台测试设备;ring 1 是全存量的 1%;ring 2 是 10%;ring 3 是 100%。ring 与 ring 之间盯健康信号(CPE 崩溃计数、PON 掉线率、会话流失、订户投诉工单)。一旦回归就自动回滚尚未完成的 ring。每一步、每一台、每一次回滚都留审计。
- 按 ring 分批的 canary 发布
- 健康信号回归时自动回滚
- 每设备完整审计链
- 按 CPE 型号 / 固件家族分组
- 按订户、按型号、或整个存量的回滚
支持的 CPE 目录
Netxol ACS 预装经过测试的适配器,覆盖运营商真正在用的 CPE 品牌:华为(HG 系列、EG 系列、Optixstar)、中兴(F600、F660、F670L、F680、F6600)、烽火(HG6145、HG6543、AN5506)、Nokia(G-140W、G-1425G、G-2425G)、Genexis(Pulse、Live)、Tenda(HG9)、TP-Link(HX510、XC220)、Zyxel(PMG5622)、Cambium(cnPilot、ePMP)、Ubiquiti(UniFi UAP、EdgeRouter)、MikroTik(带 TR-069 客户端的 RouterOS),以及参考 USP-Agent 开源实现。新型号持续加入。
- 华为 HG / EG / Optixstar
- 中兴 F600 / F660 / F670L / F680 / F6600
- 烽火 HG6145 / HG6543 / AN5506
- Nokia G-140W / G-1425G / G-2425G
- Genexis、Tenda、TP-Link、Zyxel
- Cambium、Ubiquiti、MikroTik
- USP-Agent 参考实现
从 GenieACS、Incognito、HDM 迁移过来
多数运营商是从三种前身之一走到 Netxol 的:GenieACS(开源、社区维护、无商业支持)、Incognito Broadband Command Center(重、贵、老)、Nokia HDM(锁死在 Nokia CPE)。Netxol 提供迁移工具:CPE 库存的批量导入(CSV、GenieACS 数据库导出、HDM 导出)、首次 ACS 会话上的状态对齐(一次 Inform 用合并回应,不做出厂重置)、以及一个 dry-run 模式,在提交前把要改什么摆给你看。
- CSV / GenieACS 数据库 / HDM 导出的导入器
- 首次 Inform 时的状态对齐
- Dry-run 模式带变更预览
- 历史固件活动导入
- 订户端零可见中断
多租户 ACS —— MVNO、批发、子公司品牌
Netxol ACS 支持在同一台服务器上做隔离租户:一位向子品牌转售的 MVNO 母方、一位把传输卖给小型 ISP 的批发运营商,或一家跑多个各带客服团队的区域品牌的集团。每一台 CPE、每一份服务档次、每一场固件活动都限定在某个租户里。跨租户查询只对集团管理员身份开放。运营语境见 /solutions/national-carrier。
- CPE / 档次 / 活动级别的租户隔离
- 支持 MVNO 母 + 子品牌
- 批发运营商转售 Netxol 容量
- 按租户的 SLA 与速率限制
- 面向集团运营者的跨租户视图
安全、规模与审计
ACS 处理"把配置推到客户设备"这件安全关键的事 —— 这里一旦被拿下,就是每一位订户都被拿下。Netxol 上的是 TLS 1.3 加证书 pinning、连接请求上的 mTLS、HMAC 签名的开通载荷、按计划轮换的按 CPE 凭据,以及一份完整的审计日志,写清楚每次参数变更、每次固件推送、每次重启。规模上,ACS 单集群支撑几十万台活跃 CPE;容量规划见 /blog/tr-369-usp-adoption-2026。
- TLS 1.3 + 证书 pinning
- 连接请求上的 mTLS
- HMAC 签名的开通载荷
- 按 CPE 的凭据轮换
- 完整审计日志 —— 每一次参数变更
- 单集群几十万活跃 CPE
此 playbook 中您获得的一切。
我们通常将此 playbook 与 Netxol Core X5.
大多数运营商在跨过第一个 1 万用户之后,都会落到 X5 上。算力翻倍、电源冗余,足够的余量覆盖从开通一台 ONT 到关掉当月账目的整条用户生命周期。
已在运行此策略的运营商。
第一次通话中我们经常收到的问题。
上线需要多长时间?
小型部署从拆箱 Core 到第一位付费订户不到一周即可完成;更大规模的推出以周为单位规划,而不是月。
我们需要更换现有硬件吗?
不需要。NOS 附带适配器,支持每一款主流 OLT 和路由器。您保留自己拥有的设备;我们替换其上的工具。
我们的数据会怎样?
默认情况下一切都留在您的 Core 设备上。备份存至您选择的对象存储。除非您启用可选的遥测通道,否则订户数据不会离开您的机架。
我们可以从其他平台迁移吗?
可以——我们运行一个范围明确的迁移项目,配有匹配的数据映射和切换窗口。Standard 版本包括首次迁移。
同一形状的其他故事。
把一台 ONT 寄给用户。他一插上电，NOS 就完成开通、把它绑定到用户档案，并点亮所购套餐 —— 全程无需工程师碰过任何一份配置文件。
阅读成效Huawei、ZTE、FiberHome、CDATA、V-SOL、HSGQ、BDCOM、Nokia 等 —— 全部被抽象在一个厂商无关的接口之后。板卡、端口、环境持续监控;ONT 自动发现(包括未授权接入的);秒级开通,退网时干净回收。光功率 Tx/Rx 阈值可以比订户提前数周察觉到熔接的劣化。
阅读业务成果NOC 在凌晨 3 点做的大多数事情，都是琐碎、乏味且可重复的。NOS 就是为发现这些模式而生：在安全的范围内自动处理，同时让人始终参与到任何不属于常规的事情中。
阅读