呼叫业务数据处理方法、装置、设备及存储介质

技术领域

本申请涉及通信技术，尤其涉及一种呼叫业务数据处理方法、装置、设备及存储介质。

背景技术

随着第五代移动通信技术(5th Generation Mobile CommunicationTechnology，5G)网络业务的发展，为了获得更高质量的语音通话和视频呼叫体验，呼叫业务逐渐从长期演进语音承载(Voice over Long-Term Evolution，VoLTE)方式向新空口承载语音(Voice over New Radio，VoNR)方式转变。但由于VoNR覆盖不全面，为了保证呼叫业务的连续性，目前通过演进分组系统语音回落(Evolved Packet System Fallback，EPSFB)将呼叫业务从VoNR向VoLTE切换。在该场景下，呼叫业务涉及5G和4G两个通信系统，该两个通信系统均可以包括核心网域和无线域。

目前对于呼叫业务故障的识别与处理是在每个域上依靠人工进行的，存在识别与处理的效率和准确率较低的问题。

发明内容

本申请提供一种呼叫业务数据处理方法、装置、设备及存储介质，用以解决目前呼叫业务故障的识别与处理是在每个域上依靠人工进行的，识别与处理的效率和准确率较低的问题。

第一方面，本申请提供一种呼叫业务数据处理方法，包括：

获取所述第一通信系统的第一核心网域的外部数据表示XDR、第二核心网域的XDR，所述第二通信系统的第三核心网域的XDR，以及，无线域的XDR；所述第一核心网域和所述第三核心网域用于提供语音业务和/或数据业务，所述第二核心网域用于提供多媒体业务；所述无线域包括第一通信系统的无线域和/或第二通信系统的无线域；所述语音业务包括呼叫业务；

根据各域的XDR，生成至少一个终端设备的至少一次呼叫业务的XDR呼叫记录；

根据至少一个终端设备的至少一次呼叫业务的XDR呼叫记录，目标业务类型的呼叫业务对应的问题树矩阵，确定各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果；所述问题树矩阵用于表征XDR呼叫记录、故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系。

第二方面，本申请提供一种呼叫业务数据处理装置，第一通信系统和第二通信系统之间采用语音回落的方式提供呼叫业务，包括：

获取模块，用于获取所述第一通信系统的第一核心网域的外部数据表示XDR、第二核心网域的XDR，所述第二通信系统的第三核心网域的XDR，以及，无线域的XDR；所述第一核心网域和所述第三核心网域用于提供语音业务和/或数据业务，所述第二核心网域用于提供多媒体业务；所述无线域包括第一通信系统的无线域和/或第二通信系统的无线域；所述语音业务包括呼叫业务；

处理模块，用于根据各域的XDR，生成至少一个终端设备的至少一次呼叫业务的XDR呼叫记录；根据至少一个终端设备的至少一次呼叫业务的XDR呼叫记录，目标业务类型的呼叫业务对应的问题树矩阵，确定各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果；所述问题树矩阵用于表征XDR呼叫记录、故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系。

第三方面，本申请提供一种电子设备，包括：处理器、通信接口，以及存储器；所述处理器分别与所述通信接口和所述存储器通信连接；

所述存储器存储计算机执行指令；

所述通信接口与外部设备进行通信交互；

所述处理器执行所述存储器存储的计算机执行指令，以实现如第一方面中所述的方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面中所述的方法。

本申请提供的呼叫业务数据处理方法、装置、设备及存储介质，通过获取终端设备在多个通信系统包括的多个域中的XDR，将终端设备对应的XDR进行合成，获得同一终端设备的同一呼叫业务的XDR呼叫记录，该XDR呼叫记录可以表征该呼叫业务在多个域中的数据，仅需识别该XDR呼叫记录即可联合分析该呼叫业务在多个域中的故障。通过合成后的XDR呼叫记录，以及，与合成后的XDR呼叫记录存在映射关系的问题树矩阵，确定该终端设备的呼叫业务的故障信息，从而在实现自动关联与识别多个通信系统的核心网域和无线域上呼叫业务的故障，并自动处理该故障的功能的情况下，提高识别和处理呼叫业务的故障的效率和准确率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为现有的一种ESPFB场景的通信系统架构示意图；

图2为本申请实施例提供的一种呼叫业务数据处理方法的流程示意图；

图3为本申请实施例提供的另一种呼叫业务数据处理方法的流程示意图；

图4为本申请实施例提供的再一种呼叫业务数据处理方法的流程示意图；

图5为本申请实施例提供的一种可能的呼叫业务的目标业务类型对应的问题树矩阵的示意图；

图6为本申请实施例提供的另一种可能的呼叫业务的目标业务类型对应的问题树矩阵的示意图；

图7为本申请实施例提供的一种输出呼叫业务的故障定界分析结果的流程示意图；

图8为本申请实施例提供的一种网元维度故障定界分析结果的示意图；

图9为本申请实施例提供的另一种网元维度故障定界分析结果的示意图；

图10为本申请实施例提供的再一种网元维度故障定界分析结果的示意图；

图11为本申请实施例提供的一种小区维度故障定界分析结果的示意图；

图12为本申请实施例提供的另一种小区维度故障定界分析结果的示意图；

图13为本申请实施例提供的再一种小区维度故障定界分析结果的示意图；

图14为本申请实施例提供的另一种输出呼叫业务的故障定界分析结果的流程示意图；

图15为本申请实施例提供的一种目标终端的呼叫业务的故障定界分析结果的示意图；

图16为本申请实施例提供的一种呼叫业务数据处理装置的结构示意图；

图17为本申请实施例提供的一种电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

本申请提供的呼叫业务数据处理的方法，可以适用于图1所示的ESPFB场景的通信系统架构示意图。如图1所示，该架构包括：第一通信系统的第一核心网域、第二核心网域、以及无线域，第二通信系统的第三核心网域、以及无线域，终端设备。

