CN114710798B - 一种故障定位方法及装置 - Google Patents

一种故障定位方法及装置 Download PDF

Info

Publication number
CN114710798B
CN114710798B CN202210407812.2A CN202210407812A CN114710798B CN 114710798 B CN114710798 B CN 114710798B CN 202210407812 A CN202210407812 A CN 202210407812A CN 114710798 B CN114710798 B CN 114710798B
Authority
CN
China
Prior art keywords
performance index
fault
signaling
index data
network element
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210407812.2A
Other languages
English (en)
Other versions
CN114710798A (zh
Inventor
周诗雨
刘喜卿
程新洲
赵振桥
肖天
成晨
朱小萌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China United Network Communications Group Co Ltd
Original Assignee
China United Network Communications Group Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China United Network Communications Group Co Ltd filed Critical China United Network Communications Group Co Ltd
Priority to CN202210407812.2A priority Critical patent/CN114710798B/zh
Publication of CN114710798A publication Critical patent/CN114710798A/zh
Application granted granted Critical
Publication of CN114710798B publication Critical patent/CN114710798B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/04Arrangements for maintaining operational condition
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了一种故障定位方法及装置,涉及网络管理技术领域,用于迅速、有效地定位5G核心网三层架构中的故障。该方法包括:采集业务流程中各个网元之间交互的信令;在业务流程失败时,根据业务流程中各个网元之间交互的信令,确定出故障相关的网元;获取故障相关的网元的运行数据,故障相关的网元的运行数据包括容器接口的性能指标数据、虚拟机接口的性能指标数据以及宿主机接口的性能指标数据;判断故障相关的网元的运行数据中是否存在异常的性能指标数据;在故障相关的网元的运行数据中存在异常的性能指标数据时,将异常的性能指标对应的接口确定为故障位置,异常的性能指标对应的接口为容器接口、虚拟机接口或者宿主机接口。

Description

一种故障定位方法及装置
技术领域
本申请涉及网络管理技术领域,尤其涉及一种故障定位方法及装置。
背景技术
随着网络技术的不断发展,第五代移动通信技术(5th Generation MobileCommunication Technology,5G)的核心网面临着由传统网络架构向虚拟化开放网络架构的转型。
采用三层架构部署网络,可以使5G核心网充分释放5G网络能力,促进5G核心网的云化,实现全网资源共享。但是,运行业务流程时,仍然存在着告警信息海量、故障定位较为复杂等问题,严重影响网络运行效率。虽然现有的网络故障监控平台和深度包检测(DeepPacket Inspection,DPI)分析系统可以实现一定的业务监控、网元管理能力,但仍然缺少整体的跨三层架构的面向业务的监控手段。
因此,针对采用三层架构的5G核心网,如何迅速且有效地确定网络故障的位置,是一个急需解决的问题。
发明内容
本申请提供一种故障定位方法及装置,用于针对5G核心网的三层架构,准确且迅速的确定故障位置,以使得运维人员可以根据故障位置,查找故障发生的原因,进而提升网络的运行效率。
为达到上述目的,本申请采用如下技术方案:
第一方面,本申请提供一种故障定位方法,包括:采集业务流程中各个网元之间交互的信令;在业务流程失败时,根据业务流程中各个网元之间交互的信令,确定出故障相关的网元;获取故障相关的网元的运行数据,故障相关的网元的运行数据包括容器接口的性能指标数据、虚拟机接口的性能指标数据以及宿主机接口的性能指标数据;判断故障相关的网元的运行数据中是否存在异常的性能指标数据;在故障相关的网元的运行数据中存在异常的性能指标数据时,将异常的性能指标对应的接口确定为故障位置,异常的性能指标对应的接口为容器接口、虚拟机接口或者宿主机接口。
本申请提供的技术方案至少带来以下有益效果:通过采集各个网元之间交互的信令,可以从水平方向对5G核心网三层架构中的网元层进行故障梳理,确定故障相关的网元。再通过采集故障相关的网元的运行数据,包括故障相关的网元在5G核心网三层架构中各个接口的性能指标数据,可以从垂直方向对5G核心网三层架构进行故障排查,进而确定故障位置。通过水平方向和垂直方向对采用三层架构的5G核心网进行故障定位,可以实现对5G核心网的全面监控,更加精准、迅速、有效进行故障定位,进而探寻故障发生原因,以便运维人员可以针对该故障进行网络维护。
可选的,判断故障相关的网元的运行数据中是否存在异常的性能指标数据,包括:对于故障相关的网元的运行数据中的各个性能指标数据,判断性能指标数据是否处于预设取值范围内;若性能指标数据处于预设取值范围内,则确定性能指标数据为正常的性能指标数据;若性能指标数据未处于预设取值范围内,则确定性能指标数据为异常的性能指标数据。这样,通过预设取值范围的设置,可以确定故障相关的网元的运行数据中是否存在异常的性能指标数据,进而判断故障是否发生在该网元的各个接口中,方便运维人员据此确定故障原因。
可选的,性能指标数据包括:超文本传输协议(Hypertext Transfer Protocol,HTTP)时延峰值、传输控制协议(Transmission Control Protocol,TCP)建连客户端时延峰值或者TCP建连服务端时延峰值中的一项或多项。通过这些性能指标数据,可以准确判断业务流程是否出现故障,若性能指标数据异常,则说明业务流程出现故障,需要运维人员进行相应的网络维护。
可选的,根据业务流程中各个网元之间交互的信令,确定出故障相关的网元,包括:对于各个信令,判断信令是否符合标准格式;若信令不符合标准格式,确定信令为异常信令;将与异常信令相关的网元确定为故障相关的网元。这样,通过判断信令是否准确,即可梳理出故障相关的网元,方便运维人员对故障相关的网元进行更深入的故障排查。
可选的,根据业务流程中各个网元之间交互的信令,确定出故障相关的网元,包括:根据业务流程中各个网元之间交互的信令,判断业务流程是否完成;若业务流程未完成,则从业务流程中各个网元之间交互的信令中,确定业务流程中最后一条信令;将与业务流程中最后一条信令相关的网元确定为故障相关的网元。这样,通过判断信令是否完整,即可梳理出故障相关的网元,方便运维人员对故障相关的网元进行更深入的故障排查。
第二方面,本申请提供一种故障定位装置,包括:包括获取单元和处理单元。
获取单元,用于采集业务流程中各个网元之间交互的信令;
处理单元,用于在业务流程失败时,根据业务流程中各个网元之间交互的信令,确定出故障相关的网元;
获取单元,还用于获取故障相关的网元的运行数据,故障相关的网元的运行数据包括容器接口的性能指标数据、虚拟机接口的性能指标数据以及宿主机接口的性能指标数据;
处理单元,还用于判断故障相关的网元的运行数据中是否存在异常的性能指标数据;
处理单元,还用于在故障相关的网元的运行数据中存在异常的性能指标数据时,将异常的性能指标对应的接口确定为故障位置,异常的性能指标对应的接口为容器接口、虚拟机接口或者宿主机接口。
可选的,处理单元,具体用于:对于故障相关的网元的运行数据中的各个性能指标数据,判断性能指标数据是否处于预设取值范围内;若性能指标数据处于预设取值范围内,则确定性能指标数据为正常的性能指标数据;若性能指标数据未处于预设取值范围内,则确定性能指标数据为异常的性能指标数据。
可选的,性能指标数据包括:HTTP时延峰值、TCP建连客户端时延峰值或者TCP建连服务端时延峰值中的一项或多项。
可选的,处理单元,具体用于:对于各个信令,判断信令是否符合标准格式;若信令不符合标准格式,确定信令为异常信令;将与异常信令相关的网元确定为故障相关的网元。
可选的,处理单元,具体用于:根据业务流程中各个网元之间交互的信令,判断业务流程是否完成;若业务流程未完成,则从业务流程中各个网元之间交互的信令中,确定业务流程中最后一条信令;将与业务流程中最后一条信令相关的网元确定为故障相关的网元。
第三方面,本申请提供一种计算机可读存储介质,该计算机可读存储介质中存储有计算机指令,当该计算机指令在计算机上运行时,使得计算机执行上述任一种故障定位方法。
第四方面,本申请提供一种装置,包括:处理器和存储器;该存储器用于存储计算机执行指令,该处理器与存储器连接,当装置运行时,处理器执行存储器存储的计算机执行指令,以使该装置执行上述任一种故障定位方法。
第五方面,本申请提供了一种包含计算机执行指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述任一种故障定位方法。
在本申请的具体实现方式中,上述装置各部件的名字对设备本身不构成限定,在实际实现中,这些部件可以以其他名称出现。只要各个部件的功能和本申请的具体实现方式类似,即属于本申请权利要求及其等同技术的范围之内。
另外,第二方面至第五方面中任一种设计方式所带来的技术效果可参见上述第一方面中不同设计方法所带来的技术效果,此处不再赘述。
附图说明
图1为本申请实施例提供的一种5G核心网三层架构的结构示意图;
图2为本申请实施例提供的一种5G核心网三层架构中采集器的部署示意图;
图3为本申请实施例提供的一种故障定位装置的硬件结构示意图;
图4为本申请实施例提供的一种故障定位方法的流程示意图;
图5为本申请实施例提供的又一种故障定位方法的流程示意图;
图6为本申请实施例提供的又一种故障定位方法的流程示意图;
图7为本申请实施例提供的一种注册业务的流程示意图;
图8为本申请实施例提供的一种故障定位装置的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中,除非另有说明,“多个”的含义是两个或两个以上。
在本申请的描述中,需要说明的是,除非另有明确的规定和限定,术语“相连”、“连接”应做广义理解,例如,可以是固定连接,也可以是可拆卸连接,或一体地连接。对于本领域的普通技术人员而言,可以具体情况理解上述术语在本申请中的具体含义。另外,在对管线进行描述时,本申请中所用“相连”、“连接”则具有进行导通的意义。具体意义需结合上下文进行理解。
在本申请实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
如背景技术所描述,在5G核心网运行过程中,存在海量的告警信息,故障定位较为复杂。因此,亟需一种迅速、有效的故障定位方法,准确定位故障发生的位置,探寻发生故障的原因,使得运营商可以据此进行网络优化,提高服务质量。
针对上述问题,本申请实施例提供一种故障定位方法,可以根据5G核心网中网元层的信令,确定故障相关的网元。再采集故障相关的网元在三层架构各个接口的运行数据,判断其中是否出现异常性能指标数据,进而根据异常指标数据定位故障。通过水平方向与垂直方向对5G核心网进行监控,对故障定位更加准确、有效,且实际实施也更加简单。
本申请提供的故障定位方法,适用于图1所示的采用三层架构的5G核心网100中。如图1所示,采用三层架构的5G核心网100由硬件层101、虚拟层102以及网元层103三部分组成,各部分之间通过接口(图1未示出)进行信息交互。应理解,此处对模块的划分是示意性的,仅仅为一种逻辑功能划分,并不代表各功能模块的实际位置部署如图1所示。
在一些实施例中,硬件层101中包括多个宿主机。其中,宿主机可以理解为担当一“宿主”身份的计算机硬件,为计算机运行提供物质基础。
在一些实施例中,虚拟层102中包括多个虚拟机。
需要说明的是,通过虚拟化技术,可以将一台宿主机虚拟化得到多个虚拟机。在一台宿主机上可以运行多台虚拟机,每台虚拟机可运行不同的操作系统,并且应用程序都可以在相互独立的空间内运行而互不影响,从而显著提高计算机的工作效率。
虚拟化技术主要分为以下几类:
第一类、平台虚拟化(Platform Virtualization)。
在一些实施例中,实际应用中通常所说的虚拟化主要是指平台虚拟化技术,是指针对计算机和操作系统的虚拟化。平台虚拟化通过使用控制程序(Control Program,也被称为Virtual Machine Monitor或Hypervisor),隐藏特定计算平台的实际物理特性,为用户提供抽象的、统一的、模拟的计算环境。
第二类、资源虚拟化(Resource Virtualization)。
在一些实施例中,资源虚拟化,是指针对特定的系统资源的虚拟化,比如内存、存储、网络资源等。例如,“虚拟内存”就是通过将一部分不用的硬盘虚拟化为内存,实际上,硬盘资源并没有增加,只是提高了硬盘的利用率。
第三类、应用虚拟化(Application Virtualization)。
在一些实施例中,应用虚拟化,是指针对应用层面的虚拟化,包括仿真、模拟、解释技术等。
在一些实施例中,网元层101中包括多个容器。其中,容器是一个允许在资源隔离的过程中运行应用程序和其依赖项的、轻量的、操作系统级别的虚拟化技术。容器为网元提供隔离的运行空间,网元指在网络管理中可以实现监视和管理功能的最小单位。每个容器内都包含一个独享的完整用户环境空间,并且一个容器内的变动不会影响其他容器的运行环境。多个容器可以在同一台虚拟机上运行,并与其他容器共享系统内核。
在一些实施例中,网元层103中的网元通过容器接口实现网元与虚拟层102之间的信息交互,通过虚拟机接口实现与硬件层101之间的信息交互,通过宿主机接口实现与外部设备之间的信息交互。
在一些实施例中,在5G核心网的三层架构之间,可以部署采集器,以采集网元在三层架构之间的各个接口的运行数据。
图2为本申请提供的一种5G核心网三层架构中采集器的部署方式。如图2所示,在虚拟层102与网元层103中,可以部署标记型语言(Plain Old Documentation,POD)采集器,以采集5G核心网中各个网元的容器接口以及虚拟机接口的运行数据。在硬件层101中,可以部署多计算机切换器(Keyboard Video Mouse,KVM)采集器,以采集5G核心网中各个网元的宿主机接口的运行数据。
本申请还提供了一种故障定位装置200,用于采集、存储各个网元的运行数据,并根据网元的运行数据确定故障的位置,可以应用于如图1所示的5G核心网中。
图3为故障定位装置200的一种硬件结构示意图。如图3所示,该故障定位装置200包括处理器201、存储器202、通信接口203、总线204,存储器202独立于处理器201存在。其中,处理器201、存储器202以及通信接口203之间可以通过总线204连接。
在一些实施例中,处理器201是故障定位装置的控制中心,可以是一个处理器,也可以是多个处理元件的统称。例如,处理器201可以是一个通用中央处理单元(centralprocessing unit,CPU),也可以是其他通用处理器等。其中,通用处理器可以是微处理器或者是任何常规的处理器等。
在一些实施例中,处理器201可以包括一个或多个CPU,例如图3中所示的CPU 0和CPU 1。
在一些实施例中,存储器202可以是只读存储器(read-only memory,ROM)或可存储静态信息和指令的其他类型的静态存储设备,随机存取存储器(random access memory,RAM)或者可存储信息和指令的其他类型的动态存储设备,也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory,EEPROM)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。
在一些实施例中,存储器202可以通过总线204与处理器201相连接,用于存储指令或者程序代码。处理器201调用并执行存储器202中存储的指令或程序代码时,能够实现本发明实施例提供的故障定位方法。
在一些实施例中,存储器202也可以与处理器201集成在一起。
在一些实施例中,通信接口203,用于与其他设备通过通信网络连接。所述通信网络可以是以太网,无线接入网,无线局域网(wireless local area networks,WLAN)等。通信接口203可以包括用于接收数据的接收单元,以及用于发送数据的发送单元。
在一些实施例中,总线204,可以是工业标准体系结构(Industry StandardArchitecture,ISA)总线、外部设备互连(Peripheral Component Interconnect,PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture,EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,图3中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
需要指出的是,图3中示出的结构并不构成对故障定位装置的限定,除图3所示部件之外,该故障定位装置可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合上述图1示出的5G核心网三层架构以及图3示出的故障定位装置,对本申请实施例提供的故障定位方法进行详细介绍。
如图4所示,本申请实施例提供一种故障定位方法,应用于上述故障定位装置200,该方法包括以下步骤:
S101、采集业务流程中各个网元之间交互的信令。
在一些实施例中,通过在5G核心网的网元层部署探针,故障定位装置可以采集到网元层各个网元之间交互的信令。
在一些实施例中,故障定位装置实时监测网元层各个网元之间交互的信令,并将采集到的信令存储起来。由于存储空间的限制,管理人员可以预先设置故障定位装置存储预设时间段内各个网元之间交互的信令。例如,管理人员可以根据故障定位装置存储空间的大小,设置故障定位装置存储过去7天内各个网元之间交互的信令,也可以设置故障定位装置存储过去30天内各个网元之间交互的信令。
S102、在业务流程失败时,根据业务流程中各个网元之间交互的信令,确定出故障相关的网元。
需要说明的是,各个网元之间进行信令交互,依据第三代合作伙伴计划(3rdGeneration Partnership Project,3GPP)标准。应理解的是,业务流程的进行依赖于各个网元之间交互的信令的准确性和完整性。当网元之间交互的信令出现错误或信令不完整时,业务流程就会失败,当网元之间交互的信令完整且准确时,业务流程才得以进行下去。所以,当网元之间交互的信令出现错误或信令不完整时,可以确定发出、传递或者接收这些信令的网元之中的一项或多项发生故障,则可以将发出、传递以及接收这些信令的网元确定为故障相关的网元。
S103、获取故障相关的网元的运行数据。
其中,故障相关的网元的运行数据包括容器接口的性能指标数据、虚拟机接口的性能指标数据以及宿主机接口的性能指标数据。
在一些实施例中,性能指标数据包括以下一项或多项。
1、HTTP时延峰值。
HTTP是浏览器与服务器之间进行数据传输必须遵循的规则,也是互联网上应用最为广泛的一种网络协议。
HTTP时延指客户端发送HTTP请求到服务端响应HTTP请求之间的时延。
2、TCP建连客户端时延峰值。
TCP是一种面向连接(连接导向)的、可靠的、基于字节流的运输层(Transportlayer)通信协议。为实现数据的可靠传输,TCP要在应用进程间建立传输连接。它是在两个传输用户之间建立一种逻辑联系,使得通信双方都确认对方为自己的传输连接端点。TCP连接的建立采用客户端服务端方式,主动发起连接建立的应用进程叫做客户端,而被动等待连接的应用进程叫做服务端。
TCP建联客户端时延指从客户端发出请求报文段到客户端发出确认报文段之间的时长。
3、TCP建连服务端时延峰值。
TCP建联服务端时延指从服务端接收到来自于客户端的请求报文段到服务端接收到来自于客户端的确认报文段之间的时长。
应理解的是,这些性能指标数据可以通过部署在5G核心网三层架构中的采集器获得。若性能指标数据出现异常,则说明采集到该性能指标数据的接口出现故障,运维人员应对此处进行维护,以保障网络的运行效率。
在一些实施例中,在采集业务流程中各个网元各个接口之间的运行数据之后,故障定位装置可以以流程图形式呈现每次业务具体流程,以便运维人员根据流程图对网络进行优化升级。
S104、判断故障相关的网元的运行数据中是否存在异常的性能指标数据。
在一些实施例中,可以通过判断性能指标数据是否处于预设取值范围内,来判断故障相关的网元的运行数据中是否存在异常的性能指标数据。若性能指标数据处于预设取值范围内,则确定该性能指标数据为正常的性能指标数据;若性能指标数据未处于预设取值范围内,则确定该性能指标数据为异常的性能指标数据。
其中,预设取值范围可以通过该网元预设时长内的运行数据来确定。例如,预设取值范围的上限可以是该网元过去7天内的运行数据的均值的150%,预设取值范围的下限可以是该网元过去7天内的运行数据的均值的50%。
例如,假设网元接入与移动管理功能(access and mobility managementfunction,AMF)过去7天内虚拟机接口的HTTP时延峰值均值为600ms,则可以确定AMF虚拟机接口的HTTP时延峰值的预设取值范围为300ms-900ms。若检测到AMF虚拟机接口的HTTP时延峰值为547.3ms,处于预设取值范围内,则AMF虚拟机接口的HTTP时延峰值为正常的性能指标数据。若检测到AMF虚拟机接口的HTTP时延峰值为1036ms,未处于预设取值范围内,则AMF虚拟机接口的HTTP时延峰值为异常的性能指标数据。
S105、在故障相关的网元的运行数据中存在异常的性能指标数据时,将异常的性能指标对应的接口确定为故障位置。
其中,异常的性能指标对应的接口为容器接口、虚拟机接口或者宿主机接口。
图4所示技术方案至少带来以下有益效果:本申请提供的方案通过采集各个网元之间交互的信令,首先对5G核心网三层架构中的网元层进行故障梳理,确定故障相关的网元。再排查故障相关的网元的运行数据,进而确定故障位置。从水平方向和垂直方向全面监控5G核心网的三层架构,可以更加精准、迅速、有效进行故障定位。
在一些实施例中,基于图4所示的实施例,如图5所示,上述步骤S102可以具体实现为步骤S201-S203。
S201、对于各个信令,判断信令是否符合标准格式。
S202、若信令不符合标准格式,确定信令为异常信令。
S203、将与异常信令相关的网元确定为故障相关的网元。
在一些实施例中,与异常信令相关的网元包括发出异常信令的网元、传递异常信令的网元或者接收异常信令的网元中的一个或多个。
应理解的是,3GPP标准规定了信令的标准格式,不符合标准格式的异常信令不能被网元识别,则会导致业务流程失败。当故障定位装置监控网元层时,若采集到的各个网元之间交互的信令中出现了异常信令,则说明发出该信令的网元、传递该信令的网元或者接收该信令的网元中的一个或多个发生故障,进而可以将发出该信令的网元、传递该信令的网元以及接收该信令的网元确定为故障相关的网元。
图5所示技术方案至少带来以下有益效果:上述方法主要从信令的准确性来判断业务是否失败。由于各个网元之间交互的信令都有标准的格式,所以在采集到网元层各个网元之间交互的信令之后,只需判断信令是否符合标准格式,即可梳理出故障相关的网元,方便运维人员后续对故障相关的网元进行更深层次的故障排查。
在一些实施例中,基于图4所示的实施例,如图6所示,上述步骤S102可以具体实现为步骤S301-S303。
S301、根据业务流程中各个网元之间交互的信令,判断业务流程是否完成。
S302、若业务流程未完成,则从业务流程中各个网元之间交互的信令中,确定业务流程中最后一条信令。
S303、将与业务流程中最后一条信令相关的网元确定为故障相关的网元。
在一些实施例中,与业务流程中最后一条信令相关的网元包括发出最后一条信令的网元、传递最后一条信令的网元或者接收最后一条信令的网元中的一个或者多个。
应理解的是,3GPP标准规定了业务流程完成时信令的标准格式。即当业务流程中某一信令之后各个网元之间不进行信令交互时,认为信令不完整,业务流程未完成。当故障定位装置监控网元层时,若采集到业务流程进行到某一信令时缺少后续信令,导致业务流程未完成,则确定该信令为业务流程中最后一条信令。这种情况说明发出最后一条信令的网元、传递最后一条信令的网元或者接收最后一条信令的网元中的一个或多个发生故障,进而可以将发出最后一条信令的网元、传递最后一条信令的网元以及接收最后一条信令的网元确定为故障相关的网元。
图6所示技术方案至少带来以下有益效果:上述方法主要从信令的完整性来判断业务是否失败。由于3GPP标准规定了业务流程完成时的各个网元之间交互的信令的标准格式,所以当信令不完整时,就会导致业务流程未完成,这样就说明与最后一条信令相关的网元出现了故障。通过监测网元层各个网元之间交互的信令,可以从水平方向梳理出故障相关的网元,方便运维人员后续对故障相关的网元的各个接口进行故障排查。
在一些实施例中,业务流程可以包括注册、服务请求、PDU会话建立、切换以及策略关联等。接下来将以注册业务为例具体描述本申请提供的故障定位方法,如图7所示,注册流程可以包括以下步骤:
S401、通信设备向接入网设备发送注册请求。
S402、接入网设备执行AMF选择流程。
S403、接入网设备向第一AMF发送注册请求。
S404、第一AMF根据注册请求,确定第二AMF,并向第二AMF发送上下文传输请求。
其中,第一AMF是当前为通信设备提供服务的AMF。第二AMF是之前为通信设备提供服务的AMF。
S405、第二AMF向第一AMF发送上下文传输请求的响应消息。
S406、第一AMF向通信设备发送标识请求(例如Identity Request)。
S407、通信设备向第一AMF发送标识请求的响应消息(Identity Response)。
S408、第一AMF执行鉴权功能(authentication server function,AUSF)选择流程。
S409、通信设备和网络侧之间执行认证和安全流程。
在步骤S9中,通信设备与网络侧之间会执行主鉴权流程,并且在主鉴权流程结束之后,通信设备会与网络侧建立/激活安全上下文。
S410、第一AMF向第二AMF发送注册完成通知。
S411、第一AMF向UE发起标识获取流程。
S412、第一AMF与设备标识寄存器(equipment identity register,EIR)执行设备标识检查。
S413、第一AMF执行统一数据管理(unified data management,UDM)选择流程。
S414、第一AMF与UDM执行注册、订阅获取流程。
S415、若第一AMF确定第二AMF提供的策略控制功能(policy control function,PCF)信息不可用,第一AMF执行PCF选择流程。
S416、若第一AMF确定第二AMF提供的PCF信息可用,且PCF信息指示的PCF是第二AMF使用的PCF时,第一AMF向该PCF发送控制策略获取请求。
S417、第一AMF向SMF发送事件开放通知消息。
S418、第一AMF向非3GPP互通功能(non-3GPP interworking function,N3IWF)发送N2请求。
S419、N3IWF向第一AMF返回N2请求的响应消息。
S420、第一AMF向通信设备发送注册接收消息(例如Registration Accept)。
其中,注册接收消息用于指示网络侧接受通信设备的注册。
S421、通信设备向第一AMF发送注册完成消息(例如Registration complete)。
可以理解的是,注册完成消息用于指示完成注册流程。以上对注册流程中各个步骤进行了介绍,注册流程还可以包括其他步骤,本申请实施例不限于此。
假设故障定位装置通过采集5G核心网三层架构中网元层各个网元之间交互的信令,得知注册流程中第8步鉴权失败,则可以据此确定故障相关的网元为AMF、AUSF、UDM。
以性能指标数据包括HTTP时延峰值、TCP建连客户端时延峰值以及TCP建连服务端时延峰值为例,查阅采集器采集到的各个网元各接口的性能指标数据。
当前AMF各个接口的性能指标数据如表1所示。
表1当前AMF各个接口的性能指标数据
AMF各个接口的性能指标数据的预设取值范围如表2所示。
表2 AMF各个接口的性能指标数据的预设取值范围
对比表1与表2的数据可以得知,AMF的运行数据中的各个性能指标数据均处于预设的取值范围内,不存在异常的性能指标数据,则说明与AMF相关的接口并未出现故障。
当前AUSF各个接口的性能指标数据如表3所示。
表3当前AUSF各个接口的性能指标数据
AUSF各个接口的性能指标数据的预设取值范围如表4所示。
表4 AUSF各个接口的性能指标数据的预设取值范围
对比表3与表4的数据可以得知,AUSF的运行数据中的各个性能指标数据均处于预设的取值范围内,不存在异常的性能指标数据,则说明与AUSF相关的接口并未出现故障。
当前UDM各个接口的性能指标数据如表5所示。
表5当前UDM各个接口的性能指标数据
UDM各个接口的性能指标数据的预设取值范围如表6所示。
表6 UDM各个接口的性能指标数据的预设取值范围
对比表5与表6的数据可以得知,UDM虚拟机接口的HTTP时延峰值与TCP建连服务端时延峰值超出预设取值范围,UDM宿主机接口的HTTP时延峰值、TCP建连客户端时延峰值以及TCP建连服务端时延峰值均超出预设取值范围,则可以锁定故障发生在UDM的虚拟机接口与宿主机接口,需要运维人员对这两个接口进行维护。
上述主要从方法的角度对本申请提供的方案进行了介绍。可以理解的是,为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的算法步骤,本发明能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
本申请实施例还提供一种故障定位装置800。如图8所示,为本申请实施例提供的一种故障定位装置800的结构示意图。该故障定位装置800用于解决针对5G核心网三层架构中存在海量告警信息、故障定位较为复杂的问题,例如用于执行图4、图5或图6所示的故障定位方法。该故障定位装置800包括:获取单元801和处理单元802。
获取单元801,用于采集业务流程中各个网元之间交互的信令。
处理单元,用于在业务流程失败时,根据业务流程中各个网元之间交互的信令,确定出故障相关的网元。
获取单元801,还用于获取故障相关的网元的运行数据,故障相关的网元的运行数据包括容器接口的性能指标数据、虚拟机接口的性能指标数据以及宿主机接口的性能指标数据。
处理单元802,还用于判断故障相关的网元的运行数据中是否存在异常的性能指标数据。
处理单元802,还用于在故障相关的网元的运行数据中存在异常的性能指标数据时,将异常的性能指标对应的接口确定为故障位置,异常的性能指标对应的接口为容器接口、虚拟机接口或者宿主机接口。
在一些实施例中,处理单元802,具体用于:对于故障相关的网元的运行数据中的各个性能指标数据,判断性能指标数据是否处于预设取值范围内;若性能指标数据处于预设取值范围内,则确定性能指标数据为正常的性能指标数据;若性能指标数据未处于预设取值范围内,则确定性能指标数据为异常的性能指标数据。
在一些实施例中,处理单元802,具体用于:对于各个信令,判断信令是否符合标准格式;若信令不符合标准格式,确定信令为异常信令;将与异常信令相关的网元确定为故障相关的网元。
在一些实施例中,处理单元802,具体用于:根据业务流程中各个网元之间交互的信令,判断业务流程是否完成;若业务流程未完成,则从业务流程中各个网元之间交互的信令中,确定业务流程中最后一条信令;将与业务流程中最后一条信令相关的网元确定为故障相关的网元。
应理解,本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
本申请实施例还提供了一种计算机可读存储介质,包括计算机执行指令,当其在计算机上运行时,使得计算机执行上述实施例提供的任意一种故障定位方法。
本申请实施例还提供了一种装置,包括:处理器和存储器,该存储器用于存储计算机执行指令,该处理器与存储器连接,当装置运行时,处理器执行存储器存储的计算机执行指令,以使该装置执行上述实施例提供的任意一种故障定位方法。
本申请实施例还提供了一种包含计算机执行指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述实施例提供的任意一种故障定位方法。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时,可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机执行指令。在计算机上加载和执行计算机执行指令时,全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机执行指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,计算机执行指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如,软盘、硬盘、磁带),光介质(例如,DVD)、或者半导体介质(例如固态硬盘(solid state disk,SSD))等。
尽管在此结合各实施例对本申请进行了描述,然而,在实施所要求保护的本申请过程中,本领域技术人员通过查看附图、公开内容、以及所附权利要求书,可理解并实现公开实施例的其他变化。在权利要求中,“包括”(comprising)一词不排除其他组成部分或步骤,“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施,但这并不表示这些措施不能组合起来产生良好的效果。
尽管结合具体特征及其实施例对本申请进行了描述,显而易见的,在不脱离本申请的精神和范围的情况下,可对其进行各种修改和组合。相应地,本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明,且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何在本申请揭露的技术范围内的变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应该以权利要求的保护范围为准。

