# 通信网络自动化：从手动运维到意图驱动 你有没有想过，一个拥有几百万用户、几万基站的移动网络，日常运维是什么体验？ 想象一座城市里有10000盏红绿灯，每盏都需要一个交通警察手动拨动开关。白天调时序、晚上查故障、刮风下雨还要紧急处理——这就是传统通信网络运维的真实写照。每台路由器、每个网元，都需要工程师一条一条敲CLI命令去配置。一个新业务上线，可能要协调几十个团队、改几百台设备，周期以"月"计算。 而今天，行业正在经历一场从"手动驾驶"到"自动驾驶"的革命。这场革命的核心，就是**网络编排与自动化**。 ## 一、问题的根源：为什么传统网络管不住了 ### 1.1 网络复杂度的指数级增长 2G时代，一个基站就是一个基站，配置几个参数就能工作。但到了5G时代，事情完全不同了： | 维度 | 2G/3G时代 | 4G时代 | 5G时代 | |------|----------|--------|--------| | 网元类型 | 3-4种 | 6-8种 | 15+种（虚拟化+容器化） | | 配置参数 | 几十个 | 几百个 | 几千个（含切片参数） | | 业务类型 | 语音+短信 | 语音+数据 | eMBB/URLLC/mMTC三大场景 | | 部署周期 | 数月 | 数周 | 按需实时 | | 运维模式 | 人工CLI | 半自动脚本 | 意图驱动自动编排 | **一个5G核心网**，可能包含AMF、SMF、UPF、PCF、UDM、NRF、NSSF、AUSF、NEF、AF等十几个网络功能，每个都需要独立配置，又要协同工作。如果全靠人工，出错率极高——据统计，**超过60%的网络故障是人为配置错误导致的**。 ### 1.2 传统OSS/BSS的困境 运营商的信息系统分为两大阵营：  > *图表 1* **BSS（Business Support System）** 面向客户和业务：你办理一个5G套餐，从选套餐、下订单、到出账单，都归BSS管。 **OSS（Operations Support System）** 面向网络和运维：基站宕了、网元挂了、流量异常了，OSS负责发现和处置。 传统的问题在于： - **烟囱式架构**：每个厂家有自己的网管系统，互不相通。华为设备用华为的网管，中兴设备用中兴的网管，爱立信设备又是一个网管。运营商需要同时操作5-10个不同的管理平台。 - **CLI/SNMP时代**：配置靠命令行一条条敲，监控靠SNMP协议轮询。一个全网参数变更，可能需要写上千行脚本。 - **被动响应**：出了故障才知道，没有预测能力。平均故障恢复时间（MTTR）以小时计。 这就像一个公司有10个部门，每个部门只说自己的方言，互相听不懂，老板想传达一个指令，得分别找10个翻译。 ## 二、虚拟化革命：NFV与MANO架构 ### 2.1 从硬件到软件的根本转变 2012年，ETSI（欧洲电信标准化协会）提出了一个划时代的概念——**NFV（Network Functions Virtualization，网络功能虚拟化）**。 核心思想非常简单：**把原来跑在专用硬件上的网络功能，变成跑在通用服务器上的软件。** 想象一下：以前你买一台专用防火墙设备，花50万，功能固定，扩容还得再买一台。现在，防火墙变成一个软件包，需要多少就启动多少实例，跑在普通的x86服务器上，像装App一样简单。 $$\text{网络功能成本} = \text{专用硬件成本} + \text{软件许可} + \text{运维成本}$$ NFV之后： $$\text{网络功能成本} = \text{通用服务器分摊} + \text{软件许可} + \text{大幅降低的运维成本}$$ ### 2.2 MANO：虚拟化的"大脑" 有了虚拟化能力，几百个VNF（虚拟网络功能）在数据中心里跑着，谁来管它们？谁来决定哪个VNF部署在哪台服务器上？谁来负责扩容缩容？故障了谁来重启？ 这就是**MANO（Management and Orchestration，管理与编排）** 的职责——它是NFV体系的"总调度中心"。  > *图表 2* 三个核心组件各司其职： | 组件 | 全称 | 职责类比 | |------|------|---------| | **NFVO** | NFV Orchestrator | 公司CEO——决定"做什么"，统筹全局资源 | | **VNFM** | VNF Manager | 项目经理——管理每个VNF的一生（创建、运行、扩容、终止） | | **VIM** | Virtual Infrastructure Manager | 后勤主管——管理服务器、存储、网络等底层资源 | **一个实际的工作流程**： 1. 运营商在BSS上下了一个"为企业客户开通5G专网切片"的订单 2. BSS通过API告诉NFVO：我需要一个包含AMF+SMF+UPF的网络服务 3. NFVO查看资源清单，决定UPF部署在边缘数据中心、AMF/SMF部署在中心DC 4. NFVO指示VIM在两处分别分配计算/存储/网络资源 5. NFVO指示VNFM实例化这三个VNF 6. VNFM启动VNF、注入配置、检查健康状态 7. 全部就绪后，通知BSS：切片已开通 整个过程全自动，**从原来的数周缩短到分钟级**。 ### 2.3 从VNF到CNF：容器化的进一步演进 VNF是虚拟机级别的虚拟化——每个VNF跑在一台虚拟机里。但虚拟机太"重"了，启动慢、资源开销大（一个虚拟机自身就要占1-2GB内存）。 于是行业转向了**CNF（Cloud-Native Function，云原生网络功能）**——用容器（Container）替代虚拟机。5G核心网中的AMF、SMF、UPF等，正在全面容器化。 | 维度 | VNF（虚拟机） | CNF（容器） | |------|-------------|------------| | 启动时间 | 分钟级 | 秒级 | | 资源占用 | 高（需完整OS） | 低（共享宿主OS） | | 粒度 | 整个网元一个VM | 微服务拆分，每个进程一个容器 | | 弹性伸缩 | 慢（需启动新VM） | 快（K8s HPA自动扩缩） | | 管理工具 | OpenStack | Kubernetes | ## 三、意图驱动网络：说"要什么"而非"怎么做" ### 3.1 从命令式到声明式的范式转变 传统的网络配置是**命令式（Imperative）**的——你告诉网络每一步怎么做： ``` router ospf 1 network 10.0.0.0 0.0.0.255 area 0 interface GigabitEthernet0/0 ip address 10.0.1.1 255.255.255.0 no shutdown ``` 你需要知道每台设备的型号、每个接口的名字、每个参数的取值。稍有差错，网络就可能瘫痪。 **意图驱动网络（Intent-Driven Networking，IBN）** 则是**声明式（Declarative）**的——你只告诉网络你想要什么结果： > "保障A分部到总部的视频会议延迟低于50ms，可用性99.99%。" 至于怎么配置路由策略、怎么选路径、怎么调QoS参数——**编排器自动搞定**。 ### 3.2 意图驱动网络的四层架构  > *图表 3* **第1层——意图表达**：这是面向用户的入口。可能是一个Web Portal上的表单，也可能是自然语言接口。TM Forum定义了标准化的Intent API，让意图可以跨厂商传递。 **第2层——意图翻译**：这是IBN的核心难点。把"视频会议延迟低于50ms"这个业务意图，翻译成： - 路由策略（选低延迟路径） - QoS策略（优先转发视频流量的包） - 资源预留（确保带宽充足） - 监控指标（设置50ms阈值的告警） 翻译过程依赖**策略引擎**和**AI模型**。策略引擎中预定义了大量规则，AI模型则通过历史数据学习最优策略。 **第3层——自动执行**：翻译出的配置方案通过SDN控制器下发到网络设备。南向接口从传统的CLI/SNMP，演进到了**NETCONF/YANG**（结构化配置）和**gNMI/gRPC**（流式遥测）。 **第4层——持续保障**：这是IBN区别于传统自动化的关键。传统自动化是"配完就完"，IBN是"配完还要持续盯"——通过实时遥测，持续验证网络行为是否符合意图声明，一旦发现偏差，自动触发修复。 ### 3.3 闭环自动化：网络的自愈能力 闭环（Closed-Loop）是网络自动化的核心机制。它的工作原理可以用一个公式概括： $$\text{Closed-Loop} = \text{Monitor} \rightarrow \text{Analyze} \rightarrow \text{Plan} \rightarrow \text{Execute} \rightarrow \text{Verify}$$ 这就是著名的**MAPE-K循环**（Monitor-Analyze-Plan-Execute with Knowledge）。  > *图表 4* 一个真实场景：某企业客户的5G专网突然出现视频卡顿。 1. **Monitor**：遥测系统检测到UPF的包处理延迟从10ms升到了80ms 2. **Analyze**：AI分析引擎关联多个指标，发现是UPF容器CPU利用率飙到了95%，原因是该企业临时增加了视频监控摄像头数量 3. **Plan**：策略引擎决定自动扩容UPF——启动2个新的UPF实例分担负载 4. **Execute**：编排器通过K8s API自动扩容UPF的Pod数量 5. **Verify**：30秒后，遥测确认延迟已回落到15ms，SLA恢复正常 整个过程从发现到修复，**不超过2分钟**，无需人工介入。传统方式下，这个故障可能要1-2小时才能定位和解决。 ## 四、ONAP：开源自动化的标杆 ### 4.1 ONAP是什么 **ONAP（Open Network Automation Platform，开放网络自动化平台）** 是Linux基金会旗下的开源项目，由AT&T的ECOMP和中国移动的OPEN-O合并而来。它是目前电信行业最全面的自动化编排平台。 ONAP的目标是：**提供一个统一的平台，实现网络服务的全生命周期自动化——从设计、创建、部署到监控、修复、优化。** ### 4.2 ONAP核心架构 ONAP的架构分为两大阶段： | 阶段 | 功能 | 类比 | |------|------|------| | **设计时（Design-Time）** | 定义网络服务模板、策略规则、闭环逻辑 | 建筑师画图纸 | | **运行时（Run-Time）** | 实例化服务、监控运行、闭环自愈 | 施工队按图纸盖楼并维护 | 设计时的关键组件： - **SDC（Service Design & Creation）**：服务设计工具，拖拽式定义网络服务拓扑 - **Policy Engine**：策略引擎，定义什么条件下触发什么动作 运行时的关键组件： - **SO（Service Orchestrator）**：服务编排器，端到端的网络服务生命周期管理 - **AAI（Active & Available Inventory）**：资源清单，记录网络中所有资源和它们的关系 - **DCAE（Data Collection Analytics & Events）**：数据采集与分析，AI/ML的"眼睛" - **VID（Virtual Integration Deployment）**：部署执行接口 - **APPC（Application Controller）**：应用控制器，对VNF进行配置和操作 ONAP的典型工作流： 1. 在SDC中设计一个"5G eMBB切片"的服务蓝图 2. 定义闭环策略：当UPF CPU>80%时，自动扩容 3. 用户通过BSS下单，触发SO创建切片实例 4. SO通过AAI查询可用资源，协调VID/APPC完成VNF部署 5. DCAE持续监控，一旦触发策略条件，自动执行闭环修复 ### 4.3 ONAP与O-RAN SMO的关系 O-RAN（Open RAN）引入了一个新组件——**SMO（Service Management and Orchestration，服务管理与编排）**，专门负责O-RAN无线接入网的管理。 SMO的功能与ONAP有重叠但也有区别： | 维度 | ONAP | O-RAN SMO | |------|------|-----------| | 管理范围 | 端到端（核心网+传输+云） | 无线接入网（O-CU/O-DU/O-RU） | | 接口 | TMF Open API / REST | O1/O2/A1接口 | | AI/ML | DCAE（数据分析） | Non-RT RIC（非实时RIC） | | 定位 | 全局编排器 | RAN域编排器 | 在实际部署中，SMO可以作为ONAP的子组件或通过API与ONAP协同。ONAP负责全局编排，SMO负责RAN域的精细化管控。 ## 五、TM Forum ODA：运营商的数字化转型蓝图 ### 5.1 从eTOM到ODA的演进 TM Forum（电信管理论坛）长期以来定义了运营商的标准流程框架——**eTOM（enhanced Telecom Operations Map）**。eTOM定义了运营商"应该做哪些事"：客户管理、计费、网络运维、供应链管理等。 但eTOM只是流程框架，没有告诉运营商"怎么做"。于是TM Forum推出了**ODA（Open Digital Architecture，开放数字架构）**——它提供了从流程到实现的技术蓝图。 ### 5.2 ODA的核心理念 ODA的核心理念是**可组合性（Composability）**——把庞大的单体OSS/BSS系统，拆解为一组可独立部署、可组合的微服务组件，通过标准Open API互联互通。 ``` 传统模式： ┌─────────────────────────────────────┐ │ 单体BSS系统 │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │CRM │ │计费 │ │订单 │ │产品 │ │ │ │ │ │ │ │管理 │ │目录 │ │ │ └─────┘ └─────┘ └─────┘ └─────┘ │ │ 紧耦合，改一个牵动全部 │ └─────────────────────────────────────┘ ODA模式： ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │CRM │ │计费 │ │订单 │ │产品 │ │微服务│ │微服务│ │微服务│ │微服务│ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └───────┴────┬───┴───────┘ Open API 松耦合，独立升级 ``` ODA定义了**解耦组件清单**——每个组件对应一个TMF Open API。运营商可以"混搭"不同供应商的组件：A厂商的计费、B厂商的CRM、C厂商的订单管理，通过标准API连接。 ### 5.3 对工程师的实际影响 如果你是运维工程师或系统集成工程师，ODA意味着： - **不再被单一厂商锁定**：各个组件可以独立替换 - **API成为核心技能**：TMF Open API（如TMF622订单管理、TMF620产品目录）是标准接口 - **DevOps思维**：CI/CD流水线、微服务部署成为日常工作 ## 六、O-RAN与rApp/xApp：无线网络的智能化 O-RAN架构引入了**RIC（RAN Intelligent Controller，无线智能控制器）**，把AI能力注入无线接入网： | 组件 | 实时性 | 部署位置 | 功能 | |------|--------|---------|------| | **Non-RT RIC** | >1秒 | SMO内 | 制定无线策略、训练AI模型 | | **Near-RT RIC** | 10ms-1秒 | 部署在边缘 | 实时无线资源优化 | Non-RT RIC上运行**rApp**（策略应用），Near-RT RIC上运行**xApp**（实时控制应用）。它们通过**A1接口**交互：Non-RT RIC下发策略，Near-RT RIC根据策略实时控制。 典型的应用场景： - **xApp：负载均衡**——实时检测各小区负载，将用户从拥挤小区引导到空闲小区 - **rApp：SLA保障**——根据历史流量模式训练模型，预测拥塞并提前制定策略 ## 七、实战连接：工程师视角 ### 7.1 调试中的常见场景 **场景1：VNF实例化失败** 在MANO环境中，VNF实例化可能失败。排查思路： 1. 查看VNFM日志——是镜像拉取失败、资源不足还是配置错误？ 2. 查看VIM资源池——是否还有足够的CPU/内存/存储？ 3. 查看网络连通性——VNF需要的虚拟网络是否已创建？ **场景2：闭环未触发** 定义了"CPU>80%自动扩容"的策略，但实际没有触发： 1. 检查遥测数据——是否正确采集到了CPU指标？ 2. 检查策略引擎——阈值配置是否正确？策略是否激活？ 3. 检查编排器——是否收到了策略触发指令？执行是否成功？ **场景3：意图不收敛** 声明了"延迟<50ms"的意图，但系统反复修复又反复违反： 1. 可能是资源确实不足——当前容量无法满足需求 2. 可能是意图冲突——有其他意图占用了相同资源 3. 需要人工介入调整意图或扩容基础设施 ### 7.2 常见误解 | 误解 | 实际 | |------|------| | "自动化会取代所有运维工程师" | 自动化取代的是重复性操作，工程师需要转型为策略定义者和异常处理者 | | "意图驱动就是自然语言配置" | 当前主要是结构化的声明式API，自然语言只是前端交互方式之一 | | "ONAP部署了就实现自动化了" | ONAP只是平台，还需要大量的服务蓝图设计、策略定义、数据训练 | | "闭环等于无人值守" | 闭环处理已知场景，未知异常仍需人工干预 | | "NFV=软件化" | NFV不只是软件化，关键是编排能力和弹性伸缩能力 | ## 常见问题 **Q: ONAP和OSM有什么区别，运营商该选哪个？** A: ONAP和OSM都是开源MANO实现。ONAP由Linux基金会主导（AT&T、中国移动等参与），功能全面但复杂度高，适合大型运营商。OSM由ETSI主导，轻量级，适合中小型运营商或特定场景。实际上很多运营商并非二选一——核心编排可能用ONAP，特定域管理可能用OSM，通过API协同。 **Q: 意图驱动网络和SDN是什么关系？** A: SDN是基础设施层面的技术——把网络的控制平面和数据平面分离，提供集中控制能力。意图驱动网络是更高层次的理念——它可能利用SDN作为执行手段之一，但还涉及AI翻译、策略引擎、持续验证等SDN不具备的能力。简单说：SDN是"手"，IBN是"大脑"。 **Q: 闭环自动化的"闭环"到底是什么意思？** A: "闭环"是指从监控到执行再到验证形成一个自我反馈的循环——系统能自动发现问题、分析原因、执行修复、验证结果。与之对应的是"开环"——系统只负责检测和告警，修复动作需要人工执行。闭环的关键是**验证环节**——修复后要确认效果，如果没修复就继续调整。 **Q: 5G网络切片的编排与传统VPN业务开通有什么本质区别？** A: 传统VPN是静态的——开通后配置固定，除非手动修改。5G网络切片是动态的——切片的资源配额、QoS参数、甚至拓扑结构都可以根据实时需求动态调整。这需要MANO具备实时感知和动态编排能力，远超传统业务开通的复杂度。 **Q: 普通工程师如何入门网络自动化？** A: 建议路径：①学习Python和网络编程基础（NETCONF/RESTCONF/YANG）；②了解NFV/MANO概念和ETSI架构；③动手实践——部署一个OSM或轻量级ONAP环境；④学习TM Forum Open API标准；⑤关注O-RAN RIC和xApp/rApp开发。YANG模型和REST API是两个最核心的技术基础。 ## 参考来源 1. [ETSI NFV MANO Architecture Explained](https://www.telecomtrainer.com/mano-architecture-explained-nfv-orchestration-vnfm-and-vim-in-5g-networks/) — NFV MANO三大组件原理与5G应用详解 2. [TM Forum Open Digital Architecture](https://www.tmforum.org/open-digital-architecture/) — ODA标准框架与组件定义 3. [ONAP Architecture Documentation](https://docs.onap.org/en/latest/ecosystem/architecture/index.html) — ONAP官方架构文档 4. [Intent-Based Network Automation for Agile Telecom Services](https://www.tietoevry.com/en/blog/2025/12/intent-based-network-automation/) — 意图驱动网络自动化在电信中的应用 5. [O-RAN SMO and RIC Architecture](https://www.telecomtrainer.com/inside-the-o-ran-architecture-understanding-ric-smo-and-open-interfaces-in-next-gen-ran/) — O-RAN架构中SMO与RIC的原理详解 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。