其中，该第一通信系统的第一核心网域和第二通信系统的第三核心网域用于提供语音业务和/或数据业务，该第一通信系统的第二核心网域用于提供多媒体业务。

需要理解的是，图1所示的第一通信系统和第二通信系统可以是如下任一网络制式，例如，可以适用于全球移动通讯(Global System of Mobile communication，简称GSM)、码分多址(Code Division Multiple Access，简称CDMA)、宽带码分多址(WidebandCode Division Multiple Access，简称WCDMA)、时分同步码分多址(Time Division-Synchronous Code Division Multiple Access，简称TD-SCDMA)、长期演进(Long TermEvolution，简称LTE)系统、5G新空口(New Radio，NR)系统及未来的6G等网络制式。

示例性的，该第一通信系统的网络制式为5G，第二通信系统的网络制式为第四代移动通信技术(4th Generation Mobile Communication Technology，4G)。

上述接入网设备可以是GSM或CDMA中的基站(Base Transceiver Station，简称BTS)和/或基站控制器，也可以是WCDMA中的基站(NodeB，简称NB)和/或无线网络控制器(Radio Network Controller，简称RNC)，还可以是LTE中的演进型基站(Evolutional NodeB，简称eNB或eNodeB)，或者中继站或接入点，或者5G网络中的基站(gNB)等，本申请在此并不限定。

上述终端设备可以是指向用户提供语音和/或其他业务数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。终端设备可以经无线接入网(Radio Access Network，简称RAN)与一个或多个核心网设备进行通信，无线终端可以是移动终端，如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语言和/或数据。再例如，无线终端还可以是个人通信业务(Personal CommunicationService，简称PCS)电话、无绳电话、会话发起协议(Session Initiation Protocol，简称SIP)话机、无线本地环路(Wireless Local Loop，简称WLL)站、个人数字助理(PersonalDigital Assistant，简称PDA)等设备。无线终端也可以称为系统、订户单元(SubscriberUnit)、订户站(Subscriber Station)，移动站(Mobile Station)、移动台(Mobile)、远程站(Remote Station)、远程终端(Remote Terminal)、接入终端(Access Terminal)、用户终端(User Terminal)、用户代理(User Agent)、用户设备(User Device or User Equipment)，在此不作限定。可选的，上述终端设备还可以是智能手表、平板电脑等设备。

下面以第一通信系统为NR系统，第二通信系统为LTE系统为例，对本申请进行说明。

第一通信系统为NR系统时，第一核心网域为5G核心网(5GCore，5GC)域，该5GC域中可以包括NR系统核心网的网元，例如可以包括访问和移动性管理功能(Access andMobility Management Function，AMF)网元、会话管理功能(Session Managementfunction，SMF)网元、策略控制功能(Policy Control function，PCF)网元、统一数据管理功能(Unified Data Management，UDM)网元等。

该第二核心网域例如可以是IP多媒体系统(IP Multimedia Subsystem，IMS)域。第二核心网域中可以包括IMS核心网的网元，例如可以包括代理呼叫会话控制功能(ProxyCall Session Control Function，P-CSCF)网元，查询呼叫会话控制功能(Interrogating-CSCF，I-CSCF)网元，服务呼叫会话控制功能(SIP-CSCF，S-CSCF)，归属签约用户服务器(Home Subscriber Server，HSS)等。

第二通信系统为LTE系统时，第三核心网域为演进的分组核心网(Evolved PacketCore，EPC)域，该EPC域可以包括LTE系统核心网的网元，例如可以包括移动管理实体(Mobility Management Entity，MME)网元、HSS等。

该无线域为第一通信系统，和/或，第二通信系统中，通过无线的方式与用户终端设备进行网络连接的部分。例如可以是第一通信系统中接入网设备提供的，和/或，第二通信系统中接入网设备提供的，在第一通信系统为NR系统时，该接入网设备为gNB，在第二通信系统为LTE系统时，该接入网设备为eNB。本申请后续所述的无线域均可以根据实际情况确定为第一通信系统的无线域，或者，第二通信系统的无线域，或者第一通信系统的无线域和第二通信系统的无线域。

在本申请中，第一通信系统的接入网设备(例如基站)上业务覆盖不全面，例如，部分接入网设备暂未覆盖呼叫业务，导致无法为其无线信号覆盖范围内的终端设备提供呼叫业务。第二通信系统的接入网设备覆盖呼叫业务，即能够提供呼叫业务。

目前，在该场景下，当终端设备同时处于第一通信系统的未覆盖呼叫业务的接入网设备的无线信号覆盖范围内和第二通信系统的接入网设备的无线信号覆盖范围内、且终端设备当前接入在第一通信系统时，若终端设备需要使用呼叫业务时，可以通过ESPFB的方式，将呼叫业务回落到第二通信系统上，以通过第二通信系统的接入网设备和核心网进行呼叫业务，从而保障呼叫业务的通话连续性。该呼叫业务例如可以是语音通知、语音呼入、语音呼出、视频呼叫等。

因此，在ESPFB方式下的呼叫业务，可能涉及上述第一通信系统的第一核心网域、第二核心网域、以及无线域，第二通信系统的第三核心网域、以及无线域等多个域。目前对于呼叫业务故障的识别和处理是通过人工对每个域中的呼叫业务数据进行分析、判断、以及进行处理的。通过上述人工的方式识别和处理呼叫业务故障，存在以下几点问题。

问题1：人工识别和处理呼叫业务故障的效率较低。当呼叫业务量较大时，人工无法及时地对呼叫业务故障进行识别与处理。

问题2：人工识别和处理呼叫业务故障的准确率较低。若工作人员的经验不足，或者，工作人员短时间内需要处理大量的呼叫业务故障，则可能会导致识别和处理呼叫业务故障的准确率降低。

问题3：人工难以快速地联合多个通信系统包括的多个域中的呼叫业务数据以进行故障的识别与处理。

有鉴于此，本申请提供了一种呼叫业务数据处理方法，通过获取终端设备在多个通信系统包括的多个域中的外部数据表示(External Data Representation，XDR)，将终端设备对应的XDR进行合成，获得同一终端设备的同一呼叫业务的XDR呼叫记录，该XDR呼叫记录可以表征该呼叫业务在多个域中的数据，仅需识别该XDR呼叫记录即可联合分析该呼叫业务在多个域中的故障。通过合成后的XDR呼叫记录，以及，与合成后的XDR呼叫记录存在映射关系的问题树矩阵，确定该终端设备的呼叫业务的故障信息，从而在实现自动关联与识别多个通信系统的核心网域和无线域上呼叫业务的故障，并自动处理该故障的功能的情况下，提高识别和处理呼叫业务的故障的效率和准确率。

本申请的执行主体可以为呼叫业务识别处理系统，该呼叫业务识别处理系统可以为驱动程序、程序代码软件，也可以为存储有相关执行代码的介质，例如，U盘等；或者，该呼叫业务识别处理系统还可以为集成或安装有相关执行代码的实体装置，例如，芯片、微控制单元(Microcontroller Unit，简称MCU)、电脑、计算机等电子设备。

该呼叫业务识别处理系统的功能可以是集成在实体装置上的；也可以是通过其它设备构建后，存储在存储介质中，该实体装置通过运行该存储介质中的相关执行代码，实现该呼叫业务识别处理系统的功能的；还可以是部署在云平台上的，为实体装置提供呼叫业务的识别与处理功能。

下面，以该呼叫业务识别处理系统的功能集成在目标设备上的为例，以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请实施例提供的一种呼叫业务数据处理方法的流程示意图。

如图2所示，该方法可以包括：

S201、获取第一通信系统的第一核心网域的外部数据表示XDR，第二核心网域的XDR，第二通信系统的第三核心网域的XDR，以及，无线域的XDR；。

其中，该第一核心网域和所述第三核心网域用于提供语音业务和/或数据业务，所述第二核心网域用于提供多媒体业务。该语音业务包括呼叫业务，该呼叫业务例如可以是音频呼叫业务，视频呼叫业务等；该数据业务以数据传输和信息交互为主，用于访问远程信息、交互式娱乐、电子商务等；该多媒体业务用于传送图片、音频、视频、菜单、表情、位置、动作、增强现实(Augmented Reality，AR)/虚拟现实(Virtual Reality，VR)等多媒体数据。该XDR数据中可以包括终端设备的标识，该终端设备的呼叫业务数据等内容。

示例性的，在5GC域下，该XDR包括的字段如下表1所示：

表1

示例性的，在IMS域下，该XDR包括的字段如下表2所示：

表2

/>

示例性的，在EPC域下，该XDR包括的字段如下表3所示：

表3

示例性的，在5G无线域下，该XDR包括的字段如下表4所示：

表4

/>

示例性的，在5G无线域下，该XDR包括的字段如下表5所示：

表5

/>

/>

一种可能的实现方式，可以通过各域中包括的网元的DPI接口，获得各域中的XDR。示例性的，在5GC域中，网元之间的DPI接口例如可以包括N1、N2、N4、N7等接口；在IMS域中，网元之间的DPI接口例如可以包括SIP、Diameter、GxRx、Nc、Sv接口等；在EPC域中，网元之间的DPI接口例如可以包括S1MEE、S6a接口等；在无线域中可以包括对应的通信系统的MR接口。其中，通过DPI接口获取各域中的XDR例如可以是通过Kafka、企业服务总线(EnterpriseService Bus，ESB)、文件传输协议(File Transfer Protocol，FTP)等方式获取的。

另一种可能的实现方式，各域中包括的网元主动上报其XDR。

S202、根据各域的XDR，生成至少一个终端设备的至少一次呼叫业务的XDR呼叫记录。

根据各域的XDR，获取终端设备进行呼叫业务的时间与呼叫业务的数据，根据终端设备的标识，以及，呼叫业务的时间，确定各域的XDR是否属于同一终端设备的同一次呼叫业务。将属于同一终端设备的同一次呼叫业务的XDR合成为该终端设备的该次呼叫业务的XDR呼叫记录。该XDR呼叫记录中包括该终端设备在各域上的XDR包括的数据内容。其中，在XDR合成XDR呼叫记录时，可以删除各域的XDR中重复的内容，也可以是仅选择各域的XDR中部分内容进行合成等。

一种可能的实现方式，可以根据实际需求选择待合成的各域的XDR的范围，即在各域的XDR中选择与该实际需求对应的部分XDR进行合成。

另一种可能的实现方式，将当前获得的所有的各域的XDR，按照上述方式合成。

S203、根据至少一个终端设备的至少一次呼叫业务的XDR呼叫记录，目标业务类型的呼叫业务对应的问题树矩阵，确定各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。

其中，该问题树矩阵用于表征XDR呼叫记录、故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系。该问题树矩阵可以是根据历史XDR数据统计分析后获得的，也可以是利用历史XDR数据和历史呼叫业务故障识别与处理结果进行模型训练后获得的，该历史呼叫业务故障识别与处理结果与该历史XDR数据相关。该故障定界域可以根据实际情况进行划分，例如可以划分为以下故障定界域：未知域、EPC域、IMS域、CS域、无线域、数通域、用户域、终端域、传输域、内容源域、开户数据域、5GC域等。本申请对于故障定界域的划分不做限制。

本申请实施例提供的一种问题树矩阵可以如下表6所示：

表6

/>

/>

其中，该业务情况为获取各域的XDR时获取的，该业务情况对应的业务类型、呼叫类型、接通状态、以及业务结果在各域的XDR中均包括对应的值。该业务类型例如可以是注册、主叫、接通等。该呼叫类型用于指示该次呼叫业务的类型，例如可以是VoNR、ESPFB、VoLTE等。该接通状态用于指示呼叫业务的所使用的网络是否成功接通，例如可以是成功，或者失败。该业务结果用于指示该次呼叫业务的结果，例如可以是接通成功，接通失败，发生掉话等。在各域上，每个域中包括多个字段，这些字段用于指示该XDR呼叫记录中与故障定界网元、故障定界域、故障定界结果、问题原因和处理建议等相关的内容，该字段可以是根据实际需求确定的，本申请对此不做限制。

对于不同业务类型的呼叫业务，该问题树矩阵可以是不同的。呼叫业务的目标业务类型为该XDR呼叫记录对应的呼叫业务的业务类型，根据该目标业务类型，确定处理该XDR呼叫记录的问题树矩阵。此外，本申请中对于不同的呼叫类型，该问题树矩阵可以是相同的，也可以是不同的。当对于不同的呼叫类型，问题树矩阵不相同时，可以进一步根据该呼叫类型确定处理该XDR呼叫记录的问题树矩阵。

一种可能的实现方式，根据XDR呼叫记录中全部字段对应的值，和问题树矩阵与这些字段的值对应的映射关系，确定故障定界网元、故障定界域、故障定界结果、问题原因和处理建议。

另一种可能的实现方式，根据XDR呼叫记录中部分字段对应的值，和问题树矩阵与这些字段的值对应的映射关系，确定故障定界网元、故障定界域、故障定界结果、问题原因和处理建议。该部分字段可以是根据实际需求选取的，本申请对此不做限定。

本申请提供的呼叫业务数据处理方法，通过获取使用呼叫业务的终端设备在各域上的XDR，将各域上的XDR根据该终端设备以及一次呼叫业务进行合成，获得用于指示各终端设备的各次呼叫业务的XDR呼叫记录，该XDR呼叫记录可以表征该呼叫业务在多个域中的数据，仅需识别该XDR呼叫记录即可联合分析该呼叫业务在多个域中的故障。再根据该XDR呼叫记录，目标业务类型的呼叫业务对应的问题树矩阵的映射关系，获取各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果，从而在实现自动关联与识别多个通信系统的核心网域和无线域上呼叫业务的故障，并自动处理该故障的功能的情况下，提高识别和处理呼叫业务的故障的效率和准确率。

下面，对于如何实现步骤S202中根据各域的XDR，生成至少一个终端设备的至少一次呼叫业务的XDR呼叫记录进行详细说明。

由于各域的XDR的采集方式、采集设备可能是不同的，因此即使在不同域中采集同一时间产生的XDR，这些XDR的采集时间也可能是不同步的。因此，在采集各域的XDR时，可能存在采集时间不同步的问题，从而导致在合成XDR呼叫记录时，因存在的采集时间差使得合成该XDR呼叫记录的各域XDR缺失，进而影响判断该呼叫业务数据故障的准确性。

图3为本申请实施例提供的另一种呼叫业务数据处理方法的流程示意图。如图3所示，步骤S202可以包括：

S301、按照接收到各域XDR的时间，将各域XDR异步导入各域的堆栈。

该各域的堆栈用于存储从各域中获取的XDR，存储在各域的堆栈中的XDR用于后续合成XDR呼叫记录。该堆栈根据对应域中的XDR的采集时间顺序，存储该XDR。各域的堆栈可以持续存储该域中的XDR，不删除任何已存储的XDR；也可以是设定了存储XDR的保持时长，当XDR存储在堆栈中的时间超过该保持时长时，从该堆栈中删除该XDR。

通过异步导入堆栈的方式存储各域的XDR，能够保证即使采集XDR的时间存在时间差，该堆栈中也能将待合成XDR呼叫记录的对应的XDR都存储下来，防止因采集XDR的时间差导致在合成时缺失部分XDR的情况。

S302、按照XDR保持最大时长，从各域的堆栈中提取属于同一终端设备的同一次呼叫业务的XDR，并利用提取到的XDR，生成该终端设备的一次呼叫业务的XDR呼叫记录。

其中，同一终端设备的同一次呼叫业务是根据XDR中包括的时间，以及，终端设备的标识确定的。该XDR中包括的时间为该终端设备的呼叫业务对应的时间，例如可以是该呼叫业务的开始时间。该XDR中包括的终端设备的标识用于唯一指示该终端设备，该标识例如可以是国际移动用户识别码(International Mobile Subscriber Identity，IMIS)，和/或，移动台国际ISDN号码(Mobile Subscriber International ISDN/PSTN number，MSISDN)，具体与第一通信系统和第二通信系统中唯一标识终端设备的方式有关。可以通过设置预设时间段，将在该预设时间段内具有相同的终端设备标识的XDR判定为同一终端设备的同一次呼叫业务的XDR。该预设时间段用于限制该XDR中包括的时间在同一时间段区间内，该预设时间段可以根据实际需求确定，本申请对此不做限制。

一种可能的实现方式，对于相同终端标识的XDR，认为是同一终端设备的呼叫业务产生的XDR。在确认同一终端设备的XDR后，判断同一终端设备的XDR的时间，若存在不同的XDR的时间属于同一预设的时间段内，则可以判断这些XDR为同一终端设备的同一次呼叫业务的XDR。

另一种可能的实现方式，首先将堆栈中所有XDR按照预设的时间段进行划分，然后在每一段预设的时间段内，按照终端标识进行划分，从而确定同一终端设备的同一次呼叫业务的XDR。

该XDR最大保持时长为XDR存储在各域堆栈中尚未用于合成XDR呼叫记录时，能够保持存储在堆栈中但不被删除的最大时长，当XDR没有用于合成XDR呼叫记录，且存储在堆栈中的时间超过该XDR最大保持时长时，将该XDR从该域堆栈中删除(或弹出)。

一种可能的实现方式，该XDR最大保持时长是不变的。

即当前各域的堆栈中存储的XDR的存储时间均小于该XDR最大保持时长。根据上述同一终端设备的同一次呼叫业务的判断方式，提取各域中所有属于同一终端设备的同一次呼叫业务的XDR，并删除这些XDR中相同的数据，将剩余的XDR数据进行合并，从而获得该终端设备的一次呼叫业务的XDR呼叫记录。

另一种可能的实现方式，该XDR最大保持时长根据多个域的匹配进度发生变化。

S3021、对于同一终端设备，若从第一核心网域的堆栈和第二核心网域的堆栈匹配到该终端设备在第一核心网域的XDR和第二核心网域的XDR，则按照第一保持最大时长，检测第三核心网域的堆栈中是否存在该终端设备的XDR。

其中，第一核心网域的XDR和第二核心网域的XDR根据上一种实现方式中所说的匹配方式，在最大保持时长内确定第一核心网域的XDR和第二核心网域的XDR是否属于同一终端设备的同一次呼叫业务的XDR，若不属于则表征无法匹配，当前各域堆栈中暂不存在可以进行匹配的XDR，因此需要继续等待后续采集XDR存储入各域堆栈中再次尝试匹配，若堆栈中的XDR在到达第一保持最大时长后，仍无法进行匹配，则表征该XDR不存在能够匹配的其他XDR，因此从对应的堆栈中弹出该XDR，节省该堆栈的存储空间，以存入新采集到的XDR；若属于则表征能够匹配，进一步检测第三核心网域的堆栈中存在该终端设备的XDR。

S3022、当第一核心网域的XDR和第二核心网域的XDR能够匹配时，若检测第三核心网域的堆栈中存在该终端设备的XDR，则说明第三核心网域的堆栈中也存在能够匹配的XDR，将第三核心网域的XDR上述第一核心网域的XDR和第二核心网域的XDR匹配后的结果进行匹配。此时，仅剩无线域的堆栈中的XDR未完成匹配，此时剩余未匹配的XDR的总数较小，匹配时间较短，因此可以按照小于第一保持最大时长的第二保持最大时长，检测无线域的堆栈中是否存在该终端设备的XDR，进一步在第二保持最大时长内匹配无线域的堆栈中的XDR。

S3023、若无线域的堆栈中存在该终端设备的XDR，则将该终端设备在第一核心网域的XDR、第二核心网域的XDR、第三核心网域的XDR和无线域的XDR合并，得到该终端设备的该次呼叫业务的XDR。该合并方法例如可以是将上述域中的XDR中包括的不重叠的内容进行合并，得到该终端设备的该次呼叫业务的XDR；也可以是将上述域中的XDR中包括的不重叠的内容进行合并，并根据实际需求删除部分内容，得到该终端设备的该次呼叫业务的XDR。

S3024、若无线域的堆栈中不存在该终端设备的XDR，和/或，第三核心网域的堆栈中不存在该终端设备的XDR，则将该终端设备其余已匹配到的XDR合并，得到该终端设备的该次呼叫业务的XDR。例如，若无线域的堆栈中不存在该终端设备的XDR，但第三核心网域的堆栈中存在该终端设备的XDR，则合并第一核心网域的XDR、第二核心网域的XDR、第三核心网域的XDR；若无线域的堆栈中不存在该终端设备的XDR，且第三核心网域的堆栈中不存在该终端设备的XDR，则合并第一核心网域的XDR、第二核心网域的XDR；若无线域的堆栈中存在该终端设备的XDR，第三核心网域的堆栈中不存在该终端设备的XDR，则合并第一核心网域的XDR、第二核心网域的XDR、无线域的XDR。

本申请实施例提供的方法，通过将获取的各域的XDR异步输入各域的堆栈的方法，保证即使采集XDR的时间存在时间差，该堆栈中也能将待合成XDR呼叫记录的对应的XDR都存储下来，解决了因采集XDR的时间差导致在合成时缺失部分XDR的问题。此外，通过判断采集到的各域的XDR是否属于同一终端设备的同一呼叫业务，将各域的XDR按照同一终端设备的同一呼叫业务合并，得到该终端设备的该次呼叫业务的XDR呼叫记录，从而减少了各域XDR数据中重复的内容，并且使得多个域上同一终端设备的同一次呼叫业务仅以一条XDR的方式表示，提高了后续对终端设备的呼叫业务数据的故障识别与处理的效率，实现了联合多个域对呼叫业务的故障进行分析的功能。

下面，对于如何根据问题树矩阵获得目标业务类型的呼叫业务的故障定界分析结果进行详细解释。

步骤S203中所示的问题树矩阵中包括XDR呼叫记录中第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段、故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系。

根据该XDR呼叫记录中第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段中的至少两个目标字段，与故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之中至少一项之间的存在映射关系。例如可以通过第一核心网域的第一目标字段、第二核心网域的第二目标字段，以及该映射关系，确定故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之中至少一项的结果；或者通过上述三项目标字段，以及该映射关系，确定故障定界网元、故障定界域、故障定界结果、问题原因和处理建议的结果。

在该实现方式下，图4为本申请实施例提供的再一种呼叫业务数据处理方法的流程示意图。如图4所示，步骤S203可以包括：

S401、针对每个终端设备的每个XDR呼叫记录，根据该XDR呼叫记录中第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段，以及，呼叫业务的目标业务类型对应的问题树矩阵，确定该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议。

首先根据呼叫业务的目标业务类型，确定对应的问题树矩阵。将每个终端设备的每个XDR呼叫记录中包括的内容，按照该问题树矩阵中包括的第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段，填入对应的值。根据该第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段对应的值，以及，第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段、故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系，确定故障定界网元、故障定界域、故障定界结果、问题原因和处理建议的结果。

示例性的，当业务类型为“注册”，呼叫类型为“VoNR/EPSFB”时，一种可能的呼叫业务的目标业务类型对应的问题树矩阵如图5所示。其中，第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段、故障定界网元、故障定界域、故障定界结果、问题原因和处理建议的具体内容可以参考图5，此处不再赘述。