Claims (12)

1.一种故障定位方法,其特征在于,所述方法包括:
采集业务流程中各个网元之间交互的信令;
在所述业务流程失败时,根据所述业务流程中各个网元之间交互的信令,确定出故障相关的网元;
获取所述故障相关的网元的运行数据,所述故障相关的网元的运行数据包括容器接口的性能指标数据、虚拟机接口的性能指标数据以及宿主机接口的性能指标数据;
判断所述故障相关的网元的运行数据中是否存在异常的性能指标数据;
在所述故障相关的网元的运行数据中存在异常的性能指标数据时,将所述异常的性能指标对应的接口确定为故障位置,所述异常的性能指标对应的接口为所述容器接口、所述虚拟机接口或者所述宿主机接口。
2.根据权利要求1所述的方法,其特征在于,所述判断所述故障相关的网元的运行数据中是否存在异常的性能指标数据,包括:
对于所述故障相关的网元的运行数据中的各个性能指标数据,判断所述性能指标数据是否处于预设取值范围内;
若所述性能指标数据处于预设取值范围内,则确定所述性能指标数据为正常的性能指标数据;
若所述性能指标数据未处于预设取值范围内,则确定所述性能指标数据为异常的性能指标数据。
3.根据权利要求1或2所述的方法,其特征在于,所述性能指标数据包括:超文本传输协议HTTP时延峰值、传输控制协议TCP建连客户端时延峰值或者TCP建连服务端时延峰值中的一项或多项。
4.根据权利要求1所述的方法,其特征在于,所述根据所述业务流程中各个网元之间交互的信令,确定出故障相关的网元,包括:
对于各个信令,判断所述信令是否符合标准格式;
若所述信令不符合标准格式,确定所述信令为异常信令;
将与所述异常信令相关的网元确定为所述故障相关的网元。
5.根据权利要求1所述的方法,其特征在于,所述根据所述业务流程中各个网元之间交互的信令,确定出故障相关的网元,包括:
根据所述业务流程中各个网元之间交互的信令,判断所述业务流程是否完成;
若所述业务流程未完成,则从所述业务流程中各个网元之间交互的信令中,确定所述业务流程中最后一条信令;
将与所述业务流程中最后一条信令相关的网元确定为所述故障相关的网元。
6.一种故障定位装置,其特征在于,包括获取单元和处理单元;
所述获取单元,用于采集业务流程中各个网元之间交互的信令;
所述处理单元,用于在所述业务流程失败时,根据所述业务流程中各个网元之间交互的信令,确定出故障相关的网元;
所述获取单元,还用于获取所述故障相关的网元的运行数据,所述故障相关的网元的运行数据包括容器接口的性能指标数据、虚拟机接口的性能指标数据以及宿主机接口的性能指标数据;
所述处理单元,还用于判断所述故障相关的网元的运行数据中是否存在异常的性能指标数据;在所述故障相关的网元的运行数据中存在异常的性能指标数据时,将所述异常的性能指标对应的接口确定为故障位置,所述异常的性能指标对应的接口为所述容器接口、所述虚拟机接口或者所述宿主机接口。
7.根据权利要求6所述的装置,其特征在于,所述处理单元,具体用于:
对于所述故障相关的网元的运行数据中的各个性能指标数据,判断所述性能指标数据是否处于预设取值范围内;
若所述性能指标数据处于预设取值范围内,则确定所述性能指标数据为正常的性能指标数据;
若所述性能指标数据未处于预设取值范围内,则确定所述性能指标数据为异常的性能指标数据。
8.根据权利要求6或7所述的装置,其特征在于,所述性能指标数据包括:HTTP时延峰值、TCP建连客户端时延峰值或者TCP建连服务端时延峰值中的一项或多项。
9.根据权利要求6所述的装置,其特征在于,所述处理单元,具体用于:
对于各个信令,判断所述信令是否符合标准格式;
若所述信令不符合标准格式,确定所述信令为异常信令;
将与所述异常信令相关的网元确定为所述故障相关的网元。
10.根据权利要求6所述的装置,其特征在于,所述处理单元,具体用于:
根据所述业务流程中各个网元之间交互的信令,判断所述业务流程是否完成;
若所述业务流程未完成,则从所述业务流程中各个网元之间交互的信令中,确定所述业务流程中最后一条信令;
将与所述业务流程中最后一条信令相关的网元确定为所述故障相关的网元。
11.一种计算机可读存储介质,其特征在于,包括计算机指令,当所述计算机指令在计算机上运行时,使得所述计算机执行如权利要求1至5中任一项所述的故障定位方法。
12.一种故障定位装置,其特征在于,所述装置包括存储器和处理器;
所述存储器和所述处理器耦合;
所述存储器用于存储计算机程序代码,所述计算机程序代码包括计算机指令;
其中,当所述处理器执行所述计算机指令时,使得所述故障定位装置执行如权利要求1至5中任一项所述的故障定位方法。
CN202210407812.2A 2022-04-19 2022-04-19 一种故障定位方法及装置 Active CN114710798B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210407812.2A CN114710798B (zh) 2022-04-19 2022-04-19 一种故障定位方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210407812.2A CN114710798B (zh) 2022-04-19 2022-04-19 一种故障定位方法及装置

