书名:迈向自智网络时代:核心网自动驾驶网络
ISBN:978-7-115-67958-1
本书由人民邮电出版社发行数字版。版权所有,侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用,未经授权,不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟,与我们共同保护知识产权。
如果购买者有侵权行为,我们可能对该用户实施包括但不限于关闭该帐号等维权措施,并可能追究法律责任。
主 编 朱浩鹏 郭洪志
副 主 编 田 江 李静雅 李 雷
责任编辑 郭 家
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线:(010)81055410
反盗版热线:(010)81055315
本书立足5G核心网,眺望6G核心网,预测未来核心网的关键特征、网络架构演进要素,以及在演进过程中可能遇到的挑战。本书重点介绍核心网自动驾驶网络关键解决方案,以实现核心网自动驾驶愿景为目标,尝试定义高稳、智简、质优三大价值主张,并列举典型优秀实践案例,阐明应如何推行和落实相关措施。此外,解读核心网自动驾驶网络关键技术,从网络新架构和新技术两大方面,论证构建关键的产品能力所需的中长期技术准备。最后,面向6G,展望核心网自动驾驶网络的未来。
本书可为从事核心网、智能化领域研究的专业人士,以及对数据通信技术感兴趣的广大读者提供参考。
主 编:朱浩鹏 郭洪志
副 主 编:田 江 李静雅 李 雷
委 员:姚弋宇 雷彦辉 魏 宏 董晓刚 梁永军
丁 烨 周朝富 张 帆 李 峰 徐日东
韩培丽 王 栋 梁 鹏 霍 元 胡 翔
胡永昌 王云芳 廉晶晶 韩 琼 黄西娟
杨馨宇 王 斌 付鹏伟
技术审校:黄 河 张 勇
朱浩鹏:华为Fellow,先后担任华为核心网移动软交换解决方案SE Leader、核心网首席SA、核心网首席架构师、核心网架构与设计部部长等。主要负责华为核心网产品线关键架构和技术竞争力构建,引领产品线架构创新和关键技术突破,确保核心网架构定义和解决方案整体竞争力在业界持续领先。拥有20多年核心网领域工作经验,主导华为R99和R4移动交换机、One Network、VoLTE/IMS、NFV/电信云原生、5G核心网架构和解决方案设计、“磐石”可靠性方案、核心网三大智能解决方案、AISF智能体服务平台、AI推理平台等方案的架构定义和关键竞争力构筑。担任ETSI NFV、Layer 123等国际重大峰会主题演讲嘉宾、中国软件研发管理行业技术峰会联席主席。作为主要发明人,其70多项专利获得国内授权,32项专利完成PCT国际申请。
郭洪志:华为iMaster MAE-CN产品首席架构师,核心网运维领域的技术领军者。拥有20年核心网运维与智能化技术研发经验,致力于推动电信网络运维从“人工干预”向“完全自治”演进。作为华为核心网自动驾驶技术演进的关键推动者,先后主导了U2020、MANO、MAE-CN三大代际产品的体系架构设计,构建了行业领先的网络运维技术栈,打造了CDCT全流程自动化、用户面设备即插即用部署、云网数字孪生仿真等解决方案。目前正带领团队将AI大模型技术引入故障诊断领域,该团队研发的智能故障处理Agent实现了核心网运维效率的突破性提升。
田江:华为核心网云化网络运维专家。拥有10年核心网全场景运维经验,专注于云原生网络架构设计与智能运维系统开发领域。参与构建核心网运维架构体系,完成多代核心网运维架构的迭代升级与优化。在电信云运维领域,主导设计基于AI的硬件失效预测模型及多模态故障诊断算法,实现运维场景的智能化突破。主导云化网络全生命周期管理、智能运维系统设计及AI技术工程化落地,具有大型网络运维工程实施经验。
李静雅:华为核心网领域信息体验高级工程师。拥有多年核心网信息架构设计经验,主导设计多个产品资料体系和技术专题,包括iMaster MAE-CN资料体系、ADN技术画册等。
李雷:华为核心网运维智能技术规划专家。拥有18年核心网运维经验,曾在华为爱尔兰研究所负责ADN技术规划,并长期专注于通信网络运维智能化、AIOps及大语言模型在运维领域的应用研究。拥有多年核心网运维研发与技术规划经验,主导或参与华为核心网智能运维技术项目的规划与落地,参与多项国家级/企业级智能化运维项目,推动AI技术在故障预测、根因分析、自动化处置等场景的规模化应用,并与高校及研究机构保持紧密合作,共同探索运维智能化的前沿趋势。

通信网络作为构建数字经济的核心基础设施,承载着推动人类社会迈向智能时代的重要使命。回顾我国通信产业的发展历程,从1G时代的空白到5G时代的引领,核心网始终是技术演进的关键支撑点。当前,随着从5.5G向6G迈进,网络架构正经历前所未有的变革,云化、智能化、空天一体化成为核心网发展的三大趋势,而自智网络正是这一变革的重要突破口。
在5G规模商用和6G研究加速的背景下,核心网面临着运维复杂度激增、业务敏捷性不足、体验确定性难以保障等挑战。传统依赖人工经验、逐层排查的运维模式已难以适应未来网络的需求。自智网络的提出,正是为了解决这一矛盾,通过AI、数字孪生、意图驱动等技术的深度融合,实现网络的自感知、自决策、自优化,最终迈向L5完全自治。
本书系统地阐述了核心网自智化的演进路径,从架构重生、高稳敏捷、体验保障到6G前瞻,层层递进,既有理论高度,又有实践深度。本书不仅剖析了云原生、分布式AI、智能编排等关键技术,还结合企业的实际案例,展示了自智网络在提高运维效率、降低故障率、优化用户体验等方面的显著成效。这些探索为行业提供了宝贵的参考,也为我国在6G时代继续保持技术领先奠定了坚实基础。
自智网络不仅是技术的革新,更是产业生态的重构。它要求运营商、设备商、标准组织、研究机构等各方协同创新,共同推动网络向智能化、服务化、开放化方向发展。中国通信标准化协会(China Communications Standards Association,CCSA)一直致力于推动通信技术的标准化和产业化,自智网络作为未来网络的核心,也将成为我们重点关注的领域之一。
期待本书能够为行业同仁提供有价值的参考,助力我国通信产业在智能化转型中把握机遇、迎接挑战。让我们携手共进,推动核心网向更高水平的自智演进,为智能世界的全面到来贡献力量!

中国通信标准化协会理事长

通信网络如同数字时代的血脉,每一次数字脉动都承载着人类文明进步的能量。从1G到5G,核心网始终是通信系统的“中枢神经”,默默支撑着全球数十亿用户的无缝连接。然而,随着5.5G向6G演进,云化、智能化和空天一体化带来的复杂度呈指数级增长,传统核心网正面临系统性挑战——运维效率与业务敏捷性的矛盾、网络复杂性与体验确定性的失衡,以及如何实现理想中的高稳定性、高可靠性、零中断网络等,这些难题急需一场从“网络+人+工具”到“智能网络+人”的范式革命。
在实践中,华为深刻认识到网络智能化不仅是技术演进,更是运营商商业成功的战略选择。过去十年,核心网经过NFV云化转型,解耦了硬件与软件,实现了以软件为核心的代际转变;而未来十年,智能化将成为核心网代际跃迁的关键标志。本书试图回答一个重要问题:如何让核心网从云化时代的“功能执行者”进化为智能时代的“认知决策者”,最终成为主管数字世界万物互联的智能体。
让我们展开这场探索之旅。以架构重生为基石,结合云原生与智能内核,可以让网络具备“自感知”能力。华为ICNMaster通过AI智能体和数字孪生技术,实现了业务发放效率的倍增、故障自动化处理和高效网络自愈,这些表现是“自智网络”雏形的实证,而高稳与敏捷的平衡是智能化的突破点。“数字大脑+机械手臂”的协同范式,证明智能技术不仅能提高效率,更能重构可靠性标准。体验确定性则是价值锚点。基于业务确定性体验保障QoE体系和基于业务类别的智能识别的优化自闭环,标志着业务体验从“尽力而为”到“确定性体验保障”的质的变化。对核心网及网络智能化真正的颠覆在于认知跃迁。当AI原生内核与空天算力深度融合,核心网将突破原有的网络属性,演化为具备意图理解、自主演进的智能体。这种智能体能够基于业务对网络的需求,自主调度和管理网络资源,实现以业务为核心的自智网络。华为提出的AN L4蓝图已指明网络智能化的发展路径:2025—2027年实现单域自治,2028—2030年完成跨域协同,最终构建“网络即服务”的终极形态。在这个发展过程中,高稳网络能力所体现出的从“故障不宕机”向“业务永在线”的五级跃升,揭示了网络智能化的本质是对人类服务能力的升维。
作为亲历者,我们深知这场变革中每一项挑战的艰巨性。云原生转型带来的运维复杂度、OTT业务创新倒逼的敏捷需求、6G全息通信提出的确定性挑战……每个问题都需要打破思维惯性与技术边界。但正是这些挑战,让通信人始终站在网络技术革命的潮头。本书凝聚了华为与全球领先运营商在实践中沉淀的智慧结晶,从架构设计到算法创新,从运维范式到商业逻辑,力求为行业提供可复用的方法论。
站在5.5G与6G交替的关口,我们比任何时候都更接近“自动驾驶网络”的愿景。这不仅是华为“把复杂留给自己,把简单带给客户”理念的延续,更是整个产业拥抱智能世界的集体宣言。期待与全球同仁携手,以确定性技术应对不确定性挑战,共同开启通信网络的下一个黄金十年。
华为云核心网MAE领域总裁

核心网是通信网络的关键部分,用于处理和转发用户数据,并提供数据上网、语音电话、视频电话、短信和消息等基础通信服务。核心网连接了边缘网络(如无线接入网)和其他网络(如互联网),承担着用户鉴权、数据传输、路由和业务控制等核心功能。
在过去的20年,作为网络架构变革的先锋,核心网实现了全面的IP化和云原生,网络容量和网络功能得到了极大的丰富,已成为支撑全球移动互联网可靠的基础设施,在国计民生中发挥了核心作用。在5.5G时代浪潮下,核心网朝着云原生架构和全融合趋势持续演进,云化网络规模与复杂度快速提升。同时,核心网还需要通过业务创新和网络优化,持续提升用户业务体验。因此,亟须引入先进的智能化技术,提高核心网的可靠性、韧性以及运维和运营效率。
为实现“三自”(自配置、自修复、自优化)的通信网络,TM Forum提出的自智网络成熟度模型,依据网络自智化能力,将自智网络划分为“L0人工运维、L1系统辅助、L2部分自治、L3有条件自治、L4高度自治、L5完全自治”6个代际。TM Forum提出的自智网络理念得到了行业的广泛认可和积极呼应,目前已从“统一理念”阶段进入“标准立项”阶段,各大标准组织均在快速推进标准的立项。核心网处于网络中心位置,网络位置高、运维难度大,基本实现了IP化和云原生,部分领先的运营商已将核心网作为自智网络战略落地的重点,并积极向前推进。
在网络高度复杂、业务高度敏感的云原生核心网系统中,要想把AI的价值充分发挥出来,真正解决核心网面临的重大挑战,就需要在AI技术和核心网技术两个方向上持续展开跨域的基础理论、网络架构、关键技术和算法以及商业模式的研究与创新,同时也需要学术界和运营商、设备制造商等各界同仁的共同努力。现将华为核心网自动驾驶网络的最新研究成果和实践知识整理成书,与业界共享,希望与更多的学者和专家一起推动核心网自动驾驶目标早日实现,加速核心网的智能化全面转型,持续推进通信行业的健康发展。
华为Fellow、核心网首席架构师