示例性的，当业务类型为“主叫”，呼叫类型为“EPSFB”时，一种可能的呼叫业务的目标业务类型对应的问题树矩阵如图6所示。

需理解的是，该上述第一目标字段、第二目标字段与故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系可以是根据实际需要预先设置的，本申请对此不作限制。

在实际使用本方法时，可以根据实际需求对第一目标字段、第二目标字段、第三目标字段包括的字段数量，以及，第一目标字段、第二目标字段、第三目标字段具体包括哪些字段进行设定，并可以根据实际需求增加字段或者删减字段，本申请对此不作限制。

S402、根据该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议，获取该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。

实现方式1：无论定界域结果是否为无线域，均直接以该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议作为该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。

实现方式2：根据定界域结果是否为无线域，确定目标业务类型的呼叫业务的故障定界分析结果。

一种可能的实现方式，若该呼叫记录对应的定界域非无线域，则将该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议作为该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。即该故障定界分析结果中包括故障定界网元、故障定界域、故障定界结果、问题原因和处理建议，以及每项结果根据上述第一目标字段、第二目标字段、第三目标字段获得的对应的值。

另一种可能的实现方式，若该呼叫记录对应的定界域为无线域，进一步对无线域中该XDR呼叫记录存在的无线方面的具体原因进行分析，以无线方面的具体原因作为该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。从而为该XDR呼叫记录对应的呼叫业务的故障提供更加详细的故障定界分析结果。该故障定界分析结果可以仅包括无线方面的具体原因，也可以同时包括上述问题树矩阵输出的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议等内容。

S4021、根据该XDR呼叫记录中无线域的第四目标字段，以及，预设字段、第四目标字段与无线域问题原因三者之间的映射关系，获取该XDR呼叫记录对应的无线域问题原因。其中，第四目标字段包括预设字段。

该第四目标字段可以是能够表征该无线域中呼叫业务实际情况的数据对应的字段，例如可以包括该终端设备所在的该无线域覆盖的小区的参考信号接收功率(ReferenceSignal Receiving Power，RSRP)、该小区相邻的小区的RSRP、终端设备到基站的距离、基站的接收干扰功率平均值等字段。该预设的字段可以是无线接入技术(Radio AccessTechnology，RAT)中包括的INTRAT字段和INTNCRAT字段。

根据该预设的字段，确定该XDR呼叫记录中无线域的第四目标字段与无线域问题原因的映射关系，然后根据该映射关系，以及该第四目标字段，确定该无线域问题原因。该无线域的问题原因可以根据实际需求设定，例如可以包括以下至少一项：覆盖空洞、假性弱覆盖、快衰落、过覆盖、叠覆盖、上行干扰、模三干扰等。

可选的，当该XDR呼叫记录中INTRAT字段和INTNCRAT字段无值时，仅通过无线域的第四目标字段中除预设字段之外的内容与无线域问题原因的映射关系确定该无线域问题原因。示例性的，第四目标字段与无线域问题原因的映射关系例如可以如下表7所示。

表7

其中，该无线域问题原因，以及，第四目标字段与无线域问题原因的映射关系可以根据实际需求确定，本申请中的表2仅是提供一种参考示例，上述无线域问题原因，以及，第四目标字段与无线域问题原因的映射关系并不以此为限。

可选的，当该XDR呼叫记录中INTRAT字段和INTNCRAT字段有值时，还可以通过无线域的第四目标字段、预设的字段与无线域问题原因的映射关系确定该无线域问题原因。示例性的，无线域的第四目标字段、预设的字段与无线域问题原因的映射关系例如可以如下表8所示。

表8

/>

/>

其中，该无线域问题原因，以及，无线域的第四目标字段、预设的字段与无线域问题原因的映射关系可以根据实际需求确定，本申请中的表3仅是提供一种参考示例，上述无线域问题原因，以及，无线域的第四目标字段、预设的字段与无线域问题原因并不以此为限。

S4022、将该XDR呼叫记录对应的无线域问题原因，以及，该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议作为该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。

在完成步骤S402后，本方法还可以包括存储该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。

可选的，该XDR呼叫记录中还可以包括用于存储目标业务类型的呼叫业务的故障定界分析结果的字段，例如可以是LTE_Radio_Result字段。在该实现方式下，本方法还可以包括，将目标业务类型的呼叫业务的故障定界分析结果填充到该用于存储目标业务类型的呼叫业务的故障定界分析结果的字段中，以便于快速与该XDR呼叫记录对应的终端设备的呼叫业务进行匹配，从而实现将该反馈该故障定界分析结果快速反馈至对应的终端设备的呼叫业务的故障请求的功能。

可选的，将该故障定界分析结果存储在预设的除XDR呼叫记录之外的位置，在接收到对应的终端设备的呼叫业务的故障请求时，对该故障定界分析结果进行匹配。

本申请实施例提供的方法，通过对XDR呼叫记录中第一核心网域、第二核心网域、第三核心网域中对应的目标字段与故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系，确定了目标业务类型的呼叫业务的故障定界分析结果。另外在故障定界域为无线域时，还可以进一步确定该无线域包括的无线域问题原因，从而获得更加精准的故障定界分析结果。

在获得目标业务类型的呼叫业务的故障定界分析结果后，本申请提供的呼叫业务数据处理方法还包括输出针对目标业务类型的呼叫业务的故障定界分析结果。

实现方式A：根据目标业务类型输出呼叫业务的故障定界分析结果。

图7为本申请实施例提供的一种输出呼叫业务的故障定界分析结果的流程示意图。如图7所示，该方法可以包括：

S701、接收针对目标业务类型的呼叫业务的故障定界分析请求。

