CN115037697B - 业务访问请求处理方法及装置、系统、可读存储介质 - Google Patents

Abstract

本申请公开了一种业务访问请求处理方法及装置、系统、计算机可读存储介质，该方法包括：监控终端设备上的目标应用，其中，SDK卡嵌入终端设备上，并存储有需要提供业务保障的目标应用及对应的业务保障类型标识；拦截所述目标应用发起业务访问请求的请求数据包；在所述请求数据包中添加所述目标应用对应的业务保障类型标识，所述业务保障类型标识用于核心网设备向所述目标应用提供对应类型的业务保障；通过所述终端设备发送添加所述业务保障类型标识后的所述请求数据包。本申请实施例能够降低现有业务识别带来的额外负载。

Description

业务访问请求处理方法及装置、系统、可读存储介质

技术领域

本申请涉及网络通信技术领域，尤其涉及一种业务访问请求处理方法及装置、系统、计算机可读存储介质。

背景技术

当前2/3/4G网络时代，为了实现对特定业务的专项保障，在核心网侧静态配置具体业务对应的IP或URL(统一资源定位符)地址，并在核心网设备上布署业务特征库，由设备厂家研发团队对当前的热点业务的地址或行为进行关联分析，生成一个对常见业务的地址或端口等特定信息进行分析完成自动识别补充，并定期进行业务识别库的更新，从而实现对业务的识别。在此基础上，核心网设备制定特定业务专项保障的策略，比如建立专有承载、资源抢占优先级等。当核心网侧收到终端设备上报的业务访问请求时，将终端设备业务请求的目的地址与核心网设备上的配置规则进行匹配，若业务匹配成功，则触发专项保障策略，实现对该请求业务的优先保障。

然而，当前技术采用的是运营商事先在网络上人工完成业务访问地址的静态配置，当大量业务需要有专项保障需求时，网络侧的配置数据变得更加庞大，核心网设备为了完成业务识别带来了额外负载的增加。

如何有效降低保障业务识别带来的额外负载，是本申请所要解决的技术问题。

发明内容

本申请实施例的目的是提供一种业务访问请求处理方法及装置、系统、计算机可读存储介质，用以解决现有业务保障识别带来的额外负载增加的问题。

为了解决上述技术问题，本说明书是这样实现的：

第一方面，提供了一种业务访问请求处理方法，包括：由嵌入终端设备的软件开发工具SDK卡执行，该方法包括：监控所述终端设备上的目标应用，其中，所述SDK卡中存储有需要提供业务保障的目标应用及对应的业务保障类型标识；拦截所述目标应用发起业务访问请求的请求数据包；在所述请求数据包中添加所述目标应用对应的业务保障类型标识，所述业务保障类型标识用于核心网设备向所述目标应用提供对应类型的业务保障；通过所述终端设备发送添加所述业务保障类型标识后的所述请求数据包。

可选的，在所述请求数据包中添加所述目标应用对应的业务保障类型标识，包括：如果所述业务访问请求为所述目标应用启动后的初始业务访问请求，则在所述请求数据包中添加所述目标应用对应的业务保障类型标识。

可选的，在所述请求数据包中添加所述目标应用对应的业务保障类型标识，包括：如果所述业务访问请求不是所述目标应用启动后的初始业务访问请求，则获取所述请求数据包中携带的业务访问目的地址；如果当前获取的业务访问目的地址与前一次获取的所述目标应用的业务访问目的地址不一致，则在所述请求数据包中添加所述目标应用对应的业务保障类型标识。

可选的，还包括：如果当前获取的业务访问目的地址与前一次获取的所述目标应用的业务访问目的地址一致，则不在所述请求数据包中添加所述目标应用对应的业务保障类型标识并发送所述请求数据包。

第二方面，提供了一种业务访问请求处理方法，由嵌入SDK卡的终端设备执行，所述SDK卡中存储有需要提供业务保障服务的目标应用及对应的业务保障类型标识，该方法包括：拦截用户对所述终端设备上的目标应用发起的业务访问请求对应的请求数据包；在所述请求数据包中添加所述目标应用对应的业务保障类型标识，其中，所述业务保障类型标识用于核心网设备向所述目标应用提供对应类型的业务保障；发送添加所述业务保障类型标识后的所述请求数据包。

第三方面，提供了一种业务访问请求处理方法，由核心网设备执行，该方法包括：接收终端设备的目标应用发起的业务访问请求的请求数据包，所述请求数据包中添加有所述目标应用对应的业务保障类型标识；根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略；根据所述业务保障策略向所述目标应用提供业务保障服务。

可选的，根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略，包括：获取配置数据表，其中，所述配置数据表记录不同业务保障类型标识与不同业务保障策略的对应关系；从所述配置数据表获取所述业务保障类型标识对应的业务保障策略。

第四方面，提供了一种业务访问请求处理系统，包括：

终端设备，所述终端设备嵌入SDK卡，所述SDK卡中存储有需要提供业务保障服务的目标应用及对应的业务保障类型标识，所述终端设备用于拦截用户对所述终端设备上的目标应用发起的业务访问请求对应的请求数据包；在所述请求数据包中添加所述目标应用对应的业务保障类型标识；发送添加所述业务保障类型标识后的所述请求数据包；

核心网设备，用于接收添加所述业务保障类型标识后的所述请求数据包；根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略；根据所述业务保障策略向所述目标应用提供业务保障服务。

第五方面，提供了一种电子设备，包括存储器和与所述存储器电连接的处理器，所述存储器存储有可在所述处理器运行的计算机程序，该计算机程序被该处理器执行时实现如第一方面至第三方面中任一所述的方法的步骤。

第六方面，提供了一种计算机可读存储介质，该计算机可读存储介质上存储计算机程序，该计算机程序被处理器执行时实现如第一方面至第三方面中任一所述的方法的步骤。

本申请实施例通过在终端设备上嵌入SDK卡，SDK卡中存储有需要提供业务保障的目标应用及对应的业务保障类型标识，对终端设备上指定的目标应用的业务实时监控和保障，实现需保障的目标应用与其对应的业务保障类型标识的绑定，SDK卡将终端设备上报的请求数据包填充业务保障类型标识后发送，以用于核心网设备根据填充的业务保障类型标识对目标应用业务进行识别，从而向目标应用提供对应类型的业务保障。

如此，可改变现有通过IP或URL业务地址进行业务识别的方式，省略了原有的业务识别操作，由此显著降低设备负载，且实现对业务精确的识别，提高业务识别准确率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请第一实施例的业务访问请求处理方法流程图。

图2是本申请第二实施例的业务访问请求处理方法流程图。

图3是本申请第三实施例的业务访问请求处理方法流程图。

图4是本申请实施例的业务访问请求处理方法的示例流程图。

图5是本申请实施例的业务访问请求处理系统的结构方框图。

图6是本申请实施例的电子设备的结构方框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。本申请中附图编号仅用于区分方案中的各个步骤，不用于限定各个步骤的执行顺序，具体执行顺序以说明书中描述为准。

为了解决现有技术中存在的问题，本申请实施例提供一种业务访问请求处理方法，由嵌入终端设备的软件开发工具(Software Development Kit，SDK)卡执行。图1是本申请第一实施例的业务访问请求处理方法流程图，如图1所示，包括以下步骤：

步骤102，监控所述终端设备上的目标应用，其中，所述SDK卡中存储有需要提供业务保障服务的目标应用及对应的业务保障类型标识；

步骤104，拦截所述目标应用发起业务访问请求的请求数据包；

步骤106，在所述请求数据包中添加所述目标应用对应的业务保障类型标识，所述业务保障类型标识用于核心网设备向所述目标应用提供对应类型的业务保障；

步骤108，通过所述终端设备发送添加所述业务保障类型标识后的所述请求数据包。

基于上述实施例提供的方案，上述步骤102中，目标应用为终端设备上安装的需要核心网设备提供业务保障服务的应用。例如，用户终端设备上安装有APP1、APP2等不同的应用，其中APP1购买了特定业务的专项保障，例如对APP1提供建立专有承载的业务保障服务。SDK卡为可植入终端设备的嵌入式卡，SDK中存储有所嵌入的终端设备上购买特定业务的目标应用及其购买的业务保障类型的标识，下文中也称作为业务ID。目标应用可以是一个也可以是多个，一个目标应用对应于一个业务保障类型标识。SDK卡上存储的目标应用与业务保障类型的标识的对应关系配置数据表，例如如下表1所示：

表1

APP1	业务ID＝1
		APP2	业务ID＝2
…	…

不同的业务保障类型标识用于核心网设备向目标应用提供对应类型的业务保障，核心网设备提供的业务保障与业务保障类型的标识的对应关系配置数据表，例如如下表2所示：

表2

业务ID＝1	建立QCI＝6的专有承载
		业务ID＝2	修改QoS中资源抢占优先级
…	…

其中，QCI为服务质量(Quality of Service，QoS)等级标识。

一个目标应用对应于一个业务保障类型标识，表示核心网设备提供的专项业务保障服务只与目标应用类型有关，而不具体区分该目标应用下的业务访问请求的资源类型。例如，APP1对应的需要提供的业务保障服务为建立QCI＝6的专有承载，则对该APP1启动后发送的任何业务访问请求均提供专有承载的保障服务，不论是请求视频资源还是网页资源。

虽然一个目标应用对应于一个业务保障类型标识，但是终端设备上的不同目标应用可以均对应相同的业务保障类型标识，例如上表1中APP1和APP2均购买了业务ID＝1的业务保障服务。

在步骤102中，SDK卡可以启用守护进程对目标应用进行实时行为监控。

在步骤104中，当目标应用启动后，存在用户通过终端设备对目标应用发起业务访问请求时，SDK拦截目标应用发起业务访问请求的请求数据包，以对业务访问请求对应的业务进行识别。

拦截的请求数据包中携带有对应的业务访问目的地址，SDK卡可以记录目标应用与该业务访问目的地址的对应关系。业务访问目的地址用于核心网设备在为目标应用提供业务保障服务时使用，具体地，核心网设备对业务访问目的地址与终端设备的目标应用之间的业务访问通路提供业务保障服务。

基于上述实施例提供的方案，可选的，上述步骤106中，在所述请求数据包中添加所述目标应用对应的业务保障类型标识，包括：如果所述业务访问请求为所述目标应用启动后的初始业务访问请求，则在所述请求数据包中添加所述目标应用对应的业务保障类型标识。

当用户首次打开终端设备的某个目标应用时，如果没有发起任何业务访问请求，则SDK卡会监控到业务访问目的地址为空。如果用户发起业务访问请求，则通过拦截的请求数据包获取到请求数据包携带的业务访问目的地址。

在一个实施例中，可以将每次业务访问请求对应请求数据包携带的业务访问目的地址记录到记录表中。

在目标应用存在初始业务访问请求后，则在首个请求数据包中添加目标应用对应的业务保障类型标识，以使得核心网设备在接收到该添加业务保障类型标识的首个请求数据包后，根据业务保障类型标识为目标应用提供对应类型的业务保障。核心网设备会在目标应用开启后，一直为其提供目标应用对应类型业务保障。

可选的，上述步骤106中，在所述请求数据包中添加所述目标应用对应的业务保障类型标识，包括：如果所述业务访问请求不是所述目标应用启动后的初始业务访问请求，则获取所述请求数据包中携带的业务访问目的地址；如果当前获取的业务访问目的地址与前一次获取的所述目标应用的业务访问目的地址不一致，则在所述请求数据包中添加所述目标应用对应的业务保障类型标识。

在该实施例中，如果业务访问请求的目的地址，IP或URL发生改变，表示用户对目标应用的当前业务访问请求转换为该目标应用的其他访问请求访问，例如从访问目标应用的综艺视频转换为访问该目标应用的网页文字，此时拦截的请求数据包的业务访问请求的目的地址会发生改变。

如上文所述，在目标应用开启后的首次业务访问请求的请求数据包中添加业务保障类型标识后，核心网会一直对目标应用提供业务保障，直至目标应用关闭。