Publications (2)

Publication Number Publication Date
CN114710798A CN114710798A (zh) 2022-07-05
CN114710798B true CN114710798B (zh) 2024-04-19

Family

ID=82174940

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210407812.2A Active CN114710798B (zh) 2022-04-19 2022-04-19 一种故障定位方法及装置

Country Status (1)

Country Link
CN (1) CN114710798B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115442837A (zh) * 2022-08-26 2022-12-06 浪潮通信信息系统有限公司 网络系统故障排查方法、装置及电子设备
CN116723530B (zh) * 2023-08-09 2023-11-03 中国电信股份有限公司 故障网元确定方法、装置、计算机设备和存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101753243A (zh) * 2008-12-19 2010-06-23 华为技术有限公司 一种业务故障的定位方法及装置
CN104639386A (zh) * 2013-11-15 2015-05-20 中国电信股份有限公司 故障定位系统和方法
CN105471669A (zh) * 2014-09-11 2016-04-06 中国移动通信集团湖南有限公司 一种通信网络故障定位的方法及装置
WO2016184021A1 (zh) * 2015-05-21 2016-11-24 中兴通讯股份有限公司 一种虚拟化网络功能业务故障的处理方法及装置
CN108696371A (zh) * 2017-04-06 2018-10-23 中国移动通信集团广东有限公司 网络故障确定方法及系统
WO2021179643A1 (zh) * 2020-03-12 2021-09-16 华为技术有限公司 故障处理的方法、装置以及系统
CN114172794A (zh) * 2020-09-10 2022-03-11 中国联合网络通信集团有限公司 网络故障定位方法及服务器

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103856966B (zh) * 2012-11-28 2017-06-09 华为技术有限公司 远程无线网络故障的定位方法和装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101753243A (zh) * 2008-12-19 2010-06-23 华为技术有限公司 一种业务故障的定位方法及装置
CN104639386A (zh) * 2013-11-15 2015-05-20 中国电信股份有限公司 故障定位系统和方法
CN105471669A (zh) * 2014-09-11 2016-04-06 中国移动通信集团湖南有限公司 一种通信网络故障定位的方法及装置
WO2016184021A1 (zh) * 2015-05-21 2016-11-24 中兴通讯股份有限公司 一种虚拟化网络功能业务故障的处理方法及装置
CN108696371A (zh) * 2017-04-06 2018-10-23 中国移动通信集团广东有限公司 网络故障确定方法及系统
WO2021179643A1 (zh) * 2020-03-12 2021-09-16 华为技术有限公司 故障处理的方法、装置以及系统
CN114172794A (zh) * 2020-09-10 2022-03-11 中国联合网络通信集团有限公司 网络故障定位方法及服务器

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
5G核心网元多维特征融合故障预警;韦强申;《通信技术》;20220320;全文 *
吕卓琼.浅谈传输网络及设备的故障定位处理方法.《科技视界》.全文. *

