CN112491595B - 故障区域定位方法、装置、设备及计算机可读存储介质 - Google Patents
故障区域定位方法、装置、设备及计算机可读存储介质 Download PDFInfo
- Publication number
- CN112491595B CN112491595B CN202011262778.1A CN202011262778A CN112491595B CN 112491595 B CN112491595 B CN 112491595B CN 202011262778 A CN202011262778 A CN 202011262778A CN 112491595 B CN112491595 B CN 112491595B
- Authority
- CN
- China
- Prior art keywords
- cdr
- transaction
- module
- fault
- service
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/2218—Call detail recording
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S10/00—Systems supporting electrical power generation, transmission or distribution
- Y04S10/50—Systems or methods supporting the power network operation or management, involving a certain degree of interaction with the load-side end user applications
- Y04S10/52—Outage or fault management, e.g. fault detection or location
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请提供了一种故障区域定位方法,该方法包括:将来自各个目标接口的信令数据进行合成,得到各个事务的CDR,其中的每一事务包括来自同一接口的一个请求以及对该请求的响应;根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR;根据各个业务的CDR,将各个业务进行关联,得到各个SDR;将各个SDR中的同类故障进行聚合,并定位该同类故障所属的划分区域。可见,本申请以信令分析为基础,实时跟踪业务故障原因,并将同类故障聚合分类形成热点区域,这样,便可以对大概率将要发生的区域性故障给出预警,从而可以有效防止大面积的区域性故障。
Description
技术领域
本申请涉及通信技术领域,特别涉及一种故障区域定位方法、装置、设备及计算机可读存储介质。
背景技术
目前,为了提升网络质量及用户体验,运营商或监管部门需要实时了解网络运行状态、网络故障原因、故障位置等信息,并以此为依据优化网络设备、修复网络故障、处理用户投诉等。但是,5G网络错综复杂,常规定位手段仅能解决常见问题,对特定用户行为触发的深层的网络故障无能为力。
现有技术方案主要通过对用户的上网行为进行跟踪并形成日志,结合日志和原始信令分析等手段定位故障。具体地,该方案主要是对业务信令流程进行关联跟踪,形成日志并记录对应的原始信令,当通信业务发生故障时,可以通过日志和原始信令反查的方式推导故障原因,但这种方式仅适合解决用户投诉、单业务故障定位等情况,无法对通信网络中常见问题归类聚合,形成有效预案。尤其是,该方案对于如某个故障总是发生在某个区域、或某个区域的故障率明显高于其它区域等区域性故障问题,无法提前给出预警。
发明内容
有鉴于此,本申请提供了一种故障区域定位方法、装置、设备及计算机可读存储介质,能够定位到大概率将要发生的区域性故障。
具体地,本申请是通过如下技术方案实现的:
一种故障区域定位方法,包括:
将来自各个目标接口的信令数据进行合成,得到各个事务的呼叫详细记录CDR,所述事务包括来自同一接口的一个请求以及对该请求的响应;
根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR;
根据各个业务的CDR,将各个业务进行关联,得到各个会话详细记录SDR;
将各个SDR中的同类故障进行聚合,并定位所述同类故障所属的划分区域。
一种故障区域定位装置,包括:
合成模块,用于将来自各个目标接口的信令数据进行合成,得到各个事务的呼叫详细记录CDR,所述事务包括来自同一接口的一个请求以及对该请求的响应;
关联模块,用于根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR;
共享模块,用于根据各个业务的CDR,将各个业务进行关联,得到各个会话详细记录SDR;
聚合模块,用于将各个SDR中的同类故障进行聚合,并定位所述同类故障所属的划分区域。
一种电子设备,包括:处理器、存储器;
所述存储器,用于存储计算机程序;
所述处理器,用于通过调用所述计算机程序,执行上述故障区域定位方法。
一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述故障区域定位方法。
由以上本申请提供的技术方案可见,将来自各个目标接口的信令数据进行合成,得到各个事务的CDR,其中的每一事务包括来自同一接口的一个请求以及对该请求的响应;根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR;根据各个业务的CDR,将各个业务进行关联,得到各个SDR;将各个SDR中的同类故障进行聚合,并定位该同类故障所属的划分区域。可见,本申请实施例以信令分析为基础,实时跟踪业务故障原因,并将同类故障聚合分类形成热点区域,这样,便可以对大概率将要发生的区域性故障给出预警,从而可以有效防止大面积的区域性故障。
附图说明
图1为本申请示出的一种5G接口关联采集点拓扑图;
图2为本申请示出的一种故障区域定位方法的流程示意图;
图3为本申请示出的一种区域定位整体结构框图;
图4为本申请示出的一种关联流程示意图;
图5为本申请示出的一种多路HASH结构示意图;
图6为本申请示出的一种多路HASH结点示意图;
图7为本申请示出的一种聚合流程示意图;
图8为本申请示出的一种故障区域定位装置的组成示意图;
图9为本申请示出的一种电子设备的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
在介绍本申请实施例之前,首选对本申请实施例涉及的技术术语进行介绍。
UE:4/5G终端用户;
SUCI:Subscription Concealed Identifier,用户隐藏标识;
SUPI:Subscription Permanent Identifier,用户永久标识;
GPSI:Generic Public Subscription Identifie,通用公共签约标识;
PEI:Permanent Equipment Identifier,永久设备标识符;
PFCP:Packet Forwarding Control Protocol,即报文转发控制协议,5G的N4接口的应用协议;
NGAP:Next Generation Application Protocol,是5G接入网和核心网之间N2接口的信令面协议;
GUTI:Globally Unique Temporary Identifier,全球唯一临时UE标识,是5G核心网为用户分配的临时唯一标识;
AMF:Access and Mobility Management Function,负责5G用户的移动管理功能;
UDM:Unified Data Management,即统一数据管理功能,用于存储5G用户的永久信息;
AUSF:Authentication Server Function,即鉴权服务器功能,用于对5G用户鉴权;
SMF:Session Management Function,5G核心网的会话管理功能;
UPF:User Plane Function,用户面功能,用于将5G用户的数据流向不同的数据网络;
TEID:Tunnel Endpoint Identifier,隧道标识,唯一标识用于为用户传输数据;
S1AP:S1 Application Protocol,即S1接口应用协议,是4G接入网与核心网之间信令面协议;
CDR:Call Detailed Record,详细的呼叫记录,即呼叫详细记录;
SDR:Session Detailed Record,详细的会话记录,即会话详细记录;
IMEI:International Mobile Equipment Identity,国际移动设备识别码;
RAN:无线接入网;
IP:Internet Protocol,网际互连协议;
HTTP:HyperText Transfer Protocol,超文本传输协议;
NAS:Non Access Layer,非接入层;
LAC:Location Area Code,位置区码;
CI:Cell Identity,小区标识;
S-NSSAI:Single Network Slice Selection Assistance Information,单一网络切片选择辅助信息,用于标识一个网络切片;
APN:Access Point Name,接入点名称;
ECGI:E-UTRAN,小区全局标识符;
TCP:Transmission Control Protocol,传输控制协议;
PCF:Policy Control Function,策略控制功能;
SBI:Service-based Interface,基于服务的接口;
SEQID:Sequence Number,顺序号;
SEID:Session Endpoint Identifier,会话端点标识;
GTPV2:GPRS Tunning Protocol,GPRS隧道协议;
用户面隧道:RAN和UPF为用户数据传输建立的通道,通过IP+TEID标识;
信令面隧道:SMF和UPF为控制数据传输建立的通道,通过IP+SEID标识。
事实上,业务故障的触发原因大多相似,重复率很高,若能将重复出现的问题归类汇总形成规律,再结合对网络业务的深层次挖掘跟踪,不仅可以发现常规手段无法定位的复杂问题,还可对可能发生的故障形成有效预警。
本申请实施例将提供一种故障区域定位方法,具体是一种基于5G信令关联的故障热点区域定位方法,该方法是以信令分析为基础,对网络业务进行深层次挖掘,对频繁发生故障的网元、接口或位置进行分类汇总,形成故障热点区域,并对复杂的故障问题给出合理的推理性或经验性建议。
信令分析涉及到的5G接口拓扑图,可参见图1所示的5G接口关联采集点拓扑图。信令分析过程覆盖5G网络所有接口的信令数据,包括空口、N1、N2、N4、N8、N10、N11、N12、N14、N22等,网元和用户首先都需要注册到网络,当用户合法注册后,从空口发起业务,经RAN进入核心网,经过N8、N12接口鉴权后,再经AMF、SMF、PCF等网元建立业务通道,从而实现所需业务。在任何一个网元或信令流转过程中,都可能发生故障,如路由故障、网元故障、协议故障、消息格式错误、鉴权失败、资源不足等,为定位故障热点区域,需要从信令中提取并关联出SUPI、GPSI、IMEI、故障原因、网元类型、接口、位置等关键信息,形成SDR。
本申请实施例将基于创新性的信令关联方法,对通信业务进行跟踪分析及归类汇总,将故障点和故障原因聚合在不同的栅格内形成故障热点区域,并对TOP热点区域(即故障频发区域)进行预警,主要对大概率将要发生的区域性故障给出预警,防止大面积区域性故障。
参见图2,为本申请实施例提供的一种故障区域定位方法的流程示意图,该方法包括以下步骤S201-S204,需要说明的是,后续将结合图3所示的区域定位整体结构框图、图4所示的关联流程示意图以及图7所示的聚合流程示意图,对步骤S201-S204进行具体介绍。
下面对图2所示的步骤S201-S204进行具体介绍:
S201:将来自各个目标接口的信令数据进行合成,得到各个事务的CDR,其中的每一事务包括来自同一接口的一个请求以及对该请求的响应。
本申请实施例不对目标接口的类型进行限定,具体地,可以将5G网络的每一接口定义为目标接口、也可以选取其中的部分接口分别定义为目标接口。例如,可以将N2接口、SBI接口、N4接口中的每一接口分别定义为目标接口,其中,SBI接口包括N5/N7/N8/N11/N12/N14/N22等在内的所有基于服务的接口。
在本申请实施例的一种实现方式中,S201中的“将来自各个目标接口的信令数据进行合成,得到各个事务的CDR”,具体可以包括以下步骤A1-A2:
步骤A1:将来自各个目标接口的信令数据进行解码,得到解码结果。
在本实现方式中,需要将来自各个目标接口的原始的信令数据,按其编码格式进行解码,从而得到解码结果。
参见图3所示的5个模块,包括解码模块、合成模块、关联模块、共享模块和聚合模块,这些模块之间可以通过消息队列或TCP等方式进行通信。其中,可以由解码模块实现本步骤A1。
以信令数据为5G信令为例进行说明,当5G信令通过网口进入设备后,由底层驱动以IP地址为关键字KEY,将各个5G信令分流到解码模块;5G信令涉及多种协议,包括N1接口的NAS协议、N2接口的NGAP协议、N14接口的GTPV2协议、N4接口的PFCP协议和其它服务类接口使用的HTTP2协议等,解码模块需要完成NAS、NGAP、GTPV2、PFCP、HTTP2等协议的解码,在进行解码时,分别按照协议规范定义的编码格式进行解码,为提升解码性能,解码模块可以通过多个线程共同完成解码功能。并且,解码模块需要提取故障定位所需的所有相关字段,包括SUPI、GPSI、PEI、LAC/CI、S-NSSAI、IP+TEID、APN、CAUSE(原因值)、网元IP(网元地址)、网元类型、接口、基站名称等字段中的至少一项解码字段。
然后,解码模块可以以IP+PORT(IP+接口)为关键字KEY,将解码结果分发到图3所示的合成模块,解码模块和合成模块之间可以通过消息队列通信,即,解码结束后,通过消息队列将解码结果发送到合成模块。
另外,参见图4所示的关于解码模块的流程示意图:在接收到5G数据后,通过IP将数据分发到解码模块;判断该数据是否是5G信令,如果否,则丢弃该数据,如果是,则按照相关协议进行解码,并将解码结果写入合成模块的无锁队列。
步骤A2:关于每一目标接口,按照该目标接口对应的预设关键字,将属于该目标接口的解码结果进行合成,得到各个事务的CDR。
基于上述步骤A1可知,可以由图3所示的合成模块实现本步骤A2。合成模块可以按照特定的合成规则,对同一目标接口内的信令数据进行合成,以将一次完整业务流程中的一个事务合成为一个CDR,其中,每一事务可以包括一个请求以及针对该请求的一个响应消息,为便于描述,每一事务的CDR可以简称为事务CDR。
下面以N2接口、SBI接口和N4接口分别作为目标接口时,对如何合成事务CDR进行介绍。
1、N2接口
可以以NGAP_UE_NGAP_ID和NGAP_RAN_NGAP_ID为关键字KEY,为一次完整的业务流程建立一个业务CDR(也称父CDR),记录该整个业务流程的关键信息;同时,以“一个请求以及针对该请求的响应”作为一个事务的方式,为每个事务建立一个CDR,从而合成多个事务CDR,将该事务CDR作为其父CDR的子CDR,以此记录每个事务的运行状态和结果。
2、SBI接口
SBI接口包括N5/N7/N8/N11/N12/N14/N22等在内的所有基于服务的接口,可以以IP+PORT为关键字KEY,以“一个请求以及针对该请求的响应”作为一个事务的方式,为每个事务建立一个CDR,从而合成多个事务CDR,以此记录每个事务的运行状态和结果。
3、N4接口
可以以IP+SEQID为关键字KEY,以“一个请求以及针对该请求的响应”作为一个事务的方式,为每个事务建立一个CDR,从而合成多个事务CDR,以此记录每个事务的运行状态和结果。
另外,参见图4所示的关于合成模块的流程示意图:合成模块从其合成队列中读取解码模块写入的解码结果,基于这些解码结果所属的接口,比如,上述的N2接口、SBI接口和N4接口等,按照各自对应的预设关键字KEY查找HASH(哈希)表,可以通过对该HASH表中的节点进行创建和填充,完成所有事务CDR的合成。
S202:根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR。
在本申请实施例中,可以由图3所示的关联模块实现本步骤S202,具体地,在图3中,合成模块按照特定规则,将各个事务的CDR分发到关联模块,关联模块便可以将这些事务关联起来,形成一个或多个完整业务的CDR,为便于描述,可以将每一完整业务的CDR称为业务CDR,然后,关联模块按照接口间关联规则将业务CDR发送到共享模块。
在本申请实施例的一种实现方式中,S202中的“根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR”,具体可以包括:根据目标信息,将各个事物进行关联,得到各个业务的CDR;其中,该目标信息包括至少一个目标接口对应的用户面隧道信息以及含有故障码的事务CDR,用户面隧道信息是根据对应目标接口内的各个事务的CDR、将该目标接口的各个事务进行关联后提取到的。
具体来讲,为了实现端到端关联,在5G网络中,需要从N4、N11、N2接口提取完整的隧道信息,但RAN和UPF两端的隧道信息分布在不同的事务中,所以,需要将接口内的多个事务关联起来,具体关联方式如下:
1、N4接口
可以以信令面IP+SEID为关键字KEY,将N4接口的各个事务CDR分发到关联模块,然后,关联模块以IP+SEID为关键字KEY,将Create/Modify/Release(创建/修改/释放)等多个事务关联起来,以提取完整的用户面隧道地址信息。
2、N11接口
可以以SmContextID为关键字KEY,将N11接口的各个事务CDR分发到关联模块,然后,关联模块以SmContextID为关键字KEY,将CreateSMContext/UpdateSMContext/ReleaseSMContext(创建/更新/释放)等多个事务关联起来,以提取完整的用户面隧道地址。
需要说明的是,在初次创建上下文Context时,上述三个事务CreateSMContext/UpdateSMContext/ReleaseSMContext中仅包含RAN侧隧道地址,UPF侧隧道信息包含在N1N2MsgTransfer消息中,所以,为获取完整的隧道信息,需要将N1N2MsgTransfer事务和上述三个事务关联起来。在图3中,为了降低关联模块的复杂性,将N1N2MsgTransfer事务进行关联的功能可以在共享模块中完成,其中,N1N2MsgTransfer事务可以由合成模块直接送到共享模块。
3、N2接口
关于N2接口的事务CDR,在将事务CDR作为子CDR合入到父CDR的过程中,父CDR将得到完整的用户面隧道信息。在图3中,合成模块可以将含有完整用户面隧道信息的父CDR发送到共享模块。
4、其它接口
在图3中,关于含有SUPI或GPSI的事务CDR,可以直接发送共享模块;将其它含有故障码的事务CDR均匀分发到关联模块,将无故障码且无SUPI信息的事务CDR丢弃。
在本申请实施例中,CDR中涉及到的网元类型、归属省份、归属地市、经纬度等字段,可以通过号段分析、IP地址和静态表映射等方式填充,以便后续S204中涉及的聚合模块使用。
另外,参见图4所示的关于合成模块和关联模块的流程示意图:对于N4接口的事务CDR,可以以IP+SEID为关键字KEY计算索引,并将带有索引的事务CDR写入关联队列的无锁队列;对于N11接口的事务CDR,可以以SmContextID为关键字KEY计算索引,并将带有索引的事务CDR写入关联队列的无锁队列;关联模块从其无锁队列中读取数据,基于这些数据所属的接口,比如,上述的N4、N11接口等,按照各自对应的预设关键字KEY查找HASH(哈希)表,可以通过对该HASH表中的节点进行创建和填充,完成所有业务CDR的形成。
S203:根据各个业务的CDR,将各个业务进行关联,得到各个SDR。
在本申请实施例中,各个SDR可以通过N路哈希表的方式进行维护,其中,N大于1。
在图3中,共享模块内部会维护一个全局的多路HASH表,负责将用户的一次端到端业务关联起来,形成一个SDR,这样便可以形成多个SDR,至此,已完成全部信令关联。此时,共享模块将包含原因值的带故障的SDR送入数据库由聚合模块使用,以便聚合模块按照不同粒度对故障原因进行聚合,生成聚合栅格,并在超过设定域值时给出预警。
共享模块可以通过多路HASH表的方式维护用户关系,每个用户关系构成一个SDR。其中,该多路HASH表可以包括以下5个关键字KEY中的至少一个:
SUPI、GPSI、GUTI、NGAP ID、IP+TEID(即IP与TEID的组合标识)。
下面以多路HASH表包括上述5个关键字KEY为例,对多路HASH进行介绍,参见图5所示的多路HASH结构示意图、以及图6所示的多路HASH结点示意图。
在图5中,共享模块共用一个全局HASH表,HASH表被均分为5等分,分别作为上述5个KEY的HASH范围。HASH表中每个结点通过一个pnode_t表示,参见图6,其中,pnode_t->data指向一个gui_node_info_t结构,gui_node_info_t中的user_info指向一个SDR,每个SDR通过一个gui_user_info_t结构表示。
在图6所示的gui_user_info_t结构中,该结构中的back_node[KEY_TYPE]分别指向各结点。然而,当一个结点指向gui_user_info_t时(比如图6中SUPI通过user_info指向gui_user_info_t时),gui_user_info_t中的ref递增;当一个结点被删除时,被删除结点指向的gui_user_info_t中的ref递减,且该节点对应的back_node[KEY_TYPE]清空,被删除结点的user_info指针也清空;当gui_user_info_t结构中的ref==0时,删除该gui_user_info_t结构表示的SDR。
当共享模块收到来自合成模块和关联模块(参见图3和图4所示)发送的CDR后,共享模块可根据其维护的多路HASH表包含的关键字(如上述5个KEY)找到SDR并进行合并填充,当SDR在满足条件时,将其更新到数据库。
具体来讲,参见图4所示的关于共享模块的流程示意图:共享模块通过读取共享模块队列中的数据,获取所有的KEY(比如上述5个KEY)值,再计算每一个KEY对应的HASH桶,并对所有桶加锁;然后,在共享模块维护的全局HASH表中查找HASH节点,即,对于每一KEY对应的HASH节点,确定HASH表中是否存在该HASH节点;对于不存在的节点,则创建该节点;如果节点全部存在,则根据这些KEY去找对应的SDR,若不存在该SDR,则创建并填充该SDR,若存在该SDR,则将通过将SDR中的ref值进行递增(比如+1)的方式,实现对该SDR的合并;如果该SDR中包括新的KEY,则计算该新KEY对应的HASH桶并对该HASH桶加锁,转而执行上述“确定HASH表中是否存在该HASH节点”的步骤,并执行该步骤的后续步骤;如果该SDR中不包括新的KEY,则将该SDR写入数据库即可。
需要说明的是,本申请实施例将上述步骤由多个模块完成,各模块并行运行,可极大地加快关联效率;其中,共享模块同其它模块间可通过队列或TCP的方式进行通信,方便跨平台分布式部署;此外,共享模块采用多路HASH实现SDR,可在移动或切换时确保SDR信息的完整性和实时性。
S204:将各个SDR中的同类故障进行聚合,并定位该同类故障所属的划分区域。
在本申请实施例中,可以预先进行区域划分,例如,全国按省可以划分为32个区域,各省可以以每个地市划分为一个区域,地市可以以LAC/CI位置区划分为一个区域。
在上述步骤S201-S203中,可以基于5G信令对用户发起的业务流程进行实时跟踪,将各接口和接口间信令以特定规则关联起来,并从各接口信令中提取关键信息以形成SDR记录。基于此,在本步骤S204中,可以基于SDR记录中的网元、接口、时间、失败或拒绝原因等定位业务故障,具体的,可以在指定时间粒度内进行统计汇总,确定某些位置区内发生的故障数、故障原因,以统计出同类故障所属的划分区域。
进一步地,在本申请实施例中,若同一划分区域的同类故障的数量超过预设阈值,则将该同类故障所属的划分区域,形成一个故障栅格。具体来讲,当某个划分区域的总故障数达到一定范围后,自动形成一个故障栅格,一个故障栅格可以在前台表示为一个具有预设颜色(如红色)的方块,每个故障栅格可以表示为一个高故障率热点区域。
本申请实施例可以以一个位置区为最小粒度,将故障聚合分类到以栅格为组织单位的区域内,从而形成故障的热点区域,此外,还可以按照故障数对故障栅格进行排序,将排序在前的预设数量(比如TOP10)的故障栅格给出预警提示。可见,本申请实施例通过将错误码汇聚成故障栅格的方式,为用户提供区域性故障预警,可有效缩短定位范围、并可快速定位故障热点区域,降低了发生大面积故障的可能性。
此外,每个栅格可以下钻并关联其所有故障记录,在后台表示为一条详细记录时,可以至少包括如下字段:
关于每一栅格所关联的故障记录,可以记录在一个故障表中,该故障表仅保存SDRID(SDR标识)即可,而不需要存储SDR本身,这样,可以占用极少的内存。此外,关于每一故障栅格指向的同类故障,该同类故障对应的预设阈值为阶段性阈值,也就是说,当该同类故障的数量超过其预设阈值时,每超过一次便更新一次栅格,可确保故障栅格的实时性。
进一步地,在本申请实施例中,若同一划分区域的同类故障的数量超过预设阈值,则通过查询故障经验库,获取该同类故障的解决方案。具体来讲,可以预先创建一个故障经验库,在该故障经验库中记录各种故障的解决方案,这些解决经验通常是相关人员通过积累学习故障解决经验得到的,这样,便可以通过故障码关联故障经验库,从而获得建议解决方案。
其中,故障经验库可以包括如下字段:
故障码 | 故障原因 | 方案来源 | 建议解决方案 |
可见,本申请实施例通过积累学习故障解决经验,形成经验库,当热点区域中的故障同经验库中某条规则匹配时,将两者自动关联,并基于此可以向用户提供有效的解决方案。
在本申请实施例中,上述内容可以由图3所示的聚合模块实现。
参见图7所示的聚合流程示意图,该聚合流程为:先从数据库读取SDR数据,判断该SDR数据中是否包含故障码;若该SDR数据中不包含故障码,则从数据库读取新的SDR数据,并执行上述“判断该SDR数据中是否包含故障码”的步骤;若该SDR数据中包含故障码,则以“地市+区县+位置+经纬度”为关键字KEY生成栅格ID,利用该ID对已有的栅格进行查找,确定是否存在该ID对应的栅格;若成功查找到该ID对应的栅格,则将所读取的SDR数据的SDRID存入该栅格的故障表中;若没有成功查找出该ID对应的栅格,则创建该栅格、并初始化该栅格内的故障表,然后将所读取的SDR数据的SDR ID存入该栅格的故障表中;统计故障表内累加的故障计数;若该故障计数未超过预设阈值,则从数据库读取新的SDR数据,并执行上述“判断该SDR数据中是否包含故障码”的步骤;反之,若该故障计数超过预设阈值,则将该栅格标记为一个故障栅格(比如将该栅格标记为红色),然后,判断数据库中是否存在该故障栅格的记录,若存在,则更新该故障栅格的记录,若不存在,则生成该故障栅格的记录;在更新故障栅格记录和生成故障栅格记录后,可以从故障栅格的更新时刻或生成时刻开始计时,判断计时时长是否超过预设阈值(即判断栅格是否超时),若是,从数据库中释放该故障栅格的节点,若否,则从数据库读取新的SDR数据,并执行上述“判断该SDR数据中是否包含故障码”的步骤。
综上,在本申请实施例提供的故障区域定位方法中,将来自各个目标接口的信令数据进行合成,得到各个事务的CDR,其中的每一事务包括来自同一接口的一个请求以及对该请求的响应;根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR;根据各个业务的CDR,将各个业务进行关联,得到各个SDR;将各个SDR中的同类故障进行聚合,并定位该同类故障所属的划分区域。可见,本申请实施例以信令分析为基础,实时跟踪业务故障原因,并将同类故障聚合分类形成热点区域,这样,便可以对大概率将要发生的区域性故障给出预警,从而可以有效防止大面积的区域性故障。
此外,本申请实施例还可以结合故障经验库给出合理有效的解决方案,可使运营商提前预防大概率区域性故障,减少用户投诉,提升用户体验及企业形象,直接或间接提高企业收益。
参见图8,为本申请实施例提供的一种故障区域定位装置的组成示意图,该装置包括:
合成模块810,用于将来自各个目标接口的信令数据进行合成,得到各个事务的呼叫详细记录CDR,所述事务包括来自同一接口的一个请求以及对该请求的响应;
关联模块820,用于根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR;
共享模块830,用于根据各个业务的CDR,将各个业务进行关联,得到各个会话详细记录SDR;
聚合模块840,用于将各个SDR中的同类故障进行聚合,并定位所述同类故障所属的划分区域。
在本申请实施例的一种实现方式中,合成模块810,具体用于:
将来自各个目标接口的信令数据进行解码,得到解码结果;
关于每一目标接口,按照该目标接口对应的预设关键字,将属于该目标接口的解码结果进行合成,得到各个事务的CDR。
在本申请实施例的一种实现方式中,关联模块820,具体用于:
根据目标信息,将各个事物进行关联,得到各个业务的CDR;
其中,所述目标信息包括至少一个目标接口对应的用户面隧道信息以及含有故障码的事务CDR;所述用户面隧道信息是根据对应目标接口内的各个事务的CDR、将该目标接口的各个事务进行关联后提取到的。
在本申请实施例的一种实现方式中,所述各个SDR通过N路哈希表的方式进行维护,N大于1。
在本申请实施例的一种实现方式中,所述哈希表包括以下关键字中的至少一个:
用户永久标识SUPI、通用公共签约标识GPSI、全球唯一临时用户标识GUTI、5G接入网和核心网之间N2接口的信令面协议的标识NGAP ID、网际互连协议IP和隧道标识TEID的组合标识。
在本申请实施例的一种实现方式中,所述方法还包括:
若同一划分区域的同类故障的数量超过预设阈值,则将该同类故障所属的划分区域,形成一个故障栅格。
在本申请实施例的一种实现方式中,所述方法还包括:
若同一划分区域的同类故障的数量超过预设阈值,则通过查询故障经验库,获取该同类故障的解决方案。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
本申请实施例还提供了一种电子设备,该电子设备的结构示意图如图9所示,该电子设备9000包括至少一个处理器9001、存储器9002和总线9003,至少一个处理器9001均与存储器9002电连接;存储器9002被配置用于存储有至少一个计算机可执行指令,处理器9001被配置用于执行该至少一个计算机可执行指令,从而执行如本申请中任意一个实施例或任意一种可选实施方式提供的任意一种故障区域定位方法的步骤。
进一步,处理器9001可以是FPGA(Field-Programmable Gate Array,现场可编程门阵列)或者其它具有逻辑处理能力的器件,如MCU(Microcontroller Unit,微控制单元)、CPU(Central Process Unit,中央处理器)。
应用本申请实施例,以信令分析为基础,实时跟踪业务故障原因,并将同类故障聚合分类形成热点区域,这样,便可以对大概率将要发生的区域性故障给出预警,从而可以有效防止大面积的区域性故障。
本申请实施例还提供了另一种计算机可读存储介质,存储有计算机程序,该计算机程序用于被处理器执行时实现本申请中任意一个实施例或任意一种可选实施方式提供的任意一种故障区域定位方法的步骤。
本申请实施例提供的计算机可读存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory,只读存储器)、RAM(RandomAccess Memory,随即存储器)、EPROM(Erasable Programmable Read-Only Memory,可擦写可编程只读存储器)、EEPROM(Electrically Erasable Programmable Read-Only Memory,电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是,可读存储介质包括由设备(例如,计算机)以能够读的形式存储或传输信息的任何介质。
应用本申请实施例,以信令分析为基础,实时跟踪业务故障原因,并将同类故障聚合分类形成热点区域,这样,便可以对大概率将要发生的区域性故障给出预警,从而可以有效防止大面积的区域性故障。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。
Claims (8)
1.一种故障区域定位方法,其特征在于,包括:
将来自各个目标接口的信令数据进行合成,得到各个事务的呼叫详细记录CDR,所述事务包括来自同一接口的一个请求以及对该请求的响应;
由关联模块,根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR;
由共享模块,根据各个业务的CDR,将各个业务进行关联,得到各个会话详细记录SDR;
由聚合模块,将各个SDR中的同类故障进行聚合,并定位所述同类故障所属的划分区域;
所述将来自各个目标接口的信令数据进行合成,得到各个事务的呼叫详细记录CDR,包括:
由解码模块,将来自各个目标接口的信令数据进行解码,得到解码结果;
由合成模块,关于每一目标接口,按照该目标接口对应的预设关键字,将属于该目标接口的解码结果进行合成,得到各个事务的CDR;
所述解码模块、合成模块、关联模块、共享模块和聚合模块并行运行,其中,共享模块同其它模块之间通过队列或传输控制协议TCP的方式进行通信,所述各个SDR通过N路哈希表的方式进行维护,N大于1。
2.根据权利要求1所述的方法,其特征在于,所述根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR,包括:
根据目标信息,将各个事物进行关联,得到各个业务的CDR;
其中,所述目标信息包括至少一个目标接口对应的用户面隧道信息以及含有故障码的事务CDR;所述用户面隧道信息是根据对应目标接口内的各个事务的CDR、将该目标接口的各个事务进行关联后提取到的。
3.根据权利要求1所述的方法,其特征在于,所述哈希表包括以下关键字中的至少一个:
用户永久标识SUPI、通用公共签约标识GPSI、全球唯一临时用户标识GUTI、5G接入网和核心网之间N2接口的信令面协议的标识NGAP ID、网际互连协议IP和隧道标识TEID的组合标识。
4.根据权利要求1-3任一项所述的方法,其特征在于,所述方法还包括:
若同一划分区域的同类故障的数量超过预设阈值,则将该同类故障所属的划分区域,形成一个故障栅格。
5.根据权利要求1-3任一项所述的方法,其特征在于,所述方法还包括:
若同一划分区域的同类故障的数量超过预设阈值,则通过查询故障经验库,获取该同类故障的解决方案。
6.一种故障区域定位装置,其特征在于,包括:
解码模块,用于将来自各个目标接口的信令数据进行解码,得到解码结果;
合成模块,用于关于每一目标接口,按照该目标接口对应的预设关键字,将属于该目标接口的解码结果进行合成,得到各个事务的CDR;
关联模块,用于根据各个事务的CDR,将各个事物进行关联,得到各个业务的CDR;
共享模块,用于根据各个业务的CDR,将各个业务进行关联,得到各个会话详细记录SDR;
聚合模块,用于将各个SDR中的同类故障进行聚合,并定位所述同类故障所属的划分区域;
所述解码模块、合成模块、关联模块、共享模块和聚合模块并行运行,其中,共享模块同其它模块之间通过队列或TCP的方式进行通信,所述各个SDR通过N路哈希表的方式进行维护,N大于1。
7.一种电子设备,其特征在于,包括:处理器、存储器;
所述存储器,用于存储计算机程序;
所述处理器,用于通过调用所述计算机程序,执行如权利要求1-5中任一项所述的故障区域定位方法。
8.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现权利要求1-5任一项所述的故障区域定位方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011262778.1A CN112491595B (zh) | 2020-11-12 | 2020-11-12 | 故障区域定位方法、装置、设备及计算机可读存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011262778.1A CN112491595B (zh) | 2020-11-12 | 2020-11-12 | 故障区域定位方法、装置、设备及计算机可读存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112491595A CN112491595A (zh) | 2021-03-12 |
CN112491595B true CN112491595B (zh) | 2023-04-07 |
Family
ID=74930180
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011262778.1A Active CN112491595B (zh) | 2020-11-12 | 2020-11-12 | 故障区域定位方法、装置、设备及计算机可读存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112491595B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113660608B (zh) * | 2021-08-17 | 2022-08-05 | 中国联合网络通信集团有限公司 | 容量热点区域确定方法、装置、设备及存储介质 |
CN113973043B (zh) * | 2021-10-14 | 2024-03-15 | 博瑞得科技有限公司 | 一种故障分析方法、装置及计算机可读存储介质 |
CN114302259B (zh) * | 2021-12-27 | 2024-10-29 | 杭州迪普信息技术有限公司 | 用户信息收集方法、装置、设备及计算机可读存储介质 |
CN115988438B (zh) * | 2022-12-14 | 2024-07-30 | 中国联合网络通信集团有限公司 | 呼叫业务数据处理方法、装置、设备及存储介质 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1960367A (zh) * | 2005-10-31 | 2007-05-09 | 中兴通讯股份有限公司 | 一种通用多协议关联方法 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2425020A (en) * | 2005-04-08 | 2006-10-11 | Agilent Technologies Inc | Processing information from a telephone system |
US8606821B1 (en) * | 2005-12-30 | 2013-12-10 | At&T Intellectual Property Ii, L.P. | Method and apparatus for consolidating call data records |
US7773727B1 (en) * | 2005-12-30 | 2010-08-10 | At&T Intellectual Property Ii, L.P. | Method for providing predictive maintenance relating to trunk operations in a VoIP network |
CN101883004A (zh) * | 2009-05-04 | 2010-11-10 | 华为技术有限公司 | 一种业务数据合成的方法、装置及系统 |
CN102438080A (zh) * | 2011-08-19 | 2012-05-02 | 北京沃泰丰通信技术有限公司 | 一种呼叫详细记录合成方法及装置 |
WO2014040633A1 (en) * | 2012-09-14 | 2014-03-20 | Huawei Technologies Co., Ltd. | Identifying fault category patterns in a communication network |
US9497648B2 (en) * | 2014-04-30 | 2016-11-15 | International Business Machines Corporation | Detecting cellular connectivity issues in a wireless communication network |
CN106911517B (zh) * | 2017-03-22 | 2020-06-26 | 杭州东方通信软件技术有限公司 | 一种移动互联网端到端问题定位方法和系统 |
CN108833724B (zh) * | 2018-07-23 | 2021-03-19 | 北京邮电大学 | 一种cdr合成方法及装置 |
US11025782B2 (en) * | 2018-12-11 | 2021-06-01 | EXFO Solutions SAS | End-to-end session-related call detail record |
-
2020
- 2020-11-12 CN CN202011262778.1A patent/CN112491595B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1960367A (zh) * | 2005-10-31 | 2007-05-09 | 中兴通讯股份有限公司 | 一种通用多协议关联方法 |
Also Published As
Publication number | Publication date |
---|---|
CN112491595A (zh) | 2021-03-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112491595B (zh) | 故障区域定位方法、装置、设备及计算机可读存储介质 | |
US11870656B2 (en) | Network data analytics method and apparatus | |
US9717011B2 (en) | Event management in telecommunications networks | |
Iyer et al. | {CellIQ}:{Real-Time} Cellular Network Analytics at Scale | |
JP4964951B2 (ja) | 無線ネットワークにおける区域内通話エリアの判定 | |
CN108111320B (zh) | 一种本地业务计费方法、服务器和计费网关 | |
EP2304985B1 (en) | Providing subscriber identity for cell traffic trace in e-utran | |
CN111817868B (zh) | 一种网络质量异常的定位方法与装置 | |
CN103916256B (zh) | 网络优化方法及装置、系统 | |
US12061517B2 (en) | Using user equipment data clusters and spatial temporal graphs of abnormalities for root cause analysis | |
WO2012106861A1 (zh) | 终端分布信息获取方法、数据获取装置以及通信系统 | |
US20160020982A1 (en) | Method, device and system for online processing of data | |
CN102098659A (zh) | 一种快速校验国际移动设备标识的方法及系统 | |
CN114339719B (zh) | 一种dpi数据采集方法及相关装置 | |
CN109992427A (zh) | Dpi关联规则回填处理方法、装置、设备及介质 | |
CN109885636B (zh) | 一种用户画像方法和服务器 | |
CN109756382B (zh) | 故障定位方法和装置 | |
CN114342454A (zh) | 无线核心网络中整合分析报告的分发 | |
CN114302259B (zh) | 用户信息收集方法、装置、设备及计算机可读存储介质 | |
CN112788661B (zh) | 网络数据的处理方法、网元及系统 | |
Rizwan et al. | A zero-touch network service management approach using AI-enabled CDR analysis | |
US10462220B2 (en) | Cellular network hierarchical operational data storage | |
CN107005424A (zh) | 用于云部署中的网络元件的网络过程的分布式追踪 | |
CN111277552B (zh) | 一种对直径信令安全威胁识别的方法、装置及存储介质 | |
CN106454882A (zh) | 一种获取用户话单xDR的方法和装置 |
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 |