通信网络作为数字社会的神经网络,始终承载着人类文明进步的脉搏。从模拟通信到数字革命,从语音传输到万物智联,核心网默默守护着全球数十亿用户的每一次通话、每一条数据、每一帧影像。在5.5G向6G演进的历史性跨越中,网络架构正经历着云化、智能化和空天一体化的三重变革,传统核心网面临着运维复杂度激增、业务敏捷性不足、体验确定性难以保障等系统性挑战。
据TM Forum研究,全球91%的电信运营商已将自智网络列为战略优先级,相关投资规模将以19.6%的年复合增长率持续攀升。这种战略转向的背后,是5.5G时代多制式网络融合、云原生架构解耦、实时沉浸业务爆发带来的运维范式重构。人工配置耗时以周计、故障定位依赖专家经验、业务上线周期无法匹配OTT(Over The Top,通过互联网提供应用服务)创新速度等痛点,正倒逼核心网向自动驾驶网络演进。
本书以自动驾驶网络为技术主线,系统解构核心网智能化转型的路径与方法,通过四维演进视角展开讨论。
第一维度,架构重生。从NFV(Network Function Virtualization,网络功能虚拟化)云化到IntelligentCore(智能内核),剖析云原生架构如何通过数字孪生、意图引擎、分布式AI(Artificial Intelligence,人工智能)代理等创新技术,构建具备自感知、动态调优能力的神经中枢。华为实践表明,该架构可使业务发放效率提高8倍,重大故障自愈率达92%。
第二维度,聚焦网络高稳性与业务敏捷性的双重突破。通过 “数字大脑 + 机械手臂” 的协同范式,实现分钟级业务部署与秒级故障定位。结合3D全息运维、风险态势感知等创新方案,将变更回退率从行业平均水平15%降至0.3%。
第三维度,突破传统 “尽力而为” 的服务模式,基于用户行为建模和QoE(Quality of Experience,体验质量)数字孪生技术,为工业控制、元宇宙等场景提供确定性体验保障。
第四维度,展望6G时代沉浸式全息通信、星地协同计算等场景,勾勒 “网络即服务” 的终极形态,当AI原生内核与空天算力网络深度融合,核心网将进化成具备认知思维的智能体,实现从 “人驾网络” 到 “网赋万物” 的范式颠覆。
全书共5章,层层递进。
● 第1章:以史为鉴,系统回顾核心网从程控交换到云原生IntelligentCore的代际跃迁,解析移动通信业务变迁对网络架构的驱动作用。重点探讨虚拟化、服务化架构等技术如何推动核心网从硬件绑定向软件定义转型,为后续智能化演进奠定基础。
● 第2章:构建愿景,基于行业趋势分析,提出 “三零” (零等待、零接触、零故障)服务目标。从网络自动化、网络高稳性、体验最优化3个维度,构建包含意图驱动、智能防御、数字孪生等核心能力的演进蓝图,揭示自动驾驶网络对运维范式的重构价值。
● 第3章:聚焦实战,针对云原生转型带来的运维挑战,提出智能调度、多维校验等关键技术路径。重点阐述如何通过AI技术实现云化资源管理、业务变更风险控制及客户体验保障。
● 第4章:技术破局,解析数字孪生、网络仿真、意图驱动、运维大模型等核心技术,阐述其如何支撑网络IntelligentCore建设,如何通过架构层创新实现算力资源动态调优、自然语言交互配置等能力,展现从传统运维向认知决策跨越的技术突破。
● 第5章:智启未来,展望6G时代全息通信等新兴场景,提出认知智能体发展、空天一体化等演进方向。探讨数字孪生网络与物理网络的深度协同机制,描绘NaaS(Network as a Service,网络即服务)的终极形态及其对产业生态的重塑作用。
在数字化转型的深水区,核心网自动驾驶不仅是技术命题,更是商业战略。期待本书能成为产业同仁穿越技术迷雾的指南针,让我们共同开启通信网络的下一个黄金十年。

核心网位于通信网络的核心控制层,负责对接入用户的认证、话务路由、目的地寻址、计费、业务逻辑管理等,是整个通信系统的大脑。每一个人的每一次通话,每一次移动网络的数据访问请求,都会经过核心网。回顾过去的几十年,核心网经历了多个重要的演进和发展阶段。下面以移动通信网络为例,从通信网络代际演进和网络使能技术的角度简单回顾核心网驱动下的移动通信业务变迁,如图1-1所示。

图1-1 核心网驱动下的移动通信业务变迁
注:GSM为Global System for Mobile Communications,全球移动通信系统;CDMA为Code Division Multiple Access,码分多址;WCDMA为Wideband Code Division Multiple Access,宽带码分多址;TD-SCDMA为Time Division-Synchronous Code Division Multiple Access,时分同步码分多址;LTE为Long Term Evolution,长期演进技术;NR为New Radio,新空口。
具有2G核心网的手机初期只有语音、短消息等功能,组网较为简单。2G核心网主要采用CS(Circuit Switching,电路交换)域,即不同用户独占各自分配到的资源数据,如图1-2所示。
2G的移动核心网部分主要包括MSC/VLR、HLR/AUC、EIR等。MSC是核心网的核心组成,实现交换功能,包括移动用户寻呼接入、信道分配、呼叫接续、话务量控制、计费和基站管理等。VLR是一个动态数据库,存储一个MSC服务区域内当前来访用户的信息。例如,通过各种位置更新流程,实时更新并记录用户当前的位置信息,从而保证MSC在呼叫过程中能够在该用户所处位置区的所有小区或服务区进行搜索,以快速、准确地找到被叫用户。HLR是一种存储本地用户信息的数据库,一个HLR能够控制若干移动交换区域。HLR存储所有签约移动用户的位置、业务数据、账户管理等信息,并可实时地提供对用户位置信息的查询和修改操作,以及实现各类业务操作,包括位置更新、呼叫处理、鉴权和补充业务等,完成移动通信网络中用户的移动性管理。AUC是用于鉴定用户身份是否合法、保存用户密钥的数据库,本质上和HLR数据库没有什么区别。EIR是存储移动设备参数的数据库,用于对移动台设备鉴别和监视,并拒绝非法移动台入网。

图1-2 2G核心网架构
注:BTS为Base Transceiver Station,基站收发台;BSC为Base Station Controller,基站控制器;MSC为Mobile Switching Center,移动交换中心;VLR为Visitor Location Register,漫游位置寄存器;HLR为Home Location Register,归属位置寄存器;AUC为Authentication Center,鉴权中心;EIR为Equipment Identity Register,设备识别寄存器;ISDN为Integrated Service Digital Network,综合业务数字网;PSTN为Public Switched Telephone Network,公用电话交换网;PLMN为Public Land Mobile Network,公共陆地移动网。
其他相关设备或网络包括BTS、BSC、ISDN、PSTN和PLMN。BTS通过空口传送业务和信令。BSC是BTS的管理者,负责资源分配,建立终端和BTS的连接,一个BSC可以控制一个或多个BTS。ISDN是一个数字电话网络国际标准,是一种典型的CS网络系统。PSTN是一种旧式电话系统。PLMN是由政府所批准的经营者,是以为公众提供陆地移动通信业务为目的而建立和经营的网络。该网络通常与PSTN互联,形成整个地区或国家规模的通信网。
2.5G核心网增加了PS(Packet Switching,分组交换)域,实现了手机上网的功能,如图1-3所示。

图1-3 2.5G核心网架构
注:SGSN为Serving GPRS Support Node,GPRS服务支持节点;GGSN为Gateway GPRS Support Node,GPRS网关支持节点。
PS域包括SGSN和GGSN两个网元。SGSN主要实现移动性管理、会话管理、分组数据包的路由与转发、计费、短消息和QoS(Quality of Service,服务质量)管理等功能。GGSN是终端接入外部分组网络的网关,从外部网的角度来看,GGSN就像是可寻址GPRS(General Packet Radio Service,通用分组无线服务)网络中所有用户IP地址的路由器。
相比2G核心网,3G核心网除了提供传统的语音和短消息业务,还提供高速的数据服务。由于网络容量快速扩大,3G核心网可以很好地支持图片、音乐、视频等多媒体信息业务以及上网浏览网页等功能。3G核心网主要包括WCDMA系统、CDMA2000系统和TD-SCDMA系统。
3G核心网发展中的一个重要里程碑是3GPP(3rd Generation Partnership Project,第三代合作伙伴计划)Release 5技术规范版本的发布,标志着3G核心网向全IP架构演进,IP技术成为所有信令消息的承载技术,改变了原有呼叫流程,3G核心网架构如图1-4所示。

图1-4 3G核心网架构
注:BSS为Base Station Subsystem,基站子系统;PCU为Packet Control Unit,分组控制单元;ATM为Asynchronous Transfer Mode,异步传输方式;MGW为Media Gateway,媒体网关;VMSC为Visited Mobile Switching Center,被访移动交换中心;GMSC为Gateway Mobile Switching Center,关口移动交换中心;HSS为Home Subscriber Server,归属用户服务器;SS7为Signaling System Number 7,七号信令系统;UTRAN为Universal Telecommunication Radio Access Network,通用电信无线接入网;RNC为Radio Network Controller,无线网络控制器;CG为Charging Gateway,计费网关;BG为Border Gateway,边界网关;IMS为IP Multimedia Subsystem,IP多媒体子系统;MGCF为Media Gateway Control Function,媒体网关控制功能;P-CSCF为Proxy-CSCF,代理呼叫会话控制功能;MRFC为Media Resource Function Controller,媒体资源功能控制器;S-CSCF为Serving-CSCF,服务呼叫会话控制功能;MRFP为Multimedia Resource Function Processor,多媒体资源功能处理器;SCE为Service Creation Environment,业务生成环境;SCP为Service Control Point,业务控制点;SMS为Short Message Service,短消息业务。
3G核心网架构方面的一个优化是控制面和用户面分离。控制面是管理和控制用户会话信令的一个逻辑平面;用户面是转发用户的实际业务数据(包括语音数据、上网的多媒体等数据)的一个逻辑平面。
CS域由MSC演进为MSC服务器和MGW的分离结构,同时增加IMS域,增强IP QoS能力,支持端到端的IP多媒体业务。VMSC服务器和GMSC服务器是控制面实体,主要实现MM(Mobility Management,移动性管理)、CM(Call Management,呼叫管理)、MGC(Media Gateway Controller,媒体网关控制器)等功能。MGW是承载面实体,主要实现语音及媒体流的交换,以及提供各种资源,比如编解码器、回波抵消器、放音和收号资源等。
PS域的分离指的是之前耦合在SGSN和GGSN上的控制面与用户面功能的逻辑分离:SGSN上移,只承担控制面的功能,即用户会话管理的信令传输;然后,接入网侧的RNC和GGSN直连,传输用户面的用户实际业务数据,这提高了数据传输效率,并使得网元部署更加灵活。
IMS域提供IP多媒体服务的标准化架构框架,包括CSCF(Call Session Control Function,呼叫会话控制功能)、MGCF、MRFC和MRFP。CSCF主要实现注册、鉴权、会话控制、业务触发、拓扑隐藏、QoS控制、NAT(Network Address Translation,网络地址转换)穿透、安全管理等功能;MGCF使IMS用户和CS用户之间可以实现通信;MRFC根据来自AS(Application Service,应用服务)和S-CSCF的信息操控MRFP,使MRFP提供用户面资源,完成输入媒体流的混合和处理等。
4G核心网采用LTE,实现了更高速的数据传输和更低的时延。4G核心网的特点是支持更多的移动互联网应用,如视频应用等,同时引入了虚拟化等技术,实现了软硬件的分层解耦,如图1-5所示。

图1-5 4G核心网架构
注:EPC为Evolved Packet Core,演进分组核心网;UMTS为Universal Mobile Telecommunications System,通用移动通信系统;MME为Mobility Management Entity,移动性管理实体;PCRF为Policy and Charging Rules Function,策略和计费规则功能;E-UTRAN为Evolved UMTS Terrestrial Radio Access Network,演进型UMTS陆地无线接入网;Serving GW为Serving Gateway,服务网关;PDN GW为Packet Data Network Gateway,分组数据网络网关;PDSN为Packet Data Serving Node,分组数据服务节点。
4G核心网包括MME、HSS、PCRF、Serving GW和PDN GW等模块。MME只负责处理信令相关的流程,包括控制面的移动性管理、用户上下文和移动状态管理、分配用户临时身份标识等。HSS存储了LTE网络中所有与业务相关的用户数据,提供用户签约信息管理和用户位置管理功能,类似2G核心网和3G核心网中的HLR。PCRF实现动态QoS策略控制和动态的基于流的计费控制等功能。Serving GW是接入网络的不同用户锚点,负责用户在不同接入技术之间移动时用户面的数据交换,以屏蔽不同接入网络的接口。PDN GW指的是采用分组协议的数据网络,泛指移动终端访问的外部网络,即与外部IP网络连接的网元。
5G核心网的架构发生很大变化,采用了SBA(Service-Based Architecture,基于服务的架构),借鉴了微服务的概念,把原来具有多个功能的整体拆分成多个具有独立功能的个体,如图1-6所示,每个个体对外提供自己的服务。就外部表现来看,网元数量大幅增加,模块化拆分的方式给万物互联的5G核心网带来了很多益处。5G核心网具有更大的带宽和更低的时延,实现了更优异的网络灵活性和可编程性,能支撑工业智能化产业升级转型,如智能交通、智能制造、智能矿山、智能港口等。