Also Published As

Publication number Publication date
CN114710798A (zh) 2022-07-05

Similar Documents

Publication Publication Date Title
CN114710798B (zh) 一种故障定位方法及装置
US11700540B2 (en) Method and device for monitoring network data
CN108039964B (zh) 基于网络功能虚拟化的故障处理方法及装置、系统
EP2563062B1 (en) Long connection management apparatus and link resource management method for long connection communication
US20160006766A1 (en) Method and apparatus for providing analysis service based on behavior in mobile network environment
JP6729399B2 (ja) システム、仮想化制御装置、仮想化制御装置の制御方法及びプログラム
CN106888106A (zh) 智能电网中的it资产大规模侦测系统
EP3013001B1 (en) Service quality index calculation method and calculation apparatus, and communications system
CN106489251A (zh) 应用拓扑关系发现的方法、装置和系统
WO2016058318A1 (zh) 虚拟机vm资源弹性伸缩处理方法、装置及系统
JP6888078B2 (ja) ネットワーク機能nf管理方法及びnf管理装置
CN102790716A (zh) 使用物理网络交换机保护虚拟化计算环境的方法和装置
CN108989151B (zh) 用于网络或应用性能管理的流量采集方法
KR20170129253A (ko) 네트워크 기능 가상화 기반 장애 처리 방법 및 장치
CN111030873A (zh) 一种故障诊断方法及装置
CN110366276A (zh) 服务化架构基站
CN108243055A (zh) 一种容器云自动发现与注册系统及方法
CN104639386B (zh) 故障定位系统和方法
CN101199162B (zh) 一种控制通信网络的方法、系统和设备
CN105955838A (zh) 一种系统死机的原因查看方法及装置
CN108039956A (zh) 应用监控方法、系统和计算机可读存储介质
CN103731287A (zh) 一种故障接管服务器选择方法
CN111343153A (zh) 数据包检测方法、装置、服务器及存储介质
CN112235300B (zh) 云虚拟网络漏洞检测方法、系统、装置及电子设备
JP6243906B2 (ja) モバイルデバイス内で複数の候補アプリケーションのための通信接続を提供するための方法及びデバイス

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant