业务处理方法、基站和计算机可读存储介质

技术领域

本申请实施例涉及通信技术领域，特别涉及一种业务处理方法、基站和计算机可读存储介质。

背景技术

随着5G网络的大规模建设运行，5G在垂直行业中的应用也逐渐展开。然而，相比于传统面向个人(TO consumer，简称：ToC)用户的业务，垂直行业涉及的业务模型更为复杂多样，不同业务对服务质量的要求也不尽相同。这种情况下，使用传统的服务质量(Qualityof Service，简称：QoS)保障手段难以应对不同的业务类型。

发明内容

本申请实施例的主要目的在于提出一种业务处理方法、基站和计算机可读存储介质，旨在针对不同类型的业务进行针对性的保障，以满足不同的业务类型的业务需求。

为至少实现上述目的，本申请实施例提供了一种业务处理方法，应用于基站，包括：在检测到UE接入所述基站后，识别所述UE的业务类型；确定与所述业务类型对应的业务保障参数；根据所述业务保障参数，对所述UE进行业务保障。

为至少实现上述目的，本申请实施例还提供了一种基站，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的业务处理方法。

为至少实现上述目的，本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述的业务处理方法。

本申请实施例中，基站在检测到UE接入后，先识别UE的业务类型，然后确定与业务类型对应的业务保障参数，再根据业务保障参数，对UE进行业务保障。不同的业务类型均对应有各自的业务保障参数，由于是根据业务类型对应的业务保障参数，对UE进行业务保障，因此，能够针对性的根据UE的业务类型，对UE进行针对性的业务保障，有利于满足不同的业务类型的业务需求。

附图说明

图1是本申请实施例中提到的业务处理方法的流程示意图；

图2是本申请实施例中提到的步骤101的实现过程的流程示意图；

图3是本申请实施例中提到的步骤102和步骤103的实现过程的流程示意图；

图4是根据本申请实施例中提到的基站的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

目前，传统的QoS保障手段应对繁多的业务类型，这些业务类型，比如在港口业务中，往往存在包括岸桥远控(用于后台控制前台)、现场视频回传(用于现场情况监测)等多种完全不同的业务：岸桥远控属于高频小包业务，现场视频回传属于低频大包业务，两者对稳定性、传输速率、时延等指标的要求并不相同。此外，许多港口(如天津港、盐田港等)目前也越来越多地采用无人驾驶车(或其他机器人)进行港口货物搬运等工作，这种情况下往往需要现场视频回传业务与岸桥远控业务同时实时进行，业务情况更加复杂。

在一些实施例中，并不会不对这些不同业务进行识别，仅采用同一套性能保障参数，则难以同时满足多业务的要求：如控制类型的高频小包业务，对于可靠性、时延要求极高(可靠性往往要求99.999％，时延要求前台到后台单向10ms左右)，对于时延抖动也有较高的要求(通常1ms以内)，但对于带宽、流量要求往往并不高(带宽通常10M以内)；而低频大包类的视频业务却对于带宽要求较高，对可靠性的要求相对于控制业务则较低。按照传统的保障方法，如需对可靠性、抖动等指标进行保障，一般会采用降低调制与编码策略(Modulation and Coding Scheme，简称：MCS)的目标值、设置较低目标误包率、降低流数等保守调度方式，同时为降低传输时延，则需采用开启上行预调度等方法，但这些保障方法将会大幅降低无线系统的容量，降低频谱利用率，此时如视频回传类的大流量业务将无法正常进行。

此外，上述描述是在假设5G网络仅用于保障某一特定区域面向企业(ToBusiness，简称：ToB)业务的前提下的情况，若该区域内仅存在需要高可靠性保障的业务则一套保障参数也可勉强满足ToB用户的需求。然而在实际应用中，从建网成本上考虑，运营商往往希望同一片区域的基站可同时服务于ToB行业用户和ToC大网普通用户，即ToB、ToC业务混合存在的情况，这种情况下若为了ToB业务的稳定性而强行降低系统容量与频谱效率，则商用网络中的资源将被大量占用，普通用户体验将大幅下降，这是运营商无法接受的。本申请的发明人考虑到：只有能够精准识别出不同的业务并予以针对性的保障，运营商才能与垂直行业用户建立起合理有效的网络使用收费标准，创造出新的盈利点，这是除去技术角度外的现实的驱动力。而目前同一片区域的基站使用一套保障参数的方式并未实现这一要求，成为了5G商用网络在垂直行业中大规模使用的阻碍之一。

基于此种现实情况，本申请实施例提供了一种业务处理方法，以对不同业务类型进行精准识别和保障，从而达到在满足不同业务服务质量的前提下，实现无线系统容量最优、对系统影响最小的要求。本申请实施例对于实现将5G系统在垂直行业的全面商用、降低建设成本、创造新的盈利增长点将有着较高的价值。本申请实施例的业务处理方法可以应用于基站，下面对本实施方式的业务处理方法的实现细节进行具体的说明，以下内容仅为方便理解提供的实现细节，并非实施本方案的必须。

本实施方式中的业务处理方法的流程示意图如图1所示，可以包括：

步骤101：在检测到UE接入基站后，识别UE的业务类型；

步骤102：确定与业务类型对应的业务保障参数；

步骤103：根据业务保障参数，对UE进行业务保障。

本申请实施例中，基站在检测到用户终端(User Equipment，简称：UE)接入后，先识别UE的业务类型，然后确定与业务类型对应的业务保障参数，再根据业务保障参数，对UE进行业务保障。不同的业务类型均对应有各自的业务保障参数，由于是根据业务类型对应的业务保障参数，对UE进行业务保障，因此，能够针对性的根据UE的业务类型，对UE进行针对性的业务保障，有利于满足不同的业务类型的业务需求。

在步骤101中，基站可以在检测到UE接入基站后，识别UE的业务类型。业务类型比如可以包括：高频小包类型、低频大包类型；其中，高频小包类型也可以理解为控制类型，低频大包类型也可以理解为流量类型。需要说明的是，本实施例中只是以上述两种业务类型为例，在具体实现中，业务类型的种类并不以上述两种类型为限。

在步骤102中，基站可以根据识别出的业务类型，确定与业务类型对应的业务保障参数。不同的业务类型可以均对应有各自的业务保障参数，不同的业务类型对应的业务保障参数可以不相同。比如，高频小包类型的业务对应的业务保障参数可以包括：较低的MCS目标值、较低的目标误包率、较低的流数；低频大包类型的业务对应的业务保障参数可以包括：较高的MCS和RB资源。需要说明的是，上述描述业务保障参数时提到的“较低的”、“较高的”表示相对较低和相对较高，比如，较低的MCS目标值是指高频小包类型的业务对应的业务保障参数中的MCS目标值相对于低频大包类型的业务对应的业务保障参数中的MCS目标值较低。在具体实现中，较低的MCS目标值或者较高的MCS目标值的具体数值可以根据业务类型和业务场景得到，即使是同一种业务类型的业务，在不同的场景下对应的业务保障参数也可能存在差异，使得业务保障参数对不同场景的适应性更强。

在步骤103中，基站可以根据业务保障参数，对UE进行业务保障。比如，基站可以在UE在线的时间段内持续运用UE的业务类型对应的业务保障参数，以对UE进行业务保障。假设业务保障参数为：较低的MCS目标值，采用单流的传输模式，设置较低的误包率，则基站可以根据这些业务保障参数去分配物理层的资源给不同的业务。

在一些实施例中，步骤101的实现方式可以为：读取UE中的用户身份识别模块(Subscriber Identity Module，简称：SIM)卡所绑定的业务标识信息；当在基站中能查询到与业务标识信息对应的业务类型，将查询到的业务类型识别为UE的业务类型。在具体实现中，承载不同业务的UE可以使用不同类型的SIM卡，不同类型的SIM卡可以具有不同的业务标识信息，以达到区分识别不同业务的目的。通过UE中的SIM卡所绑定的业务标识信息识别UE的业务类型的方式，可以在协议数据单元会话(Protocol Data Unit，简称：PDUSession)建立后，基站即可直接对UE的业务类型进行识别而无须借助其他网元，且无需在UE发起业务后才能进行业务类型的识别，有利于简单快速的识别出UE的业务类型。

其中，业务标识信息可以包括以下之一或其任意组合：SIM卡签约的切片信息、质量标识(Quality identification，简称：QI)信息、自定义的标识信息；其中，切片信息、质量标识QI信息、自定义的标识信息可以为三种并列的用于区分不同业务类型的信息。自定义的标识信息可以为根据实际需要设置的用户标识业务类型的信息，在具体实现中，自定义的标识信息可以为广义Type。

在一个例子中，基站工作在5G网络下，业务标识信息包括SIM卡签约的切片信息、5G网络的5QI信息。切片信息+5QI的组合对应很多不同的业务类型，比如：承载控制业务的SIM卡所绑定的业务标识信息可以为：切片1+5QI6，承载流量业务的SIM卡所绑定的业务标识信息可以为切片2+5QI9，即可在基站区别开这两类业务。其中，切片1和切片2可以为SIM卡签约的切片的标识信息，5QI6和5QI9中的“6”和“9”可以理解为5QI后面的后缀，后缀为一个数字，如果后缀用n表示则5QIn可以代表不同要求的承载，不同要求的承载可以对应不同的业务类型。在具体实现中，SIM卡签约哪张切片或者建立哪些承载是由核心网分配的，核心网可以通过信令将这些信息发送给基站，比如核心网可以通过PDU Session将SIM卡签约的切片信息和/或建立的承载信息即5QI发送给基站，基站就得到UE中的SIM卡所绑定的业务标识信息，不需要其他的网元帮它来识别。

在一些实施例中，步骤101的实现方式可以为：当判定基站具有边缘计算网元，接收边缘计算网元发送的UE的业务类型；其中，边缘计算网元基于UE发起的业务的目的地址识别出UE的业务类型。本实施例中，借助边缘计算网元也可以对UE发起的业务进行业务类型的识别，丰富了业务类型的识别方式，使得即使当在基站中不能查询到与业务标识信息对应的业务类型，也可以借助边缘计算网元完成业务类型的识别。

其中，边缘计算网元比如可以为：移动边缘计算(Mobile Edge Computing，简称：MEC)网元、基站引擎(NodeEngine，简称：NE)网元等。基站具有的边缘计算网元可以设置在基站中，也可以设置在与设置在基站外与基站直连。边缘计算网元可识别到UE发起的业务的目的地址，然后可以根据业务的目的地址识别出业务类型，再将识别出业务类型反馈至基站。其中，考虑到边缘计算网元比如MEC通常和基站是同一个公司制作的，因此为了避免传输数据被盗取保证数据传输的安全性，边缘计算网元可以通过私有接口将业务类型反馈至基站。

在具体实现中，本领域技术人员可以根据实际需要设置业务的目的地址和业务的业务类型之间的对应关系，该对应关系可以预存在边缘计算网元中，边缘计算网元可以根据预存的该对应关系，得到UE发起的业务的目的地址对应的业务类型。

在一些实施例中，步骤101的实现方式可以为：当判定基站不具有边缘计算网元，对UE进行预调度；识别预调度的过程中UE发起的业务的业务特征；根据业务特征，建立UE发起的业务的业务类型。其中，预调度可以理解为基站发起主动探测模式对业务类型进行智能学习，在具体实现中，如果基站既不能通过SIM卡所绑定的业务标识信息识别得到UE的业务类型，也不能借助边缘计算网元识别得到UE发起的业务的业务类型，则说明UE的业务可能是基站未接触过的新的业务，则基站可以对UE进行预调度，即基站可以对UE主动发起探测模式，以对这一新的业务的业务类型进行智能学习。预调度的过程中UE发起的业务的业务特征可以包括：UE发送的数据包的大小、UE发送数据包的发送周期等。基站可以根据UE发送的数据包的大小和UE发送数据包的发送周期，建立UE发起的业务的业务类型。比如，如果UE发送的数据包非常大、发送周期长，可以确定UE发起的业务的业务类型为流量业务，建立流量业务的业务类型；如果UE发送的数据包很小、发送周期短，可以确定UE发起的业务可能是对时延要求非常高的业务，则可以建立低时延业务的业务类型。

在具体实现中，业务类型建立好之后，可以存储在基站和/或边缘计算网元中，后续有和该建立的业务类型匹配的业务上线后，可以直接识别出该业务的业务类型，而无需再次发起探测模式。可以理解的是，建立业务类型的过程可以理解为业务类型从无到有的过程，或者理解为业务类型的积累的过程。本实施例中，如果无法通过绑定SIM卡或通过业务目的地址的方式进行业务类型的识别，还可以通过基站发起主动探测模式，通过在一段周期内获取UE的业务的有效数据包大小、发送周期等特征，建立业务类型并记录，有利于得到新的业务类型，使得业务类型的识别并不完全依赖于已有的业务类型。

在一个例子中，对UE进行预调度的过程可以如下：基站根据预设的初始调度授权量，主动向UE下发资源；其中，主动向UE下发资源可以理解为基站在未收到UE发送的调度请求的情况下，向UE下发资源。如果在预调度期间，基站收到大量Padding包，可以确定基站向UE下发的资源不够，则基站可以在初始调度授权量的基础上增加调度授权量。当在预设时间段内都没有出现Padding包，可以认为当前的调度授权量与UE实际的业务需求匹配，此时，基站收到的UE发送的数据包可以作为有效数据包，基站可以记录有效数据包的大小及发送周期，并将记录的有效数据包的大小及发送周期作为预调度的过程中UE发起的业务的业务特征，然后根据记录的有效数据包的大小及发送周期，建立UE发起的业务的业务类型。预调度期间出现大量的Padding包的原因可能为：基站下发资源的周期与UE上发业务数据包的周期不匹配，比如，基站100ms发一次资源，UE10ms发一次数据；基站对UE的调度授权量与UE实际需要的资源量不匹配，比如，基站对UE的调度授权量较小，但UE实际需要的资源量较大。

在一个例子中，在对UE进行预调度的过程中，如果基站接收到UE发送的调度请求(Scheduling request，简称：SR)，则可以再次启动主动探测模式，即重新对UE进行预调度。

在一个例子中，基站是否要进行预调度以及进行预调度时需要使用的参数，可以由边缘计算网元决定，边缘计算网元可以通知基站需要进行预调度的消息，并向基站发送一些预调度期间可能会使用的参数。其中，预调度期间需要使用的参数比如可以为：发起预调度的时间点、预调度的初始调度授权量等。也就是说，建立新的业务类型的过程可以由基站和边缘计算网元配合完成。

在一个例子中，考虑到ToB用户和ToC用户的数量级差异，大量的ToC用户将会过量地消耗有限的资源。因此，如果无法通过绑定SIM卡或通过目的地址的方式进行业务类型识别，则对于ToC用户可以不发起主动探测模式，对ToB用户可以发起主动探测模式。其中，ToC用户可以理解为签约ToC切片的SIM卡所在的UE，类似的，ToB用户可以理解为签约ToB切片的SIM卡所在的UE。

在一些实施例中，步骤102的实现方式可以为：当在基站中能查询到与业务类型对应的业务保障参数，将查询到的业务保障参数确定为业务类型对应的业务保障参数。基站可以判断基站是否存储与UE的业务类型对应的业务保障参数，当判定基站中存储与UE的业务类型对应的业务保障参数，可以确定在基站中能查询到与业务类型对应的业务保障参数。

比如，基站中可以预存业务类型与业务保障参数之间的映射关系，通过该映射关系查询与UE的业务的业务类型对应的业务保障参数。在具体实现中，该映射关系还可以包括业务场景，不同业务场景下相同的业务类型也可能对应不同的业务保障参数，比如，园区A中的业务类型1与园区B中的业务类型1所对应的业务保障参数可能存在差异。可选的，映射关系可以根据实际需要在不同业务场景下对不同业务类型的业务进行学习得到，还可以由本领域技术人员根据实际需要预先设置。通过在基站中查询与业务类型对应的业务保障参数，使得可以无需借助其他网元，就能快速方便的得到需要的业务保障参数。

在一个例子中，对于通过SIM卡所绑定的业务标识信息识别业务类型的方式，当UE上线建立PDU承载后，基站可以根据获取的SIM卡签约的切片信息和5QI信息直接调用对应的业务保障参数。

在一些实施例中，步骤102的实现方式可以为：当判定基站具有边缘计算网元，判断边缘计算网元是否内置有业务类型对应的业务保障参数；当判定边缘计算网元内置有所述业务类型对应的业务保障参数，将边缘计算网元内置的业务类型对应的业务保障参数确定为业务类型对应的业务保障参数。通过将业务保障参数内置到MEC、NE等边缘计算网元，有利于降低基站的配置复杂度并适度节约资源，而且，边缘计算网元为相对独立的网元，可以实时配置和刷新业务保障参数，有利于更快适应可能发生变化的业务场景。

比如，MEC、NE等边缘计算网元可以预先内置有不同业务类型对应的业务保障参数，基站可以通过边缘计算网元得到UE的业务类型对应的业务保障参数。比如，边缘计算网元可以将内置的UE的业务类型对应的业务保障参数通过预设的私有接口发送给基站。

在一个例子中，对于通过MEC、NE等边缘计算网元识别业务类型的方式，业务类型被识别后将可以通过预设的私有接口被传递给对应的基站。这种业务类型的识别方式下，可以将业务保障参数内置到MEC、NE等边缘计算网元，降低基站的配置复杂度并适度节约资源，同时可以实时配置和刷新保障参数。

在一个例子中，考虑到大量基站可能无须承载ToB业务，而通常具有边缘计算网元的基站大部分都是为了承载ToB的业务，承载ToC的业务的基站不太可能用边缘计算网元。对于不需要承载ToB的业务的基站，内置业务保障参数配的用处不大，有时调用的时候甚至会耗费资源。因此，对于通过MEC、NE等边缘计算网元识别业务类型的基站，可以将业务保障参数内置到MEC、NE等边缘计算网元。

在一些实施例中，步骤102的实现方式可以为：对UE进行预调度；识别预调度的过程中UE发起的业务的业务特征；根据业务特征，建立UE发起的业务的业务类型；根据建立的业务类型，生成UE发起的业务的业务类型对应的业务保障参数。有利于得到新的业务类型对应的业务保障参数，使得业务保障参数的确定并不完全依赖于已有的业务保障参数。

其中，基站对UE进行预调度的过程可以理解为基站发起主动探测模式，基站发起主动探测模式建立业务类型的过程在上文已经描述过，为避免重复，此处不再赘述。基站根据建立的业务类型，可以生成UE发起的业务的业务类型对应的业务保障参数，发起主动探测模式所建立的业务类型可以理解为基站或边缘计算网元中未存储过的业务类型。基站可以参考基站或边缘计算网元中已经存储的业务类型对应的业务保障参数，生成新建立的业务类型对应的业务保障参数。比如，基站中可能存储有与新建立的业务类型类似的业务类型对应的业务保障参数，基站可以结合新建立的业务类型的业务特征和与该新建立的业务类型类似的业务类型的业务特征，对与该新建立的业务类型类似的业务类型的业务特征对应的业务保障参数进行调整，生成新建立的业务类型对应的业务保障参数。其中，类似的业务类型之间可能存在相似的业务特征，比如，发送的数据包的大小及发送周期接近，只是在具体数值上略微存在差异。在具体实现中，如果两个业务类型的业务特征之间的相似度大于预设相似度，可以认为两个业务类型类似；其中，预设相似度可以根据实际需要进行设置，本实施例对此不作具体限定。

在一个例子中，对于使用主动探测模式进行业务识别的方式，在该方式中可在一段时间内对UE开启预调度：在预调度期间启动一个业务识别实例，记录UE的有效数据的大小及数据发送周期。如果预调度的授权量不够，则加大预调度授权量；如果进行了业务识别并进行了业务保障后，UE又产生了SR，则可以再次启动主动探测模式；如果预调度期间出现了大量的Padding，可以在后续生效的保障参数中预调度授权量大小。当主动探测模式完成后，基站可以根据建立的业务类型生成一套建立的该业务类型对应的业务保障参数并在该UE在线的时间段内持续运用该业务保障参数。

在一个例子中，当MEC、NE等边缘计算网元内置有业务保障参数，基站可以将生成的业务保障参数后通过私有接口传递给MEC、NE等边缘计算网元，MEC、NE等边缘计算网元记录UE发起的该业务的目的地址、切片信息、业务保障参数等有用信息，等后续检测到属于该新建立的业务类型的业务上线后可以直接通知到对应的基站省略掉主动探测过程，直接得到MEC、NE等边缘计算网元记录的业务保障参数，从而进行业务保障。

在一些实施例中，识别业务类型的方式可以为：在UE接入基站后，基站先读取UE中的SIM卡所绑定的业务标识信息，当在基站中能查询到与业务标识信息对应的业务类型，将查询到的业务类型识别为UE的业务类型。当在基站中不能查询到与业务标识信息对应的业务类型，判断基站是否具有边缘计算网元，当判定基站具有边缘计算网元，接收边缘计算网元发送的UE的业务类型；其中，边缘计算网元基于UE发起的业务的目的地址识别出UE的业务类型。当判定基站不具有边缘计算网元，对UE进行预调度；识别预调度的过程中UE发起的业务的业务特征；根据业务特征，建立UE发起的业务的业务类型。也就是说，步骤101实现方式可以参考图2，包括：

步骤201：UE接入基站，建立PDU Session。

步骤202：基站读取SIM卡所绑定的业务标识信息；其中，业务标识信息比如可以为：切片信息+5QI信息。

步骤203：判断基站是否有SIM卡所绑定的切片信息+5QI信息这一组合配置；如果是，则执行步骤204，否则执行步骤205；其中，基站可以判断基站本身是否有SIM卡所绑定的切片信息+5QI信息这一组合配置。

步骤204：基站根据SIM卡所绑定的切片信息+5QI信息这一组合配置，确定对应的业务类型。

步骤205：判断基站是否具有对应的边缘计算网元；如果是，则执行步骤206，否则执行步骤208；其中，基站可以判断基站本身是否具有对应的边缘计算网元。

步骤206：UE开启业务，边缘计算网元识别UE开启的业务的目的地址。

步骤207：边缘计算网元根据目的地址，确定业务类型，并将业务类型反馈至基站。

步骤208：基站发起主动探测模式，记录主动探测期间的业务的有效数据大小、数据发送周期，建立起新的业务类型。

其中，建立的新的业务类型可以存储在基站和/或边缘计算网元中。

本实施例中，在进行业务类型的识别时，先根据SIM卡所绑定的业务标识信息进行业务类型的识别(识别方式1)，如果不能根据SIM卡所绑定的业务标识信息进行业务类型的识别，再借助边缘计算网元，基于业务的目的地址进行业务类型的识别(识别方式2)，如果不能借助边缘计算网元得到业务类型，再发起主动探测过程，从而完成业务类型的识别(识别方式3)。本实施例中提供了可选的3种业务识别的方式，且3种业务识别方式具有先后顺序，如果识别方式1可以识别出业务类型，则不会启动识别方式2和3，如果识别方式2可以识别出业务类型，则不会启动识别方式3，当识别方式1和2均未能识别出业务类型，才会启动识别方式3。基于这样的顺序进行业务类型的识别，主要是考虑到，根据SIM卡所绑定的业务标识信息进行业务类型的识别是相对最简单、最方便、最快速且无需借助其他边缘计算网元的识别方式。基于业务的目的地址进行业务类型的识别方式，需要借助边缘计算网元，发起主动探测过程难免需要耗费流量和资源。因此，基于本实施例中的识别顺序，有利于相对简单、快速、方便的对可能出现的各种业务类型进行全面的识别。

值得一提的是，本实施例中3种识别方式的执行顺序只是以类似图2中所表示的顺序为例，在具体实现中，3种识别方式的执行顺序并不以此为限。

在一些实施例中，识别业务类型后，确定业务类型对应的业务保障参数并根据业务保障参数进行业务保障的方式可以为：当在基站中能查询到与业务类型对应的业务保障参数，将查询到的业务保障参数确定为业务类型对应的业务保障参数。当在基站中不能查询到与业务类型对应的业务保障参数，判断基站是否具有边缘计算网元；当判定基站具有边缘计算网元，判断边缘计算网元是否内置有业务类型对应的业务保障参数；当判定边缘计算网元内置有业务类型对应的业务保障参数，将边缘计算网元内置的业务类型对应的业务保障参数确定为业务类型对应的业务保障参数。当判定边缘计算网元没有内置业务类型对应的业务保障参数，对UE进行预调度；识别预调度的过程中UE发起的业务的业务特征；根据业务特征，建立UE发起的业务的业务类型；根据建立的业务类型，生成UE发起的业务的业务类型对应的业务保障参数。也就是说，步骤102和步骤103的实现方式可以参考图3，包括：

步骤301：判断基站是否存储与UE的业务类型对应的业务保障参数；如果是，则执行步骤302，否则执行步骤303；其中，基站可以判断基站本身是否存储与UE的业务类型对应的业务保障参数。

步骤302：在基站中查找UE的业务类型对应的业务保障参数，并根据查找到的业务保障参数进行业务保障；其中，基站可以在基站中查找UE的业务类型对应的业务保障参数。

步骤303：判断基站是否具有对应的边缘计算网元；如果是，则执行步骤304，否则执行步骤306；其中，基站可以判断基站本身是否具有对应的边缘计算网元。

步骤304：判断边缘计算网元是否内置UE的业务类型对应的业务保障参数；如果是，则执行步骤305，否则执行步骤306；其中，基站可以判断基站本身对应的边缘计算网元是否内置UE的业务类型对应的业务保障参数，比如，边缘计算网元内置有UE的业务类型对应的业务保障参数时，边缘计算网元可以将业务保障参数发送给基站，从而基站可以判定判断边缘计算网元内置有UE的业务类型对应的业务保障参数。

步骤305：基站采用边缘计算网元内置的UE的业务类型对应的业务保障参数进行业务保障。

步骤306：基站发起主动探测模式。

步骤307：基站对UE发起预调度流程，启动业务识别实例。

步骤308：基站判断预调度授权量是否足够；如果是，则执行步骤310，否则执行步骤309。

步骤309：基站增加预调度授权量。

步骤310：基站判断是否产生SR；如果是，则执行步骤306，否则执行步骤311。

步骤311：基站记录业务的有效数据大小和数据发送周期。

步骤312：基站根据有效数据大小和数据发送周期，建立新的业务类型。

步骤313：基站根据新的业务类型，生成新的业务类型对应的业务保障参数，根据确定的该业务保障参数进行业务保障。

其中，新的业务类型对应的业务保障参数可以存储在基站和/或边缘计算网元中，形成新的业务类型与其对应的业务保障参数之间的映射关系，方便后续再次识别到该新的业务类型时，可以根据上述的映射关系得到对应的业务保障参数。

本实施例中，在确定业务保障参数时，先判断基站中是否内置UE的业务类型对应的业务保障参数，如果基站中内置有UE的业务类型对应的业务保障参数(确定业务保障参数的方式1)，直接利用基站中内置的业务保障参数进行业务保障。如果基站中未内置有UE的业务类型对应的业务保障参数，进一步判断基站是否具有对应的边缘计算网元，如果基站具有对应的边缘计算网元，则再判断边缘计算网元中是否内置有UE的业务类型对应的业务保障参数，如果边缘计算网元中内置有UE的业务类型对应的业务保障参数(确定业务保障参数的方式2)，则直接利用边缘计算网元中内置的业务保障参数进行业务保障。如果基站不具有对应的边缘计算网元，或者边缘计算网元中未内置有UE的业务类型对应的业务保障参数，则可以进一步通过发起主动探测过程，以得到UE的业务类型对应的业务保障参数(确定业务保障参数的方式3)，从而实现对UE的业务保障。

本实施例中，在业务类型识别成功后，提供了可选的3种确定业务保障参数的方式，且3种确定业务保障参数的方式具有先后顺序，如果确定业务保障参数的方式1可以确定出UE的业务类型对应的业务保障参数，则不会启动确定业务保障参数的方式2和3，如果确定业务保障参数的方式2可以确定出UE的业务类型对应的业务保障参数，则不会启动确定业务保障参数的方式3，当确定业务保障参数的方式1和2均未能确定出UE的业务类型对应的业务保障参数，才会启动确定业务保障参数的方式3。基于这样的顺序进行业务保障参数的确定，主要是考虑到，直接从基站中查询UE的业务类型对应的业务保障参数是相对最简单、最方便、最快速且无需借助其他边缘计算网元的方式。上述的确定业务保障参数的方式2，需要借助边缘计算网元，确定业务保障参数的方式3难免需要耗费流量和资源。因此，基于本实施例中的业务保障参数的确定顺序，有利于相对简单、快速、方便的确定出可能出现的各种业务类型对应的业务保障参数。

值得一提的是，本实施例中3种确定业务保障参数的方式的执行顺序只是以类似图3中所表示的顺序为例，在具体实现中，3种确定业务保障参数的方式的执行顺序并不以此为限。

本申请的实施例中，能够根据实际情况采用不同的识别方式对不同类型的业务进行识别，业务类型识别成功后则采用针对性的精准保障策略即采用与业务类型对应的业务保障参数进行业务保障，以针对性的进行资源分配，从而从而在不影响系统容量的情况下实现对不同业务的精准保障。

需要说明的是，本申请实施例中的上述各示例均为为方便理解进行的举例说明，并不对本发明的技术方案构成限定。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本申请实施例还提供了一种基站，如图4所示，包括至少一个处理器401；以及，与至少一个处理器401通信连接的存储器402；其中，存储器402存储有可被至少一个处理器401执行的指令，指令被至少一个处理器401执行，以使至少一个处理器401能够执行上述实施例中的业务处理方法。

其中，存储器402和处理器401采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器401和存储器402的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器401处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器401。

处理器401负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器402可以被用于存储处理器401在执行操作时所使用的数据。

本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。