图1-6 5G核心网架构
注:NSSF为Network Slice Selection Function,网络切片选择功能;NEF为Network Exposure Function,网络开放功能;NRF为Network Repository Function,网络仓储功能;PCF为Policy Control Function,策略控制功能;UDM为Unified Data Management,统一数据管理;AUSF为Authentication Server Function,认证服务器功能;AMF为Access and Mobility Management Function,接入和移动性管理功能;SMF为Session Manager Function,会话管理功能;UE为User Equipment,用户设备;RAN为Radio Access Network,无线电接入网,业界常称无线接入网;UPF为User Plane Function,用户面功能;DN为Data Network,数据网络。
在5G核心网中,各个模块的功能如下。
NSSF根据用户设备的请求、网络切片订阅信息及策略,选择并管理适用的网络切片实例,确保用户接入与其服务需求匹配的切片。
NEF具有开放各个NF(Network Function,网络功能)网元的能力,可以转换内外部信息。
NRF提供服务注册以及服务间互相找到对方的IP地址并进行通信的功能。比如SMF要和AMF通信,就要通过NRF找到与SMF对应的AMF,类似IT(Information Technology,信息技术)领域DNS(Domain Name System,域名系统)的功能。
PCF为控制面提供策略控制,继承PCRF的功能。
UDM负责统一管理用户数据,包括用户身份、签约信息、鉴权数据等,类似4G核心网中的HSS。
AUSF专门处理用户鉴权请求,其接收来自AMF的认证需求后,向UDM获取用户密钥并完成鉴权计算,确保用户身份的合法性。AUSF的核心作用是保障5G核心网接入的安全性。
AMF继承MME中NAS(Non-Access Stratum,非接入层)的接入控制功能。
SMF负责用户会话的管理和控制,继承MME、SGW-C(Serving Gateway Control Plane,服务网关控制面)、PGW-C(Packet Data Network Gateway Control Plane,分组数据网关控制面)的会话管理功能。
UPF负责用户面分组数据的路由转发等功能,继承SGW-U(Serving Gateway User Plane,服务网关用户面)和PGW-U(Packet Data Network Gateway User Plane,分组数据网关用户面)的用户面功能。
前面以网络代际为线索,回顾了核心网的网络业务、技术,以及核心网架构的演进历程。下面展望未来,介绍核心网面临的机遇与挑战。
近几年,AI技术飞速发展,在各行各业都得到了广泛的应用,AI技术如何与核心网结合,成为下一代核心网的关键命题。一方面,华为主张将AI技术应用于核心网,解决核心网代际叠加演进造成的网络运维复杂等问题;另一方面,华为也希望下一代核心网的网络架构能够更好地服务于各种AI业务。
以下从AI4NET(AI for Network,面向网络的AI)和NET4AI(Network for AI,面向AI的网络)两个方面分析AI原生的下一代核心网。
先分析AI4NET。由于网络的数据安全性、隐私性要求高,因此数据不应该放在公有云(包括运营商的公有云,如移动云)上,而应该放在网络云上进行训练、推理,确保安全、可靠。AI4NET的本质是引入AI服务网络,AI的责任边界在网络部,从数据安全、网络安全的角度来看,需要以物理上的隔离机制和手段来保障网络基础设施安全、可靠运行。
再分析NET4AI。从未来网络演进来看,绝大部分数据会在边缘侧产生,其中主要的数据是视频、图像、音频等非结构化数据,对这些海量非结构化数据进行低时延、高效处理,才能确保用户有较好的业务体验。为网络云最短路径提供AI算力可控制成本,网算合一可帮助运营商构建核心的差异化竞争力。运营商的公有云业务,相比Amazon、Azure、谷歌、阿里巴巴、腾讯云等公有云厂商,属于同质化竞争,难以构建差异化竞争力。
AI4NET和NET4AI是一体两面的,最终架构是趋同的,华为的主张是构建同一个AI算力基础设施,提供分布式AI算力、最短时延、最优化调度,使能业务体验最佳,与公有云之间形成差异化竞争力。
随着未来网络的演进,用户对数据主权的要求越来越高,比如在2B(to Business,面向企业)等场景下,不允许用户面的数据离开用户园区,必须采用联邦学习的方案。这种场景下,使用网络云的AI算力是最高效的方案。
核心网的发展历程和代际演进及未来发展如图1-7所示。通信网络经历了从简单的语音通信到支持多种大带宽、低时延、智能化应用的过程,每一代技术的演进都带来了更高的性能和更丰富的业务应用场景,推动了通信技术的不断进步。

图1-7 核心网的发展历程和代际演进及未来发展
注:VoLTE为Voice over Long-Term Evolution,基于长期演进技术的语音通话;MBB为Mobile BroadBand,移动宽带;NB-IoT为Narrowband Internet of Things,窄带物联网;MTC为Machine-Type Communication,机器类型通信;VoNR为Voice over New Radio,基于新无线技术的语音通话;eMBB为enhanced Mobile Broadband,增强移动宽带;mMTC为massive Machine-Type Communication,大规模机器类型通信;uRLLC为ultra-Reliable Low-Latency Communication,超可靠低时延通信;PRO为Performance and Resource Optimization,性能和资源优化;MEC为Mobile Edge Computing,移动边缘计算;MSS为Mobile Switching Subsystem,移动交换子系统;SBC为Session Border Controller,会话边界控制器;UGW为Unified Gateway,统一网关;NFVI为Network Function Virtualization Infrastructure,网络功能虚拟化架构;ADN为Autonomous Driving Network,自动驾驶网络。
核心网网络架构技术的演进在推动网络、产品和运营商组网发展的同时,也带来了诸多运维挑战。以下从网络架构演进、产品架构演进和运营商组网复杂度增加3个方面进行详细分析。
第一,网络架构演进(见图1-8和图1-9)。随着5G SA(Standalone,独立组网)核心网的演进,网络架构经历了从传统架构到服务化架构的全面重构。这种架构的转变带来了诸多运维挑战。

图1-8 核心网的网络架构演进(1)
注:AF为Application Function,应用功能;VM为Virtual Machine,虚拟机。

图1-9 核心网的网络架构演进(2)
注:DRA为Diameter Routing Agent,Diameter路由代理;STP为Signal Transfer Point,信令转接点;SAE-HSS为System Architecture Evolution Home Subscriber Server,体系架构演进归属用户服务器;IMS-HSS为IP Multimedia Subsystem Home Subscriber Server,IMS归属用户服务器;NWDAF为Network Data Analytics Function,网络数据分析功能;BSF为Bootstrapping Server Function,引导服务功能;CHF为Charging Function,计费功能(网元);UDSF为Unstructured Data Storage Function,非结构化数据存储功能;SMSF为Short Message Service Function,短消息服务功能;vSEPP为visited Security Edge Protection Proxy,拜访地安全边缘保护代理;hSEPP为home Security Edge Protection Proxy,归属地安全边缘保护代理;CSMF为Communication Service Management Function,通信服务管理功能;NSMF为Network Slice Management Function,网络切片管理功能;NSSMF为Network Slice Subnet Management Function,网络切片子网管理功能;ULCL为Uplink Classifier,上行分类器;App为Application,应用;MEP为Maintenance Association End Point,维护联盟边缘节点。
交互流程复杂化。服务化解耦使得NF被拆解为独立的服务,端到端的交互流程显著增加。例如,3GPP R17中,NF数量已超过40个,参考点超过90个,NF服务超过110个,如图1-10所示。以用户附着流程为例,单用户附着流程涉及22条信令,跨6个NF交互,如图1-11所示,这不仅导致附着失败率上升,也使得故障点的数量大幅增加。

图1-10 3GPP R15~R17定义的NF以及接口数量逐版本增加