该故障定界分析请求用于获取该目标业务类型的呼叫业务的故障定界分析结果。该目标业务类型例如可以是前述所说的注册、主叫、接通等，还可以包括呼叫业务回落情况、呼叫业务时延、掉话指标等类型。该针对目标业务类型的呼叫业务的故障定界分析请求可以是通信系统工作人员的终端设备上报的。

S702、根据各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果，获取针对目标业务类型的呼叫业务的故障定界分析结果。

通过获取在预设时间内属于该目标业务类型的所有终端设备的呼叫业务的XDR呼叫记录，获取针对目标业务类型的呼叫业务的故障定界分析结果。根据该针对目标业务类型的呼叫业务的故障定界分析结果，从多个维度对该故障定界分析结果进行分析，从而获得多个维度下的针对目标业务类型的呼叫业务的故障定界分析结果。该多个维度例如可以包括：区域维度、网元维度、小区维度、终端类型维度等。

其中，该区域维度限制了在预设时间内属于该目标业务类型的所有终端设备的呼叫业务的地理位置；网元维度限制了在预设时间内属于该目标业务类型的所有终端设备的呼叫业务所使用的网元；小区维度限制了在预设时间内属于该目标业务类型的所有终端设备的呼叫业务所处于的小区；终端类型维度在预设时间内属于该目标业务类型的对应的终端设备的类别。

一种可能的实现方式，可以根据所有终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果，生成针对目标业务类型的呼叫业务的故障定界分析结果，即不从上述维度中进行进一步划分。

另一种可能的实现方式，可以根据上述任意一项维度，进一步获取在该维度下，所有终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果，生成并输出在该维度下的针对目标业务类型的呼叫业务的故障定界分析结果。

在该实现方式下，图8为本申请实施例提供的一种网元维度故障定界分析结果的示意图。该故障定界分析项目为SIP首拆占比分析。其中，该SIP首拆占比为上表6中SIP首拆消息名称字段中不同值的占比。

图9为本申请实施例提供的另一种网元维度故障定界分析结果的示意图。该故障定界分析项目为定界域占比分析。其中，该定界域为上表6中故障定界域中不同结果的占比。

图10为本申请实施例提供的再一种网元维度故障定界分析结果的示意图。该故障定界分析项目为定界结果占比分析。其中，该定界结果为上表6中故障定界结果中不同结果的占比。

图11为本申请实施例提供的一种小区维度故障定界分析结果的示意图。该故障定界分析项目为SIP首拆占比分析。其中，该SIP首拆占比为上表6中SIP首拆消息名称字段中不同值的占比。

图12为本申请实施例提供的另一种小区维度故障定界分析结果的示意图。该故障定界分析项目为定界域占比分析。其中，该定界域为上表6中故障定界域中不同结果的占比。

图13为本申请实施例提供的再一种小区维度故障定界分析结果的示意图。该故障定界分析项目为定界结果占比分析。其中，该定界结果为上表6中故障定界结果中不同结果的占比。

S703、输出针对目标业务类型的呼叫业务的故障定界分析结果。

例如可以通过应用程序、短信、小程序等任意提醒方式，向工作人员的终端设备输出该目标终端的呼叫业务的故障定界分析结果。

实现方式B：根据目标终端输出呼叫业务的故障定界分析结果。

图14为本申请实施例提供的另一种输出呼叫业务的故障定界分析结果的流程示意图。如图7所示，该方法可以包括：

S801、接收针对目标终端的呼叫业务的故障定界分析请求。

该故障定界分析请求用于获取该目标终端的呼叫业务的故障定界分析结果，例如可以是该目标终端的一次呼叫业务的故障定界分析请求，也可以是该目标终端在某时间段内的多次呼叫业务的故障定界分析请求。该针对目标终端的呼叫业务的故障定界分析请求可以是该目标终端上报的，也可以是通过其他终端设备上报的包括该目标终端标识，以及，呼叫业务标识的故障定界分析请求。

S802、提取目标终端的各XDR呼叫记录针对各业务类型的呼叫业务的故障定界分析结果，获取该目标终端的呼叫业务的故障定界分析结果。

根据该目标终端标识，以及，呼叫业务标识，提取该所述目标终端的各XDR呼叫记录，并根据该目标终端的各XDR呼叫记录，获取针对各业务类型的呼叫业务的故障定界分析结果，并根据该故障定界分析请求对应的业务类型，确定所要选取的该目标终端的呼叫业务的故障定界分析结果。

S803、输出该目标终端的呼叫业务的故障定界分析结果。

例如可以通过应用程序、短信、小程序等方式，向目标终端设备，或者，上报该故障定界分析请求的终端设备输出该目标终端的呼叫业务的故障定界分析结果。

示例性的，图15为本申请实施例提供的一种目标终端的呼叫业务的故障定界分析结果的示意图。如图15所示，该目标终端的呼叫业务的故障定界分析结果包括：定界网元、定界域、定界部门、定界结果、问题原因和处理建议。其中，定界网元为前述图5中的故障定界网元、定界域为前述图5中的故障定界域，定界结果、问题原因和处理建议可以如图5中所示，定界部门可以根据实际情况确定，或者根据与定界网元存在映射关系的实际技术部门确定。

本申请提供的输出呼叫业务的故障定界分析结果的方法，通过向用户使用的终端设备故障定界分析结果，从而使得用户在提出故障定界分析请求后，能够更快地收到与该故障定界分析请求对应的故障定界分析结果。此外，还通过向工作人员的终端设备推送与故障定界分析结果相关的统计数据，从而更加直观地展示当前的多个通信系统下，呼叫业务的故障情况，便于提前发现呼叫业务故障。

需要了解的是，本申请实施例以5G和4G通信系统为例对该呼叫业务数据处理方法进行了说明。但在将该方法运用在其他通信系统上时，可以根据该通信系统的特点与实际情况，对本方法中的内容进行适应性调整。

图16为本申请实施例提供的一种呼叫业务数据处理装置的结构示意图。如图16所示，该呼叫业务数据处理装置包括：获取模块11，处理模块12。在一种可能的实施方式中，还包括：接收模块13。

获取模块11，用于获取该第一通信系统的第一核心网域的外部数据表示XDR、第二核心网域的XDR，该第二通信系统的第三核心网域的XDR，以及，无线域的XDR。该第一核心网域和该第三核心网域用于提供语音业务和/或数据业务，该第二核心网域用于提供多媒体业务。该无线域包括第一通信系统的无线域和第二通信系统的无线域。该语音业务包括呼叫业务。

处理模块12，用于根据各域的XDR，生成至少一个终端设备的至少一次呼叫业务的XDR呼叫记录。根据至少一个终端设备的至少一次呼叫业务的XDR呼叫记录，目标业务类型的呼叫业务对应的问题树矩阵，确定各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果；该问题树矩阵用于表征XDR呼叫记录、故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系。

一种可能的实现方式，处理模块12具体用于，按照接收到各域XDR的时间，将各域XDR异步导入各域的堆栈。按照XDR保持最大时长，从各域的堆栈中提取属于同一终端设备的同一次呼叫业务的XDR，并利用提取到的XDR，生成该终端设备的一次呼叫业务的XDR呼叫记录。

在该实现方式下，处理模块12具体用于，对于同一终端设备，若从第一核心网域的堆栈和第二核心网域的堆栈匹配到该终端设备在第一核心网域的XDR和第二核心网域的XDR，则按照第一保持最大时长，检测第三核心网域的堆栈中是否存在该终端设备的XDR。若检测第三核心网域的堆栈中存在该终端设备的XDR，则按照第二保持最大时长，检测无线域的堆栈中是否存在该终端设备的XDR，该第二保持最大时长小于该第一保持最大时长。若无线域的堆栈中存在该终端设备的XDR，则将该终端设备在第一核心网域的XDR、第二核心网域的XDR、第三核心网域的XDR和无线域的XDR合并，得到该终端设备的该次呼叫业务的XDR。若无线域的堆栈中不存在该终端设备的XDR，和/或，第三核心网域的堆栈中不存在该终端设备的XDR，则将该终端设备其余已匹配到的XDR合并，得到该终端设备的该次呼叫业务的XDR。

在上述任意一种实现方式下，该问题树矩阵包括XDR呼叫记录中第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段、故障定界网元、故障定界域、故障定界结果、问题原因和处理建议之间的映射关系。处理模块12，具体用于针对每个终端设备的每个XDR呼叫记录，根据该XDR呼叫记录中第一核心网域的第一目标字段、第二核心网域的第二目标字段、第三核心网域的第三目标字段，以及，呼叫业务的目标业务类型对应的问题树矩阵，确定该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议。根据该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议，获取该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。

在该实现方式下，处理模块12，具体用于若该呼叫记录对应的定界域非无线域，则将该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议作为该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。若该呼叫记录对应的定界域为无线域，则根据该XDR呼叫记录中无线域的第四目标字段，以及，预设字段、该第四目标字段与无线域问题原因三者之间的映射关系，获取该XDR呼叫记录对应的无线域问题原因；该第四目标字段包括该预设字段。将该XDR呼叫记录对应的无线域问题原因，以及，该呼叫记录对应的故障定界网元、故障定界域、故障定界结果、问题原因和处理建议作为该XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果。

可选的，接收模块13，在处理模块12确定各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果之前，用于接收针对目标业务类型的呼叫业务的故障定界分析请求。处理模块12，在确定各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果之后，还用于根据各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果，获取针对目标业务类型的呼叫业务的故障定界分析结果。输出针对目标业务类型的呼叫业务的故障定界分析结果。

可选的，接收模块13，在处理模块12确定各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果之前，用于接收针对目标终端的呼叫业务的故障定界分析请求。处理模块12，在确定各终端设备的各XDR呼叫记录针对目标业务类型的呼叫业务的故障定界分析结果之后，还用于提取该目标终端的各XDR呼叫记录针对各业务类型的呼叫业务的故障定界分析结果，获取该目标终端的呼叫业务的故障定界分析结果。输出该目标终端的呼叫业务的故障定界分析结果。

本申请实施例提供的呼叫业务数据处理装置，可以执行上述方法实施例中的呼叫业务数据处理方法，其实现原理和技术效果类似，在此不再赘述。

图17为本申请实施例提供的一种电子设备的结构示意图。其中，该电子设备用于执行前述所说的呼叫业务数据处理方法。该电子设备例如可以是前述所说的部署有呼叫业务数据处理系统的设备。如图17所示，该访问控制设备1700可以包括：至少一个处理器1701、存储器1702，通信接口1703。

存储器1702，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。

存储器1702可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

处理器1701用于执行存储器1702存储的计算机执行指令，以实现前述方法实施例所描述的方法。其中，处理器1701可能是一个CPU，或者是特定集成电路(ApplicationSpecific Integrated Circuit，简称为ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路。

处理器1701通过通信接口1703可以与外部设备进行通信交互。当该访问控制设备为SDP控制器时，此处所说的外部设备例如可以是用户的终端设备，或者，工作人员的终端设备。

在具体实现上，如果通信接口1703、存储器1702以及处理器1701独立实现，则通信接口1703、存储器1702以及处理器1701可以通过总线相互连接并完成相互间的通信。总线可以是工业标准体系结构(Industry Standard Architecture，简称为ISA)总线、外部设备互连(Peripheral Component，简称为PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，简称为EISA)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果通信接口1703、存储器1702和处理器1701集成在一块芯片上实现，则通信接口1703、存储器1702和处理器1701可以通过内部接口完成通信。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述实施例中的方法。

本申请还提供一种程序产品，该程序产品包括执行指令，该执行指令存储在可读存储介质中。访问控制设备的至少一个处理器可以从可读存储介质读取该执行指令，至少一个处理器执行该执行指令使得访问控制设备实施上述各种实施方式提供的呼叫业务数据处理方法。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。