在该实施例中，如果目标应用的业务访问请求的目的地址发生改变，对于终端设备来说，所需要提供的业务保障类型仍保持不变。但是，需要告知提供业务保障的核心网，根据改变后的业务访问请求目的地址向目标应用提供业务保障类型标识对应的业务保障。因此，在业务访问请求对应的目的地址发生改变时，向请求数据包中再次添加目标应用对应的业务保障类型标识。

当目标应用发起业务访问请求时，根据目标应用与业务保障类型的标识的对应关系配置数据表中的对应关系，将首个数据包打上特定的业务ID，并上报给核心网设备。核心网设备收到该业务ID后，后续同一个数据流将均并记录为同样的业务ID。当后续业务访问请求目的地址发生改变时，再依照首包来处理，在请求数据包中添加上对应的业务ID。

此外，如果当前获取的业务访问目的地址与前一次获取的目标应用的业务访问目的地址一致，则不在请求数据包中添加目标应用对应的业务保障类型标识并发送请求数据包。

在该实施例中，如果前后获取的业务访问目的地址一致，则表示用户请求访问的业务仍为同一个业务。如果不添加业务ID，则核心网设备不会改变对目标应用提供的业务保障类型。直至目标应用被关闭后，核心网设备不再接收到请求数据包，则停止向该目标应用提供对应类型的业务保障服务。

为了解决现有技术中存在的问题，本申请实施例还提供一种业务访问请求处理方法，由嵌入SDK卡的终端设备执行，所述SDK卡中存储有需要提供业务保障服务的目标应用及对应的业务保障类型标识。图2是本申请第二实施例的业务访问请求处理方法流程图，如图2所示，包括以下步骤：

步骤202，拦截用户对所述终端设备上的目标应用发起的业务访问请求对应的请求数据包；

步骤204，在所述请求数据包中添加所述目标应用对应的业务保障类型标识，其中，所述业务保障类型标识用于核心网设备向所述目标应用提供对应类型的业务保障；

步骤206，发送添加所述业务保障类型标识后的所述请求数据包。

具体地，步骤202至步骤206执行过程可以参考图1的步骤102至步骤108，为避免重复，这里不再赘述。

为了解决现有技术中存在的问题，本申请实施例还提供一种业务访问请求处理方法，由核心网设备执行。图3是本申请第三实施例的业务访问请求处理方法流程图，如图3所示，包括以下步骤：

步骤302，接收终端设备的目标应用发起的业务访问请求的请求数据包，所述请求数据包中添加有所述目标应用对应的业务保障类型标识；

步骤304，根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略；

步骤306，根据所述业务保障策略向所述目标应用提供业务保障服务。

在一个实施例中，核心网设备可以包括提供业务保障的核心网设备，例如用户端口功能(User Port Function，UPF)服务器，和布署业务保障策略的核心网设备，例如分组控制功能块(Packet Control Function，PCF)服务器。提供业务保障的核心网设备用于接收终端设备发送的请求数据包，并请求数据包中携带的业务保障类型标识完成目标应用的业务识别。然后将该业务保障类型标识上报至布署业务保障策略的核心网设备，请求保障策略的下发。布署业务保障策略的核心网设备收到提供业务保障的核心网设备发起的业务保障请求后，根据业务保障类型标识获取对应配置的保障策略。提供业务保障的核心网设备根据布署业务保障策略的核心网设备下发的保障策略进行保障策略实施，完成对目标应用请求访问的业务的保障。

可选的，在上述步骤304中，根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略，包括：获取配置数据表，其中，所述配置数据表记录不同业务保障类型标识与不同业务保障策略的对应关系；从所述配置数据表获取所述业务保障类型标识对应的业务保障策略。

上述步骤304可以在提供业务保障的核心网设备接收到请求数据包后，提取业务保障类型标识并上报给布署业务保障策略的核心网设备，由业务保障策略的核心网设备执行。

现在参考图4，图4是本申请实施例的业务访问请求处理方法的示例流程图。在该示例中，描述了终端设备与核心网设备之间的信息交互流程，其中，终端设备中嵌入SDK卡，SDK卡中存储有需要提供业务保障服务的目标应用及对应的业务保障类型标识，核心网设备包括UPF服务器和PCF服务器。

终端设备中的SDK卡启用守护进程对目标应用进行行为监控，守护进程是在终端设备打开时，SDK卡则启动对目标应用的监控。

步骤402，终端设备发送业务请求数据包，以上报目标应用的业务访问请求，SDK卡监控到终端设备上存在目标应用发起业务访问请求时，拦截业务访问请求的请求数据包，对业务进行识别，实现目标应用的业务保障与存储的目标应用对应的业务保障类型标识的绑定关系。即，根据拦截的请求数据包的目标应用，即确定为该目标应用提供的业务保障类型。SDK卡对上报业务请求数据包进行修改，在请求数据包中例如新增一个字段“SERVICEID＝1”，从而在请求数据包中添加目标应用对应的业务保障类型标识“1”，并发送至核心网设备的UPF服务器。

UPF服务器根据终端设备上报的“SERVICE ID＝1”字段识别到业务保障类型即完成业务识别，对“SERVICE ID”字段的值填充为目标应用对应的业务保障类型标识“1”。本申请中，UPF服务器直接读取“SERVICE ID”字段的值。

步骤404，UPF服务器将“SERVICE ID”字段的数值上报至PCF服务器，以向PCF服务器发送业务保障请求，请求保障策略的下发。

步骤406，PCF服务器收到UPF服务器发起的业务保障请求后，根据“SERVICE ID”字段的数值及自身配置的业务保障策略的对应关系，获取“SERVICE ID”字段的数值对应的业务保障策略并下发至UPF服务器。

步骤408，UPF服务器根据PCF服务器下发的业务保障策略实现保障策略实施，即对终端设备目标应用提供指定类型的业务保障服务。

本申请实施例通过在终端设备上布置SDK卡，对终端设备上指定的目标应用的业务实时监控和保障，SDK实现需保障的目标应用与其对应的业务保障类型标识的绑定，将终端设备上报的请求数据包填充业务保障类型标识后发送，以实现核心网设备根据填充的业务保障类型标识对目标应用业务进行识别，从而向目标应用提供对应类型的业务保障。

如此，核心网设备不需再进行IP或URL业务地址的人工配置，只记录业务保障类型标识作为业务的识别标识并与对应目标应用绑定，即可实现业务区分和策略实施。从而改变现有通过IP或URL业务地址进行业务识别的方式，省略了原有的业务识别操作，由此显著降低设备负载，并实现对业务精确的识别，提高业务识别准确率。

此外，本申请的目标应用的业务保障不依赖于人为提供保障地址的行为，实现了基于终端设备对需保障业务的目标应用实时监测，进而进行实时保障，实现业务良性感知。

可选的，本申请实施例还提供一种业务访问请求处理系统，图5是本申请实施例的业务访问请求处理系统的结构方框图。

如图5所示，业务访问请求处理系统1000包括终端设备1200和核心网设备1400。

所述终端设备1200嵌入SDK卡，所述SDK卡中存储有需要提供业务保障服务的目标应用及对应的业务保障类型标识，所述终端设备用于拦截用户对所述终端设备上的目标应用发起的业务访问请求对应的请求数据包；在所述请求数据包中添加所述目标应用对应的业务保障类型标识；发送添加所述业务保障类型标识后的所述请求数据包；

核心网设备1400用于接收添加所述业务保障类型标识后的所述请求数据包；根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略；根据所述业务保障策略向所述目标应用提供业务保障服务。

本申请实施例提供的终端设备1200和核心网设备1400能够实现图1至图4的方法实施例涉及的终端设备、核心网设备实现的各个过程，为避免重复，这里不再赘述。

此外，本申请实施例还提供一种电子设备，图6是本申请实施例的电子设备的结构方框图。

如图6所示，电子设备2000包括存储器2200和与所述存储器2200电连接的处理器2400，所述存储器2200存储有可在所述处理器2400运行的计算机程序，所述计算机程序被所述处理器执行时实现上述任意一种业务访问请求处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述任意一种业务访问请求处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(RandomAccess Memory，简称RAM)、磁碟或者光盘等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (10)

1.一种业务访问请求处理方法，其特征在于，由嵌入终端设备的软件开发工具SDK卡执行，该方法包括：

监控所述终端设备上的目标应用，其中，所述SDK卡中存储有需要提供业务保障的目标应用与业务保障类型标识的对应关系配置数据表；

拦截所述目标应用发起业务访问请求的请求数据包；

在所述请求数据包中添加所述目标应用对应的业务保障类型标识，所述业务保障类型标识用于核心网设备向所述目标应用提供对应类型的业务保障；

通过所述终端设备发送添加所述业务保障类型标识后的所述请求数据包。

2.根据权利要求1所述的方法，其特征在于，在所述请求数据包中添加所述目标应用对应的业务保障类型标识，包括：

如果所述业务访问请求为所述目标应用启动后的初始业务访问请求，则在所述请求数据包中添加所述目标应用对应的业务保障类型标识。

3.根据权利要求1所述的方法，其特征在于，在所述请求数据包中添加所述目标应用对应的业务保障类型标识，包括：

如果所述业务访问请求不是所述目标应用启动后的初始业务访问请求，则获取所述请求数据包中携带的业务访问目的地址；

如果当前获取的业务访问目的地址与前一次获取的所述目标应用的业务访问目的地址不一致，则在所述请求数据包中添加所述目标应用对应的业务保障类型标识。

4.根据权利要求3所述的方法，其特征在于，还包括：

如果当前获取的业务访问目的地址与前一次获取的所述目标应用的业务访问目的地址一致，则不在所述请求数据包中添加所述目标应用对应的业务保障类型标识并发送所述请求数据包。

5.一种业务访问请求处理方法，其特征在于，由嵌入SDK卡的终端设备执行，所述SDK卡中存储有需要提供业务保障服务的目标应用与业务保障类型标识的对应关系配置数据表，该方法包括：

通过所述SDK卡拦截用户对所述终端设备上的目标应用发起的业务访问请求对应的请求数据包以及在所述请求数据包中添加所述目标应用对应的业务保障类型标识，其中，所述业务保障类型标识用于核心网设备向所述目标应用提供对应类型的业务保障；

发送添加所述业务保障类型标识后的所述请求数据包。

6.一种业务访问请求处理方法，其特征在于，由核心网设备执行，该方法包括：

接收终端设备的目标应用发起的业务访问请求的请求数据包，所述请求数据包中由嵌入所述终端设备的SDK卡添加有所述目标应用对应的业务保障类型标识，所述SDK卡中存储有需要提供业务保障的目标应用与业务保障类型标识的对应关系配置数据表；

根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略；

根据所述业务保障策略向所述目标应用提供业务保障服务。

7.根据权利要求6所述的方法，其特征在于，根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略，包括：

获取配置数据表，其中，所述配置数据表记录不同业务保障类型标识与不同业务保障策略的对应关系；

从所述配置数据表获取所述业务保障类型标识对应的业务保障策略。

8.一种业务访问请求处理系统，其特征在于，包括：

终端设备，所述终端设备嵌入SDK卡，所述SDK卡中存储有需要提供业务保障服务的目标应用与业务保障类型标识的对应关系配置数据表，所述终端设备用于拦截用户对所述终端设备上的目标应用发起的业务访问请求对应的请求数据包；在所述请求数据包中添加所述目标应用对应的业务保障类型标识；发送添加所述业务保障类型标识后的所述请求数据包；

核心网设备，用于接收添加所述业务保障类型标识后的所述请求数据包；根据所述业务保障类型标识获取所述业务保障类型标识对应的业务保障策略；根据所述业务保障策略向所述目标应用提供业务保障服务。

9.一种电子设备，其特征在于，包括：存储器和与所述存储器电连接的处理器，所述存储器存储有可在所述处理器运行的计算机程序，所述计算机程序被所述处理器执行时实现根据权利要求1至7中任一项所述的方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现根据权利要求1至7中任一项所述的方法的步骤。