图1-11 单用户附着流程信令交互跨6个NF示意
注:N3IWF为Non-3GPP Interworking Function,非3GPP互通功能;TNGF为Trusted Non-3GPP Gateway Function,受信任的非3GPP网关功能;W-AGF为Wireless Access Gateway Function,无线接入网关功能。
故障扩散与定位困难。在NF全互联的网络中,单个NF或NF服务故障会迅速扩散。这种故障扩散现象导致业务恢复时长延长,严重影响客户体验。
定界分析难度增大。由于服务化架构的复杂性,横向跨网元的定界分析部件增多,运维人员需要在多个层面进行故障排查,增加了运维的复杂度和工作量。
3GPP R15~R17定义的NF以及接口的具体功能如下。
NF是指5G系统中的一个逻辑节点,它提供特定的网络功能和服务。例如,AMF、SMF、UPF等都是NF。NF是5G系统架构的基本组成单元,不同的NF通过相互协作来实现5G核心网的各种功能,如用户接入、数据转发、策略控制等。
参考点是指5G系统中不同NF之间或NF与其他网络实体之间的接口,用于定义它们之间的通信和交互。通过定义参考点,可以明确不同NF之间的职责划分和交互流程,实现NF的模块化和解耦,便于网络的灵活部署和扩展。例如,N1参考点是UE和AMF之间的接口,N2参考点是RAN和AMF之间的接口。
NF服务是指一个NF服务提供者通过服务化接口向其他授权的NF服务消费者开放的一种能力。NF服务是5G系统中实现NF解耦和灵活交互的关键机制。一个NF可以提供一个或多个NF服务,其他NF可以通过调用这些服务来实现特定的系统过程。例如,SMF可以向UPF提供会话管理服务,用于创建、更新和删除PDU(Protocol Data Unit,协议数据单元)会话。
服务点是指NF服务提供者在服务化接口上开放的具体服务接入点,NF服务消费者通过服务点与NF服务提供者进行通信。服务点是NF服务的具体体现,它定义了服务的接口规范和交互方式,使得NF服务消费者能够以标准化的方式访问和使用NF服务。
第二,产品架构演进。核心网设备从传统的专有硬件设备向云原生架构演进,带来了以下运维挑战。
软硬件解耦带来的定界定位困难。云原生架构实现了软硬件的解耦,使得难以直接定位底层硬件故障对上层业务表现的影响。例如,IaaS(Infrastructure as a Service,基础设施即服务)层的网络故障,包括OvS(Open virtual Switch,开放虚拟交换机)故障、EVS(Elastic Virtual Switch,弹性虚拟交换机)故障、软硬SDN(Software Defined Network,软件定义网络)故障以及I/O(Input/Output,输入输出)异常、文件系统异常、OS(Operating System,操作系统)异常(如进程挂死、内存过载)等,都可能影响上层业务,但具体故障点难以快速确定。
跨层垂直定界定位困难。PaaS(Platform as a Service,平台即服务)层的Pod异常、容器网络异常、容器存储异常等也可能影响上层业务表现,且这些异常与底层硬件故障之间的关联难以被快速识别。非FullStack架构下,基础设施由IT厂家提供,其可靠性通常无法满足5个9(99.999%)的要求,基础设施提供商和业务网元提供商职责独立,进一步增加了上下层关联定位的难度。
第三,运营商组网复杂度增加,主要体现在以下几个方面。
多种设备形态共存。不同设备形态的共存增加了组网的复杂度,运维人员需要同时管理多种设备,增加了运维的难度和工作量。
异厂家对接难度大。核心网Overlay(覆盖)在传输网之上,非常依赖传输网的稳定运行。业务异常后,难以第一时间确定是否由传输层引起。异厂家核心网网元集成对接时,业务异常后的跨厂家协调定界定位难度极大,增加了运维的复杂度和时间成本。
人力成本上升与自动化诉求高。随着网络架构的复杂化,运维工作量大幅增加,人力成本也随之上升。同时,业务深入日常生活的各个方面,用户对故障的忍耐度极低,单纯依赖人力难以保证故障恢复时间窗大小,因此对自动化的诉求越来越高。
以下基于核心网典型运维场景及面临的挑战展开说明。
第一,基础运维场景。基础运维场景是核心网运维中最常见的部分,主要包括配置变更、KPI(Key Performance Indicator,关键性能指标)监控、告警监控和容量评估等工作。随着5G SA核心网的演进,这些工作变得更加复杂和重要。
配置变更。在服务化架构下,NF数量的增加和交互流程的复杂化使得配置变更工作变得更加烦琐。例如,一个NF的配置变更可能会影响多个相关NF的正常运行,因此需要更加谨慎地进行操作。同时,由于NF之间的依赖关系更加复杂,配置变更后的验证工作也变得更加重要,以确保变更不会对业务造成影响。
KPI监控。KPI监控是衡量网络性能和业务质量的重要手段。在5G SA核心网中,KPI的种类和数量都大幅增加。例如,除了监控传统的网络性能指标,还需要监控与QoS、客户体验相关的KPI。此外,由于网络架构的复杂化,KPI之间的关联性也更加复杂,需要更加智能化的监控工具来实现对KPI的全面监控和分析。
告警监控。告警监控是及时发现和处理网络故障的重要手段。在5G SA核心网中,由于故障点的增加和故障扩散现象的存在,告警的数量和种类也大幅增加。例如,一个NF的故障可能会引发多个相关NF的告警,导致告警信息的冗余和混乱。因此,需要更加智能化的告警监控系统来实现对告警信息的自动分类、关联和分析,以提高告警处理的效率和准确性。
容量评估。容量评估是确保网络能够满足业务需求的重要工作。在5G SA核心网中,由于业务的多样性和流量的不确定性,容量评估变得更加复杂。例如,需要考虑不同业务类型的流量特征、用户行为模式以及网络设备的性能等因素,以准确评估网络的容量需求。同时,由于网络架构的动态性,容量评估还需要能够实时反映网络的容量变化,为网络的扩容和优化及时提供依据。
第二,巡检保障场景。在重大活动以及节假日前,运维人员需要对网络设备进行健康巡检,排查系统运行隐患。由于网络架构的复杂化,巡检工作量大幅增加,需要更全面、更细致地检查。同时,对系统容量的分析也更加复杂,需要结合用户行为以及流量预测,评估系统存在的瓶颈,并有针对性地进行扩容。
健康巡检。在5G SA核心网中,健康巡检的范围和内容都大幅增加。除了对传统网络设备的检查,还需要对NF、容器、虚拟化平台等进行检查。例如,需要检查NF的运行状态、容器的资源使用情况、虚拟化平台的性能指标等,以确保网络设备的正常运行。同时,由于网络架构的复杂化,巡检的深度和广度也需要相应增加,以全面排查系统运行隐患。
系统容量分析。系统容量分析是巡检保障场景中的重要工作。在5G SA核心网中,由于业务的多样性和流量的不确定性,系统容量分析变得更加复杂,需要结合用户行为、流量预测以及网络设备性能等因素,评估系统扩容面临的瓶颈,并有针对性地进行扩容。例如,通过分析用户在重大活动期间的行为模式和流量特征,预测系统容量的需求,提前进行扩容,以确保网络的稳定运行。
应急预案制定。应急预案制定是巡检保障场景中的重要环节。在5G SA核心网中,由于故障点的增加和故障扩散现象的存在,应急预案的制定变得更加复杂。需要针对不同的故障场景,制定详细的应急预案,包括故障排查、恢复指导等。例如,针对NF故障、容器故障、虚拟化平台故障等不同类型的故障,制定相应的应急预案,确保故障能够迅速恢复,不影响用户的体验。
第三,升级/补丁场景。升级前检查、自动回退、无损升级、业务验证等工作在服务化架构下变得更加复杂。由于NF数量的增加和交互流程的复杂化,升级过程中需要更加谨慎地进行操作,以避免对业务造成影响。
升级前检查。在5G SA核心网中,升级前检查工作变得更加复杂。需要对网络设备的运行状态、配置信息、业务流量等进行全面检查,确保网络设备处于正常运行状态,且升级不会对业务造成影响。例如,需要检查NF的运行状态、容器的资源使用情况、虚拟化平台的性能指标等,以确保网络设备能够顺利进行升级。
自动回退。自动回退是升级/补丁场景中的重要保障措施。在5G SA核心网中,由于升级过程中可能出现各种问题,自动回退机制变得更加重要。需要在升级前制定详细的自动回退方案,确保在升级失败时网络能够迅速恢复到升级前的状态,不影响业务的正常运行。例如,通过备份网络设备的配置信息、业务数据等,实现升级失败后的自动回退。
无损升级。无损升级是升级/补丁场景中的重要目标。在5G SA核心网中,由于业务的多样性和流量的不确定性,无损升级变得更加困难。需要采用分批升级等策略,逐步进行升级,以减少对业务的影响。例如,通过先对部分用户进行升级,观察升级后的业务表现,再逐步扩大升级范围,实现无损升级。
业务验证。业务验证是升级/补丁场景中的重要环节。在5G SA核心网中,由于业务的多样性和复杂性,业务验证变得更加重要。需要在升级后对业务进行全面验证,确保升级后的业务能够正常运行,且性能指标符合要求。例如,通过测试业务的连接成功率、数据传输速率、业务响应时间等指标,验证升级后的业务性能。
第四,故障处理场景。故障处理场景主要指在网络设备出现故障时,运维人员需要进行的一系列工作,包括信息收集、异常检测、定界定位、应急恢复、容灾倒换等。由于故障点的增加和故障扩散现象的存在,运维人员需要更快速、更准确地进行故障处理,以减少对业务的影响。
信息收集。在5G SA核心网中,信息收集变得更加复杂。需要从多个层面收集信息,包括NF、容器、虚拟化平台等的信息。例如,需要收集NF的运行日志、容器的资源使用情况、虚拟化平台的性能指标等,以全面了解故障情况。
异常检测。异常检测是故障处理场景中的重要环节。在5G SA核心网中,由于故障点的增加和故障扩散现象的存在,异常检测变得更加困难。需要采用智能化的异常检测工具,对收集到的故障信息进行分析,快速检测出异常点。例如,通过分析NF的运行日志、容器的资源使用情况等,检测出异常点,为故障处理提供依据。
定界定位。定界定位是故障处理场景中的关键环节。在5G SA核心网中,由于网络架构的复杂化,定界定位变得更加困难。需要采用多层次、多维度的定界定位方法,快速确定故障点。例如,通过分析NF之间的交互流程、容器的网络拓扑等,确定故障点的位置,为故障处理提供准确的方向。
应急恢复。应急恢复是故障处理场景中的重要保障措施。在5G SA核心网中,由于故障对业务的影响较大,应急恢复变得更加重要。需要制定详细的应急恢复方案,确保在故障发生后能够迅速恢复业务的正常运行状态。例如,通过采用备用设备、备用链路等方式,实现故障发生后的应急恢复,减少对用户的影响。
容灾倒换。容灾倒换是故障处理场景中的重要手段。在5G SA核心网中,由于故障点的增加和故障扩散现象的存在,容灾倒换变得更加重要。需要建立完善的容灾倒换机制,确保在故障发生后能够迅速进行容灾倒换,恢复业务的正常运行。例如,通过采用双活数据中心、异地容灾等方式,实现故障发生后的容灾倒换,确保业务的高可用性。
综上所述,技术演进虽然推动了核心网的发展,但也带来了诸多运维挑战。运维人员需不断提升技能,借助智能化工具和自动化手段,以应对日益复杂的运维工作,确保网络的稳定运行和业务的高质量交付。
核心网VNF(Virtual Network Function,虚拟网络功能)的交付分为2C(to Consumer,面向消费者)和2B两类业务模式。2C业务以中心机房部署为主,设备数量少但单设备容量大,通常由设备商直接交付,分包比例低。在5G时代(如低时延、大带宽场景),2B业务需求激增,设备数量多且分散于边缘侧(如地市、工厂),需依赖分包商通过极简流程完成交付。两类业务均涉及VNF新建、升级、扩容、割接及改造等场景,下面将详细阐述。
2C是电信运营商直接面对终端消费者的业务,业务直接发放给个人消费者。2C业务的特点是设备数量相比2B业务较少,单设备容量较大,多在中心机房部署,在交付上多以设备商直接交付为主,分包比例较低。
2B是电信运营商不直接面对终端消费者,而直接面对企业的业务。电信网络进入5G时代后,由于低时延、大带宽等业务需求,2B业务逐渐增加,在运营商业务中所占的比例也逐渐增加。2B业务的特点是设备数量比2C业务的设备数量更多,单设备的容量较小,除了中心机房部署,有大量的设备会部署在边缘侧。对于2B业务,在交付上因设备数量众多且下沉到地市、街道、工厂,由分包商进行交付的诉求较多,由此引申出的交付需要极简流程以支撑分包可交付。
业务交付包括VNF网元新建、VNF版本升级、VNF扩容、VNF割接、VNF网络改造等。
VNF网元新建是指新建一个VNF网元实例,其按场景进一步细分,可得到两个子场景,第一个子场景是新建同类型VNF网元的第一个实例,第二个子场景是在已有的同类型网元实例基础上新增加一个网元实例以增加网络容量。按部署方式进一步细分,可分为基于VNFM(Virtualized Network Function Manager,虚拟网络功能管理器)进行部署和基于NFVO(Network Function Virtualization Orchestrator,网络功能虚拟化编排器)进行部署。
VNF版本升级是指VNF网元的软件版本升级。按照升级版本之间的差异大小分为两个子场景,大的软件版本升级和小的补丁安装。VNF网元升级的路径组合方式众多,在版本跨度很大时,无法一跳完成升级,需要进行两跳升级。同时,版本跨度越大,版本之间的差异越大。为了保证升级的继承性,需要投入的方案设计、排查、保障等相关工作也就越多。对于2B网络,由于网元数量众多,为了提高运维效率,还需要考虑多网元并行升级的方案设计。
VNF扩容是指VNF网元实例的容量扩大。扩容按照是否影响周边网元的对接配置,被细分为两个子场景。对于第一个子场景,只扩容计算资源,不需要周边网元增加对接链路数据;对于第二个子场景,扩容增加了对接IP和链路,需要周边网元同步增加对接链路数据。5G核心网的VNF扩容流程如图1-12所示。

图1-12 5G核心网的VNF扩容流程
注:MOP为Method of Procedure,实施方案文档;VIM为Virtualized Infrastructure Manager,虚拟化基础设施管理器;PIM为Physical Infrastructure Manager,物理基础设施管理器。
VNF割接是指将业务从老网元割接到新网元,按割接的数据类型不同进一步细分为两个子场景:局数据割接和用户数据割接。局数据割接指网元的配置数据割接,如AMF网元间的割接、CSCF网元间的割接,不涉及具体的用户数据割接。用户数据割接指网元上用户数据的割接,如HSS、UDM、UPCF(User Plane Control Function,用户面控制功能)等网元割接时所产生的用户数据之间的割接。按割接的厂家不同进一步细分为两个子场景:同厂家割接和异厂家割接。对于异厂家割接,由于厂家众多,可能有各种组合,再加上每个厂家有各种设备类型,以及局点的组网/特性/配置不同,所以往往需要针对局点设计定制化的方案。UDM的VNF割接流程如图1-13所示。

图1-13 UDM的VNF割接流程
VNF网络改造是指VNF网元功能的改造,如在4G网元的基础上叠加5G功能、在5G网元的基础上叠加4G功能、将4G网元改造成5G网元、在物理网元中叠加新的逻辑网元功能、在多合一网元中分离相关的逻辑网元等。典型的将4G网元改造为5G网元的流程如图1-14所示。

图1-14 4G网元改造为5G网元的流程
注:VNFD为Virtualized Network Function Descriptor,虚拟网络功能描述符。
VNF网元交付端到端的主要活动包括需求调研、信息采集、网络还原、网络设计、操作前检查、操作执行、测试验证、值守保障等。端到端交付活动众多,对人员的技能要求高。
需求调研。需全面挖掘运营商的各类需求,包括性能、可靠性、业务SLA(Service Level Agreement,服务等级协定)、成本、安全、业务特性、上线周期、生命周期、演进性、异厂家互通、计费、割接时长、改造时长、周边约束配合和硬件选型等。除了用户直接提出的需求,还需挖掘潜在需求,以确保后续网络设计全面符合用户业务诉求。
信息采集。为支撑网络还原和操作前检查,信息采集对全面性和准确性的要求高。采集的信息包括网络拓扑、硬件组网、型号、版本、配置、特性、容量、设备厂家、带宽、告警、统计、日志和单据等。采集对象涵盖各类设备和系统,包括VNF网元、网管、云管、VIM、PIM等,这带来了操作入口多和耗时长等难题。复杂性和多次操作是这一过程中的主要痛点。
网络还原。在新建、扩容、割接和改造VNF网元时,需准确还原现网信息,确保还原操作100%准确,避免错误网络设计给业务和后续的整改带来不可接受的损失。这依赖于对现网信息的全面采集,涉及多个网元和设备的手动操作。
网络设计。这是网络建设中最关键的部分,对于人员技能水平和网络设计结果的准确性有极高要求。网络设计时需考虑VNF层级、电信云底座及硬件耦合,确保资源利用率、性能和体验最优。同时,网络的高安全性、高可靠性、易演进性和易扩展性也是网络设计阶段不容忽视的内容。网络设计内容包括网络拓扑、组网方案、业务及SLA、地理容灾、性能容量、可维护性、安全、兼容性、路由、IP及VLAN(Virtual Local Area Network,虚拟局域网)设计等。
操作前检查。进行操作前需全面检查VNF自身及其周边系统,如电信云底座和数通网络。检查规则需灵活更新并经专家确认,避免影响现网运行。检查内容包括历史问题和最新问题,手动排查工作量大,对自动化的需求高。
操作执行。由于所处位置特殊,核心网设备的操作执行风险高,因此通常在业务量低的夜间进行操作。同时,因为这种操作的步骤复杂并可能出现异常情况,往往需要设备商和运营商联合执行,并预留足够的时间处理异常问题或者回退。在操作的准确性上,需要防呆设计以避免人为操作错误引入问题。
测试验证。测试涵盖功能、性能、可靠性、安全、对接等方面,方法有模拟测试和真实终端测试。模拟测试成本低,但由于模拟的设备和现网真实终端的设备表现有差异,效果始终略逊于真实终端测试。为了保证测试充分性,需要进行大量的测试活动。虽然自动化测试能显著提高测试效率,但是脚本开发周期长、对人员技能要求高,这进一步增加了人力消耗。同时,也需要根据不同局点的业务诉求和特点进行成本高、周期长的测试用例定制开发。除此之外,多厂商集成是运营商网络设备的一大特色,这也增加了测试用例的开发难度和人力投入。
值守保障。操作执行后,通过告警、指标和日志监控提供值守保障,及时发现并解决问题,减少对现网用户业务的影响。
对以上分析进行总结,VNF网元交付主要面临的挑战有以下3点。
第一,业务复杂,多代际产品组合方式多,技术更新演进快,技能要求高,学习周期长,对设备商及运营商自有人力的诉求高,外包及分包技能很难满足要求。
第二,对自动化水平要求高,但自动化能力构建难、投入大。
第三,对交付动网的安全性要求高,保证操作安全和操作异常后快速回退涉及的场景多。
客户体验是用户对移动网络服务全周期的主观感知,涵盖购买前、消费中和使用后的多维反馈,直接影响运营商的商业绩效。在移动网络中,核心网作为关联用户感知与客观网络数据的枢纽,需通过实时快照和动态分析支撑客户体验优化。语音业务作为基础服务,从3G到5.5G+持续演进,技术栈如VoLTE、VoNR等不断升级,推动语音接通速度、音视频质量显著提升,用户需求从基础通话扩展至高清交互场景。然而,客户体验保障面临三大挑战:一是度量建模,需平衡主观感知与客观数据,覆盖加密、大带宽等新兴场景;二是质差定界,海量数据处理、跨域协同及隐患预判对实时性要求极高;三是闭环优化,需在资源有限的情况下平衡用户优先级,结合AI仿真制定最优策略。未来,核心网需构建智能化运维体系,实现“可评—可管—可优”闭环,以动态适配业务演进与用户期望,最终提升整体用户满意度。
CX(Customer Experience,客户体验)是消费者在消费过程中所有阶段(包括购买前、消费中和使用后阶段)的认知、情感、感官和行为反应的总和。对移动网络而言,消费者是指使用最终产品和服务的终端用户或者特定场景下的行业用户。因此,移动网络的客户体验是指在购买和使用移动网络最终产品和服务的多个阶段,终端用户或者行业用户对移动网络的业务需求满足度的主观感知。客户体验最典型的3个阶段是购买前、消费中和使用后。购买前,是对于移动网络产品和业务推送契合性、友好性的感知;消费中,是对于各类数据、语音业务随时随地可用性、好用性的感知,以及业务使用过程中问题解决及时性的感知;使用后,是对于计费、账单、实际业务使用准确性和一致性的感知,以及对于客服关怀、交互友好性的感知等。
客户体验直接影响移动运营商的商业绩效。良好的客户体验能够让终端用户保持较高的忠诚度和黏性。比如体验良好的用户会持续购买移动网络产品和服务,或者在新套餐、新服务推出后,有更强的购买意愿,也乐于向更多的人推荐产品或者服务,达到一传十、十传百的效果。即使遇到偶尔的业务失效或者业务质差也不会轻易离网、更换运营商等。因此保障良好的客户体验对移动网络来说非常关键,而在所有客户体验的感知项中,网络直接承载的业务体验是所有体验的基础。如果电话打不通、无法上网,或者发生频繁的通话掉话、视频卡顿、手游断线等,再好的关怀服务或者补偿都无法弥补用户的体验损失。而核心网作为移动网络中唯一能感知用户ID(Identifier,标识符)信息的节点,是把主观的用户业务体验感知和客观的网络运行状态数据关联起来的枢纽。而作为连接无线网络和有线PDN(Packet Data Network,分组数据网络)的锚点,核心网又是快速界定问题、快速规避或者闭环解决体验类问题的关键一环。因此,核心网需要提供相应的运维能力,以保障优质的用户业务体验。
客户体验是消费者的主观感知,因此移动网络终端用户的业务体验也具有主观性特征。首先,用户对体验的感知一般属于主观性描述,如上网慢、通话不流畅等。快与慢、流畅与不流畅没有统一标准,因此对体验的度量需要找到用户共性的感知维度以及客观的判断依据。其次,体验感知具有时效性,这种时效性体现在两个方面。 一方面,体验具有实时性,感知就在彼时彼刻。不同的时间点,相同的用户,感知可能不同;相同的时间点,不同的用户,感知也可能不同。因此从网络角度,需要对用户的感知和网络状况进行实时快照,才可能客观反映当时的场景。另一方面,随时间的推进,新的应用业务不断涌现,用户的兴趣点也会与时俱进,终端用户的体验也会随着业务的发展而变化。早期的2G时代以电路域语音为主,用户着重关注语音业务体验,随着2G、3G、4G、5G数据业务的发展,用户逐渐关注网页浏览、文件下载、视频播放等业务的体验。即使同为泛视频类业务,用户对点播、直播、云游、云手机、XR等业务的体验需求也会不同。
下面将着重分析移动网络中典型的几类业务的交互流程和特征,以及当前用户对于业务体验感知的主要关注点、感知的影响因素等,以便更好地从网络视角分析核心网运维面临的困难和挑战,从而对客户体验进行更精准的网络快照和优化提升。
(1)语音业务体验
语音业务是移动网络中最基础的业务,从移动网络伊始到现今向6G核心网演进,语音业务在移动网络发展的每一代际中都得到了最广泛的应用。
图1-15所示的语音业务演进各阶段的关键技术具体如下。

图1-15 语音业务演进各阶段的关键技术
注:NSA为Non-Standalone,非独立组网;CSFB为Circuit Switched Fallback,电路交换回落;EPS FB为Evolved Packet System Fallback,演进分组系统回落。
在2G/3G阶段,MSC负责2G/3G核心网的CS业务,如语音通话、短信传输,是传统蜂窝网络的核心控制节点。CSFB用于LTE网络的语音业务解决方案,当终端在LTE覆盖下发起或接收语音呼叫时,网络将连接回落到2G/3G CS域以完成通话,通话结束后返回LTE。
在2G/3G/4G阶段,EPC是4G LTE的核心网架构,基于全IP分组交换技术,支持高速数据业务和移动性管理。IMS是基于IP的多媒体业务核心网架构,支持VoLTE、视频通话等融合通信服务,可以实现固网与移动网络融合。
在5G NSA阶段,5G过渡部署模式依赖4G核心网EPC提供控制面锚点,5G NR(5G New Radio,第五代新空口)仅增强数据速率。
在5G SA初始阶段,EPS FB是5G核心网的语音业务过渡方案,当5G未部署VoNR时,终端在5G NR覆盖下触发语音业务会使网络回落到4G LTE网络,通过VoLTE技术实现语音连续性,支持5G与4G核心网互操作。
在5G SA阶段,5G独立部署模式采用全新5G核心网,不依赖4G基础设施。
从2G、3G仅支持语音通话的CS域语音业务,到4G VoLTE,用户可以使用基于IP网络传输的IMS域语音业务,体验语音业务和数据业务的并发,接着到5G VoNR /ViNR(Video over New Radio,基于新无线技术的视频通话)、高清语音通话、高清视频通话,再到5.5G+ 新通话及更丰富的3D类、交互类通话应用,语音业务的承载网元、关键技术栈(编解码、承载协议栈、交互流程)都在持续演进(见表1-1),用户的体验也在逐步提升。
表1-1 语音业务演进的能力对比
| 能力项 |
不同阶段 |
||||
|---|---|---|---|---|---|
| 3G |
4G(VoLTE) |
5G(EPS FB) |
5G(VoNR) |
||
| 呼叫接通时长 |
5 s |
2 s |
4 s |
2 s |
|
| 语音通话质量 |
频宽 |
300~3400 Hz |
50~7000 Hz |
50~7000 Hz |
50~192 000 Hz |
| 采样率 |
8 kHz |
16 kHz |
16 kHz |
48 kHz |
|
| 比特率 |
AMR-NB最大, 12.2 kbit/s |
AMR-WB最大,23.85 kbit/s |
AMR-WB最大,23.85 kbit/s |
EVS-FB最大, 128 kbit/s |
|
| 视频通话质量 (分辨率) |
分辨率为176像素×144像素(QCIF) |
典型分辨率为480像素×640像素(VGA),甚至达到720P/1080P |
典型分辨率为480像素×640像素(VGA),甚至达到720P/1080P |
典型分辨率为480像素×640像素(VGA),甚至达到720P/1080P, H.265编码节省带宽30% |
|
| 语音质量 |
3.7分 |
4.2分 |
4.2分 |
4.7分 |
|
| 富媒体 |
与RCS(Rich Communication Services,融合通信服务)天然融合,提供即时消息、图片共享、视频共享、文件共享、呈现服务、网络地址簿等富媒体业务 |
5G消息 |
|||
注:AMR-NB为Adaptive Multi-Rate Narrowband,自适应多速率窄带语音编码;AMR-WB为Adaptive Multi-Rate Wideband,自适应多速率宽带语音编码;EVS-FB为Enhanced Voice Services-Fullband,增强型语音服务全频带编码;QCIF为Quarter Common Intermediate Format,四分之一通用中间格式;VGA为Video Graphic Array,视频图形阵列。
语音用户的业务体验感知,主观而言,覆盖如下典型维度。
第一,“打得通”,反映了语音用户对于拨打电话后能否成功接通的主观感知,如按拨号键后,能否听到正常振铃音。
第二,“接得快”,反映了语音用户对于拨打电话时从按键到听到振铃音的时间长短的感知。
第三,“不掉话”,反映了语音用户对于通话过程能持续进行、不意外中断的感知。
第四,“听得清”,反映了语音用户对于通话过程中语音质量的感知,如没有断断续续听不清、没有杂音、没有瞬时的静默等。
随着视频通话的规模商用以及新通话的逐步普及,在原有的体验诉求之上,终端用户在语音业务使用中也会对“看得清”,以及交互/闭环类业务的可用性、及时性、准确性提出新的要求。如视频通话中,视频出现黑屏、花屏、卡顿等现象,就会影响终端用户“看得清”的感知。而新通话相关业务中,除了常规的接续感知、音视频感知,用户还可能会对交互内容产生新的体验感知。比如智能翻译场景,终端用户会关注屏幕上语音对应的翻译文本呈现的实时性/同步性,翻译文本内容的正确性等;再比如交互视话场景,终端用户会关注业务共享(如照片、文件、位置、屏幕等共享)的启动时间长短(时延类体验),是否即点即用(易用性及成功率等体验)。
理论上,随着编码方式的演进、传输带宽的增加,终端用户应该拥有更好的语音业务体验,但实际网络运行中,语音业务的投诉仍然占较大比重。现阶段典型投诉项主要有3类:一是接通类投诉,如主叫和被叫均不能接通,或者主叫或被叫不能接通;二是保持类投诉,如通话过程中掉线,用户对这类问题的感知非常强烈;三是语音质量类投诉,如通话过程中时断时续、单通、通话过程中出现杂音等。
移动网络端到端语音业务体验涉及多域多网元的协同,覆盖终端、无线、传输、CS域、分组域、IMS域等多个领域,语音业务基础架构如图1-16所示。对于5.5G+新通话场景,还涉及和三方AS(Application Server,应用服务器)、媒体面平台之间的协同,任一环节发生异常丢包或者处理时延异常,都会影响端到端的接续成功、接续时延、音视频的流畅度等,继而影响用户的主观感知。

图1-16 语音业务基础架构
注:NCP为New Calling Platform,新通话平台;I-CSCF为Interrogating-CSCF,查询呼叫会话控制功能;ATCF为Access Transfer Control Function,接入转移控制功能;UMF为Unified Media Function,统一媒体功能。
在分析移动网络端到端语音业务体验的复杂成因时,需要从终端侧开始逐层拆解各环节的潜在影响因素,包括终端、无线、传输网、核心网、运营管理平台5层,具体说明如下。
① 终端侧影响。终端网络兼容性(通信双方对协议实现理解的差异)、支持的分辨率、编解码能力、性能、终端OS及其性能等均会影响语音业务体验。
② 无线侧影响。无线弱覆盖、容量不足等均可能导致上下行语音业务丢包、时延大等问题。对于代际的切换期,新制式尚未实现全面覆盖时,回落技术应用也会引入较大的切换时延问题,影响语音接通期间的体验感知。
③ 传输网侧影响。网络节点的性能和容量不足、硬件板卡和链路故障可能导致拥塞场景下丢包、传输时延大、时延抖动大,影响音视频质量。网络参数配置/修改不当可能造成环路或者网络风暴,引发大量丢包。传输网或者承载网通常提供网元之间的业务流保障,而非提供用户级视角。因此,传输网或者承载网异常通常引发的是语音群障,导致批量用户语音体验质差。
④ 核心网侧影响。核心网分组域、IMS域以及传统的CS域都涉及多个网元节点及各节点之间的协同。网元节点的低性能、容量的不足可能影响语音业务控制面和媒体面报文的转发,导致丢包、乱序等问题,继而引发语音业务的流程失败或者体验质差。异厂商之间(含核心网设备之间、终端和核心网设备之间、核心网和无线设备之间等)对于协议实现的理解存在差异,特别是对于3GPP协议未明确规范的流程的理解不一致,可能导致流程消息的时序不一致,从而造成流程冲突、流程失败,进而影响用户语音业务的可用性。网元数据配置、用户签约参数设置不当,也可能导致在核心网段对语音业务相关的流量进行不必要的策略控制,导致丢包等影响通话体验的问题。对于新通话场景,负责视频合成的节点的数目、容量、性能不足也会导致丢包或者大时延,影响视频通话质量。
⑤ 运营管理平台侧影响。在新通话场景中,媒体平台负责语音、视频等的智能识别,文本翻译等的处理,相关产品及部件的处理时延、算法实现等可能影响终端用户对于交互内容实时性、正确性的感知。
所以,移动网络的用户在使用语音业务的过程中,如果因为体验差发起了投诉,核心网作为入口分析节点,需要支持对全量用户的语音业务体验进行准确测评,对于用户投诉的这一次通话过程的回溯需要有数据支持。对于传统语音,已经有比较成熟的指标体系来评估语音业务的质量,包括接入类、保持类指标以及语音的MOS(Mean Opinion Score,平均意见得分)等。这方面的主要挑战在于当演进到新通话时代,会叠加类似数据业务的交互式应用等,因此需要增量构建语音体验模型,以便更准确地测评用户感知。对于已发生语音体验质差的场景,则需要支持快速的问题/故障隔离定界,精准指向问题段所在。多域周边数据的可获取性、无线环境的易变性都会限制核心网视角的定界定位准确性和及时性,数据源扩展和定界定位算法准确性的提升会是常态需求,需要持续迭代改进。 此外,对用户来说,最好的网络是不发生问题、随时可以拨通、可以随时享受到优秀通话质量的网络。所以对核心网来说,如果能精准、提前发现问题,识别劣化、隐患问题,并及时规避和解决,那么其对用户的价值会更大。
(2)2C数据业务体验
数据业务是移动网络的主流业务,从2G时代典型的网页浏览、即时通信等上网类业务,到4G时代长视频、短视频业务的规模兴起,再到5G时代AR(Augmented Reality,增强现实)、VR(Virtual Reality,虚拟现实)、云游戏、云手机业务的发展,移动网络既能让终端用户体验有线网络业务的丰富性,又可享受到随时随地自在互联的便利性。
网页浏览、视频、云游戏等2C场景的数据业务基本由TCP/IP(Transmission Control Protocol/Internet Protocol,传输控制协议/互联网协议)协议栈承载,因此,业务体验也必然受IP网络尽力传输的特征影响。移动网络的带宽和时延是影响数据业务体验感知的典型因素。而不同的业务对带宽和时延的敏感度不一样,所以即使在同一个网络中,用户的业务体验感知也会因应用的不同而有所差异。下面介绍几类常用业务(不同业务之间有交叉)。
第一类,网页浏览类。
网页浏览类业务是最基础的数据业务,通常被用户用来判断移动网络的可用性,即能不能上网。对于网页浏览类业务,终端用户的主观感知通常包含如下几点。
第一,业务可用性,网页是否能打开,网页上是否所有内容都正常显示,这些会影响用户对于能否上网的感知。
第二,网页打开时长,即用户输入URL(Uniform Resource Locator,统一资源定位符)并按Enter键后,多长时间能看到页面开始显示内容,多长时间能看到完整内容,这些会影响用户对于上网快慢的感知。
而在移动网络侧,如果要客观地对如上的用户业务体验感知进行表征,则需要业务建模,将主观感知和具体细化的业务报文交互流程映射并关联起来。在已经建好业务感知模型的前提下,如何定义基于模型数据测评质差或者质优的标准也是需要考量的问题。如果终端到服务器之间的物理距离较远,比如服务器在A城市,用户在B城市,两地之间的传输时延可能天然就会比用户直接访问B城市本地的服务器的传输时延大。即使访问相同位置的Web服务器,如果访问的页面大小不一样,也会导致显示页面内容所需要的时长不一样,使得终端用户访问不同的页面时感知的页面打开时延不一样。所以,测评基线需要基于指定的样本应用来确定,而无法基于一个放之四海而皆准的静态值。不同运营商、不同局点的基线可能存在差异,需要基于实际现网环境动态提取和调整,这也是在业务建模中需要考虑构建的能力之一。
第二类,泛视频类。
泛视频是指涵盖多种形态视频服务及交互式应用的综合性业务范畴,包括传统视频点播、短视频、直播,以及5G时代融合实时交互的AR/VR、云游戏等新型业务。泛视频类业务是当前移动网络流量占比最高的业务之一,也是容易引发投诉的业务。泛视频类业务的发展经历了几个阶段,不同阶段泛视频类业务的用户对于体验的关注点也有所不同。早期的点播或者组播业务,终端用户作为客户端,主要涉及视频流的下载,用户关注视频是否可正常播放、画面是否流畅等。而对于后续蓬勃发展的短视频业务,由于本身内容源的典型时长都是15 s左右,因此用户对播放时延以及流畅度的感知相对来说就更加敏感。对于直播业务,观看直播的一方类似于点播用户,主要涉及下行视频流的下载;而对于直播内容提供的一方,存在大流量的上行业务。如果上行质量差,引入严重的时延、卡顿,则下游观看直播的用户会整体受到影响。因此对于直播业务,对上行视频流提供体验保障则成了新的业务需求。而对于面向5G核心网发展起来的云业务,如AR/VR、云游戏、云手机等,则是在泛视频类业务之上叠加了强交互能力,因此在常规的视频体验之外,终端用户还会对交互性产生对应的体验感知。
视频点播/直播是泛视频类业务最基础的应用。对于泛视频类业务的主观感知,用户主要关注表1-2所示的几个方面。
表1-2 用户对泛视频类业务的主观感知
| 主观感知 |
感知子项 |
感知说明 |
典型影响因素 |
|---|---|---|---|
| 泛视频类业务可用 |
可用性 |
用户按“播放”键后视频是否可以成功播放 |
网络质量(丢包等) |
| 及时性 |
用户按“播放”键到视频画面开始播放的时长 |
网络质量(丢包、时延等) |
|
| 视频质量 |
流畅度 |
播放是否流畅,是否有频繁卡顿、花屏、黑屏等 |
网络质量(丢包、时延等) 视频客户端实现机制、编解码器性能 |
| 音画一致性 |
音画一致性 |
音画是否同步 |
网络质量(丢包、时延等) 视频客户端实现机制 |
泛视频类业务的体验受移动网络质量(带宽、时延、丢包等)的影响较大。对于点播、直播等泛视频类业务,相同的视频源常常需要提供不同分辨率的片源文件。同样的网络带宽,播放270P视频流可能很流畅,但是播放1080P的就可能频繁卡顿。不少视频厂商为了保障其用户的体验感知,在App和服务器端也提供了相应的基于网络的实时质量检测,支持人工手动或者自动动态选择合适分辨率的片源切片。所以从核心网视角去分析用户的泛视频类业务体验,原则上也需要视频流内容本身的信息。
泛视频类业务和网页浏览类业务的差异点在于,相同的网络情况下,不同的视频客户端的行为也可能给用户带来不同的体验感知。比如,视频播放以帧的粒度进行处理,如果因为网络丢包或时延,某一帧的数据没有按时完整接收,不同的客户端处理机制可能带来不同的质差表象。某一类客户端的处理机制是丢弃报文,直接等待下一个I帧(Intra-coded Frame,帧内编码帧)到达,用户感知的就是画面卡顿;而另一类客户端的处理机制是继续解码,可能会导致画面上出现马赛克或者花屏。这种解码端处理流程的异常情况仅在客户端本地能被感知。所以在核心网侧,要精准、实时地判定视频流是否出现卡顿、花屏等比较困难,只能理论上进行拟合。 比如对于卡顿的判定,需要获取视频流的分辨率、码率信息,分析客户端本地缓存的典型最低门限,再结合网络实测的下载速率等判断是否能在目标时长内完成指定量数据的下载等,还需要专家获取大量的先验信息。
与网页浏览类业务相似,视频流为保护用户隐私普遍采用加密传输。流媒体相关协议栈如图1-17所示。

图1-17 流媒体相关协议栈
注:HTTP/2为HyperText Transfer Protocol Version 2,超文本传送协议第2版;API为Application Program Interface,应用程序接口;TLS为Transport Layer Security,传输层安全(协议);RTSP为Real-Time Streaming Protocol,实时流协议;RTMP为Real-Time Messaging Protocol,实时消息协议;RTP为Real-time Transport Protocol,实时传输协议;RTCP为Real-Time Transport Control Protocol,实时传输控制协议;QUIC为Quick UDP Internet Connections,快速用户数据报协议互联网连接;TCP为Transmission Control Protocol,传输控制协议;UDP为User Datagram Protocol,用户数据报协议。
为满足大流量传输需求,应采用基于UDP的非可靠传输机制以提升传输性能。相较于TCP/IP通过明确的序列号与ACK(Acknowledgement,肯定应答)机制来精确判定丢包和时延,UDP承载的报文仅依赖其自身层信息判定丢包,而往返时延计算则需结合上层应用层数据或带外控制信息。若应用层加密导致报文内容不可解析,则网络建模复杂度会显著增加。
TCP是面向连接的可靠传输层协议,通过序列号、ACK和重传保障数据完整性,适用于HTTP(HyperText Transfer Protocol,超文本传送协议)、FTP(File Transfer Protocol,文件传送协议)等需要高可靠性的业务。
UDP是无连接的不可靠传输层协议,其开销低、时延低,适用于实时音视频、直播等容忍部分丢包的场景。
HTTP/2支持多路复用、头部压缩等优化特性,能提升Web性能,常用于流媒体[如HLS(HTTP Live Streaming,HTTP实时流媒体)、DASH(Dynamic Adaptive Streaming over HTTP,HTTP动态自适应流媒体)]分片传输。
TLS在传输层加密通信数据,保障隐私和完整性,如HTTPS(HTTP Secure,超文本传送安全协议)、RTSPS(Real-Time Streaming Protocol Secure,实时流协议安全版)。
RTSP是应用层控制协议,用于发起/终止媒体流传输,支持与RTP/RTCP结合实现实时流媒体分发,可由TCP或UDP承载。
RTMP基于TCP传输FLV/F4V流媒体视频,支持低时延直播,但逐渐被SRT(Secure Reliable Transport,安全可靠传输)协议、QUIC等替代。
RTP传输实时音视频数据,由UDP承载,提供时间戳和序列号以支持媒体同步。
RTCP是RTP的伴生协议,反馈网络质量(丢包率、时延)和参与者状态,用于QoS优化。
QUIC是基于UDP的传输协议,集成TLS 1.3(Transport Layer Security Version 1.3,传输层安全协议1.3版)加密,支持多路复用和0-RTT(0 Round Trip Time,零往返路程时间)握手,优化HTTP/3(HyperText Transfer Protocol Version 3,超文本传送协议第3版)流媒体传输(如直播、实时通信)。
第三类,Cloud XR类。
Cloud AR/VR作为5G核心网新兴的业务,在VR影视、AR/VR游戏等场景中得到较为广泛的应用。此类业务基于视频图像处理等技术,将虚拟的信息应用到真实世界,实现数字信息和真实环境在同一时空的有机叠加和融合(AR类);或者直接模拟出一个三维的虚拟世界,让用户从视觉、听觉以及触觉上可自由互动(VR类)。由于相应的计算渲染等在云上完成,结果经流化后推送给客户端,因此从本质上而言,XR类业务在使用者视听角度就是泛视频类业务,下行报文即为音视频流,上行则为用户动作捕捉的相关信息。
区别于普通视频业务的是,XR类业务强调身临其境,即沉浸式体验,视觉上要在用户视角范围内保障足够的清晰度。比如,要达到与270P同等的电视观影效果,VR视频源内容的分辨率至少达到2K,而要达到与1080P同等的电视观影效果,VR视频源内容的分辨率则需要达到4K及以上,因此,XR类业务对网络传输带宽有更高的要求。此外,XR类业务的强交互性实现需要使用必要的外部设备,如头显或者手柄等,用户动作捕捉到的相应画面之间的时延需要让用户不易感知,即业务对网络时延要求严格。因此,用户对于XR类业务的体验感知有自己特定的诉求。
以强交互业务VR游戏为例,典型的交互流程是由客户端传感器捕捉用户的动作变化,并将采集到的用户的动作、位置等变化实时发送到服务器端(云渲染平台)。服务器端进行相应的计算、渲染、编码,将处理结果以视频流的形式发送给客户端,客户端进行相应的解码处理并显示。在这个处理过程中,除了会产生如花屏、卡顿等质差感知,还有交互时延导致的特有体验感知。例如,如果动作发生到改变动作后产生相应的视野效果之间的时延较大(超过20 ms),就可能引发用户的眩晕感。本质原因是用户做了扭头的动作,如果对应的视野画面没有产生预期的变化效果,视觉所见和人的前庭系统感知就会不一致,容易产生眩晕感。对于此类问题,可以通过本地渲染即缩短显示时延来规避,但同时可能引入另一类问题,即黑边/边缘拖影。如果用户动作过快或幅度过大,超出本地缓存画面视角范围,无法通过插帧等方式“无中生有”,则视野边缘位置会产生黑边。这种场景强依赖于云渲染平台实时传送新数据的能力。如果网络时延较大,黑边拖影效果就难以避免。
此外,对于头显、手柄等外部设备,用户还会产生佩戴舒适性、轻便性、续航能力、清晰度、活动范围等方面的主观感知,这些也会影响用户对VR类业务的最终感知。但对于这类体验感知,移动网络无法获知相关信息,因此在核心网的运维方案中,针对XR体验的度量主要聚焦管道能力可影响的体验感知项。如果需要对用户的业务体验感知进行完整的测评,还涉及和其他域体验信息的协同。
第四类,云游戏/云手机类。
云游戏/云手机的应用与XR类业务比较类似,云游戏/云手机的应用与XR类业务在技术架构上具有相似性,均属于视频流传输、低交互时延的业务。与XR类业务不同的是,云游戏/云手机等应用不需要额外的专有外部传感器设备,只需要普通手机终端即可使用。用户使用的真实手机作为视频流的客户端,完成画面的解码和显示,同时捕捉手机屏幕上的操作并上报到云端进行相应的处理,并将处理结果以画面的形式传给手机端。
以云游戏为例,如图1-18所示,云游戏让玩家摆脱了原有的本地硬件的性能限制,直接使用云端的虚拟设备来运行游戏客户端,无须本地硬件频繁升级换代。因此,云游戏玩家使用手机就可以享受原先在PC(Personal Computer,个人计算机)上才可以运行的端游,也无须像普通手游一样本地下载占用存储空间的游戏包资源。理论上,云游戏弥补了传统手游/端游的短板,理应快速发展,但实际上带宽和时延的限制极大影响了云游戏的发展。

图1-18 云游戏架构
注:DC为Data Center,数据中心。
为了让玩家体验更好的视觉效果和流畅度,游戏画面的分辨率通常在1080P及以上,帧率通常为60 帧/秒甚至更高。云游戏平台的下行视频流要保障和本地游戏同等的感知,也需要保证较高分辨率和帧率。根据华为实验室对准职业玩家和普通玩家的数据采样,如果要求较好的云游戏体验,时延需要控制在40 ms以内,丢包率要小于10-4,时延抖动要小于16 ms。而实际网络中,无线网络环境的变化,传输链路、服务器侧资源拥塞,都可能导致端到端的时延项无法满足要求,导致游戏玩家明显感知到游戏画面卡顿,或者操作响应的延迟。此外,除了基础的时延项等参数,云游戏的动态帧率也会影响玩家的感知。低帧率以及帧率剧烈变化都会引发游戏画面卡顿,而此类帧率特征在传统的视频点播、直播业务中不突出。
综上,即使业务的主流程都相似,但点播、直播、XR以及云游戏等业务在体验上也会有各自的要求,在体验指标模型上也会有差异。这就需要投入大量的人力针对每一类业务进行细化分析,提取相应特征,然后固化经验。尤其是在加密承载成为主流、无法获取细分交互流程的情况下,需要基于业务报文大小、间隔等特征进行拟合,这对模型的准确性和用户感知的一致性提出了巨大挑战。这些都是核心网节点在有效度量、测评用户的业务体验时无法绕过的一环。
第五类,文件传输类。
文件传输类业务包括应用下载、App更新、HTTP文件下载、云盘的上传和下载等。对于此类业务,用户关注上传/下载的速度,对于上传/下载时长较敏感。文件传输类业务交互流程与网页浏览类业务类似,也是基于HTTP(S)/TCP/IP。此类业务主要匹配用户关注的具体应用,可以基于传输层统计信息对业务体验进行分析。
第六类,即时通信类。
即时通信类业务是移动网络应用最多的业务之一。即时通信类App已经从早期文本类通信逐步发展为多业务的融合应用,涵盖网页浏览、视频播放、文件下载、移动支付、音视频交互等诸多应用。因此对于即时通信类业务的体验,用户也会基于应用的细分有不同的感知需求。对于这一类业务的体验,在建模时也要考虑通用模型和细分模型的应用。比如对于微信业务,用户对于朋友圈图文或者视频加载刷新的响应时长敏感,当界面较长时间处于加载状态时,容易引发用户不好的体验感知继而引发投诉。而对于微信支付,支付频繁失败或者较长时间无响应也会给用户带来不好的体验感知。从用户视角,它们属于两类不同的应用场景体验感知,但从核心网视角,它们都属于HTTP承载的业务,业务流程也比较类似,所以可以基于通用速率、时延模型进行分析,重点聚焦时延的测评,只需在应用类别上加以识别和区分。由此也可以看出,对于即时通信类业务,子应用丰富且衍生融合迅速,无法使用一个唯一的模型来描述,但针对每一个细分子应用都去完备建模又耗时耗力。并且,由于此类应用的社交属性,用户间的传播很容易产生阶段性的热点应用,因此给网络侧客户体验测评方案的建模的灵活性和快速适配能力带来了较大挑战。
2C数据业务体验如表1-3所示,基本由TCP/IP协议栈承载,在传输层可以基于通用的模型分析TCP/UDP层的质量。但是从客户体验角度来说,TCP/UDP层指标是基于客观的报文交互流程提取的,偏技术视角,无法直接映射到用户的主观感知,因此对于部分场景和部分业务,还需要在业务层进行必要的体验建模和拟合。当前阶段,华为通过专家人工分析各类业务报文的特征以及获取用户主观感知的样本,已经构建出典型基础业务的体验测评,并且该测评将随着新业务的发展持续演进。
表1-3 2C数据业务体验
| 业务大类 |
用户典型业务体验 |
典型承载协议 |
|---|---|---|
| 网页浏览类 |
页面打开时长 页面打开成功与否 |
HTTP/TCP/IP HTTPS/TCP/IP |
| 泛视频类 |
视频播放成功与否 视频从单击开始到视频画面开始播放的时长 视频播放期间是否有卡顿、花屏、黑屏现象 视频播放期间是否音画同步 |
HTTP/TCP/IP HTTPS/TCP/IP QUIC/UCP/IP RTP/UDP/IP |
| Cloud XR类 |
画面是否有卡顿、花屏、黑边现象 头显、手柄动作响应的及时性 |
RTP/UDP/IP HTTPS/TCP/IP |
| 云游戏/云手机类 |
业务交互时延 游戏画面流畅与否 |
UDP/IP |
| 文件传输类 |
上传/下载速率 |
HTTPS/TCP/IP |
| 即时通信类 |
业务成功与否 业务交互时延 |
HTTP/TCP/IP HTTPS/TCP/IP |
(3)2B行业业务体验
5G 2B场景将传统的通信业务拓展到千行百业,覆盖工业制造、煤矿、港口、医疗、教育、能源、农业等多个行业。2B典型的行业应用场景见图1-19,业务数据通过CPE(Customer Premises Equipment,用户驻地设备)接收运营商BTS的5G信号并将其转换为Wi-Fi或有线信号,供本地设备(如固定摄像头、巡查机器人、摄像车、巡查无人机等)接入互联网。

图1-19 2B典型的行业应用场景
与传统2C的通信业务相比,2B行业应用通常有着很强的场景特征,不同的应用有着不同的QoS需求[1]。整体而言,2B典型的行业应用可分为如下3类,如表1-4所示。
第一类是视频监控类、现场作业类业务。该类业务主要用于园区/厂区内安防监控、移动巡检、业务检测等领域,主要涉及上行流媒体回传,要求有较大上行带宽。回传后的视频流数据可以本地存储或者进行实时在线的后端分析处理。
第二类是远程控制类业务。该类业务用于支撑企业核心的生产运营,包括对生产设备、维修机器人、AGV(Automated Guided Vehicle,自动导引车)等的远程控制,涉及业务操作的安全可靠与高效运营,属于实时交互类业务,对时延指标要求高。
第三类是采集类业务。该类业务主要用于大规模联网终端的环境监测、业务数据采集,通过对环境、业务运行状态进行分析,实现有效管理及运营。
表1-4 2B典型的行业应用
| 业务大类 |
应用实例 |
典型承载协议 |
体验要求 |
|---|---|---|---|
| 视频监控类、现场作业类业务 |
工业园区-监控摄像头视频回传 工业园区-远程视频操控 无人机-视频回传 高清直播视频回传 |
RTCP/RTP/UDP/IP RTSP/TCP/IP |
高带宽 低时延 高可靠 |
| 远程控制类业务 |
工业园区-远程控制(天车/无人天车/吊桥/AGV物流车等) 无人机-远程控制 |
S7通信协议 工业以太网协议 |
超低时延 高可靠 |
| 采集类业务 |
环境监测、业务数据采集 |
Modbus TCP/IP HTTP/HTTPS |
高带宽 低时延 高可靠 |
同一类业务在2B场景有诸多细分的应用实例,因实例化的场景诉求不同,对业务质量的要求也会有所不同。比如在园区场景中,用于实时监控的摄像头需要将拍摄的画面实时传递到监控中心;在远程操控场景中,控制室的工作人员需要基于远程传回的画面实时下达操控指令,操作远端设备。这两个场景都涉及上行流媒体的回传,但是后端的动作差异导致对于视频流的回传质量要求有所不同,如监控场景需要对画面内容的关键特征进行实时检测,或需要基于传回的实时画面进行相关的远程操作,对视频清晰度要求高。视频流分辨率多为2K~4K,同等编码条件下,码率高于2C类视频业务中应用比较广泛的720P或者1080P视频码率,对上行带宽有较高要求。此外,对于2B场景,通常由多路高分辨率摄像头并行回传视频,对传输带宽要求较高。如果多个摄像头在同一时刻上传数据,可能会引发I帧碰撞,造成瞬时的超高上传速率,移动网络报文传输路径上的部分设备可能产生拥塞,进而引发丢包或者较大的转发时延,影响图像检测的及时性和准确性。
而对于实时交互类业务,通常由S7通信协议或者工业以太网协议等工业协议承载,属于2B行业应用特有的协议栈,也需要相应的建模。即使使用相同的协议栈,不同行业应用可能也会因设置不同的通信参数、定时器等,对移动网络质量的敏感度不同。
2B行业的典型业务体验相较于2C来说,有较大的差异,主要体现在如下几个方面。
① 2B的用户通常是物,比如摄像头、龙门吊等,用户本身对业务体验不会有主观感知,但是会间接对最终企业用户产生客观的实际影响。2B时延敏感业务如果出现质差,会带来严重后果,极易引发安全问题或者影响生产,比如网络时延大导致天车停运,可能直接影响生产流程,因此体验质差的快速识别和快速定界显得尤为重要。
② 业务特定应用场景引发的问题在2C缺少经验积累,需要逐行业/园区进行定位经验积累。 比如多路视频监控并发引发I帧碰撞导致的拥塞丢包,其在2C的质差场景可能就不那么典型。此外,特定行业应用层的实现多种多样,应用层机制和5G核心网通信模式匹配引发的问题往往都具有个例特征,可能需要“一厂一策“的模式去分析。比如A企业的上层应用数据库查询机制和5G环境下TCP的传输模式的匹配度低,造成上层查询超时进而导致业务失败,这对于B企业则可能没有参考价值。
③ 体验质差的定界更困难。对于移动运营商,需要基于自己可控部分的网络数据来实现问题的精准定界。但是2B网络的端到端环节存在较多的用户自购部件(如CPE、AR头显等),导致采集数据及划分责任归属的难度大,问题定界困难。此外,2B投诉处理的闭环需要行业用户的认可,从安全生产的角度而言,通常验收条件严苛、验收周期长。因此对自运维系统来说,提供一个高可信的诊断结果让最终用户信服也面临较大挑战。
④ 运维配合方式有差异,对自动化运维、免人工介入的诉求更高。比如处理2C用户投诉时,如果需要排除终端问题,客服人员会指导用户进行换卡或者重启终端等操作以便快速隔离,此类操作在2C场景很容易完成。但是对于2B场景,常规的运维手段通常不适用,比如2B CPE在远端无法手动重启或者因影响其他业务而不能直接重启等。因此要求2B的运维方案从数据采集到质量监测再到问题定界闭环等各环节趋于自动化、智能化。
⑤ 园区硬件资源有限,轻量化本地部署需求强烈。对于2B行业用户,在特别园区独立资源部署场景中,出于对安全等方面的因素考虑,会要求相关的运行数据不出园区。因此对于园区的运维方案,需要考虑可以在园区本地部署,实现园区体验自动监测、质差检测及自动闭环。
对于移动网络的业务体验的考核或者测评,除了各移动运营商自有的考核标准、考核体系,还有业界比较公认的三方测评厂商,提供基于路测或者众测方式的测评结果,如表1-5所示。
表1-5 业务体验三方测评厂商相关信息
| 厂商 |
测评标准 |
测评方式 |
业务体验涉及测评项 |
|---|---|---|---|
| Ookla |
Ookla speedtest |
众测 |
HTTP PING时延、下载速率和上传速率 |
| Umlaut |
Umlaut(P3) |
路测、众测 |
语音、Web访问、HTTP上传、HTTP下载、视频点播/直播、OTT语音、eGaming |
| OpenSignal |
OpenSignal |
众测 |
下载速率、上传速率、视频、游戏、OTT语音 |
测评厂商基于路测或者众测的大数据进行打分/排名,公开发布或者付费发布相关的测评、排名结果,可以提升运营商的知名度,对于终端用户在选择移动运营商时的引导作用很大,因此不少国家或地区的运营商都有强烈的业务体验保障提升的诉求。但此类测评结果都来源于端侧App/SDK(Software Development Kit,软件开发工具包)的上报,而缺少网络侧的信息,且部分测试方法尚未公开。特别对于路测场景,测试过程数据(如时间、行进路径等信息)事先处于保密状态,以确保三方测评结果的公平和公正。
对测评厂商来说,移动网络是黑盒,只需要对网络进行客观的测评,然后获取结果即可。站在移动运营商角度,三方测评过程是黑盒,因此除了获取最终测评结果,还需要基于自有网络侧数据来分析测评结果,找到网络短板,并尽可能将这一过程提前。三方测评业务基本属于典型2C业务,因此对于可识别业务的核心网,在自运维方案中也需要考虑三方测评保障场景,支持对三方测评指标的拟合评估及质差定界定位,帮助运营商快速发现网络短板,及时优化以提升客户体验。此过程中需要重点考虑拟合样本数据如何精准提取,拟合指标的一致性和准确性如何保障等。
如之前的分析,移动网络业务的客户体验受多重因素影响。从业务发展角度而言,随着5.5G+网络业务体验的演进,当前的2C网络应用正从2D向3D(包括3D互联网、裸眼3D显示、3D购物、实时强交互业务等)演进,对移动网络有着更高速率、更低时延的要求。2B业务的全场景化千亿级连接、超低时延、超高可靠性,相较当前的有限用户大带宽低时延模式,会对客户体验保障有新的需求。而后续车联网的兴起,大屏/多屏车内应用、车路协同应用等也会在当前固定或者低速移动的场景外新增体验场景需求。此外,用户的报障模式也从当前电话、App界面投诉,等待人工处理反馈,变为期望可在终端上通过精练的人机交互或者一键式操作达到实时处理闭环。
对承载移动业务的网络通道而言,跨域、跨层属性将一直存在,且会持续演进。承载网元节点跨越端-管-云多域,因而业务体验会受终端能力、移动网络管道能力、业务平台应用服务节点能力等的限制。而对协议栈来说,各节点也会受物理层、链路层、网络层、传输层和应用层的各层通信机制、可靠性、流控机制影响。特别对核心网域设备而言,在云化架构下又跨越基础设施层、虚拟化层、业务层等多个技术层级,因此,业务体验受多维因素影响。叠加无线环境的实时易变、网络话务量的瞬时冲击、网络工程的频繁操作变更等影响,要实现客户体验的可评、可管、可优,需要面向一个复杂且动态变化的系统工程来构建方案。制定客户体验的运维保障方案存在诸多挑战。
第一,业务体验度量挑战。
业务体验度量挑战包含两个方面。一是体验建模的挑战,即如何基于核心网域可获取的数据对用户关注的典型业务体验进行准确而高效地建模,匹配终端用户主观感知,具备随业务发展、快速迭代演进的能力,并尽可能实现新业务特征自动智能迭代分析,减少人工介入。比如对于超大带宽、超高速率、超低时延等场景下的体验度量方法,当前的方案可能不能覆盖,需要另辟蹊径。而加密场景下的建模准确性则是需要长期解决的问题。二是体验数据获取的挑战,即如何构建高性能、易部署的采集架构,以较小的资源成本覆盖不同场景的体验数据的生成及采集需求。体验数据覆盖水平各域及垂直各层的测量或者拨测数据,采集架构需具备可灵活适配网络设备容量的扩、缩容能力,或者基于上层运维需求动态部署/使能的能力。
第二,体验质差定界定位挑战。
有了对主观体验的客观表述,接下来就是基于全网用户的体验数据进行评估分析,旨在发现问题、解决问题。第一环节就是采集、处理和分析系统的数据,面临如何支撑海量数据的分析和处理,如何支持跨域跨厂商的数据采集的挑战。核心网作为移动网络中的汇聚节点,通常单套设备的处理规格可达到千万用户级,转发处理的终端用户业务报文流量可达到数百Gbit/s级。因此在针对整网用户的体验数据进行分析时,首先需要考虑海量数据的并行接入、计算处理以及存储,提供高效的运维方案。此外,移动网络设备商通常是多域多设备厂家,每个域针对业务体验仅提供本域可获取的信息。核心网作为锚点提供分析入口时,如需关联周边域体验数据时,需要在前端基于体验模型分段分层统筹规划考虑,实现合理映射。
如果客户体验已经出现质差,如何精准、快速定界定位问题所在也存在较大挑战。常规的基于静态/动态门限比较判断、多维度分析确定TOPN(排名前N)对象、基于AI/ML(Artificial Intelligence/Machine Learning,人工智能/机器学习)算法查找共性对象等技术应用已经能保障较高水平的定界定位准确度,但新的协议栈的引入、新的网络实体的引入、网络拓扑的变化也会带来新的诉求,需要不断调优。如果考虑支撑后端自动闭环,那么对于定界定位准确度的要求会更严格。
相对于已经发生的问题,更有价值的是提前发现网络中的质差隐患。在问题还未影响用户感知或者影响批量用户的感知之前,及时识别网络中存在的隐患或者问题,以便提前处理和解决。这种隐患往往还未导致大面积的客户体验质差,因此,网络级的指标仍然表现正常。但是从局部范围看,对应的指标可能已经在缓慢发生劣化,或者异于平常的状态,发生了突变。因此,对一个自智的核心网而言,需要精准自动识别此类异常或者隐患,对于本域可以解决的异常或隐患提前预警或者自动修复,对于周边域的异常或隐患则自动预警。因此,保障异常及隐患识别的准确性、及时性、不误报、不漏报、实时识别、提前预警、确保足够的处理时间窗,仍面临较大挑战。
第三,自动保障闭环挑战。
如果网络中已经发生了客户体验质差,需要尽快闭环解决。在自动化实施闭环场景下,最大的挑战是如何确保闭环动作能达成既定效果。 如果存在多个故障/问题点,则存在多种优化手段,优先使用哪些手段恢复,实施后是否可以解决问题,或者是否可以达到优化提升效果,都需要通过计算仿真得到评估预测结果,并基于预测结果给出最优策略选择。
此外,如何保障不同客户群体验的平衡也是需要考虑的问题。无论移动网络如何扩容,移动网络的容量、带宽相对用户日益发展的业务需求来说总是稀缺资源,所以在保障高价值客户的体验和保障普通客户的体验上需要合理平衡资源,确保较高的整体用户满意度。
对终端用户而言,业务体验差时如果能享受到及时的一对一服务响应,且问题能及时地被闭环解决,也有助于客户体验的整体提升。基于核心网运维系统丰富的数据,助力运营商提升AIGC(Artificial Intelligence Generated Content,人工智能生成内容)助理能力、优化运维效率、改善终端用户感知也将是新的能力构建点。
虚拟化、容器化等云计算技术的突破为IT行业注入了强劲动力,而传统通信领域因长期依赖专有硬件与软硬件紧耦合模式,始终面临部署效率低下、软件开发周期冗长、运维管理复杂以及业务部署灵活性不足等瓶颈。随着4G时代电信行业的快速发展,CT(Communication Technology,通信技术)领域开始深度融合云计算技术,通过对传统电信网络实施组网架构重构、硬件资源重构及软件功能重构,逐步构建出具备云原生特性的新一代电信云,如图1-20所示。

图1-20 具备云原生特性的新一代电信云
注:TTM为Time to Market,上市时间;OPEX为Operating Expenditure,运营支出。
电信云涵盖一系列的虚拟化和云化技术,其中关键技术和架构如下。
NFV技术通过软硬件解耦及功能抽象,使网络设备功能不再依赖于专有硬件,资源可以实现充分、灵活共享,实现新业务的快速开发和部署,并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等。NFV是运营商为了解决电信网络硬件繁多、部署运维复杂、业务创新困难的问题而提出的。NFV在重构电信网络的同时,给运营商带来了降低TCO(Total Cost of Ownership,总拥有成本)、缩短TTM、构建开放的生态系统等优势。
降低TCO。NFV将传统电信网元软硬件解耦,把原来的专有硬件替换为标准的x86服务器、通用存储、网络设备,并使用云计算技术对服务器、通用存储、网络设备进行云化。由于“云”的组成节点极其廉价,设备成本和能源功耗得以大大降低。“云”的自动化集中式管理使管理运营效率提高,运营成本降低。“云”的通用性使资源的利用率较传统系统的大幅提高。总体来看,NFV的实施可以降低运营商的TCO。
缩短TTM。在NFV架构的电信网络中,增加新的业务节点变得异常简单,不再需要复杂的工勘、硬件安装过程。业务部署根据需要申请足够的云化资源(计算/存储/网络资源)之后,安装相应的软件并调测即可。整个过程相对传统电信网元的部署,节省了80%左右的时间。同时,如果需要更新业务逻辑、增加新的业务,也只需要更新软件并部署即可,不再需要传统电信网络中软硬件同步升级甚至更换的复杂操作,真正做到了业务可灵活调整和扩展,大大缩短了TTM,使业务创新变得更加简单。
构建开放的生态系统。传统电信网络的专有软硬件模式,决定了它是一个封闭性较高的系统。NFV架构下的电信网络,基于标准的硬件平台和简化的软件,更易于开放平台和开放接口,引入第三方开发者,使得运营商可以和第三方合作伙伴共建开放的生态系统。
NFV架构由NFVI、VNF、MANO(Management and Orchestration,管理编排系统)3个部分组成[2],如图1-21所示。

图1-21 NFV架构
注:OSS为Operational Support System,运行支撑系统;EM为Element Manager,网元管理。
第一部分是NFVI。NFVI就好比各手机厂商推出的手机系统,它给硬件设备赋予基本的组件,支持网络应用所需要的软件或者容器管理平台。
第二部分是VNF。VNF是实现NF(转发服务、IP配置等)的软件应用,就好比手机上的App。在NFV架构中,各种VNF在NFVI的基础上实现。NFVI是标准化的架构,使得不同的VNF之间实现了通用,不再依赖于原来的黑盒设备。
第三部分是MANO。MANO是用于管理各个VNF以及NFVI的统一框架,方便运维人员进行业务编排与设备管理。
SDN是一种网络管理方法,建立在将网络基础设施的控制面与转发面分离的基础上,将自动化和编程应用于控制面,使管理员具有动态调整全网流量的能力。SDN通过抽象物理网络资源(交换机、路由器等)将网络控制集中到SDN控制器上,使整个网络在逻辑上体现为单一的网络设备,通过可编程配置实现自动化配置、控制、保护和资源调整,具有网络部署方便、网络控制灵活、易扩展等特点。SDN架构如图1-22所示。

图1-22 SDN架构
注:PE为Provider Edge,运营商边缘(路由器);DC-GW为Data Center-Gateway,数据中心网关;EOR为End of Row,列尾交换机;TOR为Top of Rack,架顶交换机;VXLAN为Virtual Extensible Local Area Network,虚拟扩展局域网;NCE-Fabric为Network Cloud Engine-Fabric,网络云引擎-数据中心。
容器化架构如图1-23所示,容器化作为电信云演进的关键技术,其在轻量级虚拟化、敏捷部署和资源效率优化方面展现出显著优势。容器化的核心技术特征包括以下4点。

图1-23 容器化架构
第一,轻量化与高性能。基于Linux内核的资源隔离机制使得容器启动速度更快(毫秒级),资源占用率仅为虚拟机的1/10~1/5,显著提高了硬件利用率。容器化网元可快速弹性扩缩容,满足边缘云场景下的低时延、高吞吐需求。
第二,标准化与开源生态。ETSI(European Telecommunications Standards Institute,欧洲电信标准组织)等标准组织已推动容器在NFV领域的标准化,例如扩展NFV-MANO架构以支持容器集群管理,实现容器与虚拟机的混合编排。Kubernetes成为主流容器编排平台,并通过电信级增强满足平台高可靠性要求。
第三,云原生融合。容器与微服务、DevOps(Development and Operations,开发运维一体化)结合,支持NF的模块化重构。例如,华为TCC(Telco Converged Cloud,融合电信云)通过双栈架构(虚拟机+容器)实现统一资源管理,加速业务迭代。此外,容器支持跨环境(开发/生产/边缘)无缝迁移,简化混合云部署。
第四,技术局限性。容器在电信级场景下面临挑战,如缺乏硬件故障感知能力、网络性能优化不足,以及安全隔离性弱于虚拟机等。因此,短期内应采用虚拟机与容器共存模式。
电信云系统由微服务构成,微服务之间只能通过接口进行交互,微服务独立于开发、测试、发布、部署、升级。微服务架构如图1-24所示。
从NFV虚拟化到云化再到云原生,电信云的技术不断演进,但电信云的规模化部署仍面临技术、生态与运营层面的多重挑战。
图1-24 微服务架构
第一个挑战是技术复杂性。
多技术栈共存。NFV、SDN、容器化与云原生技术应深度协同,但标准碎片化导致多厂商互操作性差,如SDN/NFV开源滞后。
性能与可靠性瓶颈。容器化需匹配电信级高可用性,并优化底层硬件加速,如FPGA(Field Programmable Gate Array,现场可编程门阵列)和GPU(Graphics Processing Unit,图形处理单元)。
能耗管理。NFV引入通用硬件可能会增加整体能耗,需通过动态调度与绿色计算机制来平衡性能与能效。
第二个挑战是组织与流程转型。
运维模式变革。容器化要求运维体系从传统“烟囱式”向DevOps转型,但现有FCAPS(Fault,Configuration,Accounting,Performance,Security,故障、配置、计费、性能、安全)网络管理模型流程需重构以适应自动化编排。
跨领域人才缺口。同时精通CT网络与IT云技术的复合型人才稀缺,制约技术落地。
第三个挑战是生态与商业模式。
供应商锁定风险。传统VNF采用垂直集成堆栈,限制了运营商的灵活性;而要推广开放的水平架构,就必须打破厂商之间的壁垒。
混合云治理难题。跨公有云/私有云/边缘云资源的统一编排与策略协同尚未成熟,影响服务一致性。
综上所述,电信云的持续演进需以云原生为核心,通过CNF(Cloud-Native Function,云原生功能)替代VNF等技术迭代、生态共建(开源社区协作)和运营重构(敏捷组织),方能实现网络全面云化与商业敏捷。
[1]林闯,单志广,任丰原.计算机网络的服务质量(QoS)[M].北京:清华大学出版社,2004.
[2]ETSI.网络功能虚拟化(NFV)架构标准[Z].2020.